[elektro] STM32F446 TIMER3 interrupt

[r3flow]

A Ref link ugyanaz lett, ez volt a terv
http://infocenter.arm.com/help/topic/com.arm.doc.100166_0001_00_en/Chunk419908413.html


On 08/01/2018 05:15 PM, r3flow via Elektro wrote:
> 
> 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]
> 
> -----------------------------------------
>           elektro[-flame|-etc]