Sometimes it seems like Arduino is everywhere. However, with a new glut of IoT processors, it must be quite a task to keep the Arduino core on all of them. Writing on the Arduino blog, [Martino Facchin], Arduino’s chief of firmware development, talks about the problem they faced supporting two new boards from Nordic.
The boards, the Nano 33 BLE and Nano 33 BLE Sense are based on an ARM Cortex M4 CPU from Nordic. The obvious answer, of course, is to port the Arduino core over from scratch. However, the team didn’t want to spend the time for just a couple of boards. They considered using the Nordic libraries to interact with the hardware, but since that is closed source, it didn’t really fit with Arduino’s sensitivities. However, in the end, they took a third approach which could be a very interesting development: they ported the Arduino core to the Mbed OS. There’s even an example of loading a sketch on top of Mbed available from [Jan Jongboom].
On the one hand, this has two big advantages: in theory, Arduino can now run on anything that supports Mbed, which is quite a lot. Second, even though the system retains the simplicity of Arduino, the entire Mbed system is available to Arduino developers and vice versa.
On the other hand, you could argue that if you have Mbed, you don’t really need Arduino. While much is made about Arduino’s simplicity, it is really a C++ program with two predefined functions and an IDE that builds your code without as much explicit help as you’d expect. However, the wide variety of code that supports Arduino should be of interest since you could just use it from either an Arduino or Mbed program without much effort.
This might make some of our favorite Mbed labs projects more popular. If you want to see our take on an Mbed project, you can turn it into a signal generator.
Thanks [halherta] for the tip.
They should have spent the time doing properly. Nobody will use mbed to program that. They should bet harder on the future
I wouldn’t say “nobody” but combining two huge frameworks just to get e.g. a sensor talking over BLE to a phone/PC is crazy. These SoCs have a lot of flash but not THAT much.
Oh and it gets better – if you actually want to use BLE (or ANT), which is likely THE reason why you would pick these chips (their other peripherals are quite primitive, compared to e.g. STM32s, NXP or Atmel/Microchip ARM chips), then BLE is not supported and you need to use ArduinoBLE project (doesn’t need mBed). Which, surprise, requires you to flash the Nordic’s closed source softdevice blob that actually implements the radio stack and its own RTOS (I do wonder how will that work with mBed OS …).
So what did we gain here apart from wasting a ton of flash (the softdevice eats up a significant chunk too). The only case where you don’t really need the softdevice is if you want to use your own radio protocol or something like ShockBurst (the same thing as the popular nRF24L01+ chips use).
Worse, ArduinoBLE is buggy as hell, not working with the latest softdevice versions so a lot of things will not work properly. I have tried to use this for a project using the nRF52832 SoC (same family, just a bit “smaller” version of the nRF52840 – doesn’t have USB and few other differences). The build system relies on a hardwired URL where to download the softdevice binaries and Nordic has moved them, so things fail right out of the gate. Once you fix that (a lot of googling and research in the Github Issue tracker), you will discover that you need a very specific softdevice version because the ArduinoBLE uses an old version of the Nordic’s APIs. Once you finally flash that, you will discover that now you have a lot of flakiness with things dropping connections, refusing to bond/pair, hanging, etc. thanks to the obsolete softdevice. Yay …
Frankly, you are better off using the latest official SDK, which is excellent and has tons of examples and detailed documentation. Just expect a STEEP learning curve, especially if you have never used BLE before (better read something on it up beforehand, things will be a lot less intimidating). It is not as beginner friendly as Arduino but it actually works and allows you to build something usable with these SoCs – they are excellent for battery powered applications because of the extremely low power consumption. Even with the radio on and broadcasting/advertising the chip takes only about 10mA of current. And when sleeping it down in the single digit uA range …
Nice summary of the reasoning behind this choice. I was playing with the nrf51822 and similar modules for a Bluetooth gamepad. It’s not beginner friendly. I had a lot of compiler and SDK headaches. Mbed is the easy way out.
But I think I agree with the article – Mbed is easy enough for me (a software developer). I don’t need the Arduino framework stacked on top of it. Maybe a total beginner would prefer the Arduino framework. If Arduino and Mbed integrate nicely then this could be a really nice compatibility layer for Arduino to support more chips.
Does mBed actually work with these chips without the proprietary softdevice if you want BLE support? I kinda doubt it, given that it is Nordic who is providing the mBed support but I am not mBed user (too buggy with patchy hw support and minimal/nonexistent documentation for my taste).
Because if it doesn’t, then the opensource spirit argument they were making goes out of the window.
It feels more like a NIH problem again – instead of helping out the ArduinoBLE project which is trying to provide support for these SoCs, they have built yet another Arduino fork/core.
It still uses Softdevice
Mbed OS ships its own BLE stack (Cordio) and is not dependent on Softdevice for Nordic chips anymore.
@Jan Jongboom
I stand corrected! Cordio looks nice.
>Frankly, you are better off using the latest official SDK, which is excellent and has tons of examples and detailed documentation. Just expect a STEEP learning curve, especially if you have never used BLE before (better read something on it up beforehand, things will be a lot less intimidating).
I read a blog post lately that walked through the basics of BLE and then also the basics of using Nordic’s nRF5 SDK to publish the state of a button. I found it pretty easy to follow, so it might be a good intro for others as well:
https://interrupt.memfault.com/blog/bluetooth-low-energy-a-primer
Hi,
you should probably have a closer look at what we’re doing… Arduino BLE library uses HCI to interface to the underlying host controller on any BLE device and in our nano boards this is interfacing with the open source Cordio stack, not softdevice.
the Arduino BLE may be buggy as hell as you say, or may not be, according to our partners that have been testing it over several different chips (not just nordic), over different SW stacks and taking advantage of the recently released support for central.
Arduino should take their dated 80’s IDE and get with the times. Its a total joke!!!
But the incredible simplicity is the real draw. Put a non-programmer in front of an IDE with tons of buttons and panels and workspaces and preferences and it becomes overwhelming. Arduino IDE is almost perfect for entry level hobby work. There are a few things I would like to see added to it but I also don’t want to take away the experience of raw text editing that shows where we came from either.
Speaking of getting with the times, you should checkout platform.io
You can use VS Code or PlatformIO (which is almost the same thing) for Arduino. Nobody is forcing you to use the (intentionally) primitive IDE if you have outgrown it already.
The basic IDE is there for a reason – if you give VS Code to e.g. a mechanical engineer or a musician, they will be totally screwed. With this simple editor anyone can copy & paste a “sketch” and click the “Upload” button. And it works.
Arduino isn’t meant to be a competitor for a proper IDE or something like Keil, so stop bashing it.
Yeah, another layer of code so the ARM will run as fast as a PIC12…
C++ code is not “layered”, modern linkers are really good at only including necessary code, and quite a bit of work has been done to reduce the overhead of C++ on microcontrollers. If you don’t use stuff, it is not in your executable. Simple as that. For example, Andy Brown is running C++ programs on tiny STM32M0 devices with no loss in performance and almost no C++ overhead. Oh and by the way, how is gcc on PIC coming along? How do I get a compiler that supports -Os?
You have missed his point. It is not about C++ but about Arduino + mBed. Arduino is hardly known for fast code, some of the very core stuff that a lot of libraries rely on (such as digitalWrite() for I/O) is incredibly bloated and slow because of how inefficiently it is written.
And even for C++ – what you write is true as long as the code is written in a modern style, using a lot of templates, const expressions and similar features. Even the best C++ compiler in the world can’t do much with code that is written like Arduino is.
mBed is not much better – they rely a lot on the vendor supplied HAL libraries for hardware abstraction and those are universally terrible. Usually it is C-written-in-C++, preprocessor macros galore, layers and layers of semi-buggy abstractions stacked. The STM32 HAL is infamous for this. It is like that because the codebase is both old and has to compile even with old non-standard compilers from various proprietary tool vendors and not only the latest GCC/Clang.
And then there is the code size …
>STM32 HAL
It is so impressive that they managed to make their low level drivers more comprehensible than their high level HAL abstractions. Their HAL should be taken out back and shot.
what i think you may be missing is that if on one hand you can always craft your code in assembler, precisely tailoring each instruction to take advantage of each available clock cycle, most of the time today this is not a useful activity.
with high level layered software, code size and speed may increase but ease of use, modularity, reusability take a boost and make it possible to have a platform such as Arduino which provides instant access to tons of different peripherals, sensors, actuators for which you have drivers, example code, finished applications etc.
the whole purpose of abstraction is to set up a software architecture that can easily be ported over to several different platforms with minimal effort and this of course makes the code a bit more complex than it may be if you just targeted a single board/chip.
the introduction of mbed is a major step for Arduino as it brings in not only the possibility to move to new platforms quickly but helps reducing power consumption and introducing real multitasking which in the near future will help remove the complex state machines required today for parallel operations.
“…combining two huge frameworks just to get e.g. a sensor talking over BLE to a phone/PC is crazy”
And is how most programming is done when the silicon is cheaper than the programmer’s time (glares at Slack, whose bloatheap of frameworks is sitting on a GB of RAM so they could put emoji in their IRC client). That’s the sort of market Arduino targets — people who will buy a $30 board to blink a few LEDs, because using a $0.50 chip to blink those LEDs is difficult and time-consuming.
If you’re going to take a design to mass production where you’ll pay the silicon cost a million times over, or you just enjoy learning the skills to make efficient use of your hardware, then you’re already looking beyond Arduino.
Is there a reason Hackaday dissociates replies from parents, or does it just roll a d20 and break the flow of conversation on a 1?
That’s true but the thing is – there is an Arduino core for the nRF5x SoC series:
https://github.com/sandeepmistry/arduino-nRF5
And it doesn’t require mBed. It needs the Nordic softdevice for BLE, though – the same as their setup.
So duplication of effort, with the only “benefit” being a huge code size that will cut down significantly on useable flash on these chips.
Why all the negative comments about bloat? Microcontroller vendor libraries are already quite bloated. So are the Mbed libraries, which usually runs on top of the vendor libraries. And so are the Arduino libraries.
NewsFlash: Everything nowadays is bloated. Time to market trumps documentation and well designed APIs every time. And this is not just happening in the Embedded field but everywhere.
So what’s a few more 10’s of KBs of bloat? Especially when the upside is that you can use both the Mbed and Arduino APIs in the same program/application.