STM32F0 periph. library

Jaroslav Buchta jaroslav.buchta na hascomp.cz
Středa Červenec 16 18:34:15 CEST 2014


No jestli neni nakonec lepsi pouzit ty knihovny k periferiim a je po 
problemu s manipulaci s bity SFR ;-) ( az na vyjimky)


Dne 16. 7. 2014 17:35, Miroslav Mraz napsal(a):
> No vidíte, mě se zase nelíbí tento styl kódování. Pokud C umožňuje
> zapouzdřit jediný nebo skupinu bitů do struktury, tak proč to neudělat.
> Spíš je otázkou, zda použít enum jako další pouzdro. Ale zase je to jen
> otázka vkusu. Pokud to mám udělat čistě objektově, tak to použiju, s
> vědomím určitých rizik. Není to však bezpodmínečně nutné. V bitovém poli
> samotném problém skutečně nevidím:
> - přenesení na jinou endianitu mě opravdu nezajímá, to co s tím chci
> dělat je obsloužit periferie u zcela konkrétního procesoru
> - dobrý kompilátor s rozumnou optimalizací to přeloží úplně stejně
> - dá se to číst ještě lépe protože
> - pro nastavení jednotlivých bitů použiju prosté =
>
> Jen je to víc psaní. To u objektů bývá. Nicméně se začínáme shodovat na
> tom, že enum ne.
>
> Mrazík
>
> On 07/16/2014 10:32 AM, Josef Štengl wrote:
>> Pokud myslíte ten kód v main() a ne tu union-bitové pole hrůzu*, tak
>> je to asi lepší řešení. Tedy
>>
>>   + je to nezávislé na endianitě (pokud pracujete s BiEndian procesorem
>> (například arm) a překládá se to podle projektu, tak je to nutnost –
>> jinak by jste musel definovat bitová pole 2x)
>>   + kompilátor to má šanci rozumě zoptimalizovat
>>   + dá se to číst
>>
>>   - pro nastavení jednotlivých bitů je nutno definovat makro/funkci.
>>
>> Používat k těmto účelům enum je hazard s infarktem. C definuje enum
>> jako int (problém s nastavením nejvyššího bitu pro unsigned registy) a
>> překladače jsou přednastaveny všelijak - většinou packed (velikost
>> typu podle hodnot v enumu + signed/unsigned), což přináší takové
>> zajímavé varování kompilátoru a statické analýzy kódu - většinou jsou
>> v rozporu a občas i v chování.
>>
>> Mimochodem místo definování OR bych použil knihovnu  <iso646.h>. Ale
>> chápu, že je makra jsou tam definována malými písmeny :-)
>>
>> Pro mě je elegantní definovat:
>>   - registr o celé šířce
>>   - konečné pozice jednotlivých složek bitů
>>   - makro na skládání/pozici
>>
>>
>> zjednodušený příklad:
>>
>> #define DEV_CTRL_A    0u
>> #define DEV_CTRL_B    1u
>> #define DEV_CTRL_C    3u
>>
>> #define rbval(val, bitpos)    ((uint32_t)val << bitpos)
>>
>> volatile struct dev
>> {
>>      uint32_t ctrl;
>>      uint32_t set;
>>      uint32_t clr;
>> ...
>> }
>> dev;
>>
>> dev.ctrl = rbval(0u, DEV_CTRL_A)
>>           | rbval(3u, DEV_CTRL_B)
>>           | rbval(1u, DEV_CTRL_C)
>>           | rbval(1u, 6u)    /* kdo by se s tím psal .. */
>>
>> Ano, je otázkou, jak jsou zpracované dodané knihovny registrů.
>> .. a je docela pracné napsat ty pozice bitů.
>>
>> ced
>>
>>
>> * opravdu mě nebaví se dívat co z toho kompilátor na které
>> architektuře vytvoří a při jaké optimalizaci a verzi. Je to zvrácenost
>> jako mrkev s bramborami (tedy pro mě :-).
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list



Další informace o konferenci Hw-list