MPASM align problémák

Egyéb: Assembly, Ada...

Sziasztok!

Gyűröm az MPASM fordítót PIC18-ra, méghozzá a "Generate absolute code" opcióval.Próbálom következő turpisságokat megvalósítani:
- adatot EEPROM-ba rakni bájtonként.
pl.
Data1 de DefaultValue1
Data2 de DefaultValue2

- adatsort megadni 3 bájtonként
pl.
Data3 dw .1500000&0ffff
db (.1500000>>10)&0ff

A probléma:
Annak ellenére, hogy kifejezetten a PIC18 eszközökön a "de" byte-ot ír le, az align==word, így feltölti még egy nullával. Ugyanúgy a 3 is páratlan, tehát hiába szabdalom szét a 3 bájton lehírható értéket L, H és U részre, szintén feltölti nullával.
Az első problémára a megoldás pl.:
eedata de DefaultValue1, DefaultValue2
Data1 equ eedata
Data2 equ eedata+1 stb.
Erre azért van szükség, mert az adatokat nem csak beleírom az eepromba, hanem hivatkozni is szoktam rájuk. ;)
(No comment)

Megoldás a code_pack, ami csak relokálható esetben használható. Az align direktíva nem létezik.

A kérdés:
Létezik-e kultúrált megoldás byte elhelyezésére?

(Minden olyan válasz, amely arra irányul, hogy írjak relokálható kódot, használjak java-t meg xml-t, vagy apache webszervert - számomra nem elfogadható! :)))

( 4fonya | 2014. 07. 26., szo – 10:18 )

A gputils - benne a gpasm - egy ideje tudja ezt. Valamikor tavasz végén, nyár elején az EEPROM területen
megszüntettem a szóhatárra való igazítást. Azonban ha ki akarod próbálni akkor Linux-ra le kell fordítanod
a fejlesztői változatot: gputils-src-20140718-1076.tar.gz
Win-re van egy telepítő itt: gputils-20140718-1076-setup.exe
Ezek ugyan nem a legújabbak (azokat svn-ből lehet elérni), de ez a te gondodat nem érinti.

A példa kód pedig ez: 



	list    p=18f4520

Const1	equ	0xCCBBAA
Const2	equ	0x998877
Const3	equ	0x665544
Const4	equ	0x332211

start:
	return

	org	0xF00000

Str0	db	"tartalom"
Data1	db	low(Const1), high(Const1), upper(Const1)
Data2	db	low(Const2), high(Const2), upper(Const2)
Data3	db	low(Const3), high(Const3), upper(Const3)
Data4	db	low(Const4), high(Const4), upper(Const4)

	end

Az Str0 csak dísznek van. :-) A hex-ben a ConstX-ek hézag nélkül követik egymást.

---------------------------------------------------------------------

Újabb változatok a programcsomagból:

gputils-src-20140726-1081.tar.gz
gputils-20140726-1081-setup.exe

Köszi a választ! (És külön köszönöm azoknak, akik NEM válaszoltak mindenféle sületlenséget! :)
Szóval működik! DE!
A páratlan számú adatok rom-ban tárolása még mindig megoldatlan. Talán nem írtam egyértelműen, de a második példa arra vonatkozott. Addig, amíg a TBLRD*+ nem kettőt lép, addig az align és/vagy packed hiánya hiba!

Konkrétan win alatt használom (néha linuxon). Rögtön felmerül, hogy a gputils-mplab tényleg 0.3 - sajnos.
A fordító jobban ellenőrzi a dest és access mezőket, de a hibalistából nem tudok "visszakattintani" a forrásba. Az MPLAB nagyértékű és kiforrott :)))))) editora meg nem vi. :(

Tehát a pro: a gpasm már lefordítja a kódomat. (Kivétel a FLASH-ben levő adatokat)
A kontra: Ha már hardvert programozok, sokkal jobb az olyan rendszer ahol:
- le tudom fordítani akár több darabban a programot
- néhány darabot ezekből össze tudok linkelni
- a hardver, szimulátor vagy a debugger "igényeinek" megfelelően tudom lokálni
- az előbbi eredményét tudom szimbolikus debuggerben futtatni
- a végső felhasználáskor máshova - ti. a célhardverre lokálni a kódot
Persze a fentiek ellenére abszolút módban.

Ez a rendszer már egyszer létezett ám! És még nincs is 40 éve. Úgy hívták Intel Isis-II.
Vagy a Macro-80 is felülmúlja tudásban és pontosságban az mpasm képességeit. (Üzenem a mikrocsipcsipcsókás fijjúknak!)

A probléma pedig abból fakad, hogy nincs lokátor. Ez rögtön látszik az "org 0xF00000" direktívából. - Miközben a linker tartalmazza a
"CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED" sort.
Ha már megmondtam milyen processzort használok, ennek a definíciónak a headerben van a helye. Akkor meg elég pl. a ".eedata", vagy az "org eedata+3". No, és ebben az esetben mindegy, hogy milyen a processzor, és az is, hogy abszolút vagy RElokálható a kód. Viszont a fordítás megkezdésekor nyivánvaló, hogy az eedata területre nem kerülhet 16 bites utasítás a Harvard ill. az eeprom vagy HEF spec. elérése miatt. Ráadásul a pic18 nem is dolgozik 16 bites adatokkal! Ezek után vajon miért müvészet a DB után 1 darab bájtot elhelyezni?
(Az, hogy egy asm fordítót manapság már úgy írnak. mint egy magasszintű nyelvet, nem lehet a jó válasz.)

"Ha már megmondtam milyen processzort használok, ennek a definíciónak a headerben van a helye."

A gputils-ben lévő header-ek a Microchip-től származnak. (Ezzel nem árultam el újdonságot. :-) A közelmúltban fölfedeztem hogy a fejlettebb 14 bites sorozathoz kiadott header-ek nem tartalmazzák a config bitek között a DEBUG direktívát (pedig az adatlapokban létezik). Már volt panasz emiatt, de akkor még nem gondoltam hogy ez tömeges jelenség. Ezért nemrég pótoltam mindenütt ahol hiányzott. Megtehetném hogy az EEPROM kezdő címének definícióját berakom mindegyik olyan header-be amely MCU-ban valóban van ilyen memória, pl. így: 


EEPROM_START   EQU   0xF00000
EEPROM_END     EQU   0xF000FF

Mindössze számomra lenne nehezebb akkor amikor a Microchip kiad egy újabb MPLABX változatot. Mivel ilyenkor meg kell néznem minden header-t és linker scriptet aszerint hogy vajon kijavítottak-e egy-egy hibát, vagy minden maradt a régiben. Ettől függően kell karbantartanom a gputils-bővítéseket.

Egyébként érdekes hogy még nem találkoztam ilyen tipusú fölvetéssel. Úgy értem, még senki sem reklamált azért hogy hol van az EEPROM definíció.

-------------------------------------------------------------

Van jobb megoldás is annál hogy a header állományokat bővítgessem: A gputils egy belső adatbázisban tárolja minden processzor főbb jellemzőit. Ezek közt szerepel az EEPROM kezdő és végcíme is. Érdemesebb lenne létrehozni ezeket mint előre definiált állandókat. Meg is nézem hogy mit lehet tenni.

:)
Ilyet az egyik audió csipgyártóról olvastam: "Vedd tudomásul, hogy ők HARDVERT és NEM SZOFTVERT gyártanak." Hát ezért nem működnek a driverek.
No, ez mikrocsókáékra is igaz lehet.

A jelenség kb. a következő. Elkezdtem tanulni és programozi a 18f2550-et. Az adatlap több helyen azt írja, hogy a "hozzávetőleges" megoldást ábrázolják. Legalább 10 hibát találtam, pedig egyáltalán nem használok mindent a szerkezetből. Néha úgy kellett kimérni, hogy mi is történik. Kezdtem a Mikroelektronika C-vel, de minden függvényemben csak asm volt... Annak meg még rosszabb a szintaxisa...
Megjegyzem, a Mikroelektronika C fordító is igen nagy ostobaságokat állít elő.

Aztán írtam eepromot is. Hogy ne kelljen okoskodni, az adatlapban megadott kódot összeollóztam a lib-ben levő megoldással. Nem működött. Elolvastam. Kifelejtettek valamit... Ha csak elolvasom, megírom az kb. 5-6x kevesebb idő. Az adatlap=Microchip, a lib=Mikroelektronika.
Tehát ezek főként a ledvillogtató titánoknak készülnek, nem beszélve a delay rutinok sokaságáról. :)

Az eeprom definícióban nem is az elhelyezkedés a lényeg. Az a példa, amit írtál, az én meglátásom szerint hibás. Ha létezik eedata szegmens, akkor ott a db helytelen és csak a de a megengedett. Ha már ilyen speciális a hw felépítése, akkor a fordító dobjon hibát, amikor eeprom adat címét töltöm az fsr-be, vagy flash címet olyan mcu-n, amin nem lehet ezzel a regiszterrel flash-t címezni. Érdemes lenne a Macro-80 ASEG, CSEG, DSEG megoldását tanulmányoznod. Ebben az esetben a relokálhatóság sem olyan, mint amit az exe, vagy a link használ. Pl. az extern nem jelenti azt, hogy "relokálható", mindössze a definíció máshol található.

Persze elérhető az a szint, amikor az MPASM forrást már nehezen lehet gpasm-mel lefordítani. Szerintem ez nem is olyan érdekes, mert ha tényleg többet fog tudni, akkor az MPASM-et csak a tájékozatlanok fogják használni. Jelen pillanatban egy csomó fordító létezik (beleértve a C-t is), és mindegyik a legjobb, csak én nem értek egyet. :))

Mivel én "csak" használni szeretném, egészen hóbortos elképzelésm támadt: Ha a gyártó gyakran hibázik, akkor az n+1. fordító ne kövesse a hibákat, hanem legyen jobb! Nekem olcsó, nem én csinálom. ;)

"Legalább 10 hibát találtam, pedig egyáltalán nem használok mindent a szerkezetből."

Annak idején én is leaggattam a szenteket az égről amikor hiába állítottam be a soros port sebességét, mégsem azzal dolgozott amivel kellett volna. Az adatlap pedig nem segített. Végül az lett a megoldás hogy a baudrate értéket korábban kellett megadni mint ahogyan az logikusnak látszott.

"ledvillogtató titánoknak" :-D

"Ha létezik eedata szegmens" A gpasm nem köti meg ennyire a programozót.

"akkor a fordító dobjon hibát, amikor eeprom adat címét töltöm az fsr-be, ..."

Erre ugyanaz a válaszom mint följebb, hozzátéve azt hogy az assembly nyelv - véleményem szerint - a programozás teljes szabadságáról szól. A delikvens itt teljes mértékben kitombolhatja magát és olyan hibákat véthet amilyeneket csak akar.

Egészen ez év elejéig szinte egyáltalán nem nyúltam bele a fordító kódjába. Aztán kiderült hogy meghalt a kolléga aki ezzel foglalkozott. Ezután kezdtem ismerkedni a kóddal és van még olyan rész amiről csak sejtem, hogyan is működik. Amit megértettem abba helyenként már belenyúltam, itt-ott átírtam és kibővítettem. Így történt ez most is.

Ezentúl ha az adott processzorban van EEPROM akkor automatikusan létrejön két definíció:
__EEPROM_START és __EEPROM_END

Ezeket használva, nem muszáj tudni hogy hol is van ez a memóriaszegmens. A fordító már kezeli ezt a két állandót, nemcsak a pic18, hanem a pic12 és pic16 kezdetű eszközök esetében is. Este még tesztelem egy kicsit az újítást, aztán feltöltöm az svn-be és készítek belőle win32 telepítőt is.

-----------------------------------------------

Itt vannak:

gputils-src-20140728-1082.tar.gz
gputils-20140728-1082-setup.exe