Fórum témák
» Több friss téma |
Próbáltam azt is szintaktikai hibát jelez a fordító.
SFR szimbólikus név alatt mit értesz? pl EECON2? Sajnos érthetetlen okokból nem akart működni: lásd előző hozzászólások
A (code) és (/code) tag-ek közé kell tenni a beidézett kódot, de a code-nál meg kell adni, hogy asm vagy c forrásként formázza-e: (code=asm) vagy (code=c). Természetesen szögletes zárójelek kellenek, nem kerekek.
Esetleg "ACCESS" helyett csak "A"-t írva? Igen, arra gondolok, hogy valamilyen formában az EECON2 jelenjen meg ott és ne a 0xA7.
Megfogadtam Potyo tanácsát, és váltottam Microchip C18-ra...és elsőre sikerült működő kódot írni!
Köszi Szilva!: egyből ki is próbáltam  Ennek ellenére nem hagy nyugodni a hi-tech-es dolog, szóval az "A"-it is kipróbáltam: ugyanúgy syntax error... :no:
Ez mostmár annyira érdekel, hogy mondd már el privátban, honnan lehetne ezt a fordítót beszerezni. Nekem csak a 16F-hez való van meg.
A 0xFA7-ből A7 onnan ered, hogy a MOVWF utasítás mellett csak nyolc bit van a memória címzésére előlátva, ezért a 0xFA7-ből csak az alsó nyolc bit fér bele, tehát a 0xA7. Mivel nem írtad mellé, hogy az ACCESS vagy a BANKED RAM-ot célzod az utasítással, ezért az alapértelmezettet, vagyis a BANKED memóriát célozta, tehát az EECON2-vel nem csinált semmit. Amikor kiírod, hogy EECON2, akkor abból tudja, hogy az ACCESS ramot kell céloznia, ezért azzal csinálhat valamit. Az meg, hogy a gyári makró nem képes egymásután tenni a kódban a két EECON2-be történő írást, az számomra elég lenne arra, hogy ne is kisérletezzek tovább ezzel a fordítóval... A PIC nem PC, itt sokkal kötöttebb szabályok vannak, mint a PC-nél. A PIC sokkal inkább elektronikai áramkör, és csak nagyon kismértékben számítógép. Nem is tudom, hogy honnan jött nekem az a Hi-tech dolog, talán még pár évvel ezelőtt amikor elkezdtem ezekkel a dolgokkal egy kicsit babrálni. Aztán sokáig nem is foglalkoztam vele, most újra elővettem: Hi-tech fordító Ingyenes változat letölthető többfajta eszközhöz. Van professzionális is, állításuk szeint az gyorsabb és jobban optimalizált kódot készít, de jelentős különbség nincs. (csak annyi, hogy lehet, hogy ott működne az eepromba írás )  Ok, azt hiszem meg vagyok győzve: marad a Microchip fordítója; mégiscsak ő ismeri legjobban a saját termékét, vagy mi... Idézet: „mondd már el privátban, honnan lehetne ezt a fordítót beszerezni” Mármint a Hitech C fordítót? innen Az ún. Lite módja ingyenes, ami a C18 student verzióhoz hhasonlóan korlátozottan optimalizál.
Azt hittem, nem az ingyenes verzió van neki, azért kérdeztem...
Idézet: „Ok, azt hiszem meg vagyok győzve: marad a Microchip fordítója; mégiscsak ő ismeri legjobban a saját termékét, vagy mi...” Noha ez igaz, azt is figyelembe kell venni, hogy a Microchip chipek gyartasaval foglalkozik. Szoftverek gyartasahoz nem ert igazan es ez meg is mutatkozik minden teren. Sot, megkockaztatom, hogy meg a peldak, appnote-ok stb sem igazan kielegitok minden esetben, nem beszelve az USB framework-rol. HiTech forditoit az egyik legjobbkent szoktak emlegetni, talan utana jon a ByteCraft. A Microchip C18-nak amugy az egyik nagy hatranya, hogy nem tudja automatan kialakitani a pseudo-stack-et. Ok erre az overlay kifejezest hasznaljak es sok esetben eleg nehez manualisan kibogozni mi mehet overlay tarolasi osztalyba es mi auto-ba. Ezeket HiTech es ByteCraft teljesen automatan lekezeli, de mas eleg jo optimalizalasi technologiat is hasznalnak ami nincs ennyire kiforrva az MC18-ban.
Közben feldobtam a témát a Hitech oldalára is.
Megszületett a végleges, immár tényleg működő megoldás. Az asm szakaszban MOVWF 0xFA7, c formulát kell alkalmazni, hogy helyesen forduljon a cím. Megoldások: Hi-Tech módra (itt sem a beépített macro, sem a beépített függvény nem működött, ezért készült saját függvény):
Microchip C esetén megy a beépített függvény:
Egy moderátor bekertezné ezt a hozzászólást, hogy később, ha keresgél vki, akkor a megoldás összegyűjtve ki legyen emelve? Idézet: „Sot, megkockaztatom, hogy meg a peldak, appnote-ok stb sem igazan kielegitok minden esetben, nem beszelve az USB framework-rol.” Idézet: „HiTech forditoit az egyik legjobbkent szoktak emlegetni” Egyetértek(annak szokták emlegetni), annak ellenére, hogy ez az eeprom-os probléma jól rácáfol a véleményedre.
Feldobom tárgyalásra, hogy mi van akkor, ha a 21. sorban nem teljesül a feltétel hiba miatt(nem néztem még, hogy a C18 hogyan oldja meg a beépített függvényében...)?
A másik felvetésem, hogy a 25. sorban nem lenne elég egy INTCONbits.GIE = gie; ? Gyorsabban lefut és a gie már tartalmazza a megfelelő állapotot.
A pontos körülményeket nem lenne rossz ismerni. Tegnap ugyanis tettem egy kísérletet, letöltöttem a Hi-tech PICC18 Pro fordítóját, és megnéztem a generált kódot lite majd 45 napra aktivált full módban is.
Lite módban használva elvileg minden optimalizáció kikapcsolása mellett korlátlan méretű kódot lehet vele gyártani. Erősen kétséges azonban, hogy így használható lenne valamire is, mivel az asm kódban minden utasítás után 2 teljesen feleleges MOVLB volt, valamint időnként még szerintem oda nem illő MOVLW-k is. Nem véletlen tehát, hogy figyelmeztet is a fordító: a teljes verziónál sokszor hosszabb és lassabb az így kapott kód. Ha esetleg ilyen módban próbálsz meg C utasításokkal EEPROM-ot írni, az biztos nem lesz jó, kizárt dolog, hogy a 0x55-0xAA szevkencia megfelelő időzítéssel kiküldésre kerüljön. Teljes üzemmódban az egyszerű main-emet, amiben csak nem használt változókkal csináltam ezt-azt, úgy kioptimalizálta, hogy mindössze egy önmagára ugró GOTO maradt belőle (while(1){} -ben voltak az amúgy értelmetlen, számolásos műveletek). Igaz, EEPROM-os kódot nem próbáltam így generálni vele, de lenne esélye, hogy ilyenkor akár C utasításokkal is megfelelő lenne a szekvencia.
Létezhet olyan, hogy nem esik vissza az a bit nullára? Ha igen, akkor az elég gáz, akkor valami timeoutot be kellene építeni.
Ha jól emlékszem, van egy WRERR bit valamelyik regiszterben, ha hiba történik, akkor talán annak kellene jeleznie, de a WR-nek szerintem illene visszaállnia 0-ra a beépített időzítés leketyegése után. De ezt most nem az adatlap alapján mondom, azt el kellene olvasni, de most nincs előttem.
Teljesen jogos az észrevételed a végtelen ciklus miatt.
Én két megoldást tudok elképzelni: -Talán a könyebb megoldás, hogy a ciklus belsejében egy int-et inkrementálunk és a ciklusfeltételben kilpésnek számít az írás befejezése, vagy a változó maxint-té válása. Következő utasításban vizsgálandó a változó, amely ha maxint, akkor hiba volt és false-al visszatérünk (persze ekkor nem void lesz a fgv) ellenkező esetben folytatódhat a program. -Csinálunk egy globális bit változót pl error néven, amely alapesetben 0. while előtt indítunk egy timert, melynek lejárása bebillenti error-t 1. ciklusfeltétel szintén változik az error változót is elevéve. A while után, ha error==1, akkor visszatértünk hibával, egybként folytatódhat a függvény. A GIE-es dolgot én is eredetileg úgy írtam, ahogyan te említed, vki javasolta, h írjam át, amikor még nem ment progi, azóta meg így maradt  De tényleg egyszerüsíthető!
Oops tényleg!
Hiszen az elején, amikor nem ment a progi (mert rossz volt az előírt asm seq), akkor mindig kilépett a kérdéses while-ból és bebillent a WRERR. Szóval előző hozáaszólásom csak annyiban módosul, hogy nem kell timer sem és glob.változó sem, viszont a fgvnek nem void kell és a while után figyelni kell WRERR-t és annak fügvényében esetleg hibával visszatérni!
Csak halkan jegyzem meg, hogy voltak olyan PIC-ek, ahol gond volt az EEPROM irasaval - ha jol emlekszem egy mid-range szeria volt, ill az osszes olyan mid-range ami ugyanarra az eeprom modulra epitkezett rendelkezett a problemaval.
Annak az volt a kovetkezmenye, hogy az iras inditasa utan azonnal ugy erzekelte az iras befejezodott mar. Namost mikor tobb adatot is akart az emberke kiirni akkor emiatt a kiiras sikertelen lett. A megoldas valami jatek volt a sleep korul, most pontosan nem ugrik be mi is volt - ill. a masik megoldas mikor az ember besaccolta, hogy kell neki 5-10ms es kenyszer varakozassal, a bit figyelese nelkul irta ki a cuccot. Idézet: „Ha igen, akkor az elég gáz, akkor valami timeoutot be kellene építeni.” Pontosan ilyenekre valo a WDT Teszt rendszerben a resetre ra lehet aggatni debug LED-eket, amik meg azt is jelzik miert tortent reset. Tehat EEPROM irasa elott beallit a paciens egy belso flag-et, hogy milyen kritikus muvelet kovetkezik, es WDT reset eseten a megfelelo LED kodot kivilagitja igy azonnal diagnosztizalhato miert tortent a WDT. Elesben pedig a hiba kivedesere kivalo. Nyilvan nem arra kell hasznalni, hogy uzemszeruen igy mukodjon, de ilyen jellegu problemakat eleg jol lehet ezzel diagnosztizalni ill. elesben az eszkozt mukodo allapotban tartani anelkul, hogy barmifele overhead-je legyen az alkalmazasunknak.
WRERR-el kapcsolatban neked is és szilvának is igaza van! De figyelni érdemes szerintem. A gyári rutint megnézem majd, mert kíváncsi vagyok hogy oldják meg a nagyok!
Ilyen PIC-el nem hozott össze a jó sors, de ezt is elteszem a hasznos infók közé a polcra!
Amúgy most csináltam 12F683-ra ilyen mérést, hogy valós körülmények között maximum meddig tart egy rutin lefutása. Ez az eeprom-ba írja be az időtartamot, és simán elsőre megy. Csak azért említem, mert a Hi-Tech fordítóval csináltam. Bár azthiszem, ez nem az ingyenes verzió, ezért megyek is a sarokba, és legközelebb SDCC-vel csinálok ilyesmit.
Én ma délben olvasgattam a Hi-tech PICC18 user manualját. Abban egyértelműen van hivatkorás arra, hogy az EEPROM-ot EEPROM_WRITE és EEPROM_READ makrókkal kell kezelni. Megnéztem, a PICC doksiban még a kisbetűs, eeprom_write és eeprom_read függvényeket is emlegeti, a 18-as verzióban nem.
Ennek ellenére a kis próbaprogramomba (18F4550 CPU-t kiválasztva) beírtam kis- és nagybetűvel is, megnéztem, mit fordít belőle (ez a 45 napos, teljes értékű PICC18). A függvényes verzió úgy került bele a lefordított kódba, hogy paraméterfeltöltés után hív egy rutint, amiben a nagybetűs makró van kifejtve. A makró pedig inline belekerül fordításkor a kódba, nincs call. Az EEPROM írását engedélyező szekvencia mindkét helyen tökéletesnek látszik (igazi CPU-val itt nem tudom kipróbálni). Most már csak arra nem emlékszem, hogy miért is nem volt jó a gyárilag beépített módszer?
Most próbáltam ki a Lite verzióval a cuccomat, és ezt kaptam a gyári illetve kézi módszerre (természetesen az EEPROM-ba nem kerül bele semmi).
És még ezt odaírja a Build ablakba: Running this compiler in PRO mode, with Omniscient Code Generation enabled, produces code which is typically 52% smaller than in Lite mode. Hát ha csak kihagyja a szemetet, már akkor harmadára esik legalább a kódméret...
Sziasztok!
Nem tudom hol tart a project, megosztom az én ilyen irányú tapasztalatom, hátha segítek vele: Én egy 16F pic memoriáját írogattam, a FLASH-t.. ott tároltam némi infot.. a problémám ugyan ez volt, majd az adatlap (a PIC) tüzetes áttekintése után, rájöttem, hogy a memoriába 1 szót nem lehet írni, csak egy bizonyos mennyiséget, nálam pl minimum 8 szót lehet csak égetni! Javaslom nézd meg az erre vonatkozó részt az adatlapban!
A probléma azóta megoldódott, mert mint kiderült, az ingyenes fordító tesz be mindenféleképpen plusz utasításokat, amik miatt az adatlapban megadott utasítások nem futnak le egymás után, és így nem íródik be az adat az eepromba.
Most nem kötözködésképpen, de ha én akarok valamit csinálni, akkor azzal kezdem, hogy elolvasom az arra vonatkozó részt az adatlapban. Flash írást még sosem csináltam, de erre emlékszem, hogy olvastam, hogy egyszerre több szót muszáj írni.
Sziasztok!
Pickit 2-vel szeretnék egy 8lábú epromot égetni(24lc256-ot). Légyszi aki ért hozzá segítsen nekem,hogy a csatolt rajzon lévő összekötés megfelelő-e. Előre is köszönöm! robbbb
A PICkit2 README.TX állományt kell megnézni. Eszerint pedig nem jó, mert nem a 4,5 hanem az 5,6 lábakat kell használni.
Sziasztok!
Kicsit Off lennék, de megpróbálok témánál maradni, Tudna-e nekem valaki készíteni egy eprom égetőt? Persze nem ingyen kérem! Valami olyan kellene ami a proszesszortól független, mert én mint "láma" csináltattam egy jdm-et de meg se nyikkan! Előre is köszi a segítségetekért! emailem:rakos@koosk-misk.sulinet.hu
Ezzel az égetővel is próbálkozhatsz, vagy keresd meg Szilva fórumtársunkat, ha PICkit2 klónt szeretnél!
|
Bejelentkezés
Hirdetés |
