[elektro] ARM Cortex-M0 internal flash kapacitas -- mire eleg?

[hg12345]

Azért ezek a fordítási eredmények egy kicsit szerintem torzak.
mert, hogy a C-s fordítási környezet nem azonosan van beállítva (8,16,32 biten)

- printf és tsa. hoz van egyszerűsített alap library az ARM-okhoz, ami fele alatt van az eredetinek (rövid programnál  arányaiban látványosan csökkenthető a memória)

- sok múlik a változók illesztésen, ha nem állítsz be mást akkor ALIGN 4 illesztéssel dolgozik, és minden változó még char is regiszter méreten tárolódik. Vagyis, a konstansok és konstanssal feltöltött változók is akár 4x helyet igényelhetnek. Kivétel ez alól a tömb. Ha tömörségre kell menni akkor érdemes ahol lehet kisebb illesztéssel dolgozni ALIGN 2 vagy __packed elő/utó tagot használni.

-hasonlóan sokat lehet fogni, ha kihasználod a uC strukturáját vagyis, hogy támogatja az pointer+relativ cimzést, tehát egy nem egyedileg adod meg a változókat, hanem egy strukturában, így csak egy bázis cím lesz tárolva, és minden ehhez képest lesz megcímezve. Igy nem kell minden változó előtt egy címet megadni, majd beolvasni....  (ezek load/store processzorok, nem úgy mint a 8 bites eszközök amik közvetlenül is tudnak memóriában dolgozni)

-szintén nem érdemes ilyenkor a HAL-t használni, mert ez univerzális adott cég minden uC-hez való periféria kezelő egység, futási időben történő értelmezéssel, vagyis igen sok helyet foglal, fölöslegesen....

- amúgy a M3/M4 tömörebb kódot ad mint a M0!
 M0: harmad annyi ekvivalens kapu, olcsóbb, kisebb fogyasztással, M0+ mint az M0 gyorsított utasítás feldolgozó (2 ciklusos) + javított fogyasztási adatok, interpretálható 8K mélységű trace memória

-egy jól megírt programon igazából -O2 és -Os kb ~30% tömörséget ad, ez 50% és ennél nagyobb értékek esetén az eredeti program nem tökéletesen illeszkedik a uC felépítéséhez.

- egy dupla kapacítás ezeknek az eszközöknél legtöbbször $0.10 körül van, ez már csak több 10000db számoknál kezd érdekessé lenni...

- tokozás sok eszköz ezekben is elérhető SOIC20 alatt vagy QFN16 méretben ami már 3x3mm vagyis alapjában véve hely foglalást nézve nem sokkal nagyobb, mint SOT23, ezzel szemben minden ilyen eszköz támogatja a debuggolást és többfajta program feltöltést, égetést. Alapjába véve ezeknél a kisméretű eszközöknél az áramkörbe égetés biztosítása több helyet foglal el mint maga az áramkör :-(. Ami még szintén komoly hely igény az ezeknél az áramköröknél megkívánt 100nF szűrő kondik még ha 0402 terveznek már az is komoly helyigény.


Bali Zoltan <eltexto at freemail.hu> írta:
>Dehogynem, a kiírásban :) .
>
>"2388 bytes of readwrite data memory
>
>0x100-ra:
>"596 bytes of readwrite data memory"
>
>Üdv.  Zoli
>  
>
>
>
>
>2016.01.25. 17:57 keltezéssel, hg12345 írta:
>> Az nem foglal helyet :-)
>>
>> Bali Zoltan <eltexto at freemail.hu> írta:
>>> STM-nél a CSTACK 0x800 volt...
>>>
>>> Üdv.  Zoli
>>>
>>> 2016.01.25. 17:38 keltezéssel, Bali Zoltan írta:
>>>> Most nincs időm futtatni, ez egy lebegőpontos benchmark
>>>> program, amit lefordítottam. math, stdio, printf....
>>>>
>>>> /******************************************************/
>>>> // AVR opt. None
>>>> // 10 422 bytes of CODE memory (+ 136 range fill )
>>>> //    817 bytes of DATA memory
>>>>
>>>>
>>>> // AVR opt. High, Size
>>>> // 7 470 bytes of CODE memory (+ 136 range fill )
>>>> //   817 bytes of DATA memory
>>>>
>>>> /******************************************************/
>>>>
>>>> //  STM32F051  ARM Cortex-M0  opt. None
>>>> //  15 084 bytes of readonly  code memory
>>>> //     612 bytes of readonly  data memory
>>>> //   2 388 bytes of readwrite data memory
>>>>
>>>> //  STM32F051  ARM Cortex-M0  opt. High, Balanced
>>>> //  14 044 bytes of readonly  code memory
>>>> //     596 bytes of readonly  data memory
>>>> //   2 388 bytes of readwrite data memory
>>>> /******************************************************/
>>>>
>>>> Üdv.  Zoli
>>>>
>>>> 2016.01.25. 16:41 keltezéssel, Moravcsik Szilard írta:
>>>>> 2016.01.25. 12:12 keltezéssel, hg12345 írta:
>>>>>> Tapasztalatom szerint kb. hasonló helyfoglalása van mint egy PIC16/18 hasonló programnak.
>>>>>>
>>>>> Most néztem utána, a PIC16/18 is 16 bit széles kódot használ, mint a 8
>>>>> bites AVR-ek. Ha jól tudom, a Cortex-M0 is 16 bit széles (Thumb)
>>>>> utasítás készlettel működik, csak az adat kezelése 32 bites
>>>>> (címtartománya 4GB), talán az M3-tól már vegyesebb a kép.
>>>>>
>>>>> Kösz az infót!
>>>>>
>>>>> Üdv:
>>>>> Szilárd
>>>>>
>>>>>> Moravcsik Szilard <levlista.mszilard at gmail.com> írta:
>>>>>>> Sziasztok!
>>>>>>>
>>>>>>> Nézegettem az ST ARM mikrokontrollereit és feltűnt, hogy a kisebb
>>>>>>> típusoknak nem túl sok a belső flash memóriájuk. Az SRAM is szűknek
>>>>>>> látszik (pl. STM32F0x0 család, itt:
>>>>>>> http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1574).
>>>>>>>
>>>>>>> A tapasztaltabbakat kérdezem, hogy az ARM világban mire elég mondjuk
>>>>>>> 16kB (4k 32-bites Word) flash, meg mondjuk 4kByte (1k 32 bites Word) SRAM?
>>>>>>>
>>>>>>> Üdv:
>>>>>>> Szilárd
>>>>>>>
>>>>>>> ---
>>>>>>> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus védelme ellenőrizte azt.
>>>>>>> https://www.avast.com/antivirus
>>>>>>>
>>>>>>> -----------------------------------------
>>>>>>>              elektro[-flame|-etc]
>>>>>>>
>>>>>> -----------------------------------------
>>>>>>               elektro[-flame|-etc]
>>>>>>
>>>>> ---
>>>>> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus védelme ellenőrizte azt.
>>>>> https://www.avast.com/antivirus
>>>>>
>>>>> -----------------------------------------
>>>>>              elektro[-flame|-etc]
>>>>>
>>>>>
>>>> -----------------------------------------
>>>>             elektro[-flame|-etc]
>>>>
>>>>
>>> -----------------------------------------
>>>           elektro[-flame|-etc]
>>>
>> -----------------------------------------
>>            elektro[-flame|-etc]
>
>-----------------------------------------
>          elektro[-flame|-etc]