[elektro] STM32 átállás

[r3flow]

Szia!

Köszi az infót, akkor ez is kihúzva. :-D

Személy szerint nekem bevált az STM32, sokkal inkább mint az NXP. 
Cortex-M szériában ezen a kettőn kívül mást nem használtam még. De ott 
van még az Analog Devices, Nuvoton, Renesas, TI, Infineon... Ezeknek is 
van Cortex-Mx kontrollerük, már ha az STM32-vel túl sokáig tart esetleg 
elindulni... De visszautalva az eredeti levélre, gyanítom egyik sem 
szállít Atmel Studio/ASF szintű megoldást.

Z.

On 2017.01.26. 16:26, Moravcsik Szilárd wrote:
> Szia!
>
> 2016.11.21-én volt kollégám rossz tapasztalatai alapján írtam ezt:
>
> "Ők a Silicon Labs EFR32GB1 uC-kkel (ARM Cortex alapú, azt hiszem,
> bluetooth-szal is felszerelt) szenvednek már szó szerint hónapok óta.
>
> Elképesztően hiányos dokumentációkról és még trehányabb szoftver
> könyvtárakról panaszkodnak. A megvásárolt gyári hardver/szoftver
> fejlesztői környezettel kapott demo/tutorial források közül több annyira
> hibás, hogy le sem fordul a progi. Ha lefordul, akkor sem biztos, hogy
> azt csinálja, amiről a doksi ír. Pl. az ADC órajelét elfelejtik
> bekapcsolni, így az ADC meg sem mozdul, az "ADC konverzió kész" jelző
> bitre egy while() feltétellel vár a program időkifutás figyelés nélkül,
> amitől gyakorlatilag lefagy a rendszer, stb.
>
> Ugyanakkor a kollégák sok-sok év óta teljes megelégedettséggel
> használják a C51 alapú 8 biteseket tucatnyi termékben..."
>
> Üdv:
> Szilárd
>
> 2017. 01. 26. 7:52 keltezéssel, r3flow írta:
>>
>> Szia!
>>
>> Minden kezdet nehéz, ne add fel. :)
>>
>> Atmel szintű IDE/szoftver támogatása esetleg még talán a Silabs-nak van
>> de azt nem haszáltam soha. A többieknek semmi nem volt, cortexeket
>> általában az ipar használt ezek a felhasználók meg megvettek valami pár
>> ezer EUR-os IDE-t és kaptak hozzá mindent, így maguk a gyártók nem
>> fejlesztettek IDE-t, SW könyvtárból is csak minimumot. Ráadásul ezek az
>> ügyfelek szép számban vitték is a cortexeket így sem az NXP sem az ST
>> sem más cortex gyártó nem volt rászorulva a kis darabszámos hibb/mini
>> cégekre akik nem tudtak IDE-t venni maguknak. Egyedül a kínaiak kezdtek
>> el ingyenes IDE-t fejleszteni a CooCox-ot ami bár zártkódú viszont
>> ingyenes volt és tök jó. Neked első körben pont az kéne most mert kb.
>> Atmel Studio szintű sikerélményt tud adni. Sajnos évekig hanyagolták a
>> fejlesztést, STM32F0 támogatás nem tudom belekerült-e már, volt idő
>> mikor úgy tűnt, hogy megdöglött a projekt de most tán újra életrekelt
>> (persze kérdéses, hogy pl. az F0 szériát támogatja-e):
>> http://www.coocox.org/software.html
>>
>> Aztán jött a válság és hirtelen mégis kellettek az új piacok és kapkodni
>> kezdtek a gyártók, az NXP, az ST és a többiek.
>>
>> Az ST-nél teljes a káosz SW szinten. A lényeg, hogy a szélrózsa minden
>> irányában elkezdtek fejleszteni de ezek a fejlesztések egymástól
>> függetlenek. Legutóbb megbíztak egy francia csapatot egy zártkódú de
>> ingyenes IDE fejlesztésével (openstm32) de ez végtelenül fapados, és
>> például sokáig a cube sem volt képes projektet generálni hozzá, kézzel
>> kellett átszögelni. Az ST HAL lényege az, hogy plug and play gyorsan
>> tudjon elérni eredményt a fejlesztő, cserébe lassú, így igazából csak
>> prototípusokhoz jó. Vékony SW réteg az STM32 Standard Peripheral Library
>> volt, de ez nincs minden szériához és már abbahagyták a fejlesztését.
>> STM32-nél tehát vagy HAL-t használt játszani, vagy olyan szériát
>> választasz amihez van StdPeriphLib vagy megírod magadnak az alsó SW
>> réteget vagy veszel drága IDE-t amiben megtették ezt helyetted mások. Ha
>> a CooCox-on túlvagy akkor második körben továbbléphesz ChibiStudio-ra,
>> ezt egy olasz srác fejleszti az RTOS-e alá de standalone projektekhez
>> is jó
>> https://sourceforge.net/projects/chibios/files/ChibiStudio/
>>
>> Vagy ennél egyszerűbb lépcső az Atollic ingyenes IDE-je STM32-höz. Egyik
>> sem ad a kezedbe előre megírt Atmel szintű SW könyvtár, tehát az alap
>> problémát nem oldják meg, de az Atollic IDE-be pluginnal be lehet
>> integrálni a Cube-t és jól működik együtt a kettő, az ST HAL persze
>> játszós témakör. De már készül egy low level szintű HAL is, csak ki
>> tudja mikorra lesz kész vele az ST.
>>
>> Az NXP ezt a problémát úgy oldotta meg, hogy felvásárolt egy külsős
>> céget aki drága IDE-t fejlesztett kifejezetten NXP ARM-ekhez (codered)
>> és az NXP ezt kódméret limitációkkal ingyenessé tette.
>>
>> Egyedül a Silabs és az Atmel volt az aki kezdettől fogva máshogy
>> közelített a kérdéshez és nem hagyta figyelmen kívül a kis
>> felhasználókat.
>>
>> Az STM32 mikrokontrollerek maguk egyébként eléggé jók, átgondoltak jól
>> megtervezettek, képességekben gazdagok. Csak SW könyvtár nem nagyon van
>> hozzá, az házi feladat. Az NXP M0 kontrollerek sokkal fapadosabbak.
>> Atmelt ismered. Érdemes még Silabs és TI vonalon is nézelődni, hátha.
>>
>> Szóval kitartás. :)
>>
>> Üdv,
>> Z.
>>
>>
>> On 2017.01.24. 13:56, Bakcsa Zoltán wrote:
>>> Én mindig is atmel controllerekkel dolgoztam, de miután megvásárolta a
>>> MC,
>>> úgy gondoltam, ideje elkezdeni tapasztalatot gyűjteni más termékekkel
>>> is.
>>> Rendeltem egy Nucleo-767ZI-t meg egy másik, jóval kisebb nucleo-t, hogy
>>> ezeken tegyem meg az első lépéseimet.
>>>
>>> Az első nap után jelenthetem, hogy lassan ott tartok, hogy szó szerint
>>> fogok lépkedni rajtuk, de inkább ugrálni. Magukról a panelekről, vagy
>>> controllerekről amúgy nem tudok rosszat mondani (bár jót sem) mert odáig
>>> még nem jutottam el, hogy ilyen megállapításokat tehessek.
>>
>> -----------------------------------------
>>          elektro[-flame|-etc]
>
> ---
> Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
> https://www.avast.com/antivirus
>
> -----------------------------------------
>          elektro[-flame|-etc]