ARM STM32 - program v RAM

[Petr Labaj]

Diky za informace. CircleOS zkouknu.
Nepochopil jsem Vasi vetu "nemel by byt problem to namapovat i do RAM ale
zas to nepujde ladit pres JTAG". Ladeni pres JTAG se nejak zasadne lisi
podle toho, jestli je kod ve Flash nebo v RAM (to prosim nerejpu, jen se ptam,
opravdu to nevim, pres JTAG jsem zatim nikdy nic neladil).

Ano, podpora periferii je u PIC tradicne zminovana jako velky klad. To ale u me
zas tak velkou roli nehraje, protoze knihovny se snazim vyuzivat minimalne,
a i ty, ktere pouziju, si upravuji. Navic napr. s IP stackem je problem v jeho
licencnim omezeni, je povoleno ho pouzivat jen na MCU od Microchipu.
Takze tady stejne pouziju bud LwIP, uIP, pripadne vlastni stack, ktery jsem kdysi
psal (zjednoduseny IP stack, moznosti zhruba srovnatelne s uIP).
Jedine knihovne, ktere se asi nevyhnu, bude USB. Ale ta bude jiste k dispozici
i pro ten ARM.

S tou praci v RAM to ma 2 stranky:
1 - V RAM pobezi aplikace pak v realnem provozu. To zarizeni bude vykonavat
v ruzne dobe ruzne ukoly. Tohle se bezne resi tim, ze ma dane zarizeni ve
firmware jiz vsechny sve "role" predchystane, ale tady to nejde, protoze ja dopredu
nevim, co se od toho bude v budoucnu chtit. Takze moznost zcela zasadni
konfigurace funkce prostym natazenim jineho firmware je elegantni reseni.
A tlacit to do Flash dost dobre nejde, preflashovavat to nekolikrat denne,
kdyz ma MCU zarucovany pocet prepisu 1000, to mi opravdu neprijde jako
dobry napad.

2 - Ve fazi ladeni mi ladeni v RAM pripada jako velmi rozumna varianta, viz
i ten zminovany maly pocet zarucovanych prepisu Flash. Aplikace pisu
inkrementalne po modulech a ladim vicemene metodou pokus-omyl-vypis.
Takze v pracovnim dnu zcela bezne udelam 100-300 zapisu do pameti.
Ta Flash sice asi skutecne vydrzi vic nez je zarucovany pocet za nejhorsich
podminek, ale proc ji pouzivat, kdyz pres RAM je naprogramovani rychlejsi
a nicemu se pritom nesnizuje zivotnost ?

Pripada mi to jako situace, kdy by treba auto melo moznost zapnout rezim,
ve kterem jede rychleji, ma mensi spotrebu a mene se opotrebovava. Ale
tento rezim by se u toho auta nedal zapnout (i kdyz ho umi), protoze vyrobce
na pristrojovou desku neumistil zapinaci tlacitko.

PL

******************************************

From: "Jaroslav Buchta" <jaroslav.buchta na hascomp.cz>
To: "HW-news" <hw-list na list.hw.cz>
Sent: Thursday, January 05, 2012 8:14 AM
Subject: Re: ARM STM32 - program v RAM


| Doporucuju kouknout na CircleOS, je to k ST ARM procesorum a zajimavym 
| pripravkum, o vanocich jsem si s tim hral. Je to dostupne ve zdrojacich 
| (nevim jak licence) a prostredi se da pouzit RIDE, coz ma jako free 
| omezeni jen na debugovani tusim 32kB.  Ale uz Circle OS je rozdelen na 
| pevnou cast a laditelnou cast mapovanim do ruzne casti pameti, nemel by 
| byt problem to namapovat i do RAM ale zas to nepujde ladit pres JTAG 
| (stejne zas RIDE pouziva RLINK adapter...) A pak ucOS ve zdrojacich, 
| pripadne RTOS k inspiraci.
| 
| Na druhou stranu, u PIC me prijemne prekvapila podpora, kde je ke 
| stazeni ve zdrojacich vse pro periferie a jak jsem psal, zkusenosti s 
| TCPIP stackem typu uprav par radku pro jiny HW, preloz a funguje to, 
| jsou pozitivni. UART a asi vsechny periferie jsou podporovane 
| knihovnami, HW jsem ani nestudoval, je to 1 radek inicializace a pak jen 
| put/get, pripadne par radku z prikladu pokud to ma fungovat v preruseni 
| (zase bez studia prerusovaciho systemu, proste funguje). U ARM jsem toto 
| zatim obecne nenasel. Proc vam vlastne vadi ladeni ve FLASH? Byla tu o 
| tom rozsahla diskuse... Jeste stoji za zminku, ze pro ladeni to 
| prekladac preklada jinak, hlavne program po odpojeni rozhrani a resetu 
| nebezi. Tim chci naznacit, ze je to asi dost zabudovane v tom prekladaci 
| a prostredi a prevedeni do ram nebude asi jednoduche / mozne...