0

fI have software running on the 72MHz STM32F303 with some real tight control loops and have come to realize that my loops aren't running fast enough. I need to port the code to the faster 216MHz STM32F765 but I'm finding that the F7 series doesn't support the F3's SPL, and only supports the newer HAL. There is a lower layer driver for HAL, but I'm trying to save months of re-coding my software if I can. Does anyone know of any way to port the code to the F7 that won't involve months of coding?

Jedi Engineer
  • 493
  • 3
  • 11
  • 29
  • If you have a running software, I would advice not to switch to the HAL. It is not very efficient, performance wise, because it tries to address all possible use cases for all peripherals. Are you sure porting the SPL (for the peripherals you are using) to STM32F7 is such a big work ? I would expect most peripherals to work the same way, with the same or similar control registers. Did you evaluate more precisely the workload (by comparing both product datasheets) ? – Guillaume Petitjean Nov 12 '19 at 08:22
  • @GuillaumePetitjean I am certain it is a lot of work for the code I have. That is why I'm here asking if there's an easier way. All evaluations and comparisons have been made, and the processor I chose is marginally above the minimum that I need to complete the task. – Jedi Engineer Nov 13 '19 at 10:24

2 Answers2

1

Seems like you are going to need to do some work. Indeed the SPL is dead and HAL seems for this use case very unsuitable as you are talking about tight control loops.

My suggestion is to switch to HAL and roll your own functions for controlling the peripherals you use. This allows you to still use typedefs such as UART_HandleTypeDef which ST maintains and works with the HAL for less performant things. This also allows you to quickly add something new and optimize later.

Also important: test your preconceptions, HAL could be slower as it is more generic and I personally wouldn't recommend it on the SPI peripheral. (I have seen the HAL take more time between transmissions than necessary. As in two thirds of the time on the line was pause instead of data.) BUT what is your requirement? It could be that HAL suffices and if so then you should use it. If it doesn't suffice then implement a better more optimized version for your platform (F7) and test it against the HAL implementation.

Tarick Welling
  • 3,119
  • 3
  • 19
  • 44
  • Thanks, but I'm trying to avoid HAL if at all possible - immense overhead - see Guillaume's comment above for more clarity. I've seen people's code vastly expand in size when they ported to HAL and I can't have that. Most of this code is bare metal. The control loops are tight, and need to stay that way. – Jedi Engineer Nov 13 '19 at 10:30
  • Seems like the last paragraph and second one are important. PLEASE just use the predefined typedefs. You are going to be writing these yourself and they don't impact performance. It is the contents of the .c files which is slow and generic. – Tarick Welling Nov 13 '19 at 10:42
0

I just received word from ST - there is an SPL to CUBE LL migration guide:

SPL2LL CONVERTER DOCUMENTATION

CONTENT TRANSLATIONS

There is apparently also an SPL to LL conversion tool:

SPL2LL CONVERTER

If anyone has used these, please comment on efficiency and ease of porting with these tools.

Jedi Engineer
  • 493
  • 3
  • 11
  • 29