ARM STM32 - program v RAM

Čtvrtek Leden 5 19:48:15 CET 2012

Debugger a ladicí výpisy jsou dobré pro různé situace, souhlasím. 
Pracovat jen s jedním, když je možnost obojího, je nerozumné. Ze začátku 
vývoje skoro výhradně debugger, ke konci  výpisy - přerušování už může 
vadit.

Počet přepisů flash paměti je poněkud komplikovanější. Není neobvyklé, 
že µcontroler s 32bit CPU má více Flash pamětí (v jednom adresním 
prostoru) s různým určením a ta na kód programu má zaručováno 100 zápisů 
a EEPROM Flash (hezký marketingový název, že? To je jako internet v 
mobilu :-) 10 000 … po 256bytových blocích.

Je to docela prekérka, když za nový HW s debug konektorem chce výrobce 
4k€, a ty dva už došly na různé nemoci…

Když vím, jak se jednotlivé komponenty ženou na samou hranici životností 
(pouze!) pamětí, nějak nemám odvahu si koupit „novou“ ojetinu.

Jo proč jsem to začal psát. Nevím jak ARM, ale V850 (NEC, rok starý 
model, nic pro vás (je to closed source snad ve všem)) má problémy s 
interrupty, když je program spuštěn z RAM. Po zakázání a povolení 
interruptu to PC skočí zpět na FLASH adresu, Nepodařilo se mi vysledovat 
závislost. Jakmile jsem dal po spuštení programu v RAM breakpoint a 
spustil, vše fungovalo jak mělo.

ced

Dne 5.1.2012 19:01, Jaroslav Buchta napsal(a):
> - No taky jsem se do doby cca pred par mesici obesel bez debuggeru, ale
> jak jsem to zkusil, uz nechci jinak - je to jako nebe a dudy... S temi
> vypisy UART se to da dobre kombinovat.
> - to se vsechny ukoly jednoduse nevejdou do FLASH a nemuze se proste
> vetvit program?
> - Ze by to neslo ladit v RAM se tykalo jen toho omezeni free verze Ride
> - Krome PICu maji procesory zarucovan vetsi pocet prepisu - vetsinou
> aspon 10000, nejak jsem nepochopil, jestli to bude nekdo 10x denne
> aktualizovat ???
> - knihovni funkce jsem take vzdycky odmital, ale zase - procesory uz
> jsou tak slozite, ze rad cast prace a studia prenecham nekomu jinemu,
> nakonec vyrobce cipu asi vi jak co nejlepe nastavit
> - velikost pameti programu myslim uz moc nehraje roli (pokud nejde o
> tisicove serie)
> - pro volani funkci systemu bych pouzil strukturu s ukazateli na funkce
> (ma to tak i ten CircleOS pro inspiraci) v C to jde velmi snadno a
> elegantne. ARM by se mozna dal programovat i objektove ;-)
>
> Dne 5.1.2012 18:49, Petr Labaj napsal(a):
>> 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...
>>
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list