Spark Firmware compatibility and porting to other STM32 chips

Firmware
1

Hey, I was wondering about the compatibility of the spark firmware with other STM32 chips. I am planning on developing a peripheral device for my Electron project that will be based on an STM32 chip, and I was thinking about going with an F0 series chip.

Does it make sense to think about porting spark firmware over to the STM32F0 series?

Particularly if I don't need anything but the CAN stack, i2c, UART, and GPIO libraries?

Ideally I would develop the product overt time such that eventually it could feature a CAN-enabled bootloader so that I could use the Electron to flash new firmware to the the MCU over the air via CANbus.

I read the forum post Porting Spark firmware to STM32F4 and it appears that the fellow was able to port most of the spark firmware to the STM32F4 series, and @mdma says in it:

The firmware team are busy refactoring the firmware, separating the hardware-dependent code from the hardware-independent code. This should make targeting the F4 much easier!

How did that go? I can't seem to find anything else in the forum and that thread is now over 2 years old.

I guess when it comes down to it, I'm kinda looking for advice on what will be the "easiest" way to proceed if I'd like to be writing the application for my nucleo board in, say, 2 weeks:

  1. Just use an STM32F2 series controller, and use the spark firmware directly via Eclipse or Keil MDK (~$15 per MCU, total abstraction of firmware)

  2. Use a STM32F103 series controller, and use the code developed by the good folks over at stm32duino.com via Arduino IDE (~$7.50 per MCU)

  3. Adapt necessary spark firmware libraries to a "lesser" microcontroller from the STM32F0 series and develop via Eclipse or Keil MDK (~$5 per MCU, abstraction pretty good, but a patchwork)

  4. Use another ~$5-10 Wiring-based hardware/software product with built-in CAN interface (not sure if there is one out there?)

  5. Stick to the STM32F0 series and use mbed online IDE... hmm this looks tempting

  6. Stick to the STM32F0 series and learn ANSI C, develop my own libraries, get dirty and lose my mind

Clearly choice 6 is the "funnest", but I need to keep development time down.

1 Like
2

This refactoring has brought us the HAL (hardware abstraction layer) a long time ago, which also lead to the Raspberry Pi initiative where Particle firmware can run on an RPi.

All HW dependent code should now be handled via the HAL and hence almost any HW should be possible to target with less or more effort.
Sticking with the STM32F family will probably be simpler than going completely new ways.

I'd guess that should be rather close to the Spark Core (predecessor of the Photon)

1 Like
3

@jaza_tom

I’m using Particle firmware on an STM32F205 (same as Particle uses) but on a custom PCB.
I can’t comment on the ease of porting to other variants but I can say everything worked pretty smoothly when going down this track. I compile locally on Linux, and use an ST programmer over SWD to get the bootloader on, then just use USB because it’s easy.

3 Likes
4

@jaza_tom
You have the option to ported Particle Platform for another microcontroller via HAL but it is not so easy. But also you have other alternatives.
You can also use the mbed platform that has CAN library that supports a larger range of microcontrollers or use MikroC compilers which also has CAN library.
https://docs.mbed.com/docs/mbed-os-api-reference/en/latest/APIs/interfaces/digital/CAN/
https://www.mikroe.com/mikroc/
Both of the platform has its advantages.
For example MikroC use the same API for 8Bit and 32Bit microcontrollers.
You have support for multiple platforms: PIC, PIC32, dsPIC, AVR, 8051, FT90X and ARM.

My recommendation is to use Mbed platform because it is open source, you have many other libraries directly supported by ARM and is free. Also supports RTOS with a very intuitive API.

1 Like
5

Thanks for the responses everyone. I think for now I’m going to pursue using mbed to develop on the F0 series in the interests of meeting approaching deadlines.

Once things are working and undergoing field testing, I’ll reassess things and choose one of the following options:

  1. migrate from mbed to some kind of hacked version of STM32Cube with CAN bootloader
  2. buy a STM32 F0 series firmware base + HAL + CAN bootloader from a 3rd party embedded software company
  3. Port the Particle firmware library to F0 series and “tweak” the bootloader code to be able to do DFU over CAN bus

Here’s a follow up question on Particle firmware porting to other chips:

if I decided to port the particle firmware to the F0 chip, is it feasible to cut out all the non-needed components/features of spark firmware to reduce code bloat and make more memory available (i.e. get rid of the cellular, TCP/IP, Cloud, UDP, Keyboard, Mouse modules)?

What about changing the bootloader to accept firmware updates from CAN bus instead of from a modem?