Some thoughts about embedded development 2019-06-01
Geen categorie
0 Comment

Some thoughts about embedded development. In specific, about source code licenses. And the reason why I started this PSoC4 support for libopencm3 project. The first reason to start the project is, right now, the only way to develop for the PSoC4 is through PSoC Creator, which only runs on Microsoft Windows. As I don’t use Microsoft Windows, this is an annoyance. So, first of all, it’s for practical reasons. One thing to say, I’ve been a part from the PSoC 4100 family at my job. The 4100 series doesn’t have Universal Digital Blocks. Implementing those might be a challenge (for the 4200 series), however, the other peripherals shouldn’t offer that much of a challenge if all the registers are documented in the Technical Reference Manuals. (That’s a discussion for another post)

Another reason is licensing. The code generated by PSoC Creator contains

You may use this file only in accordance with the license, terms, conditions, 
disclaimers, and limitations in the end user license agreement accompanying 
the software package with which this file was provided.

What am I allowed to do with it? I want to be concerned about getting the code to run, to make it do what I want it to do. I don’t want to be concerned about license compatibility and stuff like that. That’s why I prefer MIT or BSD licenses. So I only have to think about the technical details.

Now, looking at Nordic Semiconductor, their SDK’s have a BSD license with one added closure

4. This software, with or without modification, must only be used with a
   Nordic Semiconductor ASA integrated circuit.

I can live with that. I can do pretty much anything with the code, expect running it on some other hardware. Similar licenses can be found in Expressif’s ESP8266 SDK. As it’s an SDK for Nordic Semiconductor parts, this doesn’t give me any practical restrictions. However, I believe such restriction is incompatible with, for example, the GPL license. For this reason, I’ve marked code under such licenses as non-free in my ucdev repo.

Nordic Semiconductor has also released their nrfx peripheral drivers under a BSD3 license, so without such restrictions. This means, it’s possible to develop for Nordic Semiconductor parts using only open source (OSI Approved) licenses. All peripherals are implemented, some extras only found in the SDKs such as Bluetooth have to be replaced if they’re desired, but there are open source implementation of Bluetooth, so, the Nordic Semiconductor parts are perfectly suitable for open source development.

Furthermore, STM has recently some of their STM32Cube SDK‘s on github, and the others are expected soon. Most parts are released under a BSD3 license. An exception is the USB layer, which is under the “SLA0044” license. However, there are open source replacements for that too, so, the STM32 series are suitable for Open Source development as well. On a side note, there are many STM32 clones / drop-in-replacements out there, that could use that code as well.

In the past, this wasn’t the case that much, that’s the reason the libopencm3 project started. This project, however, is under an LGPL license. In an embedded enviorement, LGPL is mostly just GPL, as there is no such thing as dynamically linking on a microcontroller, as it runs bare metal code, no operating system capable of doing resolving dynamically linked executables.

This is also the reason why I am considering releasing a stand-alone version of my PSoC4 peripheral implementation after finishing it. Not only will this release be BSD3 or MIT licensed, but also have a different style. Nowadays CMSIS-5 is Apache 2 licensed, and I prefer the CMSIS-style of peripheral definition (using structs) over the macro-based definitions used by the libopencm3 project. (eg saying SCB0->TX_CTRL in stead of SCB_TX_CTRL(SCB0))

Since on a microcontroller, there is no clear distinction between what a “driver” is and what “user code” is, I do perfer BSD3/MIT style licenses. I would like to get improvements/bug fixes, but I won’t require such. Also, I’m only interested is generic improvements, that are not tight to a specific use.

STM is releasing their STM32 drivers under a BSD3 license. It seems their STM8 code is still under a shared source license. It seems they’ve removed some restrictions that were there in the past. If I am not mistaken, it is now legal to distribute patched header files to make them work with SDCC. I haven’t looked much into STM8, only a brief glance. It’s said STM worries about clones / drop-in-replacements. They surely have a number of them in the STM32 series.