HALMX :: MXBluePillF103C8 Roadmap

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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: 87
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby ekawahyu » Wed May 18, 2016 7:34 am

Ok, that works! I am using 5.2.1

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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: 442
Joined: Thu Aug 27, 2015 6:32 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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: 294
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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: 87
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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: 294
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby Vassilis » Thu May 19, 2016 8:47 pm

nvic_.jpg
nvic_.jpg (145.94 KiB) Viewed 477 times


nvic.jpg
nvic.jpg (217.19 KiB) Viewed 477 times

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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: 87
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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: 294
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby 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.


Return to “CubeMX and HAL”

Who is online

Users browsing this forum: No registered users and 1 guest