gcc, arm, pristup k periferiim

[Jan Waclawek]

Vlastne...

... dlhsie studium toho .lst ...

... musim sa gcc ospravedlnit. 

Ked som namiesto

  WRITE_REG(hspi->Instance->CR1, (hspi->Init.Mode | hspi->Init.Direction |
hspi->Init.DataSize |
                                  hspi->Init.CLKPolarity |
hspi->Init.CLKPhase | (hspi->Init.NSS & SPI_CR1_SSM) |
                                  hspi->Init.BaudRatePrescaler |
hspi->Init.FirstBit  | hspi->Init.CRCCalculation) );

pouzil

  WRITE_REG(SPI1->CR1, (hspi->Init.Mode | hspi->Init.Direction |
hspi->Init.DataSize |
                                  hspi->Init.CLKPolarity |
hspi->Init.CLKPhase | (hspi->Init.NSS & SPI_CR1_SSM) |
                                  hspi->Init.BaudRatePrescaler |
hspi->Init.FirstBit  | hspi->Init.CRCCalculation) );


tak cela ta tirada konci (porovnaj so zaverom v
https://list.hw.cz/pipermail/hw-list/2018-August/510530.html kde je adresa
daneho SPI registra v r3, kam bola predtym pracne vyskladana po bytoch
citanych zo vstupnej struktury):
 814 028e 4A4A     		ldr	r2, .L34	@ tmp560,
 815 0290 1660     		str	r6, [r2]	@ D.8423, MEM[(struct SPI_TypeDef
*)1073819648B].CR1
(pricom 
 978              	.L34:
 979 03b8 00300140 		.word	1073819648
[nie je mi jasne, preco v toml listingu musia byt byty v poli dat
usporiadene ausgerechnet little endian, ale to je len esteticky problem,
nikto normalny do tych .lst nepozera]).

Cize, ak v zapise je priamo register, ktory treba, tak sa k nemu pristupuje
wordovo, aj ked je zapnute packovanie.

Inaksie povedane, gcc v povodnom pripade pouzije ten bytovy pristup len
kvoli tomu, lebo adresa registra mu je odovzdana cez premennu (ktora je v
tej inicializacnej strukture), takze v okamihu prekladu gcc nevie, ci ta
premenna ukazuje na deklarovanu premennu toho SPI typu (co je tiez
struct), na ktorej by si mohol vynutit zarovnanie od linkera, alebo je ta
SPI struktura polozkou v nejakej vacsej strukture, ktora by mohla byt
kvoli packovaniu nezarovnana...


... cize sa jedna o zasluzeny trest za pouzivanie "kniznic" typu Cube/HAL.

wek



----- Original Message ---------------

>Nemusi, vid ten citat od armu.
>
>Ak je struct ako taky zarovnany (co prekladac moze od linkera vynutit), tak
>prekladac presne vie, ako su zarovnane jeho jednotlive polozky, a tak k
>nim moze pristupit. Ak by to tak nebolo, tak ani po odstraneni
>fpacked-struct by sa nemohlo k jednotlivym polozkam pristupovat inak ako
>po bytoch.
>
>Hento podla mna najdete v bugzille gcc ako poziadavku aby sa to vylepsilo v
>tomto smere, nejdem to hladat.
>
>wek
>
>
>
>----- Original Message ---------------
>>Nikoli možná, ale zcela určitě. U Cortex-M0 je nezarovnaný přístup velký 
>>problém, takže překladač to rozložit vlastně musí. Pořád je to lepší než 
>>u starých verzí, kdy to rovnou spadlo do hardfaultu. Takže data, která 
>>zapisujete (čtete) musí mít explicitní zarovnání pomocí např. 
>>__attribute__ ((aligned (4))). U Cortex-M3,4 tohle dělat nemusíte, ale 
>>ani tam to není na škodu - mělo by to být o něco efektivnější.
>>
>>Mrazík
>>
>>Dne 17.8.2018 v 13:09 Jaroslav Buchta napsal(a):
>>> ...
>>>  Mozna je to i tim, ze struktura nema 
>>> attribut zarovnani na 4B.