One of the things we like about ARM processors is that there are a variety of options for library support. You can write your own code at the bare metal, of course, but you can also use many different abstraction libraries to make things easier. At the other end of the spectrum, there is Mbed, similar to the sort of libraries that Arduino supplies. Easy to use, although not always the best possible performance. Mbed now has an Mbed Labs site with a lot of extra goodies that go with the Mbed ecosystem, and it has quite a few interesting things.
You’ve always been able to write Mbed code in your browser — some people love that and some hate it and use locally-hosted tools like Platform.io. However, with the Mbed Lab, you can build and most importantly simulate your code in the browser (something we covered last year). There’s also a Javascript interpreter that runs on your chip, a small implementation of TensorFlow for deep learning, and a few other projects on the page.
The simulator is very impressive since it also includes peripheral emulation like an LCD display and a temperature sensor. We do wish it was integrated with the full IDE, but it is nice that it is open source and on GitHub, so you could add your own items to it if you wanted to. There are demo programs ranging from LED blinking programs to TCP/IP network examples.
One thing we found surprising: the simulator allows you to debug by using your browser’s debugger. There are source maps that tell the browser about your code so you can set breakpoints and do other debugging operations.
The Javascript interpreter is pretty interesting, too, though you’ll need a development device with at least 64K of memory to accommodate it. Then you can write things like:
var led = DigitalOut(D0);
var button = InterruptIn(D1);
button.fall(function() {
led.write(led.read() ? 0 : 1);
});
All of this code is open source, too, and there are several significant examples. ARM claim that Javascript code is about 100 times slower than C++ code, but that since all the underlying calls are still C++ that isn’t as bad as it sounds. It is also true that for a lot of projects, running at a few MIPS is more than sufficient.
There are more projects on the lab page and doubtlessly more to come. Meanwhile, if you want an introduction to Mbed, you could start here and move on to creating a function generator.
“funtion” .. I think we can safely assume that code example above was never actually tried.
Shows how much you actually know JS. “Funtion” happens to be a construct that returns a “Joke” object.
1++
Prove it…
Mbed is always been an impressive platform and easy to use, I don’t understand why is not more popular…
Because impressive and easy to use. It’s like a working out of the box 3D printer. I mean, what’s the fun in that?
For me personally, because it is on a cloud.
Whatever is on a cloud, it is not fully yours, and there are couple cases where the service will just cease to exist.
I use mbed-cli with gcc, it’s much better thatn their online IDE
But at that point, why are you using their proprietary package at all? Without all the UI niceties, what’s the advantage over just writing C with GCC/GDB and using openocd or similar for the JTAG/SWD/etc connection?
I tried to use platformIO and mbed-cli for awhile when I was starting out, but it was actually a lot harder than learning to write linker scripts, an NVIC table, and assembly boot code for each target. Especially since almost all vendors provide example code for all of that stuff.
There are a couple of reasons to use or at least get started with MBED locally. One of them is, it’s rather easy for newbies. Once a skeleton works it’s much easier to improve from there than starting with a dark hole. To write boot code one has to know the target pretty well already.
Another one is that MBED is fairly well organized. Same coding strategy, same file layout for all the targets. No switching between environments, no searching for and evaluating of yet more vendor provided code blobs when moving from platform to platform.
Also it’s free-to-use licensed source code, so “proprietary” doesn’t matter much.
That said, many of these vendor provided code packages I’ve seen actually match the MBED/CMSIS section for this vendor.
I like mbed c++ better than vendor specific C code, just a personal preference.
Maybe impressive, but also pretty complex.
If my memory serves correctly: simple serial I/O firmware doing nothing but echoing characters: 5956 bytes. The same after ditching all the complexity in favor of self written C code, still using CMSIS: 1092 bytes.
Simple pin toggler, just toggling a GPIO pin in a tight loop: 20 kHz. Doing the same with MBED-less C code: 5 MHz, 250 times faster.
For hardware with just 32 kB Flash (LPC1114, Cortex-M0) this makes a distinction.
Detected bloat includes e.g. checking the pin mapping at runtime, before each pin write. And writing plain text errors (where would this text be sent to, there is no console?). It looks like MBED (and CMSIS) are written far on the safe side, like one would write desktop PC applications. No efforts on tailoring or optimizing the code for just the needed chunks or doing configuration at compile time.
Note that the default builds in the online compiler are not very optimized. When doing a release build plain text errors are removed, the pinmap assertions are removed, etc. There’s a variety of tricks to make mbed builds smaller if required, incl. building with newlib-nano, removing all assertions, removing RTOS. There’s a wide variety of articles on the blog and docs, e.g. https://os.mbed.com/blog/entry/Reducing-memory-usage-with-a-custom-prin/ which was published last week.
I gave it a try 1-2 years ago on some STM32 boards and here is my experience from that.
It seemed very software people oriented. Want to create a task that runs every 1 second? sure. Want to use a timer that generates an interrupt exactly every 1 second? tough luck.
Want to do analog read? Easy. Want to change anything about how the conversion is made – tough luck, zero documentation or support.
It seemed that the system was providing a very broad coverage (many boards) but at the same time, very shallow, as not much of hardware specific code was implemented.
Mbed still encapsulates the STM32 HAL API (for STM targets), so you have both access to the Mbed APIs, but when you need access to specific timers that are not covered in the Mbed HAL, you can drop in some STM32 code. Just makes the code non-portable.
That is the thing, if I need to go to vendor specific HAL for such simple things, why not use vendor specific tools from the start and forget about mbed?
It’s probably because the “cloud” stuff.
Another reason is that “arm” is perceived to be “difficult” and starters with electronics tend to shy away from “difficult” and therefore tend to fall in the arduino trap whare they get stuck after a while.
Sometime ago I stumbled into Platformio, which seems too good to be true, and yet it seems to deliver it’s promises.
The Core of Platformio is “just” some Python scripts ( & scons) which give it extreme flexibility.
* Can be used from command line to almost any IDE (defaults to Atom).
* No foggy cloud stuff. Everything (after installation) runs from your own pc.
* 2000 searchable / downloadable libraries (including probably all mbed stuff).
https://hackaday.com/?s=platformio
https://hackaday.io/search?page=2&term=platformio
Been playing around with MicroPython. When all you’re doing is waiting for interrupts, displaying a value, sending said value to the internet. Python is ideal, the development time is a big win. I like the concept. Only problem is that I don’t like Python, I had enough of COBOL in the 80’s and 90’s. Formatting should not be used to determine code structure.
Don’t forget battery life!
The idea if I understand it correctly is that people’s needs in most microcontroller based projects are so little and the speed of current controllers so great that we don’t need to worry about efficiency.
However.. if the controller spends more cycles doing something because it is busy interpreting javascript then it is going to spend fewer cycles sleeping. That means it is going to suck down your battery faster! Also, just because the new chips can go lightning fast doesn’t mean they have to. Turning down the clock speed can also save a lot of energy.
You save way more energy by running in full-speed bursts and sleeping whenever possible. Area under the curve of power consumption vs time, and all that jazz.
If CPU makers would think so, Laptop CPUs would run at higher clock frequencies than Desktop ones. Lowering clock frequency has a number of advantages regarding power consumption, including allowing lower supply voltages.
That said, redundant cycles introduced by using a high level language waste power for both, high and low clocks (both with sleep).
Assuming you are not waiting for something, the area under the curve should be the same, whether you run fast or slow. (I am assuming here we are still dealing with the kind of CPU that keeps a fixed voltage for all frequency).
I thought CMOS pretty much uses power only during clock transitions. Minimizing executed cycles should be best. And spreading them out eliminates thermal shock. Maybe?
Mbed: Here today – gone tomorrow?
Mbed: All your code belong to US…
Or China :)