GCC optimalizace, zahada
Jaroslav Buchta
jaroslav.buchta na hascomp.cz
Sobota Listopad 4 14:25:03 CET 2017
Diky za rozbor, zas je clovek o neco chytrejsi ;-)
To casovani zkusim nejak otestovat, ale myslim, ze zrovna tohle bude OK
- ty radice jsou vesmes podobne a v tomhle paralelnim modu maji setup a
delay casy vesmes 0ns, delka WR pulzu byva desitky ns, navic to funguje
stabilne dobre nebo spatne na cele plose, IMHO se proste nenastavuji
nektere bity. Drivery na desce jsou HC245, nejak jsem jejich zapojeni
nepochopil - asi jsou tam kvuli 5V arduinu i kdyz nevim, co to pomuze,
napajene jsou z 3V3 jak jsem omeril. Datovy ma i prepinani smeru od RD,
cteni jsem zkousel na nejakem stavovem registru a hodnoty sedi. Z
obvyklych lokalizaci ID radicu to ale nic smysluplneho neprecte.
Instrukci Read ID4(0xD3) mi to cte 00, 01, 22h - to nedava smysl. Jako
bonus je u techto displeju touch screen zapojen mezi RS, WR a datove
piny - pri 300 ohmech a jeste lepe pri dotyku to dela na signalech
"zajimave" efekty, ale asi diky HC driveru to funguje i pri osklivych
napetich, chce to tvrdsi buzeni coz STM32 celkem dava pri nastaveni
nejrychlejsich vystupu, do limitu HC urovni se to vejde.
Mam to jenom na hrani, zadny dulezity projekt to neni takze priorita je
nizka, patrani po typu radice vzdavam. Ten displej ale zobrazuje fakt
hezky, prekvapive rovnomerne podsviceni, syte barvy a 320*480 za
nejakych 150 Kc...
Dobry tip s tou maskou pro BSRR, asi to usetri par instrukci, o teto
vlastnosti jsem vedel ale nijak jsem si to nespojil s touto moznosti
pouziti.
Dne 04.11.2017 v 13:22 Jan Waclawek napsal(a):
> No tak potom problem nie je tam.
>
> Cele to zacalo tym, ze v 'F1 je GPIO na APB a naviac jeho registre su
> pristupne len 32-bitovo (aj ked je napr. BRR defacto 16-bitovy), a tak
> niekoho napadlo, ze okrem toho BSRR registra, ktorym sa da nulovat aj
> nastavovat naraz, sa urobi este aj ten BRR register, ktory je pre vsetky
> prakticke ucely zbytocny. Moj osobny tip je, ze v ST zrecyklovali IP z
> nejakeho starsieho designu, mozno 8- alebo 16-bitoveho, kde na jeho
> existenciu boli nejake velmi dobre dovody.
>
> Dalsim modelom bola 'L1 a v nej je uz GPIO na AHB (asi bol krik, ze sa s
> GPIO neda robit tak rychly toggle ako u konkurencie, hoci je to IMO
> pomerne neuzitocna poziadavka, ale taky je uz zivot), uz je 8/16/32-bit
> pristup, a ten BRR tam je tiez. Toto je zachovane aj v 'F0 a 'F3, zrejme
> zo zotrvacnosti.
>
> V 'F2/'F4 uz ten zbytocny register nie je, co ale znamena, ze struktura pre
> GPIO v headeri z 'F4 SPL vyzera inak:
> typedef struct
> {
> __IO uint32_t MODER; /*!< GPIO port mode register,
> Address offset: 0x00 */
> __IO uint32_t OTYPER; /*!< GPIO port output type register,
> Address offset: 0x04 */
> __IO uint32_t OSPEEDR; /*!< GPIO port output speed register,
> Address offset: 0x08 */
> __IO uint32_t PUPDR; /*!< GPIO port pull-up/pull-down register,
> Address offset: 0x0C */
> __IO uint32_t IDR; /*!< GPIO port input data register,
> Address offset: 0x10 */
> __IO uint32_t ODR; /*!< GPIO port output data register,
> Address offset: 0x14 */
> __IO uint16_t BSRRL; /*!< GPIO port bit set/reset low register,
> Address offset: 0x18 */
> __IO uint16_t BSRRH; /*!< GPIO port bit set/reset high register,
> Address offset: 0x1A */
> __IO uint32_t LCKR; /*!< GPIO port configuration lock register,
> Address offset: 0x1C */
> __IO uint32_t AFR[2]; /*!< GPIO alternate function registers,
> Address offset: 0x20-0x24 */
> } GPIO_TypeDef;
>
> toto si vyzaduje bud to predefinovat (to je primarny dovod preco som tie
> headery prepisoval, aj ked viem ze to nie je dobry napad) alebo urobit ten
> typecast co ste urobili. Kedze ste pisali, ze to pomohlo, tak som cakal,
> ze mate nejaky hybridny header z nejakeho ktovieakeho zdroja, ktory vyzera
> nejako takto ako tento z 'F4, a teda ze v nom je BSRR definovany tak ako
> tu ten BSRRL, t.j. ako 16-bitovy. Jeden nikdy nevie, a ja 'F3 nepouzivam.
>
> Mimochodom, pri robeni Cube mali genialny napad vsetko zmenit, takze v
> headeri z CubeF4 je tato struktura takto:
> typedef struct
> {
> __IO uint32_t MODER; /*!< GPIO port mode register,
> Address offset: 0x00 */
> __IO uint32_t OTYPER; /*!< GPIO port output type register,
> Address offset: 0x04 */
> __IO uint32_t OSPEEDR; /*!< GPIO port output speed register,
> Address offset: 0x08 */
> __IO uint32_t PUPDR; /*!< GPIO port pull-up/pull-down register,
> Address offset: 0x0C */
> __IO uint32_t IDR; /*!< GPIO port input data register,
> Address offset: 0x10 */
> __IO uint32_t ODR; /*!< GPIO port output data register,
> Address offset: 0x14 */
> __IO uint32_t BSRR; /*!< GPIO port bit set/reset register,
> Address offset: 0x18 */
> __IO uint32_t LCKR; /*!< GPIO port configuration lock register,
> Address offset: 0x1C */
> __IO uint32_t AFR[2]; /*!< GPIO alternate function registers,
> Address offset: 0x20-0x24 */
> } GPIO_TypeDef;
>
>
> No ano, niekomu treba silno tresnut po prstoch klavesnicou.
>
> K anonymnym unionom a MISRE a spol. sa na tomto mieste nejdem vyjadrovat (v
> tom mojom prepisanom headri som ten union bez vahania pouzil, ale s
> vedomim, ze ten header je moj a nepotrebujem aby bol prenositelny a
> MISRA-compliant).
>
> Toto ale s Vasim problemom nesuvis.
>
> -----
>
> Chodte do RM a vsimnite si poznamku pod popisom toho BSRR registra:
>
> Note: If both BSx and BRx are set, BSx has priority.
>
> Z toho vyplyva, ze pri takychto "prehadzanych" pinoch sa da do horneho
> halfwordu BSRR dat konstanta ako maska, a do dolneho halfwordu
> "rozhadzana" verzia "zdrojoveho" slova, co sa zase da niekedy dost
> efektivne riesit tabulkou. Nie je to univerzalne lepsie riesenie, ale
> jedno z tych co stoja za zvazenie.
>
> -----
> Datova bariera je mozno dobry sposob na "o nieco dlhsi kratky delay",
> naviac dava istotu ze sa tie dva zapisy separuju - ale u STM ta istota je
> uz dana tym ze GPIO (ako aj drviva vacsina ostatnych periferii, ak nie
> vsetky) su namapovane v oblasti ktora je oznacena "Device", t.j.
> "bufferable, non-cacheable"; ten druhy atribut by mal zabezpecit, ze sa
> dva zapisy na tu istu adresu nespajaju.
>
> Instrukcnu barieru by som vsak ja osobne na delay nepouzil, lebo by som sa
> obaval, ze jej efekt co sa tyka oneskorenia zavisi od polohy kodu voci
> riadkom pamate a aktualnemu stavu jumpcache a prefetch bufra na strane
> FLASH - hoci toto je mozno neopodstatnena obava.
>
>
> -----
>
> Vas zakladny problem je mozno v nedodrzani setup-hold casov toho displeja,
> t.j. casovanie zmeny dat voci relevantnym hranam
> read/write/chipselect/cojaviemcoho. Jednak tam mate zrejme pomerne dlhe
> cesty po Nucleu a nasledne po tej doske displeja, potom akesi buffre na
> tej doske, o ktorych ste sa ani nezmienili; no a ako bonus, netusite, aky
> kontroler pouziva. Inaksie povedane, ak mate "nejaky" problem (t.j.
> neviete ho dostatocne presne popisat), a riesite ho "nejako" (nie je Vam
> uplne jasny vztah medzi C zdrojakom a vyslednym casovanim), tak dostanete
> "nejaky" vysledok.
>
> Zacal by som studiom casovania niekolkych kandidatov na ten kontroler;
> odhadom, co mozu urobit tie delaye a tie buffre; a pridanim delayov na
> miesta kde treba zarucit oneskorenia, radsej viac nez menej; pripadne
> priamo prepisanim celych kritickych sekvencii do asm.
>
> wek
>
>
> PS. Pouzitie tych rychlejsich 32-bitov prinasa niekedy necakane problemy
> takehoto druhu, t.j. ze su prirychle a presne casovanie sa dosahuje
> relativne tazko. Napr. riadenie HD44780-kompatibilneho LCD, co v 8-bitoch
> bolo kratke cvicenie o par NOPoch, sa zrazu premenilo na pomerne rozsiahlu
> sagu o timeroch, DMA a preruseniach...
>
>
>
>
> ----- Original Message ---------------
>
>> Koukam, casto, ale z tohodle nic moc relevantniho nevykoukam. Proste je
>> BSRR 32b stejne jako BRR kde je vyuzita jen spodni pulka.
>> polozka struktury je volatile a uint32_t, cekal jsem, ze s tim nebudou
>> problemy.
>>
>> typedef struct
>> {
>> __IO uint32_t MODER; /*!< GPIO port mode
>> register, Address offset: 0x00 */
>> __IO uint32_t OTYPER; /*!< GPIO port output type
>> register, Address offset: 0x04 */
>> __IO uint32_t OSPEEDR; /*!< GPIO port output speed
>> register, Address offset: 0x08 */
>> __IO uint32_t PUPDR; /*!< GPIO port pull-up/pull-down
>> register, Address offset: 0x0C */
>> __IO uint32_t IDR; /*!< GPIO port input data
>> register, Address offset: 0x10 */
>> __IO uint32_t ODR; /*!< GPIO port output data
>> register, Address offset: 0x14 */
>> __IO uint32_t BSRR; /*!< GPIO port bit set/reset
>> register, Address offset: 0x1A */
>> __IO uint32_t LCKR; /*!< GPIO port configuration lock
>> register, Address offset: 0x1C */
>> __IO uint32_t AFR[2]; /*!< GPIO alternate function
>> registers, Address offset: 0x20-0x24 */
>> __IO uint32_t BRR; /*!< GPIO bit reset
>> register, Address offset: 0x28 */
>> }GPIO_TypeDef;
>>
>> Dne 04.11.2017 v 9:57 Jan Waclawek napsal(a):
>>>> A ten registr BSRR se da pouzivat i sestnactibitove?
>>> TAK SA UZ POZRITE DO TOHO **** HEADERU!
>>>
>>> wek
>>>
>>> _______________________________________________
>>> HW-list mailing list - sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> 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