Arduino board support [AKA add ArduinoCore-mbed as a platform]

[magmilo]

Hi,

I'm interested in working with the ubxlib for a future project, but have limited experience with embedded programming.
The project is based on an Arduino board, and looking through the library's README I can see that Arduino native boards are not supported.

Are there any plans to support these boards in the future?
What are the challenges or other reasons why this is not currently possible?

[RobMeades]

Hi there: can you clarify what you mean by "Arduino native boards"? ubxlib doesn't know anything about boards. For instance, it doesn't know what an ESP-WROOM board is or an STM32F4 Discovery board is.

To paint a picture, one can think of the ubxlib firmware world like this

At the bottom there has to be a u-blox module, or you wouldn't be using ubxlib in the first place, and there has to be an MCU that ubxlib supports connected to that u-blox module via some wires, and then ubxlib actually integrates into an SDK that we have decided upon for that MCU: not a difficult choice to make as there is usually only one, and it is provided/supported by the MCU vendor.

Optionally, over the top of all of that, there is an IDE which provides a common way to build and debug SDKs. Complicating this, and not shown on the picture, there is Arduino-the-non-IDE-bit, i.e. calls like Serial() etc. ubxlib does not care about either of these things: ubxlib provides make and cmake files that any IDE will use, and calls directly into the underlying ESP-IDF SDK that Arduino-the-non-IDE-bit is wrapping.

Having said that, we currently support the Arduino IDE way of working (provided it is on an ESP32) but the Arduino IDE way of working is extremely limited: for instance, to make it build .c files they have to be in a specific place, underneath your project directory, one cannot point the IDE to sets of source files that are to be found elsewhere, which is the natural way of working for third-party libraries such as ubxlib. We have to copy the files before they can be built, which makes a mess if you want to modify them, it's really horrible. Hence we will begin deprecating support for our "Arduino IDE hack" this year.

PlatformIO, on the other hand, is very flexible and easy to use, doesn't enforce a fixed directory tree, and we support building ubxlib with the Arduino-the-non-IDE-bit world under Platform IO, hence that's what we would recommend. However, we do only support Arduino for ESP32 MCUs, not for Atmel, etc., since our integration is with the underlying SDK, not with Arduino as such.

You might ask "why don't you integrate with the Arduino APIs rather than the underlying SDK?" This is not something I've looked at but my suspicion would be that the Arduino APIs are not sufficient: ubxlib relies on RTOS-type asynchronous behaviours (tasks, queue, mutexes, semaphores), which Arduino does not natively provide, so you'd always end up needing Arduino-plus-a-bit. And we've not really been asked for it yet, but maybe your query will trigger product management activity :-).

Anyway, that's a long answer to a short question :-). Does it, at a minimum, make sense?

[magmilo]

Hi Rob,

first and foremost, thank you for this astonishingly quick and concise answer!
I think I was able to grasp the gist of it, and will try to give you a more specific motivation for opening this issue.

For the project I'm working on, we are using a Portenta H7 board which we'd like to equip with additional peripherals to enable mqtt capabilities via a celllular connection. We are also already using PlatformIO as a build tool, which should make integrating ubxlib easy. Unfortunately, the Portenta H7 is one of those boards that does not run on a ESP32 MCU.

However, the Portenta H7, along with some other Arduino boards runs on the ArduinoCore-mbed library, which integrates arm mbed os into the Arduino core. This means that these boards do have an underlying OS which offers mutexes. semaphores. and more :)

As far as I understand it, adoption for the arduino mbed integration is likely to increase in the future. Expanding this library to support arduino mbed boards might enable many people to integrate ublox modems into their Arduino projects. From my limited experience, working directly with AT commands to build out applications is a time consuming, error prone task, and represents a significant entry barrier.

[RobMeades]

I don't know about concise, but quick I'll accept :-). Glad that you're using Platform IO, I think that's a wise choice.

I see that this Portenta H7 beastie has an STM32H in it, which is not something I've come across before, should probably have a look. Somewhat ironically, and not directly associated with your question, one of the reasons ubxlib exists is because u-blox originally integrated with mbedOs (our C027 and C030 boards) but we found that gave us insufficient customer traction for the amount of effort invested, hence we decided that creating a general purpose lump of C code that customers could port as they liked was a more fruitful approach. Supporting ArduinoCore-mbed would bring us full circle.

Concerning the future of embedded OSes, purely FYI, we are seeing quite a lot of people go down the Zephyr route, I think attracted by its "Linuxey" origins, though it is nothing at all like Linux really.

Anyway, what we have here is a product management question: a flavour of Arduino with mbed-os underneath is not likely to present a technical issue, it is really down to the potential business advantage in doing so. We will be deprecating support for nRF5SDK (the old Nordic SDK, which is why I didn't mention it above) this year, so we do kind of have room for another RTOS in the test system, and it might be that mbed-os affords simpler cross-platformness than Zephyr (with which we end up using platform-specific names in the porting layer).

@hkro, @manemannen, @BHeidtmann: one for you to think about.

[hkro]

Adding Arm Mbed OS and Arduino Core for mbed enabled devices as a platform in ubxlib would enable to conveniently use many boards with ubxlib same style as ESP-IDF. I think we should put it in our backlog, see if more people need it.