Porting L1 SPL for use with L0

[e d]

I recently started a project with the L100 using SPL and it worked out great. I also was looking to migrate to a newer chipset family L0 but found out there wasn't an SPL available for the L0. I will dig into the manual but want to know if it is a big deal to port the SPL code from L1 to L0 family. Anyone has done it before please give me some initial pointers. Thanks!

ED

[Tesla DeLorean]

Migrating from SPL to HAL requires some refactoring and paradigm changes.

My general approach here has been to cherry pick the nicely abstracted stuff and discard the brain damaged stuff.

Most of the HAL USART stuff is more mentally draining than I can stand, so I've basically replaced most of it with code that more cleanly fits the buffering schemes I've used in embedded forever.

Things to watch on the CM0(+) parts is how interrupts function/prioritize, and fussiness about memory alignment (ie more like old ARM7/9 vs CM3/4).

[e d]

Thanks Clive, although I think you misunderstood my question. I am not looking to use the Cube HAL stuff but trying to modify the L1 SPL to work with L0 part.

[Tesla DeLorean]

Perhaps look at the snippets or LL (low level) libraries.

ST provides the defines in a CMSIS compliant form, you might be able to port the portions of the SPL you use. The HAL functions frequently perform similar initialization, you can cherry pick the pieces that match, or compare and contrast L1 SPL vs L0 HAL/LL and output your own L0 SPL-Lite library.

If your original code has a good/clean abstraction adapting that is probably the least heavy lift.

At the end of the day it is your project and your time, ST has abandoned the SPL and moved on.

[e d]

Will try to convert the L1 SPL first and use the HAL/LL to compare/reference. Just don't want to introduce unnecessary bugs during the process.

[Jack Peacock_2]

Converting to 'L0xx SPL is a matter of a few weeks at most, with some testing. Start with the header files before modifying the C code. I took the extra time to convert "magic numbers" in the headers to definitions in the processor register header file, with some conditional compiles for variations within the family. That fixes some of the hidden conversion problems when bits move in a register. For new features look at the F4 SPL (I think that might be the last SPL from ST) if you want to be consistent in naming.

I also took the opportunity to make a few improvements along the way. I removed spinlocks inside SPL routines, since I use an RTOS. I also modified the vector table to incorporate reentrant device driver interrupt routines (SPI, UART, I2C).

The biggest issue I found was tracking down some small typo error in the conversion. Annoying but unavoidable when there's no one else to review code.

Jack Peacock

[e d]

Thanks Jack for the tips. Sounds like a fun exercise :) but better yet, would you mind sharing your L0xx SPL source code? I am sure it'd be much appreciated. It will probably serve as a starter point or maybe just reference along the migration process.

[Amel NASRI]

Hi @e d​ ,

Did you tried the SPL2LL converter? It is a tool that converts an original SPL code to the equivalent LL code for the family you select.

More details on how to use it are available on AN5044.

-Amel

[e d]

Hi Amel, I gave it a try just for kicks and it didn't seem to convert successfully, particularly due to the error "expression is not available for the target STM32 serie" (log file attached). Not sure what I was missing. Have you had any test/validation on this tool or do you know of any successful conversions using it?

[Amel NASRI]

Hi @e d​ ,

Please make sure that you are not in the same conditions as one of the known limitations listed in the paragraph "3.2.5 SPL2LL-Converter migration tool limitations" of AN5044.

-Amel