Suggestions for better blue pill performance

[hamo]

Hello,

i am working for now on a diy project.

In this project i am interfacing LoRa SX1278 (SPI), MPU6050 (I2C) and NEO-6M (UART) with the STM32F103C8 (blue pill).

All in all it is working but because all this sensors and modules are served in the loop, it is affecting the speed of the µC.

I am thinking of using Free RTOS for that purpose.

The goal is that every 10 - 15 seconds the STM32 reads  NEO-6M and packs the results in a Buffer to send it with LoRa to the receiver.

Would free RTOS be a good idea?

Any suggestion is appreciated.

Thanks in advance

[Andrew Neil]

---

@hamo wrote:

 STM32F103C8 (blue pill).

---

On a Blue Pill, that is (almost?) certainly not a genuine ST STM32F103C8.

---

@hamo wrote:

because all this sensors and modules are served in the loop, it is affecting the speed of the µC.

---

It's only two sensors - that really shouldn't be any problem at all!

What "speed" are you achieving ?

Why do you consider this "too slow" ?

Investigate where your bottlenecks are.

Just bolting-on an RTOS won't magically speed this up!

EDIT:

---

@hamo wrote:

The goal is that every 10 - 15 seconds the STM32 reads  NEO-6M and packs the results in a Buffer to send it with LoRa to the receiver.

---

You'd need to be careful that you don't exceed the maximum allowed time-on-air...

---

@hamo wrote:

NEO-6M (UART)

---

You mean this: https://www.u-blox.com/en/product/neo-6-series ?

[hamo]

Thank you for the reply.

It affects the transmission because it reads the NEO-6M and then decode the result in the same while loop where transmitting the data occurs.

Therefore i thought of using free RTOS so it can do this tow tasks parallel? i think.

The transmission with LoRa i am working on it may be for a future radio controller for a UAV i am intending to make (maybe).

The main goal is not to affect the transmission.

One more important mission in the while loop is writting the received data to the timers (PWMs).

So all  these tasks in a while loop is delaying somehow the transmission.

I want these three tasks:

   1- receiving and retransmitting data,

   2- reading uart and decoding and

   3- write to the timers to be parallel if possible

[Tesla DeLorean]

Data from.the NEO-6M could be collected and buffered on IRQ Handler

[hamo]

---

---

---

@Andrew Neil 

You mean this: https://www.u-blox.com/en/product/neo-6-series ?

Yes, but i have just noticed that NEO-6M has reached his EOL, lol.

---

[Andrew Neil]

---

@hamo wrote:

It affects the transmission because it reads the NEO-6M and then decode the result in the same while loop where transmitting the data occurs.

---

Again, that should be no problem at all.

You need to look at what, exactly, is causing the bottleneck(s) in your code.

---

@hamo wrote:

Therefore i thought of using free RTOS so it can do this tow tasks parallel? i think.

---

No. The processor can only ever do one thing at a time - an RTOS just divides the time between the tasks.

If your task is taking too long now, then adding an RTOS won't fix that.

---

@hamo wrote:

The transmission with LoRa i am working on it may be for a future radio controller for a UAV i am intending to make (maybe)

---

Not sure LoRa is a great choice for that - it's not intended high speed data...

---

@hamo wrote:

So all  these tasks in a while loop is delaying somehow the transmission.

---

So you need to look into that "somehow" - you need to find out exactly what's causing the delay(s)

---

@hamo wrote:

I want these three tasks:

   1- receiving and retransmitting data,

   2- reading uart and decoding and

   3- write to the timers to be parallel if possible

---

Again, no reason at all to need an RTOS just for that. That's all well within the capabilities of an STM32F103.

EDIT:

What speed are you running your STM32F103? A genuine ST chip would go up to 72MHz ...

[hamo]

I am running my blue pill at 72 MHz.

I haven't descriped the situation correctly.

You are right, it has nothing to do with stm32.

The issue is with the while loop so many function getting called and therefore transmission must wait till all these functios end there job.

[Andrew Neil]

---

@hamo wrote:

The issue is with the while loop so many function getting called and therefore transmission must wait till all these functios end there job.

---

So look at those functions, and see why they are taking "too long".

Fix the issues in the functions.

Again, it really shouldn't take a long time just to read a gyro/accelerometer and a GPS.

[unsigned_char_array]

I suspect busy waiting is the problem. I don't think there are calculations that would take up significant time at 72MHz. There could be a delay in some function, or polling for a ready signal on a chip until it's ready, or waiting until a serial transaction of a peripheral is completed. Replace busy waiting by polling or interrupts should solve the problem. Basically you need to turn these busy waiting functions into statemachines that return when it's waiting for something and can continue where they left of by saving the state (you can use a switch statement). An RTOS could help you with that, because it essentially turns every thread into a statemachine (by saving the instruction pointer and stack), but you still need to use RTOS delays, yields or semphores so the RTOS knows when it can or must switch between threads. An RTOS adds some overhead and uses more memory, and you can achieve the same thing with less overhead by using a polling loop and interrupts.

My advice is to draw a simple timing diagram of your code. Use a logic analyzer to check timing. You can log the serial inputs and outputs and also toggle some spare GPIO pins at certain places in the code. That way you can visualize and quantify all your timing.

[hamo]

Thank you all for your suggessions and advices.

I will surely work on them and see how can i achieve my goals.