I wanted to create this topic to look for some guidance on your current best recommended approach to incorporating mm-iot-sdk more generically on an MCU project. I have the understanding that as of recently, mm-iot-sdk includes morselib in source, which finally realizes the possibility of pulling in the entire driver for any platform of choice, in theory.
My company is beginning to develop devices that will use the MM8108, with an MCU host architecture. Understanding that STM32 is the reference platform for MM, and generally being comfortable developing on ST, we may very well be using one from the U5 or H5 family - although we still want to understand how realistic it would be to port to other MCU family (or even different vendor) targets if necessary or convenient. Even if using STM32 (with FreeRTOS), I’m preferring to stay away from the CMSIS pack route (dependency on CubeMX code generation for certain changes or SDK updates).
The ideal in my mind is that we could generically incorporate the necessary source from mm-iot-sdk into any (probably CMake build) firmware project. No CubeMX packs / code generator, no PlatformIO, etc. But I defer with the following questions:
Is the above (with a porting guide) the final intent with mm-iot-sdk now including the source code now for morselib?
We have been told that a porting guide is close to being available. Can we expect this in the coming weeks?
Are CMSIS packs for CubeMX (if using STM32), and/or other platform integrations going to continue to be recommended and well maintained routes for incorporating the SDK?
As you know, we’re actively writing a porting guide for the MM-IoT-SDK right now. I don’t have a timeline to share for when that will be available but we will keep you in the loop.
Is the above (with a porting guide) the final intent with mm-iot-sdk
Yes, I would like for the porting guide to show how users can integrate the “core components” of morselib into a generic platform of their choosing.
Are CMSIS packs for CubeMX (if using STM32), and/or other platform integrations going to continue to be recommended and well maintained routes for incorporating the SDK?
The short answer here is yes, we will continue to recommend and maintain these platform integrations as it usually provides a shorter path forward when starting from zero. However, we recognise this doesn’t suit all users and the porting guide will focus on guiding users through a more generic integration by consuming the minimum set of components from the mm-iot-sdk.
For now, in lieu of a porting guide, you might find it beneficial to study the structure of the Zephyr port, mm-iot-zephyr. We have recently updated this to consume an open source libmorse and link against the externally provided mbedtls [1]. This has a number of CMakeLists.txt that you could use as reference which you could better adapt for your project. The important parts being:
I hope this helped. Happy to assist you in this forum should you try to attempt it before we release the guide.
[1] We will likely change this soon to, by default, compile the mbedtls provided by the mm-iot-sdk as there are some quirks around setting the correct configuration out of the box.
Thank you @ajudge . This makes a lot of sense. Ultimately like you described, I’d like to be able to generically bring in core components and any extras as required by the project, and provide hardware abstractions. While we wait for the porting guide, I’ll take a look at mm-iot-zephyr as you suggest. And I’ll be sure to create another topic for assistance if needed for whichever route we choose.
