Freescale ARM - jak zacit

[Jan Waclawek]

Poznamky bez ladu a skladu:

- Freescale bol pred par mesiacmi kupeny NXP, z tohto pohladu je otazna
buducnost radu Kinetis (aj ked samozrejme teraz sa vsetci biju do prs ze
to bude este 100 rokov); naviac ked sa vezme do uvahy historia
"dlhovekosti" mcu u Motoroly...

- ak chcete 8-bity nahradit armoidmi lebo je to moderne, tak to je s
prepacenim hlupe. Ja vidim jediny vseobecny dovod pouzit armoid miesto
8-bitu, a to je realna potreba vyssieho *vypoctoveho* vykonu (a teda nie
som si isty ci by som sa na zaciatok vobec uvazoval o M0/M0+); potom
existuju specificke aplikacie ktore dokazu vyuzit alebo priam vyzaduju
nejaku specificku periferiu, ktora v 8-bite trebars nie je dostupna

- "M0/M0+ nepodporuji JTAG" to je pravda, ale takto sformulovane to znie
ako nejaky nedostatok, co pan kolega VP tak zrejme nemyslel: v 99.9%
pripadov to vobec nevadi lebo z pohladu uzivatela je takmer uplne jedno
ako to ladiace rozhranie je fyzicky realizovane t.j. ten SWIM je OK; to
0.1% je boundary scan ale to pritomnosotu JTAG aj tak nie je zarucene

- ten najdramatickejsi architekturalny rozdiel je v tom, ze tie armoidy (a
mipsoidy aka PIC32) nie su mikrokontrolery, t.j. nie je to jednoliata
kombinacia vypoctoveho jadra, pamati a periferii navrhnuta s ohladom na
jednoduche a kontrolovane casovanie udalosti od pinu po pin, ale viac ci
menej sudrzny zlepenec procesoroveho jadra a inych kontrolerov (typicky
DMA), periferii, pamati a logiky arbitraze pristupu k zdielanym
prostriedkom prostrednictvom spolocnej zbernice resp. matice zbernic. Je
to nie nepodobne klasickym doskovym pocitacom, trebars aj IBM PC. Je to
takmer nevyhnutna dan za enormnu zlozitost, kratky cas vyvoja a snahy o
ziskanie co najvacsieho vypoctoveho vykonu. Z toho vyplyva castokrat aj
heterogenne casovania jednotlivych komponentov ktore spominal VP, a
bonusom su cache a buffre na rozhraniach medzi modulmi; no a dosledkom je,
ze aj ked cely obvod je pochopitelne stale plne deterministicky, presne
casovanie na urovni jedneho hodinoveho cyklu je prakticky
neodsledovatelne/nekontrolovatelne, a v medznych pripadoch, ked o to
naozaj ide (a najdu sa na to prostriedky), je potrebne nasadit simulaciu
na urovni hradiel (co ma k dispozicii pochopitelne len vyrobca). V praxi
sa teda tieto otazky riesia rozsiahlym mavanim rukou a odkazom na
"neobmedzeny" vykon. V skutocnosti to funguje tak, ze na vacsinu beznych
problemov mate v tom jednocipe nejaky hardware (a ze tych modulov byva
pozehnane); na cokolvek mimo toho treba ratat s nepresnosou v rade
jednotiek az desiatok cyklov najpomalejsich hodin, ktore sa danej veci
tykaju.

- opominana zalezitost ktora vyplyva z horeuvedeneho je aj kvalita
dokumentacie - vo vacsine pripadov je daleko za cimkolvek z oblasti
8-bitov. Dovodom je prave metoda zliepania (nech mi je dovolene citovat
klasika hw-listu MK: lepenie hovna k hovnu). Takze aj dokumentacia je bez
ladu a skladu co najrychlejsie nahadzana a snazi sa ohurit rozsahom, ked
uz nedokaze kvalitou; najlepsi negativny priklad su dokumenty ARMu. A ze
budete potrebovat aj tie, ak teda nebudete chciet len klzat po povrchu, bo
dokumentacia vyrobcov do detailov jadra nejde, odkazuje sa prave na ARM.
Casta je aj snaha nahradit slusnu dokumentaciu roznymi klikoidnymi
softwarmi a "kniznicami" a dalsou hromadou mavania rukou. Treba sa obrnit
a vytrvat. Na druhej strane si treba uvedomit, ze ak kazda jedna periferia
ma zlozitost porovnatelnu s celym 8-bitom, a ak tych periferii je v tom
jednocipe trebars tucet, a dalsieho poltucta inych zalezitosti (procesor,
pamati, hodiny, zbernice), nuz tak si treba vyhradit aj tomu primerany cas
a priestor na studium a experimentovanie. Alebo sa treba naucit intenzivne
a casto mavat rukou, kazdy podla svojho zaludka...

- waitstate pri behu z FLASH - to je individualne. Bezna FLASH dovoli tak
20-30MHz bez waitstate, Japonci maju aj lepsie, neviem co ma Freescale. M0
su zamerane ako low-end low-cost, takze obvykle bezia dost pomaly na to
aby isli s 0 alebo 1 WS; ale to este takmer nic neznamena. M0 ako jadro
oproti M3/M4 nema prefetch, t.j. sa nesnazi citat dalsie instrukcie pocas
vykonavania viaccyklovych instrukcii; ale niektori vyrobcovia to
kompenzuju na "svojej" strane a pridavaju prefetch na vystup FLASH.
Naviac, instrukcne slovo u Cortex-M je 16-bit (to je pre mnohych
prekvapenie), pricom cast instrukcii su dvoj-slovne, takze uz FLASH siroka
32 bitov staci na plnenie jednoslovnych sekvencii bez cakania aj ked je
jej rychlost polovicna oproti hodinam procesoroveho jadra, FLASH siroka 64
bitov je na tom este lepsie. Takto sa latencia FLASH prejavi len pri
skokoch - to by sa sice tiez dalo ciastocne kompenzovat jump cache, ale to
neviem ci u M0 niekto implementuje...

- prerusenia... nuz, vstup do prerusenia je u Cortex-M0/M0+ minimalne 15-16
strojovych cyklov, k tomu treba okrem latencie kvoli dlhym instrukciam
pridat to co bolo spomenute, napr. ze prave vtedy pristupuje k pamati aj
iny kontroler (napr. DMA), alebo spomenuta latencia FLASH... Dobre, v
ramci tohoto sa uklada aj dost znacny kontext, hromada registrov, ale aj
tak... a su aj vychytavky typu tail-chaining, kde nasledne prerusenie
vyuziva kontext ulozeny predchadzajucim prerusenim, ale aj tak... takze
latencie aj jitter su znacne. U armoiodo-mipsoidov je kvoli tomuto vyrazna
snaha predist preruseniam pomocou DMA, a u typickych komunikacnych
aplikacii je to uplne super; znova, u netypickych treba ratat desiatky az
stovky cyklov. Na druhej strane su prerusenia plne vnaratelne a
viacurovnovo priorizovatelne, co ocenia klasicki AVRkari; a je obvykle k
dispozicii dost vela prerusovacich vektorov, takze periferie maju svoje
vlastne, takze v ISR obvykle nie je potrebne skumat zdroj prerusenia, co
ocenia klasicki PICkari ('51tkari neocenia nic z tohoto, ale to je
pochopitelne, vzhladom na to ze to je daleko najlepsi 8-bit vsetkych cias
;-) ).

- sw vyvojove prostredia su 4 druhov: IAR, Keil, Tasking a spol. za dlhsie
az dlhe peniaze s moznostou vyuzit trialy a rozne akcie ake napriklad pre
tie STM32 M0/M0+ spominal VP; Rowley, Atollic (ten uz je v nepodporovanej
verzii free) a trebars aj Comsytec za kratsie peniaze; Coocox a emblocks a
pluginy do Eclipse zadarmo; no a potom je gcc/gdb/openOCD tiez zadarmo.
Nejaky zakladny okec (typu "Atollic a Coocox tiez len je Eclipse a gcc"
alebo "v prikladoch STM su podporovane Keil, IAR a Atollic" (mozno sa
mylim, nezaujima ma to velmi)) by sa dal ku kazdemu povedat, aj ked bude
subjektivny; ale podrobnosti si aj tak musite zistit sam.

- "kniznice"... o tom nechcem pisat bo som znamy z pohladu mainstreamu
extremnym postojom k nim

- neviem, ake 8-bity pouzivate a ako ste sa k nim dostali/preco ste vybrali
prave taky, ale podla mna jednym z najdolezitejsich faktorov je moznost
opytat sa. No a prave z tohoto (a zo ziadneho ineho) dovodu by som aj ja
doporucil tie STM32, ktore maju v nasich koncinach aj na tomto fore asi
najviac uzivatelov, nehovoriac o pritomnych kolegov priamo z ST


wek