( tovis | 2020. 11. 16., h – 13:27 )

Kösz a megfejtést! Ha jól látom ezt a "Programming manual" -ből szedted elő.
Azért továbbra is zavarba ejtő, amikor 12 bites cím buszt mutatnak egy olyan processzor kapcsán ami mindössze 1k RAM.
"Section 0" az alsó 64k megint bulshit, hol a 64k (ha mondjuk oda tudnék map -elni egy külső ISP RAM -ot azt mondanám OK, de így ez valami ismeretlen "jövő kép" aminek semmi köze a gyakorlati dolgokhoz). Az alap koncepció, nagyon emlékezetet a régi '51 architektúrára, ahol volt 256 bájt RAM és pussz.

Módosíthatom a kérdést, mit kell tennem azért, hogy a legpörgősebb adataimat ("volatile" pointerek és egyéb bit manipulált regiszterek) az alsó 256 bájtba kerülhjenek?

Az UART IT handleremet "tisztán" assemblerben írtam. Van ".area DATA" és ".area CODE" viszont az ".org" utasítást nem tudtam belecsűrni :( (Még jó hohgy a handshake vonalakkal nem kellett foglalkoznom)

A "a fordítót szolgáld ki jelentős többletmunkával" pontosan arról szól, hogy biztosítsa a kód hordozhatóságát, ami mint azt tisztáztuk, firmware esetében fából vaskarika. Hacsak, menet közben nem találják ki, hogy kell még valami funkció amihez nagyobb integráltságú mcu kell. Elvileg, ha maradsz a compiler által követelt konvencióknál, akkor egy mozdulattal megteheted.

Nagy szomorúság a RAM hiánya. Lehetne valami egyszerű mutli task kezelést csinálni, de 1K és benne a stack, illetve az interruptok miatt életveszély. Talán ahogy az '51 -el csináltam, ahol register bank -at négy task -ra osztottam, és nem a stacknbe tároltam le az mcu állapotokat.

A 8 lábú chipekbe belesűrített perifériák az Atmel -nél is jól láthatóak, pl. ATtiny85. Úgy látom, nem a chip de a kivezetések száma a drága.