Mbed3 and Minar

Fedora bug with the arm-none-eabi-gcc-cs patch

I found there was already a bug about the lack of libs in Fedora, but nobody had made a patch yet, so I sent mine there

https://bugzilla.redhat.com/show_bug.cgi?id=1260439

Going past Hello World

Now the "blinky" hello world app can build and run, it's a bit of a brick wall how to start writing code. Blinky looks like this

#include "mbed-drivers/mbed.h"

static void blinky(void) {
static DigitalOut led(LED1);
    led = !led;
    printf("LED = %d \r\n",led.read());
}

void app_start(int, char**) {
    minar::Scheduler::postCallback(blinky).period(minar::milliseconds(500));
}

The docs for mbed3 are still a "work in progress".

https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/Full_Guide/app_on_yotta/

has nothing really beyond blinky.

However even just looking at blinky, there are immediate questions coming like "what the hell is minar"?

Minar is Mbed's event loop

In the mbed3 "Hello World" app, it initializes via static functions from a class "Scheduler" in a namespace "minar"

minar::Scheduler::postCallback(blinky).period(minar::milliseconds(500));

Basically minar is a very simple event loop as described here (the link to here from the "app_on_yotta" page mentioned above is broken)

https://github.com/ARMmbed/minar

So from that we can learn mbed3's general gameplan is everything should be singlethreaded, nonblocking, and get back into minar as quickly as possible.

Which to me sounds very good, since Libwebsockets has had a lot of success using basically that scheme even on processors that have multicore.

(However they seem to have given up trying to convince everyone of the benefits and say they will reintroduce threading in 2016.)

Minar not preemptive

Unlike an RTOS which is using at least one interrupt to enforce what should be happening at a given time, Minar seems to be simply an event loop. If something it calls doesn't return for a while, the whole show blocks.

This method may sound trivial to ears that are used to dealing with multithreaded and multicore code, but actually there are some solid advantages to doubling down on this approach.

There is no locking
There are no locking bugs (some of which can be very low probability)
There is no locking or thread overhead
The determinism increases
Worst case resource allocation scenarios (memory, power) are easier to prove
Serialized resource allocation means stack or other dynamic areas can be used by multiple functions mutually exclusively, reducing peak usage
It's really simple... Minar has one real function "postCallback"

On the other hand unless all the callbacks Minar may visit are written with this in mind, it means Minar may not always manage to look like it is multitasking in the way people expect. But the good news is, at least in Posix it is not difficult to write in nonblocking style once you adjust your thinking a little, and clearly since mbed is relying on this it shouldn't be any tougher here.

So I think that's a good choice for this kind of "userland application" architecture, considering the restrictions of the type of silicon it's targeting.

So far I did not see how interrupt-driven hardware should interface to this event loop. I saw mentions of "drivers" I guess it can be supported there.

Extreme confusion between mbed3 and "classic"

Google and the official site is full of info that does not seem to apply to mbed3, and this info does not come with "mbed Classic" writted on it. For example the official developer.mbed.org site has this from two clicks from the homepage... "Components" and then "Ethernet"...

https://developer.mbed.org/components/cat/ethernet/

But the Freescale K64F board is not mentioned.

And again, two clicks from the homepage (Handbook | TCP IP protocols and APIs) I can get this

https://developer.mbed.org/handbook/TCP-IP-protocols-and-APIs

So eg the http server example there from 2013 is clearly not for mbed3 int main (void) { That doesn't use the Minar event loop and nor does this

    //listening for http GET request
    while (serverIsListened) {
...
    }

So all the stuff on https://developer.mbed.org is specific to "mbed Classic" and if you want to use it, needs a rewrite for mbed3.

Only the stuff on https://www.mbed.com/en/ is related to mbed3.

"mbed classic" mass migration to mbed3 shortly

Arm should really mark up those pages as "mbed classic", the same way they mark up www.mbed.com as "mbed beta site" on the top of every page, because people come to these pages via google. It doesn't have to say "Deprecated" but it should show the scope of its relevance.

They are actually explicitly preparing to deprecate everything on developer.mbed.org as written here:

https://www.mbed.com/en/development/software/mbed-os/mbed-os-migration-plan/

When mbed, together with partners and developers, have fininshed porting all compatible platforms to mbed OS, we will deprecate and eventually make http://developer.mbed.org read-only.

They have a timeline which shows a "technology preview" release next month, in Nov 2015.

And in the migration plan, they show the release of the technology preview as the time when people should migrate their board support.

So I think even though it's not really ready, it's better to persist with mbed3 and try to get somewhere by the time it is ready.

blinky, big gap, Device Connector

So I have been looking for how to move off blinky and configure the Ethernet on K64F using mbed3.

After I realized I should ignore developer.mbed.org, I found this repo linked from the mbed3 site

https://github.com/ARMmbed/mbed-client-examples

He contains really a very small bit of cpp that connects to some Arm cloud server that the README says may not be deployed yet. However looking at the README and the code, he feels he can bring up the K64F Ethernet with DHCP, evidently via some other library.

I cloned the repo and followed the build instructions in the README, but

$ git clone https://github.com/ARMmbed/mbed-client-examples
Cloning into 'mbed-client-examples'...
remote: Counting objects: 361, done.
remote: Total 361 (delta 0), reused 0 (delta 0), pack-reused 361
Receiving objects: 100% (361/361), 1.89 MiB | 684.00 KiB/s, done.
Resolving deltas: 100% (186/186), done.
Checking connectivity... done.
$ cd mbed-client-examples/
$ yotta build
info: get versions for x86-linux-native
info: download x86-linux-native@1.0.0 from the public module registry
info: get versions for linux-native
info: download linux-native@1.0.0 from the public module registry
info: get versions for mbed-client
info: download mbed-client@1.2.0 from the public module registry
info: get versions for mbed-client-c
info: download mbed-client-c@1.1.1 from the public module registry
info: get versions for mbed-client-linux
info: download mbed-client-linux@1.1.0 from the public module registry
info: get versions for mbed-client-mbedtls
info: download mbed-client-mbedtls@1.0.7 from the public module registry
info: get versions for nanostack-libservice
info: download nanostack-libservice@3.0.8 from the public module registry
info: get versions for mbedtls
info: download mbedtls@2.2.0-rc.1 from the public module registry
info: generate for target: x86-linux-native 1.0.0 at /home/agreen/projects/mbed/mbed-client-examples/yotta_targets/x86-linux-native
-- The C compiler identification is GNU 5.1.1
-- The CXX compiler identification is GNU 5.1.1
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/agreen/projects/mbed/mbed-client-examples/build/x86-linux-native
[86/124] Building C object ym/mbedtls/source/CMakeFiles/mbedtls.dir/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbedtls/source/entropy_poll.c.o
/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbedtls/source/entropy_poll.c: In function ‘getrandom_wrapper’:
/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbedtls/source/entropy_poll.c:93:13: warning: implicit declaration of function ‘syscall’ [-Wimplicit-function-declaration]
     return( syscall( SYS_getrandom, buf, buflen, flags ) );
             ^
[121/124] Building CXX object source/CMakeFiles/mbed-client-examples.dir/home/agreen/projects/mbed/mbed-client-examples/source/main.cpp.o
FAILED: /bin/c++   -Dmbed_client_examples_EXPORTS -O2 -g -DNDEBUG -I/home/agreen/projects/mbed/mbed-client-examples -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client-c -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client-linux -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client-mbedtls -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/nanostack-libservice -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbedtls -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client-c/nsdl-c -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client-c/source/libNsdl/src/include -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client-c/source/libCoap/src/include -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/mbed-client-linux/mbed-client-libservice -I/home/agreen/projects/mbed/mbed-client-examples/yotta_modules/nanostack-libservice/mbed-client-libservice -I/home/agreen/projects/mbed/mbed-client-examples/source    -include "/home/agreen/projects/mbed/mbed-client-examples/build/x86-linux-native/yotta_config.h" -MMD -MT source/CMakeFiles/mbed-client-examples.dir/home/agreen/projects/mbed/mbed-client-examples/source/main.cpp.o -MF source/CMakeFiles/mbed-client-examples.dir/home/agreen/projects/mbed/mbed-client-examples/source/main.cpp.o.d -o source/CMakeFiles/mbed-client-examples.dir/home/agreen/projects/mbed/mbed-client-examples/source/main.cpp.o -c /home/agreen/projects/mbed/mbed-client-examples/source/main.cpp
/home/agreen/projects/mbed/mbed-client-examples/source/main.cpp:16:40: fatal error: mbed-net-sockets/UDPSocket.h: No such file or directory
compilation terminated.
[121/124] Building CXX object ym/mbed-client/test/CMakeFiles/mbed-client-test-mbedclient_linux.dir/mbedclient_linux/main.cpp.o
ninja: build stopped: subcommand failed.
error: command ['ninja'] failed

Something is missing from the instructions...

What we learned this time

Minar is an event loop
mbed3 wants you to write singlethreaded, nonblocking code (until "2016" when it will grow threading suppposedly)
You can schedule callbacks from Minar
Scheduling callbacks is basically the only Minar API
developer.mbed.org is for "mbed classic" and nothing there is directly useful for mbed3
www.mbed.com is for mbed3
mbed3 has a trivial example (blinky) and a complex example with undocumented dependencies (mbed Client) that I can't build yet, and nothing inbetween that I found yet

Next post about mbed