STM32F0 periph. library

[Miroslav Mraz]

To máte do velké míry pravdu. Fakt je, že to co jsem dělal "na kšeft", v
tom byly ty původní periferní knihovny od ST jen aby to bylo z krku. Ale
když se tím bavím, řídím se heslem - kdo nechce hledá důvod, kdo chce
hledá způsob. Diskuse zde vedená tomu pak dost pomůže. Děkuji panu
Štenglovi za podnětné připomínky z praxe. Na většinu toho už jsem přišel
sám, něco jsem dosud tušil, ale nevěděl.
A i když je těch důvodů proč to nedělat tolik, žádný z nich mě zatím
nepřesvědčil, že v tomto konkrétním případě (obsluha periferií CMx) bych
to dělat neměl. Jen jsem slevil v tom, že nechám původní definice
periferií a asi nebudu používat enum.
To, že něco tak dělají všichni, to opravdu není argument. Všichni to
píšou v čistém C. Ale i vy sám zkoušíte C++, C# a jiné. Něco stále
zkoušet je dost dobrý způsob, jak se to naučit. A o to jde.

Mrazík

On 07/17/2014 10:33 AM, Jaroslav Buchta wrote:
> Me prijde, ze jediny duvod k pouzivani techto konstrukci je
> programatorsky exhibicionismus, nakonec normalne se stejne obsluha
> periferii recykluje z nejakeho prikladu a trosku se priohne, zbytecne
> bych si komplikoval zivot, kdybych nepouzival #define symboly ktere
> pouzivaji skoro vsichni.
>
> Dne 17. 7. 2014 9:41, Josef Štengl napsal(a):
>> Proč ne bitová pole? Tak tedy proč ne:-)
>>
>>  ✔ nejde vytvořit ukazatel na položku - někdy to může vadit a už jsem
>> se s tím setkal (to je obecně důvod, proč nemám rád bitová pole jako
>> taková)
>>
>>  ✔ jsou závislá na aktuální endianitě - existují architektury které
>> jsou biendian (například ARM cortext R,A, netýká se M) a máte 2
>> projekty které používají 2 čipy s malým a velkým indiánem a až na
>> jednu periférii jsou shodné (také jsem se setkal) - takže je píšete 2x
>>
>>  ✔ delší kód - každý přístup do položky pole je vlastně fyzický
>> přístup na periférii; ano podmínkou je, že adresový prostor je
>> definován jako volatile ale to je nutnost už z důvodu časování nebo
>> prostý zápis 1-0-1 na I/O nebo zabránění out-of-order vykonávání
>> instrukcí při použití optimalizace.
>>
>>  ✔ použití unionu aby jste se dostal k celému registru - pro
>> bezpečnostní aplikace (a nemusí to být zrovna automotive ale i
>> obyčejné pohony) je union nedoporučován. Ono to má rozumné důvody.
>>     - C norma nedefinuje že položky v unionu zabírají jeden adresový
>> prostor - je to sice chování většiny kompilátorů, ale není to
>> zaručeno, což norma výslovně uvádí.
>>     - opět problémy s endianitou
>>     - možné problémy se zarovnáním položek v poli, pokud je union
>> složitější (ono je třeba si na to dát pozor i u struktury)
>>     - k položce/registru existuje více možností přístupu - to slušně
>> napsané programy nedělají (proč doufám vysvětlovat nemusím)
>>
>>  ✔ není specifikováno jak se k registru bude přistupovat; pokud
>> zapisuji jeden bit tak jako byte? Nebo int? a co když nemá registr
>> velikost int a podobně?
>>
>>  ✔ možná ztráta informace - existují registry, většinou RO status
>> flagy, jež jsou mazány čtením. Program samozřejmě nepřečte jen ten
>> byte, který zrovna požadujeme.
>>
>>
>> Se všemi těmito problémy jsem se setkal během své profesní kariéry a
>> někdy stály docela dost peněz. A ještě jsem nenarazil na problém kde
>> by bitové pole nebo union bylo výhodnější použít oproti ostatním
>> způsobům poskytovaným jazykem.
>>
>> ced