STM32F3 ADC

[Jan Waclawek]

Tie vysledky uz interpretovat bez blizsieho skumania disasm neviem (a mozno
ani po tom blizsom skumani - ako vravim, nie som ziadny insider ani guru).

CM4 ma instrucny prefetch, ak si dobre pamatam tak 5 instukcii, pricom
instrukcie su 16/32-bitove a I aj S zbernica (z ktorych sa vykonava) su
32-bitove. V 'F3 je prefetch (plytka - 1 alebo 2 riadky) aj na FLASH,
sirka riadku je eeee neviem treba sa pozriet do RM, ale urcite sirsia ako
32-bitov, mozno 128. Ale CM4 nie je superskalar a teda ani nema
speculative execution, ba dokonca nema ani branch prediction/speculative
prefetch (hoci v niektorych materialoch sa naznacuje ze nieco jednoduche
by mohlo byt, ale pokial viem, v ziadnej implementacii nie je nic take
pouzite). To jadro ma byt male a je (na dnesnu dobu) male. Ergo, voci
dlhemu linearnemu kodu vnasaju skoky (a u tej 'F3 aj citanie dat/konstant
z FLASH(*)) vyrazne spomalenie.

(*) Tu sa potom prejavi jednak ta kolizia s datami v tej istej pamati, coho
efekt ste videli predtym, a tiez pri vykonavani z FLASH sa da pouzit na
zrychlenie ta finta, ze sa adresy necitaju v jednej instrukcii ako data z
offsetu voci pc, ale sa skladaju z dvoch polslov dvomi instrukciami (za
pouzitia movt).

wek


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

Subject: Re: STM32F3 ADC
   From: Jaroslav Buchta <jaroslav.buchta at hascomp.cz>
   Date: Tue, 18 Dec 2018 22:03:53 +0100
     To: hw-list at list.hw.cz

>Tak jsem udelal par pokusu
>- presun adcsvc_IsrDma do CCM - minimalni vyznam, vysledek asi 2.3us, to 
>me trosku zklamalo
>- presun DMA1_Channel1_IRQHandler tamtez - 1.8us, coz mne prekvapilo - 
>kod vypada takto:
>
>FASTRUN void DMA1_Channel1_IRQHandler(void)
>{
>   /* USER CODE BEGIN DMA1_Channel1_IRQn 0 */
>     DIAG1_S();
>     if (LL_DMA_IsActiveFlag_HT1(DMA1))
>     {
>         adcsvc_IsrDma(0);
>         LL_DMA_ClearFlag_HT1(DMA1);
>     }
>     if (LL_DMA_IsActiveFlag_TC1(DMA1))
>     {
>         adcsvc_IsrDma(1);
>         LL_DMA_ClearFlag_TC1(DMA1);
>     }
>   /* USER CODE END DMA1_Channel1_IRQn 0 */
>
>   /* USER CODE BEGIN DMA1_Channel1_IRQn 1 */
>     DIAG1_R();
>
>   /* USER CODE END DMA1_Channel1_IRQn 1 */
>}
>
>Takze dobry, prvni pokus zklamal, druhy prekvapil, asi vliv skoku, 
>adcsvc_IsrDma  je prelozena tak, ze se provadi cela sekvencne, pokud 
>neni splnena nektera z podminek, coz samozrejme exekuci prodlouzi a tady 
>CCM ma viditelne velky vyznam (CM4 nema nejakou predikci a nepredcita 
>instrukce? )
>
>Dne 18.12.2018 v 21:11 Jan Waclawek napsal(a):
>>> Mohou tam [CCM RAM] byt i vektory,
>> No ak sa tam nakopiruju a prislusne zmeni SCB_VTOR, preco nie. Toto nie je
>> Cortex-M0 ale M4.
>>
>>> nebo jen v RAM,
>> Nerozumiem.
>>
>>> nebo to nema smysl presouvat z FLASH?
>>> Snizi to pozorovatelne latenci preruseni?
>> No, ak viete pozorovat usporu casu v trvani poctu waitstatov pre jeden
>> pristup do FLASH... :-) asi to nejaky valny vyznam nema.
>>
>> wek
>>
>>
>> ----- Original Message ---------------
>>
>> Subject: Re: STM32F3 ADC
>>     From: Jaroslav Buchta <jaroslav.buchta at hascomp.cz>
>>     Date: Tue, 18 Dec 2018 20:52:06 +0100
>>       To: hw-list at list.hw.cz
>>
>> Dekuji za osvetleni, zkusim tam jeste presunout program  ISR a data
>> nechat v RAM.
>>
>>
>> Dne 18.12.2018 v 20:34 Jan Waclawek napsal(a):
>>>> nejake vysvetleni?
>>> Tipujem, ze kolizia s pristupmi do FLASH na D-zbernici (z toho disasm by sa
>>> dalo mozno mudrovat viac, ale stale je to len mudrovanie; ak chcete cistu
>>> a nespornu pravdu, v ST radi nastartuju simulator, ak sa Vas odber zacne
>>> ratat na vagony).
>>>
>>> Ta CCM RAM v 'F3 je pripojena cez maticu zbernic, tj. inak nez je to v 'F4.
>>> A aj jej pouzitie a efekt je tym padom iny; predovsetkym je urcena na to,
>>> aby z toho bezal rychly kus programu namiesto z FLASH (ktora v 'F3 nema
>>> jumpcache a data cache, aka ART, ako to ma 'F4).
>>>
>>> JW
>>>
>>>
>>> ----- Original Message ---------------
>>> Tak super, uz to funguje jak vino.
>>> Jen jedna divna vec, zpracovavam tam rychle ADC data a myslel jsem si,
>>> ze kdyz vse, krome DMA bufferu presunu do CCM RAM, tak by se to mohlo
>>> trosku zrychlit protoze se pristupy do RAM nebudou prat s DMA - opak je
>>> pravdou, operace trva o chlup dele. Kod v disassembleru vypada tak nejak
>>> stejne, nejake vysvetleni?
>>> Testovaci program ISR je pro test zatim takto a ISR trva v prumeru 2.5us
>>> pro RAM a 2.7us pro CCM. V RAM ma cas trosku vetsi rozptyl. Nejake
>>> vysvetleni? Myslel jsem, ze CCM je pro procesor nejlepe pristupna, dela
>>> to nejaka zapisova cache?
>>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list at list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>
>
>_______________________________________________
>HW-list mailing list  -  sponsored by www.HW.cz
>Hw-list at list.hw.cz
>http://list.hw.cz/mailman/listinfo/hw-list