Köszönöm
A 16-os láb RB6... Már csak az lenne a kérdésem hogy hogy ezekből melyik a PGD és PGC láb?

Ez egy erősítőbe van.Figyelő áramkörben...Ha Pickit2-vel nem megy akkor milyennel menne?

Valamilyen Eprom égetővel menne csak, mivel az adatokat nem sorosan, hanem 12 lábon keresztül kell kiolvasni és beírni.

Ooo...Na mindegy .. Akkor ezzel nem is próbálkozom....
Köszönöm az infót!!!

Sziasztok,

Azzal a problémával szerencsétlenkedek XC8-ban, hogy PIC16F877A-nál azt írja a fordító, hogy túl mély lesz a stack (11) gondolom a lehetséges 8 helyett. Valahogy be lehet állítani azt, hogy a fordító ne a hardveres stacket használja?

(Már szinte miden inline)

Kösz.

Sajnos nem lehet. Ez a figyelmeztetés akkor jön, ha a call - return stack mélysége meghaladja a maximális (midrange 8, advanced midrange 16, 18F 32) szintet. Egy 16F1xxx, 18F -re kellene áttérni, átírni az egész programot kevesebb szintet használó változatra.

Kösz a választ.

Igazából fordítva történt, nem tudok upgrade-elni merta cél éppen a downgrade lett volna. Van egy jó kis programom, amit 18F4520-ra írtam. Imit-amott kicsit módosítottam, szerettem volna, ha 16f877a-n futna, mert abból hever itthon négy is jóideje kihasználatlanul. Mmég éppen elfér benne a program, az adat stb. El is indul a program rendesen, csinál mindent, de időnként resetel. (Stack ower

Más PIC C fordító is így működik nem csak az XC?

Annyira nagyon nem értem, mert igazából a C-ben a függvények paraméterei is a stackre kerülnek nyilván az XC nem így fordít. De akkor miért nem lehetne a visszatérési címet is másképp tárolni???? A PC ha jól tudom közvetlenül is írható. Mindegy. A kérdés költői.

PIC16F877A-ben a visszatérési címeknek hardveres veremtára van. Ezt a fordító nem tudja megkerülni/befolyásolni. Úgy kell megírni a programot, hogy a maximális hívásmélység ne haladja meg a veremtár méretét!

Miért ne tudná megkerülni??? PC-t lehet írni direktben. Ha van egy fg hívás, azt a fordító úgy kódolhatná, hogy a függvény aktuális paramétereit ráteszi egy saját stack-re, majd ráteszi a hívás helye+1-et, majd a hívott címet PC-be tölti. Return-re leemeli a visszatérési címet, majd a SP-jét a paraméterek méretével csökkenti, majd az imént levett címet PC-be tölti.

Midrange PIC -eken a stack csak a PC -ből fogadja az adatot (call) és oda képes átadni (return, retlw, retfie). Adatként nem lehet beleírni ill. kiolvasni belőle.

Sziasztok!
Tanácsot szeretnék kérni.
Egy hőmérőt szeretnék, ami óránként mér hőfokot és az adatot eltárolja. Ezt mondjuk végzi 4 hónapig, majd amikor kérem, ezeket az adatokat valamilyen formában visszaadja nekem, hogy fel tudja használni a PC-ben.
A hőmérés megvan. Amit még sose csináltam az az, hogy hogyan is tároljak ilyen sok adatot, ilyen sokáig, és hogy juttassam ezeket az adatokat át a PC-be?
Csak ötletet szeretnék kérni, hogy merre induljak el, hogyan lehetne/kellene megvalósítani.
Pl kell e külön memória? Vagy csak simán a PIC memóriájában tároljam? Hogyan érdemes az adatokat a gépre tölteni? Soros, párhuzamos, vagy USB port?

Milyen PIC-el dolgozol? (érdemes olyat választani amiben van SPI és USB modul)
Érdemesebb használni külső memóriát amelybe a vett adatot letárolod és amikor kell akkor szépen kiküldöd USB-re az adatokat és számítógéppel pedig feldolgozod.

Csak egy gyors számolás:
Óránként 1 adat amely 1bájt mivel gondolom normál hőmérsékletet mérsz.
Egy nap 24 adat ezt szorozzuk átlag 30 nappal és négy hónappal, kijön mennyi bájtra lesz szükséged.
24x30x4 == 2 880 bájt
Ezt elosztod 1024-el és megkapod mennyi kilóbájtra lesz szükséged.
2880/1024 == 2.81kb
Vagy is a 4 hónapra bőven elég egy 4kb-os memória.

Ez csak egy gyors eszmefuttatás...

Te meg tudod kerülni, ha van elég programmemóriád: ha nem szubrutint használsz, hanem a legrövidebb és kevésszer használt rutinokat belefordítod, akkor jó lehet ( a szubrutin csak a memóriafogyasztást csökkenti ) thumbup:!

Uraim, elméletben ti hogyan állapítanátok meg egy memóriáról, hogy az mekkora?
Mondjuk bájtban.
Úgy vettem észre, hogy alap állapotban egy üres memória 0xFF-eket tartalmaz minden bájtján..
Én arra gondolok, hogy be kellene járni és ellenőrizni, de az a bajom ezzel a dologgal, hogy nem tudom milyen feltétel alapján járjam be és meddig pörögjön a ciklus.
Szóval vegyünk egy (128kb-os) memóriát amelyről nem tudjuk mekkora, hogy vizsgáljam meg a méretét?
Előre is köszi...

Hát persze! Sem POP sem PUSH. De kit érdekel a hardver 8 vagy esetleg 2(!) mélységű stack-je, amikor a PC közvetlenül írható??? A fordítónak el kellene felejtenie a hw saját pici stackját, mint írtam, és modelleznie egy sajátot a memóriában. Max a megszakításoknak kellene menni az eredeti hw stack-al.

Ha van egy függvény, hogy: char myfuggveny( char a, char b) és a kódban ez történik:

x = myfuggveny( A, B ) ;

akkor azt erre fordítaná:



A hívott fg. a paramétereit ott találja a szoftveres stack-en. Elérni őket az SP ill. az SP-1 címen tudja.

A fg. így térhet vissza, ha "ret" a függvény visszatérési értéke



Az már tényleg hatlövetű lenne, ha myPop, myPus, SP-- és SP++ egy-egy függvényként a user implementálhatná. (Persze ezekben nem lehet függvényhívás). Akkor az ember, ahova akarja, oda teszi a stac-ket.

Ennek a megoldásnak elég sok előnye van. Pl. nem kell foglalkozni a paraméterek által átadott hely külön, megfelelő időben történő felszabadításával. Különben a függvények lokális paraméterei is a stack-en szoktak létrejönni.

Tejesen igazad van. De ezzel olyan mértékben destruktúrálnám a kódot, hogy aztán programozó legyen a talpán, aki pl. egy hibát megtalál, kijavít. Arról nem is szólva, hogy ha 3 helyről hívsz meg valamit, akkor módosítás, javítás stb esetén 3 helyen kell javítanod. (A negyediket meg tuti elfelejted.

Az "inline" módosító pont ezt csinálná elvileg. Vagyis az inline-ként jelölt függvényt a fordító fordításkor elvileg beleilleszti a hívás helyére. Próbáltam, nekem nem úgy tűnt, mintha bármit változtatna.

Persze XC free verziót használok, lehet, hogy a PRO esetében más a helyzet, de arra sajna nincs pénzem, azt meg nem tudom ingyen honnan szerezhető be.

Valami ilyesmi?

Ezt nem igazán értem.
C-ben programozok, és nem tudom mi a := jelek együttes jelentése.
És az 1 := TRUE sor számomra érthetetlen mivel ilyet én a C-ben nem használhatok.

Itt igazából nem egy tömb méretét akarom megtudni, hanem egy külső memória IC méretét.
Szóval vagy nem tudom jól értelmezni amit írtál vagy nem arra gondolsz amire én.

Használj pl. macro-t (én asm-ben használom, de biztos van lehetőség C-ben is! ), akkor mindenhol javul ( a 16F877-nél inkább a lapozásra kell figyelni !)!


Ezt hol olvastad? Szerinted akkor miért kellene a PCLATH-al, meg a PCL-lel külön foglalkozni? Ha lehetne ilyet, akkor már régen ezt használnák a programozók, nem erőlködnének ezekkel az emlegetett dolgokkal! Sajnos, a hardver olyan, hogy csak a veremből tud megfelelő bitszámot betölteni a PC-be, különben nem foglalkozik a PCLATH-al és így nem írja a teljes PC-t, az meg csak 256 rekeszes lapot/területet jelent!

l {kis L betű}= TRUE
A ":=" a Pascalban használt formája az értékadásnak.

Ohh azt hittem 1-es ... akkor ezt benéztem.
És akkor az értékadás is érthető.
Akkor marad ez: "mem[ size ]"

A memória mérete ismeretlen.
Léptetéssel ki kellene szűrnöm a memória végét valahogy úgy, hogy a végéig növelek egy változót.
Ez eddig oké.
De mivel a memóriában lehet adat így nehéz megalapítani, hogy a vett adat az valós vagy nem.
Tehát valahogy a kommunikációval lehetne meghatározni, hogy hol a memória vége.
SPI-vel kezeld memóriáról van szó.
Tehát valahol ahol a SSPBUF regiszterbe nem kerül adat vagy már maga a memória cím amire lépne és olvasná az abban tárolt adatot, hibás vagy nincs akkor van vége elvileg a memóriának.
Szóval itt inkább valami olyasmi kellene ami figyelné, hogy az a cím létezik e még a memóriában amire éppen lépne a ciklus és ha igen akkor növeli a változót ha nem akkor megszakad a ciklus és a változóban van a memória mérete bájtban.
Vélemény az eszmefuttatásomról?

Köszönöm a válszt. Sajnos nem használtam még usb picket, sem spi-t,e utóbbit nem is tudom mi az, de mindjart utána járok.
Van esetleg tipped, milyen pic az ami jó lenne nekem? Ami olcsó is. Csak azért kérdezem, hogy mi alapjan keressem ...

Nézd, meg a 18F4550-és Pic-et.
Sok info van róla és van magyar leírás is, mind SPI, mind USB kapcsán.

Köszönöm szépen a segítséget!

A midrange (16F) architectúrát jobban áttanulmányoza a Te megoldásod több problémát vet fel, mint amit megold. Az adat memória bankokra, a program memória lap -okra van osztva. Összesen 16 byte memória érhető el a bankváltástól függetlenül, de pl. a 16F873 -on nincs is ilyen memória. A PC persze írható: előbb a PCLATH -et kell beállítani, majd ítható a PC alsó 8 bitje movwf PCL vagy az alsó 12 bitje goto x. Ekkor azonban a vezérlés már át is adódik az új címre.
A fordítók a midrange kontrollerekhez a függvény paramétereit nem szotfver stackre, hanem a közös memória területén memória rekeszekbe helyezik el.
Megoldások:
- Használod a 18F5420 -at, Rövid, gyors megoldás.
- Áttérsz advanced midrange -re.
- Megpróbálod az egymásba ágyazott eljárások számát csökkenteni. Nézd át mit fordít a fordító, elemezd a hívási láncot. (map állomány). A legmélyebb szinten kezd. A megszakítás egy szintet elhasznál. A kiszolgáló rutinból ne hívj eljárást.

Most teljesen megkevertél.
Ezt most vagy nem nekem akartad írni, vagy nem értem a leírtakban a PC és a Memória összefüggését.
Vagy esetleg elsiklottál egy pár előző bejegyzésen amiben a lényeg volt.

Ha nekem akartad, akkor én csak egy ismeretlen méretű, memória kapacitását szeretném valahogy megtudni C nyelven. (pl egy 128kb-os memóriáét ami SPI-vel van csatolva a PIC-hez)

Ha djadji-nak nyújtott eszmefuttatásomra reagáltál, akkor abba nem tudok beleszólni mert ennyire mélyen nem vagyok benne és alig értek pár szót abból amit beírt..
De véleményem szerint, ha az adatokat elmenti egy külső memóriába és ír egy rutint amivel PC-re ki tudja küldeni a már elmentett adatokat akkor szerintem fel fogja tudni használni.
Nem hiszem, hogy itt ennyire problémás lenne az, hogy mennyi adat van, mivel ezek küldését akár megoldhatja bájtonként is.
Lehet kicsivel több ideig tart, de a lényegen nem változtat.
Az SPI-t meg azért ajánlottam mert jelen esetben talán ez a leggyorsabb módja a kommunikációnak.

djadji: Memóriában a 25LCxxx családot ajánlom. 1kb-tól 1MB-ig választható méretben és ügye SPI-s.
PIC-nek azért a 18F4550-et mert kezdőnek ez a legjobb PIC amit választhat főként azért mert van hozzá sok magyar dokumentáció és segédlet.
PICCOLO SPI memória kezelés
PIC18F4550 kísérleti áramkör
USB használata

De ajánlom az egész oldalt vagy is az oldalon leírtakat áttanulmányozni.

Hát nem tudom milyen fordítót, nyelvet használsz, azért egy általános kódot írtam, nem egy konkrét nyelvre valót.

- a := az értékadás szokott lenni, úgy mint "legyen egyenlő" nem csak pascalban, a nyelvek többségében.
- mivel nem tudom milyen memóriáról van szó "mem[x]" -ként jelöltem a memória x címén lévő adatra való hivatkozás általában. Hogy az egy tömb, vagy fél tucat utasítást tartalmazó kód, szóval konkrétan hogy éred konkrétan a memóriát...ahogy jól esik.
- a ciklus végén (és közben is) size tartalmazza az éppen vizsgált memóriacímet, hogy az létezik-e.
- a vizsgálat abból áll, hogy kiolvassuk az adott címről az értéket, majd megpróbálunk oda valami mást beírni. Jelen esetben a kiolvasott érték+1-et. Újra kiolvassuk, hogy ellenőrizzük, hogy a "valami mást" (az 1-el növelt érték) kapjuk-e vissza. Ha igen, akkor nyilván létezik a cím és akkor visszaírjuk az eredeti kiolvasott értéket, hogy el ne rontsuk a tartalmat. Ha nem, akkor a ciklusnak vége és size tartalmazza, hogy hányszor voltunk sikeresek, vagyis a memória mekkora.

Nem futtatható a program saját memóriájára, mert persze magát is felülírná

Nem vagyok benne biztos. Mi a több? Hogy a fordítónak kicsit bonyolultabban kell kódolnia a függvényhívásokat, (egy idő után!) vagy az hogy széttárja a karját: bocs van ugyan még memória, de 8-nál struktúráltabb programot nem vagyok hajlandó működőképesre fordítani ezen az eszközön??



Ki a csudát érdekel! Azért használok magas szintű nyelvet, hogy ilyesmivel ne kelljen foglalkoznom. Majd ha akarok vele foglalkozni, kódolok ASM-ban. Vagy gépi kódban.



Nem ellenőriztem, de a lokális változókat, ha nem stackre teszi a fordító, akkor szégyelheti magát nagyon. Illetve nem is igen tudom elképzelni, hogy hogyan másképp csinálhatná! Csak nem lefoglalva tartja a memóriarekeszt egy változónak, amikor már kiszálltam abból a függvényből ahol az lokális volt?? Remélem nem. Én a stacken kívűl a lokális változók kezelésére más megoldást nem igen tudok. Szerintem nincs is.



Igen, igazad van, de az egész kérdés lényege az volt, hogy az elfekvő 877-est használnám. Hát persze, hogy egy nagyobb, drágább processzor megoldja a kérdést. Ahogy egy okosabb fordító is megoldaná.


Magyarán destruktúráljam. Persze, ez sok mindent megoldhat. Mint a goto, de azt azért azt sem írnám le egy C kódban.


Ezt nem értem. Mit jelent?

Hiába hadakozol a meglevő korlátokkal. Mi nem tudunk segíteni a feloldásukban. Annyit tudunk csak mondani, hogyan csinálja a Hitech / XC8 fordító. Ha tudsz jobbat, ír egy fordítót - segítünk tesztelni. Tapasztalataim szerint az XC8 pro módban is jelentősen hosszabb kódot fordít, mintha megírnám assemby -ben. Tehát van bőven lehetőség...

Megérné megnézni: View / Disassamby. A midrange csak egy FSR -rel rendelkezik, amit nem tud még offset -tel sem címezni, sőt literális címet is csak a W regiszteren keresztül lehet az FSR -re tölteni. A ram bankok max. 80 memória rekeszt tartalmaznak egybefüggő címzési lehetőséggel. Igen terjengős, lassú kód lenne a lokális változók stack -en történő kezelése. Emiatt a fordító által használt megoldások eltérnek a PC -n és más kontrollereken (I8051 - 8031) vagy CPU -kon (I8080, Z80, stb) alkalmazott megoldásoktól.
Amikor a Midrange architektúra terve készült (16C83, 16C84 - úgy 1993 táján az EEProm program memória is nagy teljesítmény volt) még fel sem merült, hogy valamikor C fordítót is fognak használni a programjuk fejlesztésére.

A megszakítás elvisz egy szintet a HW stackról. Ha a megszakítás kiszolgáló rutinból eljárásokat hívsz, további szinteket veszel el a stack -ról. Pl. A fő program a 6. szinten jár, megjön a megszkítás - a 7. szintre, ha egy eljárást hívsz belőle, az az utolsó szintet is felhasználja. Tehát a fő programnak csak 6 jut. Ha a megszakítás kiszolgáló rutin több egymásba skatujázott eljárást hív, a kihasználható szint tovább csökken.

Birs Alma: Bocsánat, hogy beleszólok, de ezzel a sok írással pl. EEPROM esetén fölöslegesen csökkentjük az élettartamát, mivel azon csak egy bizonyos számú írást végezhetünk.
Az viszont kétségtelen, hogy ez a legjobb megoldás

don_peter: Ha tudod, hogy mekkora az a memória akkor miért kell megmérni?
Ha a memóriafoglaltságot akarod lemérni (hogy mennyire van tele adatokkal) akkor az más, akkor nem szóltam semmit...