Programovani ARM, bylo prepinani seriovek

[Jan Waclawek]

Aaaa neberte to osobne, to bol len vytrysk frustracie... ;-)

wek

----- Original Message ---------------
>Celá ČR je v ST pod hranicí šumu. To že nás poctili lokální zástupci 
>návštěvou bylo hlavně to, že jsme s tím procesorem začali hodně za 
>tepla, tuším v roce 2008.
>
>Jakákoliv kritika (kterou můj šéf tehdy nezanedbal, já byl ještě čerstvý 
>absolvent) do ST zcela jistě nijak nedolehla.
>
>Dne 13. 03. 19 v 15:51 Jan Waclawek napsal(a):
>> Tak toto je, s prepacenim, sprostost.
>> 
>> Zakladny problem je v tom, ze ST nie su ochotni slusne zdokumentovat tie
>> periferie, a urobit k nim sadu slusnych prikladov. Si uvedomte, ze kazda
>> jedna periferia je zlozitostou na urovni nejakej '51 - k tym boli tucty
>> prikladov a aplikacnych poznamok, takze tu by tiez mali byt ku *kazdej*
>> periferii tucty prikladov (k niektorym stovky) a aplikacnych poznamok.
>> Typicky su priklady dva ci tri, ak ich je viac, tak su to len nezaujimave
>> derivaty; a ak je appnote, tak z neho 50% je len opisane z manualu a
>> zvysok su screenshoty z CubeMX (a to vsetko v tej "trendy" modrej scheme
>> ;-) )
>> 
>> Lenze zakladny problem je ten, ze kym do nich bude busit nejaky wek s
>> kupnou silou niekde na urovni sumu, tak to s nimi nic nespravi. A ak taki,
>> ktorym davaju ST sukromne seminare, zaujmu postoj ze "tak ako nam povedali
>> je to dobre", tak sa to nikdy nezlepsi.
>> 
>> Ano, existuju aj necakane interakcie, ale tie sa maju dostat do errat. Mam
>> sem dat zoznam toho na co som len ja sam narazil, publikoval, a ST na to
>> zvysoka kasle?
>> 
>> wek
>> 
>> 
>> 
>> ----- Original Message ---------------
>> 
>> Subject: Re: Programovani ARM, bylo prepinani seriovek
>>     From: Martin Úlehla <ok9swl at gmail.com>
>>     Date: Wed, 13 Mar 2019 15:27:39 +0100
>>       To: hw-list at list.hw.cz
>> 
>>> Ještě bych zde do komunity předal jedno varování...
>>>
>>> Měli jsme schůzi se zástupci ST, protože jsme jako jedni z prvních
>>> narazili na problém zpětného "kopnutí" u A/D na STM32F1 řady. Řešení
>>> tohoto problému jsme sice nedostali, řekli nám tehdy že A/D mají
>>> koupené, ale....
>>>
>>> Některé funkce jsme nepoužívali z jejich knihovny, ale kvůli rychlosti
>>> (motor control) jsme v přerušení přistupovali přímo na registry. Byli z
>>> toho dost odvaření a důrazně nás upozorňovali, že *ne všechny logicky
>>> správné sekvence nastavení registrů vedou k fyzicky správnému chování
>>> procesoru*.
>>>
>>> Tedy když už chcete přistupovat k HW přímo bez jejich knihovny, dostali
>>> jsme instrukci ať kopírujeme/dodržujeme sekvence nastavení z jejich
>>> knihoven. Pokud toto nedodržíte, může být chování procesoru
>>> nepředvídatelné a datasheet toto nepokrývá (nepočítá se při složitosti
>>> procesoru s přímým střílením hexačísel do registrů).
>>>
>>> Jak moc je to vážné varování jsem se nikdy nedozvěděl, ale neměl jsem
>>> potřebu se mu zbytečně protivit a ctím to dodnes i u konkurenčních
>>> procesorů. Jak víte v oblasti pohonů končí chyby hromádkami drahého uhlí.
>>>
>>> Martin
>>>
>>> Dne 13. 03. 19 v 15:08 Miroslav Mraz napsal(a):
>>>> Asi to není tak jednoduché. Jen těch modelů od ST je tolik, že se v tom
>>>> ztrácím. A zřejmě se v tom ztrácí i to ST. Překladačů pro platformu ARM
>>>> je také hodně - namátkou IAR, Keil (ARM), gcc, clang a kdoví co ještě.
>>>> Když ve firemním IDE použijete jeden, naštvete ty, co používají jiný,
>>>> když to uděláte pro všechny (a ST to má pro ty hlavní uděláno), bude z
>>>> toho nepřehledný moloch.
>>>> Pak zbývá ta obtížnější cesta - naučit se jak to funguje. Věřte, že
>>>> pokud to uděláte, zjistíte, že na tom zase tak moc složitého není. V
>>>> mnohém jsou ty ARMy na programování jednodušší než mnohý 8-bit. A
>>>> protože  obsluha periferií je většinou jen malou částí projektu, poznáte
>>>> výhody 32-bitové architektury a zpátky se vám už nebude chtít vracet.
>>>>
>>>> Mrazík