Fórumok
Sziasztok!
A program fordul, de a fordító üzen. Mit rontottam el?
Megpróbálok az áttekinthetőség kedvéeért egy gyors peszudokódot összedobni.
Főprogram
#include "cpu1.inc"
#include "config.inc"
...
A config.inc
#ifdef cpu1
...
#endif cpu1
...
#ifdef cpu2
...
init_X macro X
if (X==1)
movlw 1
else
movlw 2
movwf PSMC#v(X)CON
endif
endm
...
init_all macro
init_X 1
init_X 2
init_X 3
endm
...
#endif cpu2
Tehát a fordítás hibátlan, de megjelenik az alábbi hibaüzenet:
Symbol X not assigned a value.
Méghozzá pontosan annyiszor, ahányszor az X hivatkozás szerepel(ne) az init_all*init_X kifejtésekor. De ugye erre nem kerülhet sor, mert a cpu2 undefined.
A fordítás abszolút módban megy, a cpu1=PIC18F14K22, a cpu2=PIC16F1789.
Hozzászólások
Én ezt próbáltam:
---------------------------------------
config.inc:
---------------------------------------
main.asm:
Így fordítottam:
gpasm -w1 -p 16f1789 main.asm
(A '-w1' csak azért van hogy ne figyelmeztessen:
config.inc:12:Message[302] Register in operand not in bank 0. Ensure that bank bits are correct. Bank_bits = 0xe80, register{0x31}.)
Egyébként semmi baja és készít egy 68 bájtos hex-et (Linuxon).
A gpasm változatszáma: gpasm-1.4.0 #1146 (Sep 16 2015)
Hát bizony én csak a #1106-os hivatalos (win) build-et használtam.
Felraktam a #1146 buildet, az nem ír ilyen üzeneteket.
Az eredmény megegyezik, látszólag minden rendben van.
Kicsit megzavartalak a "pszeudokódommal". :(
#1106 build:
A hibához a 18F14K22 processzorral kell fordítani!
Akkor az init_all nem is hívható, mert nem definiált. Helyette bármilyen indifferens utasítást kell berakni.
Így fordítva négyszer írja ki a Symbol X not assigned a value üzenetet.
Azt sejteti, hogy 2 pass-ban megy végig a macro definíción, amit csak a másik processzor definiálása és a macro hívása után tehetne meg.
Azaz a fordító megpróbálja kifejteni a #v(X) értékét, de nem is járhatna arra.
További hiba, hogy az üzenetek csak az stdout-ra érkeznek.
#1141 build:
Meg is találtam: bug #284 Cannot suppress "Symbol xxx not assigned a value" message
Már csak az a kérdés, hogy mit keres a fordító a kétszeresen kizárt helyen. És erre megoldás-e egy nem használt változó default 0 értéke?
Mondd, hogy ne aggódjak! ;)
Ezzel a hibával nem találkoztam, vagy legalábbis nem jelzett ilyet senki sem.
"bug #284"
Ezt nemrégen intéztem el a bejelentést tevő javaslata szerint.
----------------------------------------------------------------------------------------------------
A bug bejelentése:
----------------------------------------------------------------------------------------------------
A megoldás után nem írt többet (általában egy hetet várok és ha nem reagál akkor zárom a ticketet), gondolom hogy megnyugodott.
Igazság szerint nem ártana rendesen átnézni egyes helyeken a gputils forrását, de ehhez hónapokig kéne rajta ülni és semmi mással nem foglalkozni. Pár éve volt hogy a nyakamba szakadt az egész, mivel meghalt az a kolléga aki addig a fordítóval magával foglalkozott. Addig én inkább csak az új processzorok (vagy MCU-k) támogatását adtam hozzá és írkáltam azokat a perl scripteket amik ebben a munkában segítettek. Amikor a gpdasm "felturbózásával" foglalkoztam akkor eléggé beleástam magam egy-egy részbe, de ha pl a gplink-hez kéne hozzányúlni akkor egy darabig nézhetném a kódokat mire megérteném hogy mi mit csinál. Nem lenne könnyű, mivel nincs leírás semmiről sem, csak a kódban akadnak néhol megjegyzések.
Láttam a bugot. Ott írtad, hogy valakinek a kísérleti kódját kerülgeted..
Itt csak az az aggasztó, hogy a define=false, kifejtetlen macro body ellenére a fordító beletúr a kódba.
A szerencse csak az, hogy az outputot és a fordítás sikerességét nem befolyásolja.
Beláthatod, hogy a default 0 érték erre nem megoldás. Külöben is, ez nem egy BASIC interpreter! :))
Jómagam több mint 30 éve dolgozok asm-ben. Volt egy jókora kihagyás, szakaszosság, de másfél éve visszakanyarodtam hardverfejlesztőnek. Szinte el se akartam hinni, hogy ilyen munkám lehet, ami még érdekel is. Kértem egy hónap türelmet, mert már teljesen ütőképesen szerettem volna munkába állni. Ez az idő nem volt mindenre elég, de előbb-utóbb ki kellett választanom azt a munkaeszközt, amivel inkább a munkára lehet koncentrálni, mint a szívásra. ;) Volt alkalmam Intel Isis-II fejlesztőrendszeren dolgozni. (persze V20-on emulálva) Abszolút kódot modulokra bontva lehetett fordítani, majd ezekből néhányat linkelni, majd (re)lokálni és szimbolikus debuggerben tesztelni. No, ilyen rendszert azóta sem láttam!
Jó 20 évet programoztam C-ben, gondoltam semmiség lesz más platformon nekiállni. Különösen azért, mert a C alatt is egészen a bitvadászat szintjére süllyedtem. Nem kis bosszúságomra a gyártó fordítója néha az alap dolgokat is rosszul fordította. A keletkezett binárist visszanézve gyakran marhaság köszönt vissza, a libből kinyert függvényekből max. a demó program volt előállítható. Áttértem asm-re nagyon nehézkesen ment a munka, mert híján voltam minden eszköznek.
Ezek után tettem át mindent gpasm-re, mert jobban értette az "én szintaxisomat" és jobb volt az eszközkészlete. Hibája csak annyi van, amennyiben az MPASM-hez hasonlít. :( Értem, hogy ez az esetleges kód hordozását könnyíti meg, de egyben le is rontja a "felhasználói élményt". Valójában a C szintaxissal kevert asm egy kis történetet juttat eszembe:
Kocsmában (csöppet sem józanul) beszélgettem egy holland házaspárral angolul. (Egyébként csak olvasok. :))
Beszédembe német szavakat kevervén (régen nem beszélek németül) megkaptam: Beszélhetek németül is, azt is értik. Én meg elnézést kértem - maradjunk meg ennél így: KEVERVE!
Szóval az mpasm_compatible mellé lehetne egy asm_compatible option is! Olyanra gondolok mint pl. írtam egy terminált (szerintem több volt, mint emuláció), és a tasm alig bírta lefordítani a rengeteg keyboard map és escape makró miatt. Fogadni mernék, hogy a pic-ekhez való fordítók nem bírnának vele, pedig ősi primitív makrók.
Szomorú dolog, amikor valaki kiesik egy kis csapatból! A felhasználóknak meg kockázatos is. Valószínűleg a Microchip irányvonala azért lett az MPLAB-X, mert szükség volt a multiplatformos rendszerre. Emiatt biztosan lehetne velük szövetkezni, hátha fektetnének a gputils fejlesztésébe egy kis pénzt - már ahogy ez az ingyenes opensource esetében lenni szokott. ;) Biztosan nem vagyok egyedül, aki szívesen látná a gputils fejlődését legalább a pic24 olyan tagjai irányába, amik nem is ds, csak a 16mips helyett tudnak 70-90-et. Ennek híján most ott tartok, hogy éppen elég a sebesség. A következő lépésben a perifériákat kell fejlesztenem, mert a kicsivel gyorsabb eszközhöz nincs fordító.
"Láttam a bugot. Ott írtad, hogy valakinek a kísérleti kódját kerülgeted..
Itt csak az az aggasztó, hogy a define=false, kifejtetlen macro body ellenére a fordító beletúr a kódba.
A szerencse csak az, hogy az outputot és a fordítás sikerességét nem befolyásolja.
Beláthatod, hogy a default 0 érték erre nem megoldás. Külöben is, ez nem egy BASIC interpreter! :))"
Teljesen igazad van. Nem tudom mikor lesz időm és energiám utánajárni ennek a hibának. Egyszer talán... Mostanában eléggé el vagyok foglalva. Van még egy kolléga aki régebben aktív volt, de ő már kb. két éve semmit sem csinál a gputils körül. Hmm... azaz mégsem, éppen ma egy lezárt ticket-ben molyolt valamit: "**discussion**: enabled --> disabled" Meg is lepődtem amikor küldte az értesítést a sourceforge.net. :-)
"Biztosan nem vagyok egyedül, aki szívesen látná a gputils fejlődését legalább a pic24 olyan tagjai irányába, ..."
Nem sok értelme lenne hiszen az XC16 és az XC32 fordító is tartalmaz assemblert: "xc16-as" és "xc32-as"
Legföljebb azzal lehet majd gond ha egyes Linux telepítőkészletekből kimarad a 32 bites binárisok futtatásának lehetősége, mint pl. a Fedora 23 lesz. (Legalábbis ezt olvastam nemrég.) De gondolom a Microchip-nél sem hülyék és majd haladnak a korral. Egy ilyen hátterű céggel fölösleges lenne versenyezni. Ha valaki a gputils-ba be szeretné építeni a pic24 és a pic32 széria támogatását akkor az egész kódot ki kéne dobni és az elejétől kezdve újat írni. Ehhez nálam komolyabb tudású emberkék kellenének, akik képesek átlátni és fejben tartani az egész kódot, ez a nagy lecsüngő helyzet. Az ilyen programozók pedig nem ragadnak le egy ilyen kis projektnél.
Azért nem akkora ez a hiba. Inkább csak bosszantó volt, amikor kis lépésekben fejlesztem a kódot és egyszer csak megjelenik több oldalnyi marhaság. (Természetesen a mintaprogram tényleg csak apró minta volt.)
Ami tényleg érdekes az a továbbfejlesztés kérdése.
A linux az kezdi túlszárnyalni a windows-t a legrosszabb értelemben! Vagy az Intel processzorok lennének ilyen gyengék? Ilyen "apróságokból" látszik, hogy a sokak által nem ismert AIX és az IBM miért ipari rendszer. Ott ugyanis számomra fel sem merült a 32-64 bit közti különbség. A programom 32 bites volt, mert a karakteres feldolgozások így egy hajszállal gyorsabban mentek. Ha a assembler listát néztem (C-ben írtam), akkor a 64 bites load egy utasítás volt egy órajel alatt. Ugyanez 32 biten két utasításnak látszott, amelyeknek rendre egy és nulla órajel volt a végrehajtási ideje. Ezzel nagyjából kimerítettem az eltéréseket, mert pl. az open() és open64() cuccokkal sem kellett külön foglalkozni. Linux alatt néha még az egyforma rendszereken is eltérően kell fordítani. :(
"De gondolom a Microchip-nél sem hülyék és majd haladnak a korral. Egy ilyen hátterű céggel fölösleges lenne versenyezni."
Ezt ugye nem komolyan mondod? Nem társalognánk itt, ha igazad lenne!
Az már nyomósabb érv lehetne, hogy az MPLAB-X miatt megszűnik a gputils, mert az már platformfüggetlen.
No, ez meg marhaság, ha elhiszed amit a fordító választásról írtam. (Amit használok: WindowsXP SP2. Sokan lehülyéznek érte. Ahol meg a nyomtatott áramkört terveztetek, ott DOS alatt futó programokat használnak. De fura.;)) Olyat is lehetne mondani, hogy kihalnak az assemblerben programozni tudók és akarók. Ekkor is megszűnne a gputils, de kizártnak tartom.
Valahol már írtam, de nem keresem meg a linket - az első eeprom írásom története:
1) Beegereztem az adatlapban szerplő programot - leakadt.
2) Spóroljunk időt! Kiollóztam (az egyébként rosszul dokumentált lib-ből) - leakadt.
3) Kiollóztam a HiTech C lib-ből - leakadt.
4) Elolvastam az adatlapot, megírtam - működött. Ez utóbbi időben csak tizedannyi volt, mint az előző próbálkozások.
Van olyan, hogy MPLAB® Code Configurator! Megnéztem, inkább használom az adatlapot! Pedig egyik dícsérője szerint: Milyen jó, nem kell dokumentációt olvasni!
Mottó: "Egy ilyen hátterű céggel fölösleges lenne versenyezni."
Aha.
Ha ezt a Motorola, Intel vagy IBM-re modod, akkor igaz. Ennek a nagy hátterű cégnek gyakran igen csapnivaló a dokumentációja, de néha már az MPLAB miatt is a tollam hullott. Pl. a text fájlok kezelését sem végzik tökéletesen. De ne bánkódjunk, van utility ennek a hibának a javítására! :(
Végezetül nem véletlenül írtam csak pic24-et. A pic32 - ha jól tudom - vásárolt core, tehát kicsit más platform. Szerintem az első lépésben kihagyható. A pic24 hasonlít a kisebbekre, csak itt-ott egy-két dma, dsp meg több regiszter, meg egy kicsit gyorsabb. A lényegi felépítés viszont hasonló.
Ennyit mára a bosszantásodról, amiért elnézésedet kérem!
Hát, furcsa világot élünk. Az assembly-t megszokásból toljuk illetve én nagyjából kiszálltam belőle, mert be kellett lássam, igen kevés helyen kell még kézzel kódot időzíteni, ahova a C nem segít.
Ellenben a C kód a periféria specifikus részeket leszámítva könnyebben portolható más mikrovezérlőkre, sőt SBC-kre is. Hiszen nem kell mindegyik assembly utasításkészletét elsajátítanom.
Gyorsan megnéztem, C-ben mennyivel lenne átláthatatlanabb ez a részlet:
$ wine cc5x/cc5x.exe -p16f1789 teszt.c
és már le is van fordítva.
"kézzel kódot időzíteni"
Ez alatt mit is kellene érteni?
"... a C kód a periféria specifikus részeket leszámítva ..."
Hát pont ezért felesleges rugózni a hordozhatóságon.
"nem kell mindegyik assembly utasításkészletét elsajátítanom"
Egy kis PIC 35 utasítást tud, a nagy (a pic24-ig) meg olyan 70-80 körül. Érdekességként az i8085 76 utasítást + 8 "nem specifikált utasítást" tudott (kb.). Elég nehéz lenne arduniora hordozni, de nyilvánvalóan semmi értelme. Egyik kollégám el akart szegődni egy kisebb java projektre, de megrémült: A fejlesztés kezdeti szakaszában a szoftver 2600 osztályt tartalmazott!! Igaz, még a marsjárón is futott volna. :D)
Ez a psmc_init() azért lenyűgöző C-ben, mert
- van hozzá a PSMC Designer - amely C vagy asm utásítássorozatot generál - a kettő kb. tökegyforma
- ezekkel nem sikerült még elindítanom a PSMC-t :(, azaz meg kellett írni, de nem úgy, nem olyan sorrendben
- összesen 7 mikrokontroller tartalmazza ezt a perifériát - ugyan mi a rossebre hordoznám?
- az init lényegében 80 sor SFR töltögetés, ami semilyen nyelven nem lesz áttekinthető
És ami a lényeg: A "szoftver" pécén fut, a kollégám írja jávában (ez az ő baja). Oda portolja, ahova akarja. Ezzel szemben mikrokontroller dolga a perifériák vezérlése. Ezen kívül nem igazán van mit portolni - meg szerinted sem lehet.
Szóval mikrokontrollerre szeretnél szoftvert írni ÉS hordozni, ugyanakkor SBC-vel vezérelsz perifériákat? Ez egyszerűen hibás eszközválasztás. Nem egy topicban előfordul.