ARM STM32 - program v RAM

[Jaroslav Buchta]

- 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