[elektro] STM32F446 TIMER3 interrupt

r3flow zoltan.nagy at vivor.hu
Wed Aug 1 17:15:30 CEST 2018


http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/Babcffjc.html

1 bájtos a write buffer. azért van, hogy ha éppen foglalt a busz amikor 
írnál a RAM-ba akkor a CPU-nak ezt ne kelljen megvárnia. nincs köze a 
flash wait state-hez, a flash az másik buszon van (ICode, DCode).

Kép
https://i.stack.imgur.com/8OKxY.png

Ref
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/Babcffjc.html

Üdv,
Z.


On 08/01/2018 03:28 PM, Bali Zoltán wrote:
> Hm, most volt egy kis időm, elgondolkodtam.
> A részleteket nem ismerem, ezért is merült
> fel bennem, minek cache-elni a SRAM-ot?
> Az FPGA-kban már 200MHz órajelű
> RAM blokkok vannak. Vagy az már nem buli?
> Annyival drágább a gyártása? Vagy majd az
> eljövendő sokkal nagyobb órajelű magok miatt
> ilyen a felépítés és kész.
> Vagy az AHB(mivel ezen lóg gondolom a sram is)
> flash wait state-jei miatt? Ezt sem tudom, hogy a
> wait state az egész lineáris címtartományra érvényes e?
> Rémlenek architect ábrák, de most nem vagyok képben,
> csak röviden szoktam időzni rajtuk, úgyis elfelejtem...
> 
> Üdv.  Zoli
> 
> 
> ----- Original Message ----- From: "r3flow via Elektro" <elektro at tesla.hu>
> To: <elektro at tesla.hu>
> Cc: "r3flow" <zoltan.nagy at vivor.hu>
> Sent: Tuesday, July 31, 2018 9:03 PM
> Subject: Re: [elektro] STM32F446 TIMER3 interrupt
> 
> 
> 
> Régen olvastam végig az ARM.com-ot a cortex doksit de van olyan emlékem,
> hogy külön felhívták a figyelmet arra hogy M3/M4 esetén ha túl gyorsan
> kilép az ISR akkor duplázás történhet, mert a memória írás ami törölné
> az interrupt bitet az írás cache miatt nem történik meg az ISR-ből
> kilépés előtt, emiatt a CPU újrahívja az ISR-t.
> 
> http://www.keil.com/support/docs/3928.htm
> 
> Üdv,
> Z.
> 
> 
> On 2018-07-31 20:23, Bali Zoltan wrote:
>>
>> Hali!
>>
>> Itt a már lekopasztott kód, ami most fut is valójában.
>>
>> void TIM3_IRQHandler(void)
>> {
>>   /* USER CODE BEGIN TIM3_IRQn 0 */
>>   GPIOC->BSRR = 1<<10;
>>   /* USER CODE END TIM3_IRQn 0 */
>> //HAL_TIM_IRQHandler(&htim3);
>>   /* USER CODE BEGIN TIM3_IRQn 1 */
>>   if(TIM3->SR & TIM_SR_UIF) {
>>   }
>>   TIM3->SR  = TIM3->SR & ~TIM_SR_UIF;
>>   GPIOC->BSRR = 1<<(10+16);
>>   /* USER CODE END TIM3_IRQn 1 */
>> }
>>
>> F446, 48MHz, maximális optimalizálással, mindenféle prefetch
>> varázslás kikapcsolva, csak UIE-vel, kétszer fut le az interrupt.
>> A csatornák PWM-re vannak állítva, belső órajel, semmi különleges.
>> Optimalizálás nélkül, egy interrupt van csak, mint a másik(F051)
>> képen. Persze, ekkor  hosszabb ideig magas a billentett port.
>> Lehet túl rövid az IT futása? Ha bent volt a végrehajtási
>> saját kódom is, akkor időnként duplázott csak. Azután kezdtem
>> lekopasztani, miután az a gyanúm támadt, hogy a futási idővel van
>> összefüggésben. Speciel most, pont kéne, hogy minél rövidebb legyen
>> az IT... Volt már olyan változat, hogy SR regiszter simán nullázva.
>>
>> http://www.kepfeltoltes.eu/images/hdd1/2018/07/31/14620180731173944.png
>>
>>
>> Átraktam a kódot, F051-re, ugyanazzal(remélem, mert Cube MX-el
>> generáltam újra). Ez max optimalizálással sem dupláz, a fenti IT kóddal-
>>
>> http://www.kepfeltoltes.eu/images/hdd1/2018/07/31/49920180731172830.png
>>
>> F446-on még az IT prioritásokat vissza vettem mindet 4-re, csak a TIMER3
>> van 0-án.
>>
>> Errátát néztem, semmi timer, IT vonatkozás.
>>
>> Ötlet? Tapasztalat?
>>
>> Köszi
>>
>> Üdv.  Zoli
>>
>> -----------------------------------------
>>          elektro[-flame|-etc]
> 
> -----------------------------------------
>           elektro[-flame|-etc]
> 
> -----------------------------------------
>           elektro[-flame|-etc]



More information about the Elektro mailing list