Fórumok
Itt szívok fél napja!
mpasm - ez ingyenes, de sok hibája van
000009C3 00045 PERIOD_3 equ P_25600
020D 3009 00048 movlw high PERIOD_3
gpasm - ez free és javítja az mpasm hibáit
000009C3 00045 PERIOD_3 equ P_25600
020D 3089 00048 movlw high PERIOD_3
Most jön az abakusz programozói tanfolyam. :(
Hozzászólások
Nem teljesen világos, hogy mit szeretnél.
Természetesen vágyom a világbékére!
Meg szeretnék egy jól működő, szarvashibáktól mentes fordítóprogramot.
Persze nem feltétlenül ebben a sorrendben - ahogy Woody Allen is mondaná.
A nyugodt élet egyik titka, hogy kerülöd azon cégek termékeit amiben szerepel a "micro" szó.
Lássuk csak:
Milyen gpasm változattal próbáltad?
Természetesen azzal, amit küldtél. :)
A P18 platformon jól működik, ez meg P16.
Ennek persze nem lenne szabad ettől függenie.
Furcsa. Direkt az ősrégi PIC16F84-el próbáltam és azt az eredmény produkálta amit a válaszomban látsz. Minden svn commit előtt tesztelem a programokat és nem teszek közzé olyat ami hibát vét.
A gputils jelenleg itt tart:
gputils-20140915-1101-setup.exe
gputils-src-20140915-1101.tar.gz
3089 :(
Tényleg furcsa. Még tovább megyek: PIC16F1789 a próbálkozás tárgya.
Az előző PIC18F2550 volt. Az előbbi következetesen téveszt, az utóbbi meg jó.
Az equ, high, low, +, -, stb. csak "számológép". Ha bármilyen függősége van a high
direktívának, akkor most kellene eltávolítani.
Nálam jó:
---------------------------------------------
Ennek utána kell járni. Nálam Fedora 20 x86_64 fut. Te milyen rendszeren és milyen programmal kisérleteztél? (gpasm -v)
A P_25600 értéke hogyan áll elő?
Esetleg így?
movlw PERIOD_3 >> 8 & 0xff
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Akkor nem áll elő a hiba ha előbb object kódot fordítasz és a gplink készíti el a hex-et. Ha viszont egyetlen modulból áll a program és a gpasm önállóan készít hex-et akkor azonnal előjön a hiba:
-------------------------------------------
Ez bizony hiba a fordítóban, nekiállok megkeresni. Úgy látszik hogy az eddig használt tesztek "lyukasak". Csodálom hogy eddig még senki sem jelezte.
Addig is áthidaló javaslatként azt ajánlom hogy a gpasm-al készíttess object kódot és a gplink segítségével állítsd elő a kész - hex - kódot.
Ezek szerint workaround, amit írtam, bár épp a lényeg vész el, a kód olvashatósága. Esetleg azt lehet tenni, hogy kommentbe odaírni a jól olvasható kódrészt.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Gondolom, olyasmi lesz a hiba, hogy jobbra rotálással csinálja a számítást, de előtte nem törli az átvitel flag-et, vagy valami hasonló. Vagy a végén nincs maszkolás.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Egy régebbi kódrészlet okozta a hibát és csak a fejlettebb 14 bites PIC családban, akkor is csak abszolút módban (tehát amikor a gpasm közvetlenül készít hex-et). Már kijavítottam és most tesztelem. Csak azon csodálkozom hogy ez eddig senkinek sem szúrt szemet. Nem volt bugreport. Ami azt jelenti hogy legalább egy éve így van. (Most nincs kedvem megnézni hogy melyik elődöm módosította ezt a részt utoljára.)
-------------------------------------
Itt van a gyógyszer:
gputils-src-20140926-1102.tar.gz
gputils-20140926-1102-setup.exe
Patch érdekelt volna, hogy látszódjék a hiba.
Hogyan fognak értesülni a disztribútorok erről? A fedorás csomagot te tartod karban? Egyelőre a Koji buildszerveren nem látom, hogy lefordították volna.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
"Patch érdekelt volna, hogy látszódjék a hiba."
Ez a lényeg, tessék. (Még a megjegyzés is hibás volt: "if var type is GVT_CBLOCK return 1, else return 0")
"Hogyan fognak értesülni a disztribútorok erről?"
Úgy hogy egyszer majd (remélem hogy nem sokára) kiadok egy végleges csomagot gputils-1.4.0 néven. A mostani (svn #1102) még csak egy fejlesztői változat. Amúgy érdemes lenne megnézned hogy egyes disztribúciók - élen a Debiannal - milyen elképesztően le vannak maradva. A Debian még mindig a gputils-0.13.7-1 változatnál tart. Nevetséges. Az Ubuntu sem különb.
"A fedorás csomagot te tartod karban?"
A gputils csomag karbantartója a Fedora package db szerint "rrankin". A név alapján gyanakszom arra hogy Roy Rankin lehet, mivel a gpsim csomag egyik fejlesztőjének levélcíme a ChangeLog alapján: Roy Rankin <rrankin@ihug.com.au>
Eszerint a Fedora 21 előzetesben a gputils-1.3.0 van benne, ez az amit tavasszal adtam ki.
Én itt szoktam megnézni, a build szerverről szerzem be, ha valami az update előtt kell.
return ((var->type == GVT_ADDRESS) ? true : false)
helyett nem egyszerűbb a
return (var->type == GVT_ADDRESS)
forma?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Egy beágyazott (ARM) fejlesztés alkalmával jöttem rá hogy egy "return (valami0 == valami1);" nem feltétlenül azt csinálja amit szeretnék. Csak akkor volt jó ha így írtam le: "return ((valami0 == valami1) ? true : false);" (A true természetesen 1, a false pedig 0, a függvény pedig egészet (int) ad vissza.) Azóta rászoktam erre az írásmódra.
Köszi a gyors javítást!
Azért egyet nem értek. A high operátor, ezért platformfüggetlennek kellene lennie.
Szóval kényszerképzetemben, ha a tripla bájt tb=010203, akkor a high 02 értéket ad vissza.
Így a
movlw high(tb)
és a
movlw 2
azonos kódot eredményez.
Ez olyan, mint a zsebszámológép, amely az egységárból úgy képzi a 2kg árát, hogy a só árát megszorozza 2, a cukor árát meg 3 értékkel, mert az cukor. :)
Szóval a cím korrekciójára nem lenne szabad egy operátor működését (néha) megváltoztatni.
PIC-eknél nem olyan egyszerű ez. Egyfelől ugyanaz a fordító egy rakás processzorra fordít, amelyek hasonlók, de nem teljesen kompatibilisek. Másfelől az operanus is változó hosszúságú: fileregister címzésekor 7 bit szokott lenni, 1 bit a cél helye, literálisnál 8 bit a szokásos, de ugrásnál ez is hosszabb jellemzően.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
2.2.2 Expressions
The gpasm expressions are implemented using 32-bit arithmetic. gpasm supports a full set of operators,
based on the C operator set.
...
HIGH = high byte
Tehát a high eredménye egy 8 bites konstans. (Ráadásul konstansból keletkezett.)
A movlw 8 bites regiszterbe tölt be egy konstanst.
Ha a betöltendő adat hosszabb, akkor a fordító sikít.
Azaz nullától végtelen bitszámig a high az izének a 8..15 bitjét jelenti. Ha típusosan néznénk, akkor a high akármiből konstanst csinál, és itt vége az okoskodásnak. A konstanst nem szabad tovább értelmezni, mert puszta szám.
Ezért nem az a hiba, hogy rossz helyen van az if, hanem hogyan keveredik oda a fordító, hogy egy művelet konstans végeredményéről elkezdi latolgatni, hogy lehet-e cím?
Ja, értem, mire gondolsz. Akkor még az lehet, hogy nem a high operátorban volt a bug. Így még el tuom képzelni.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
De bizony, ott volt. Az mplabx-el való kompatibilitás lehet az oka. Az mpasmx-el csináltam meg az ellenpróbát és emiatt a gpasm tesztek közé is fölvettem két példa asm-ot.
------------------------------
Egyébként arra készülök hogy valamikor a hét végén kiadom a gputils-1.4.0-RC1-et. A tavasz óta sok változás történt úgy hogy itt lesz az ideje.