Code porting from Arduino to stm32f100 using STM32Cube IDE

Question

I have an Arduino sketch that work perfect on my Arduino Mega 2560 but I should port that code from the Arduino IDE to STM32Cube IDE (eclipse based) because I must use an stm32f100 for my project. I'm new on the stm32 world and not a veteran using eclipse based IDE so it's like I don't know what's the best way to make work the Arduino code on my stm32. Considering that I'm using theese 2 libraries on the Arduino IDE: https://github.com/olikraus/u8g2 for drive my lcd; https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino for the modbus protocol. I need help to understand what's the best whay to port the code from Arduino to stm32: How easy is to do this if it's possible? May be better find different libraries written for the stm32 and basically change a lot of my previous code? Take in consideration I'm not good using this eclipse based IDE and I have only few notions about HAL. Thank you for helping me.

Answer 1

Although I have not used STM32CubeIDE yet, it is - AFAIK - essentially a combination of STM32CubeMX and Atollic Truestudio. My suggestions below are partly based on my experience with these.

Regarding drivers ... It is unlikely that the drivers you referred to - for the LCD and Modbus communication - will work without modification. Nonetheless, if you are not daunted by that fact, read on.

Start simple

If you have never programmed for the STM32 before, it is best to start with something simple - before trying to implement or integrate an LCD driver and RS485 functionality. Walk before you run as they say.

Start by simply toggling an LED.

while (1) {
   HAL_Delay(500);
   HAL_GPIO_TogglePin(MyLED_Port, MyLED_Pin);
}

Next try some UART communication. I personally prefer to use the low-level library for this - as it offers considerably more control for receiving serial data. Sending a byte over UART using the LL interface, for example, looks like

uint8_t byte = 'a';
LL_USART_TransmitData8(USART2, byte);

Note that you should only use LL_USART routines in your code if you have initialized your USART peripheral using the LL interface. If you initialized it using the HAL interface, you should only use HAL routines throughout the code. You may find it easier to start with the HAL library.

By the way ... Some of the STM32 development boards offer serial communication via the USB port - which is extremely useful for prototyping and debugging.

Interrupts

You will need to learn about interrupts - if you have not done so already. This will probably be important for UART / serial communication, for example.

To explain why interrupts are important in serial communication ...

Imagine that a byte arrives in your UART buffer, and you do not read it before the next byte arrives. In this case you will have a UART overrun error (a particular flag will be set in the status register for the peripheral in question). One of the best ways to mitigate against this is to use a UART receive interrupt - and to write to a circular buffer inside that interrupt.

The Arduino library handles this for you automatically. Both its Serial.read() and Serial.print() routines use interrupts behind the scenes, for example. If you switch to STM32CubeMX - using either the HAL or LL (Low-Level) interfaces - you will need to handle the interrupts yourself.

I can't emphasize enough how important it will be to learn about interrupts. Google is your friend.

Timers

One of the most useful features of microcontrollers are their hardware timers. You will also want to learn about these in due course. Combined with interrupts they can be used for a wide variety of things.

Multi-tasking and concurrency

Unless you plan to use an RTOS such as FreeRTOS (I am not sure your STM32F100 device will have enough memory for that), you need to consider how you are going to handle multiple tasks - if you have more than one. Ideally, you do not want any of your tasks to be 'blocking'. Implementing your tasks as state machines is one way to achieve this.

You may already be doing this in your Arduino code - inside your loop() function. In any case, this could be a good opportunity to learn about the 'super loop architecture' and state machines.

HAL or LL interface?

You mentioned that you plan to use the HAL interface in your post. You may find, in due course, that the low-level (LL) driver is more versatile for certain peripherals (eg the UART). Whichever interface you use for a particular peripheral, bear in mind that you should not use a mix of both for the same peripheral. Ie, if you initialize a peripheral using the HAL library, don't attempt to use LL functions to interact with that peripheral later in the program. Once you have a chosen an interface for a peripheral, stick with it throughout your code.

Debugging experience

If you are using a STM32 development board for prototyping, these typically have a built-in ST-Link device - and offer a good debugging experience out of the box. Compared to the Arduino, in fact, the debugging experience is much better . With the Arduino library you are relying on Serial.print() statements inserted throughout your code. With Truestudio / Eclipse / STM32CubeIDE + ST-Link device, you have a proper debugger - can insert breakpoints, view the call stack, inspect local and global variables, special function registers, etc..

So, even though the suggestions above might pose a steep learning curve, the debugger may at least make certain things easier - and help you to overcome any problems that arise.

Alternatives

If the above all sounds like too much work - or too steep a learning curve - you could look in to STM32duino as someone suggested in the comments. I have no experience with this so can't comment.

Answer 2

Use stm32duino. You will be able to largely use existing code. Things to avoid are eg low-level port manipulation by writing straight to the io registers. Instead write your code so it compiles on both AVR and stm32.