Dobrý, ale dost tomu chybí jedna věc: popis pamětí a adresování.
Ono se to jednak nabízí někde, kde se vychází z x51, ale taky proto, že je to 16b potvora s až 768kB FLASH + RAM + SFR (na to je 16b GPR málo) a u JMPS je zmínka, že dovoluje jako jediná skok na jiný segment. Ale kde se bere číslo segmentu? Jak se odliší RAM od FLASH při natahování čísla do registru? Atd.
Bez toho to prostě nějak není kompletní... :(
Trošku jsem doplnil druhou kapitolu (poslední odstavec):
https://www.root.cz/clanky/mikroradice-a-dsp-spolecnosti-infineon-sestnactibitove-cipy-c166-a-xc166/#k02
A taky kapitolu o adresování:
https://www.root.cz/clanky/mikroradice-a-dsp-spolecnosti-infineon-sestnactibitove-cipy-c166-a-xc166/#k09
Není tam všechno, například chybí EXTxx instrukce + možnost obejít DPP, ale o těch se ještě zmíním. Ale na úvod, jak se to řeší, by to doufám mohlo stačit.
No stejně, řešení přes ty bázové registry je asi fajn, ale neřeší problém s polem, které překročí rozsah 14 bitů že? Řekněme že mám pole a[100000] a budu k prvkům přistupovat normálně přes pointer ve smyčce s ++ toho pointeru. To se asi přeloží na [Rw+], což je sice fajn, ale jak se řeší přetečení na té hranici? Určitě se DPPx nezvýší, to by rozbilo ostatní kód... Nebo si překladač všechny DPPx připraví pěkně za sebe, aby mu to vycházelo? to by bylo prudce elegantní...
No u všech podobných řešení narazíš na podobný problém (pamatuje někdo segmantaci v DOSu? :-). Automaticky na úrovni překladače to moc řešené není pro dynamická pole, pro pole statická se nějaká základní podpora dá řešit. Teď nevím, jak řeší porovnávání ukazatelů, tam taky může být problém (opět viz DOS...)
Ale obecně - je to pořád "jen" šestnáctibitový šváb, sice má adresování báze+offset, ale to z něj nedělá švába s unifikovanou 24bitovou adresou.
V automotive aplikacich neni ani jedno problemem, tedy pokud se koukam do kodu co je v ridicich jednotkach. Dynamicka pole se temer nevyskytuji (nebo jsou hodne mala), staticka resi prekladac, resp. linker. Ono ty C167ky maji u sebe stejne vzdycky tragicky malo pameti (128k-1MB flash, max 64kB RAM, bootrom 32k, apod.). Vykon neni tak oslnivy, aby si tam mohli dovolit delat taskarice typu prepocitavani nejakych pointeru a dynamickou alokaci.
Vlastne cely SW v ECU je jen obrovske mnozstvi primych nebo zpetnovazebnich fci, ktere neustale lookupuji nejake hodnoty v tabulkach.
Zajimave je pouziti DPPx, kdy v ECU jsou lidove receno "mapy" (kalibracni data) a pro ruzne rezimy a nastaveni jsou ve flash u nekolik atypu ECU namapovany tak, aby offset zustal stejny, jen se meni DPP.
Tragicky málo paměti je 128 bajtů RAM. Ale 64 KB on-chip RAM???
Dynamická alokace v embedded?? K tomu se při auditu kódu dávají tři červené vykřičníky do protokolu a autor takového řešení je zván na bešprechung. Týká se to snad jen juniorů a ještě jsem nezažil, že by si to některý dokázal obhájit.
Automatická alokace bývá příliš náročná na prostředky, ruční je zas náchylná k chybám a obtížně testovatelná. Chybí-li MPU, což je v embedded obvyklé, je to brána k obrovským průšvihům.
Je-li součástí systému i nějaká flash s nějakým filesystemem, platí pro ni totéž - čtení je ok, zápis z vůle firmware do existující struktury znamená minimálně poznámku o zanedbatelném dopadu z hlediska tearingu, dynamická změna struktury je červený vykřičník.
No jo, je jina doba ... jsou motorovky i s 8MB flash, co na to dodat. Vsude bezi OSEK, data se duplikuji ruzne po flashce jak je zrovna nekdo potreboval, atd. V nejbeznejsich starych EDC16kach (PowerPC) je bezne 28+32k RAM a je skoro cela plna! K tomu ~ 1,5MB flash (0,5 on chip, 1MB mimo).
Trosku jsem premyslel, ze bych jako takove anti-retro udelal rizeni motoru na nejakem dospelem pocitaci (jako vylozene x86 ;-) ). Pracovne to jinak mam na obycejnem PICu, utoci to do cca 10k rpm (motorka).