FW development platform

elsalahy commented 4 years ago

Summary:

This issue is to discuss possible platforms and environments that we could investigate/develop around the ST node FW.

Actions will be taken based on this discussion and separate issues will be opened and linked to this issue.

elsalahy commented 4 years ago

Currently here is the landscape:

Tools/platforms provided by ST for the STM32WL chip

Baremetal They provide everything as most MCU vendors do and this essentially includes:
- An adapted LMN LW stack
- Dual Bank LoRaWAN FUOTA
FreeRTOS ST provides the MCU port layer which allows for basic functionality but most essentially no LW stack support or FUOTA.

They also might add Mbed OS support port layer similar to the FreeRTOS one with no LW stack support (not confirmed and there is no SW around it at all and can be long after the initial release)

Current FW development

We focused on bare-metal and will continue to focus on it due to the good support available from ST.
We experimented porting basic functionality to Threadx (azureRTOS) and it was successful (no LW stack support).
Application development is unnecessary complex in bare-metal.
We will have a bare-metal FW support for the device no matter which platform we choose.
We need to develop around a platform that makes it easy to develop applications while having all the expected functionality.

What we can explore (proper analysis of advantages and disadvantages will follow in another comment)

Using the stack with FreeRTOS.
Using the stack with Threadx.
Using the stack with Mbed OS.

We can use these platform in multiple ways:

Adapt the stack to function in one or two threads and have the application layer in another one or two threads.
Complete integration of the stack into the platforms similar to what Jan did with Mbed OS (not recommended due to maintenance cost)
Wait for vendor/ enthusiasts to adapt any of the platforms and use the most useful port.

elsalahy commented 4 years ago

CC: @johanstokking and @wienke ^

azerimaker commented 4 years ago

Considering some of the feedbacks from our inner circle, especially Kris from Tlera Corp, having unofficial Arduino support would also be very appealing for some users. I think we should consider that too.

There's already a wrapper Arduino library and LoRaWAN stack available with bootloader function for the STM32L4 family and porting it to STM32WL would not be so hard. Even Lacuna guys also have the same approach. We can even ask our inner circle to port it for us.

elsalahy commented 4 years ago

I think we should implement the best platform that fits customer needs and we can leave the Arduino platform implementation to the enthusiasts and the device adapters.

No production worthy device was shipped with Arduino code and it is in fact considered a beginners tool and most professionals don't appreciate the Arduino libs.

johanstokking commented 4 years ago

I also think that Arduino support is a nice-to-have, but shouldn't be our own bet.

@elsalahy can you comment on the advantages and disadvantages of FreeRTOS, ThreadX and Mbed OS?

In any case, we can use LMN, right?

elsalahy commented 4 years ago

@johanstokking yes we will base it on LMN and will keep any eye on the the design of the basic modem (official Sub GHz support planned by end of September/middle of October) as it might be better in terms of OS integration.

Will post a summary of the advantages and disadvantages and an implementation proposal for each possible platform within this week!

elsalahy commented 4 years ago

Platforms proposals:

FreeRTOS + LMN LoRaWAN Stack

Relevant technical background:

ST provides an STM32WL FreeRTOS+LMN LoRaWAN special implementation for the dual core SOC.
ST ports the LoRaWAN stack to the M0+ core and ports FreeRTOS to the M4 core.
Though IPC (inter processor communication), a FreeRTOS and LoRaWAN implementation is achieved.
This special implementation avoids the integration of the stack into the OS and relies on the IPC.
This Implementation cannot be used with the single core SOC.

Proposed FreeRTOS implementation:

Integrate the OS with the LoRaWAN stack for the single core setup.
Handle LoRaWAN RX and TX as High priority threads.

Advantages:

FreeRTOS is one of the most famous embedded OS's with a great vendor and community support.
FreeRTOS appeals to both beginners and and professionals.
ST provides an official support and target port of the OS for the M4 core.
FreeRTOS is considered lightweight in comparison to Mbed OS
FreeRTOS has great support for various MCUs and communication technologies.

Disadvantages:

If we do a single core implementation, it might confuse the ST/TTN community who will observe two FreeRTOS+LoRaWAN implementations.
Strategically, We don't gain a lot from doing the proposed implementation, in comparison to Microsoft Azure RTOS.

elsalahy commented 4 years ago

Platforms proposals:

MbedOS + LMN LoRaWAN Stack

Relevant background:

Mbed OS 6 has support for ST devices.
Mbed OS 5 has support for ST devices and a functional LoRaWAN stack.

Proposed Mbed OS implementation:

Integrate LoRaWAN LMN stack as an external library.
Design a portable lib compatible with mbed os 5 and 6 (+Mbed OS 6 bare-metal).
Handle threads in event queues.

Advantages:

Building applications using Mbed OS is considered the easiest. (in comparison to FreeRTOS and ThreadX)
The lib can be easily implemented due to the existing reference support
Mbed provides boot-loader, FUOTA support for various IoT devices and communication technologies.

Disadvantages:

Uncertainty around the future of Mbed as an operating system.
Confusion between our proposed implementation and the original existing LW support.
The lib will not be as portable in comparison to other OSs due to the abstraction level of Mbed OS.
No STM32WL support for the OS yet (easily done thought because of L4 support)

elsalahy commented 4 years ago

Platforms proposals:

Azure RTOS(ThreadX) + LMN LoRaWAN Stack

Relevant background:

Azure RTOS is a new operating system purchased recently by Microsoft and used to be called ThreadX
ThreadX used to require a license and the source code wasn't available publicly.
Microsoft renamed it Azure RTOS and the source code is now available on GitHub
Microsoft is also pushing tutorials for using the OS as seen in the getting started
Any ST chip can get the Licensee for free, see news article.

Proposed Azure RTOS (ThreadX) implementation:

Integrate the LW stack with ThreadX similar to the WIFI implementation done in getting started
High priority threads for LW TX and RX similar to FreeRTOS.

Advantages:

ThreadX has very small footprint making it easily portable to any MCU and it is the smallest in comparison to Mbed OS and FreeRTOS
ThreadX integrates with any library as a standalone OS with no abstraction layers, in comparison to Mbed OS.
Heavily certified/tested and has great documentation.
Microsoft is planning to push the OS for the next upcoming years.
Known by professionals

Disadvantages:

Unknown and unfamiliar to beginners.
Very minimum support.
No community as it used to be a paid commercial product.
No official support for other communication technologies except for WIFI.

elsalahy commented 4 years ago

@johanstokking what do you think, did I miss any points. Let me know and I can add them.

I think we mainly need an OS to make it simple for anyone to build an application and expand on the vision of a generic device.

I think we should pick this up in a call after we detailed all the options and advantages/disadvantages in this issue.

johanstokking commented 4 years ago

Indeed I feel like this is more a marketing decision than a technical decision.

Going with a cloud provider "branded" RTOS is opening and closing doors at the same time. Note that I would consider Mbed OS also a "cloud provider's RTOS": Arm is increasingly positioning Mbed OS as a client for Pelion.

My current preference, but that's entirely intuitive, is going with FreeRTOS for low footprint, compatibility, neutrality and community.

elsalahy commented 3 years ago

With DB results, we have very few reasons to build and maintain an integration with Mbed OS. Here is my current proposal:

We adapt the AWS FreeRTOS port for the single core ST STM32WL variant.
We build sample applications for the single core one.
We use ST FreeRTOS integration on the multicore variant (one core with LMN and one running FreeRTOS).
Depending on the needs we can use a similar approach with Azure RTOS.

TheThingsBot commented 3 years ago

This issue has been mentioned on Discuss The Things Industries. There might be relevant details there:

https://discuss.thethingsindustries.com/t/rtos-for-generic-node-do-we-want-need-it-noob-questions/384/2

elsalahy commented 3 years ago

Working on #79 and #81 (FreeRTOS)

Closing the issue and it can be used as a reference for relevant pull requests.

TheThingsBot commented 3 years ago

This issue has been mentioned on Discuss The Things Industries. There might be relevant details there:

https://discuss.thethingsindustries.com/t/gnse-supported-platforms-official-and-community/583/2

TheThingsIndustries / generic-node-se