We added MBED support to Sniff a while back, but didn't really announce it, as there were a few things about the install and setup process that are a bit tricky. At the time MBED 2 provided an easy to use on-line system, which wasn't really powerful enough to support Sniff, and some a fairly half hearted support for exporting to off line toolchains - many of which were commercial. We hoped that situation would change, and now with the introduction of MBED 3 that's all been replaced with a random collection of python scripts, with multiple package dependancies, that don't support most of the hardware, and fail to compile the demo examples... I don't know what's going on with the project, but find it strange that while the MBED2 system focused so much on being a simple online tool, then MBED3 is a sprawling complex off line tool.
When we were looking to port to MBED we needed to pick a board to work with, and most of them were simply overpriced, and underpowered. Cheap, direct from china sources of Arduino and other boards have pushed prices down to the point that spending £40 to £60 on a board with an M0 or at best an M3 ARM processor doesn't make a lot of sense. By comparison an M3 Arduino Due clone is under £10.
Then we discovered the STM Nucleo series. STM want serious developers to use their chips in commercial products, and one of the ways they do that is by putting them in dev boards so they can play with them. They have a whole series of boards with different versions of their processors on, each with slightly different performance characteristics. However we're not interested in the fine details - we want a fast chip with lots of memory, and we want to pay as little as possible for it...
In that case meet the STM32F411 Nucleo! It's an M4 series ARM at 100MHz, with 512K flash and 128KRam. With those specs its matching or exceeding the Due in every respect. (M3,84MHz,512,96). It even includes Arduino Uno comparable headers, and does a better job of putting things like SPI in the right place than the Due does. It's even semi-5V tolerant, though there a few gotcha's so probably best to treat it as 3.3v only, and be happy it doesn't blow up when you make a mistake.
But its got one crazy trick up that means its going to run Sniff better than anything else... IT'S GOT AN FPU!!!!! Variables in Sniff are floating point, which is a big problem if you're worried about performance on an embedded chip because they're slower to calculate with and the CPU's we use for that sort of thing don't have FPU's to help... except the N411 (I'm going to call it that because STM didn't give it a fun catchy name) does.
Having explained how this board just might be the best thing out there, you're probably asking "ok - how much?". We'll I saved the best TWO details for last. It's costs under £10... from official major UK suppliers like CPC, Farnell, Mouser etc. That is an insane price. For some eBay/Ali clone it would be still great, but this is for an official, supported first party board, through official distribution channels, it even comes in packaging with art work and stuff! An official Due is about £30.
If I've convinced you to rush of and order one, then great... ... .... welcome back, but lets build some code.
As I noted earlier the MBED site is a bit of a mixed message right now,
but the first thing to do is go to the MBED 2 dev site, and get your board working there. Create a project for your new board, and compile it. You should end up with an executable you can drag to the usb drive that appears when you plug in your board. With that working, right click on the project and "export" it for toolchain "GCC Arm Embedded". Not only does this check everything is working, but (as far as I know) it's the only easy way to get hold of the libraries for your board... we'll need those later.
[Update: Install the Yotta App/Installer for Mac or Windows and you're good to go! On Linux just install the compiler and the rest should work!]
Finally we're ready to compile a Sniff program, by simply typing
To test the performance I modified the prime numbers example:
make num number
make test number
make found number
.set num to 2
.repeat until num > 1000
..set test to 2
..repeat until num mod test = 0
...change test by 1
..if test = num
...change found by 1
..change num by 1
The changes are that we now test to 1000 (so it takes longer), and rather than printing out the results (which would only test the serial I/O speed! ), it counts them, then prints out how long it took. No this isn't a fast way to find primes - the point is to stress the processor.
For a couple of baselines this took about 0.002s on my (old) Mac desktop, while the good old Arduino Uno took 2.129s (this is consistent as unlike the Mac its not doing a bunch of other things at the same time). Initial conclusions: the Uno is slow, but we know that. The AVR is an amazing chip, but its 16MHz, 8 bit and no FPU. Fast maths is not what its designed to do.
That Arduino Due clocks in at, in some respects, a more disappointing 0.857s. It's over twice as fast, but then again - it's a 32bit chip running at over 5 times the clock rate.
Our N411 takes 0.346s. That's almost 10 times faster than an Uno, and 2.5 times faster than a Due despite similar clock rates. Also the N411 code was 16468bytes while the Due used 30092. While they both have 512K of flash, the n411 (at least for this very simple test) is using it more efficiently - which you'd expect from the improved CPU architecture.
Working on the initial development on OSX Yosemite the board ran smoothly. There was an annoying "drive disconnected" message every time the N411 reset itself, but it was rock solid. One really nice feature is that MBED doesn't use the serial connection for programming which means that you can leave a serial monitor open, rather than having to disconnect each time. El Capitan has been a little more glitchy, but that might just be my setup.
The Arduino pinout is a big help transitioning, but remember its 3.3V. Shield should work, but not all will, and documentation on shields is usually bad. In addition to the Arduino headers there are also "morpho" headers which is STM's own header layout, which have all of the "arduino" pins plus more. In Sniff if you use the D1-13 or A0-5 pin notation then that referers to the Arduino pins, while bare numbers 1-64 refer to the morpho layout.
Overall most of the embedded examples ran well on the N411, and while in theory the Due is an Arduino, the extra features and support that brings typically are restricted to the AVR chipset. The N411 is an amazing board, and being able to just order one from a UK supplier for a sensible price should make us all really excited.
So why aren't we screaming about it? toolchain. Sniff uses the Arduino toolchain to target Arduino which handles all of the board issues. You download the Arduino app and you're good to go. Installing the compiler and then downloading the libraries for each specific MBED board is just messy. We've got a basic framework for supporting multiple MBED boards but supporting each board is a separate piece of work.
For most MBED boards that's just not worth the effort. They don't offer a compelling price/performance mix to make them worth moving from Arduino, but the N411 is a bit special and deserves some special attention.