HALMX :: MXBluePillF103C8 Roadmap

Development of new Cores using the STMCubeMX and HAL
User avatar
Slammer
Posts: 255
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Slammer » Wed May 18, 2016 7:21 am

ekawahyu wrote: ...
I had to comment out these two lines due to conflict (itoa.h):
...
Which version of compiler are you using? As I remember the gcc 4.8 has no problem with itoa, but in newer versions there is conflict. Normally the __STRICT_ANSI__ compiler flag resolves the problem (I tested with 4.9 and 5.1)
Last edited by Slammer on Wed May 18, 2016 9:31 am, edited 1 time in total.

User avatar
ekawahyu
Posts: 107
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by ekawahyu » Wed May 18, 2016 7:34 am

Ok, that works! I am using 5.2.1

User avatar
ekawahyu
Posts: 107
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by ekawahyu » Thu May 19, 2016 5:33 am

I got a little issue with STM32CubeMX, you guys probably already know the answer. I am trying to configure an auto-reload timer with an interrupt. I can enable/disable it, but the Preemption Priority number is always greyed out. I could modify the source code, but that would defeat the purpose of generating the code from STM32CubeMX. Do I need to configure something else so that this Preemption Priority can be modified?

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by stevech » Thu May 19, 2016 4:00 pm

It's rare to need preemption. Is there a particular rationale for needing it?

I have one situation where it's needed, due to high frequency EXTI interrupts from an ASIC than needs a few tens of microseconds' interrupt latency worst case. CubeMX lets me set that preemption priority.

For recurring timer interrupts, as I recall, the timer hardware (not the ISR) reloads the interval counter automatically if configured for such.

User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Thu May 19, 2016 6:52 pm

ekawahyu wrote:I got a little issue with STM32CubeMX, you guys probably already know the answer. I am trying to configure an auto-reload timer with an interrupt. I can enable/disable it, but the Preemption Priority number is always greyed out. I could modify the source code, but that would defeat the purpose of generating the code from STM32CubeMX. Do I need to configure something else so that this Preemption Priority can be modified?
if i understood correctly, to enable the Preemption Priority on CubeMX go to Configuration tab -> NVIC, select the interrupt you want to enable and set the Preemption Priority.
If the interrupt is already enabled, just change the priority value.

User avatar
ekawahyu
Posts: 107
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by ekawahyu » Thu May 19, 2016 7:59 pm

I have been there and enabled the interrupt, but it is still greyed out. Even I tried to save it, generate the code, etc. Could you show it the exact steps you did on BluePill? I must have missed one step somewhere.

User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Thu May 19, 2016 8:47 pm

nvic_.jpg
nvic_.jpg (145.94 KiB) Viewed 661 times
nvic.jpg
nvic.jpg (217.19 KiB) Viewed 661 times

User avatar
ekawahyu
Posts: 107
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by ekawahyu » Thu May 19, 2016 9:49 pm

Got it! My bad, I didn't look at the System tab for the NVIC. All is good! Thanks Vassilis!

User avatar
ekawahyu
Posts: 107
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by ekawahyu » Fri May 27, 2016 6:24 am

@Vassilis: I can see that the USBSerial has RX (and potentially TX) buffers, but I also see that usb_cdc_if.c has both RX and TX buffers declared instead of pointing to the USBSerial's. What is your plan with this? Which one you would get rid of?

User avatar
Vassilis
Posts: 320
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Fri May 27, 2016 11:35 am

ekawahyu wrote:@Vassilis: I can see that the USBSerial has RX (and potentially TX) buffers, but I also see that usb_cdc_if.c has both RX and TX buffers declared instead of pointing to the USBSerial's. What is your plan with this? Which one you would get rid of?
Well, the usb_cdc_if.c uses its own rx and tx buffers for each incoming/out-coming data batch. That means, if you send 4 bytes from your serial terminal to the STM32 those bytes will be written into the UserRxBufferFS[APP_RX_DATA_SIZE] buffer. If you send another 4 after a time period (for example 1 second) the previous 4 bytes will be overwritten by the new bytes.
For that reason you need a second buffer (ring_buffer rx_buffer) to write every unread incoming byte up to the size of the second buffer.
The same principles exist to the txbuffer that I have not finished yet.

You will say, why you use 128 bytes for the first buffer (UserRxBufferFS[APP_RX_DATA_SIZE]) and 128 for the second buffer (rx_buffer) ?
The answer is that the USB needs a big enough buffer to receive one data batch. For example, if you send 32 bytes from your serial terminal and the UserRxBufferFS[] buffer has only 4 bytes length (CubeMX default value), then the STM32 will be stuck.

In programming there are many ways to do the same thing. As a start I chose to use that way (2 buffers). If you have another solution, a more efficient approach, we can talk about it. The solution must include the tx buffer that has not been implemented yet.

Post Reply