Fedora mbed3 support patches

When I started looking at mbed, the first problem I met was that Fedora's arm-none-eabi packages do not generate the "nano" library versions necessary for C++ on mbed: mbed itself is C++.

I fixed the rpm specfile to take care of this and sent patches to solve it on an existing Bugzilla entry about the problem

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

These were taken up by the maintainer of the Fedora packages and pushed to testing a couple of weeks ago

https://bodhi.fedoraproject.org/updates/FEDORA-2015-9f0bfdec67

And the fixed packages went into Fedora Stable 5 days ago.

So now, F22 / F23 / Rawhide can be used with mbed out of the box.

Actually that was quite interesting, the toolchain has to be built twice with different CFLAGS and selected libs from the second build merged with the first build. But the installed packages are aware of the DESTDIR they are installed into, some swapping around is necessary so both builds feel they were installed into the final DESTDIR, even though that can't be done directly. Otherwise rpmbuild will blow QA errors.

mbed3 broken listen socket

As I wrote before, mbed3 listen socket behaviour was badly broken and subject to races. I opened an issue on it in github

https://github.com/ARMmbed/sockets/issues/35

and last week the bug was fixed and pushed to the public mbed repository in sal-stack-lwip 1.0.4.

That seems to completely solve the variety of race-type issues around accepting connections from a listening socket, which is great.

mbed3 500ms polled OnSent issue

There's now one outstanding problem with mbed3 sockets I know about, again I filed a github issue

https://github.com/ARMmbed/sockets/issues/38

This problem is less critical than the first one, everything acts correctly but OnSent() notifications are delayed and occur at 500ms intervals if no incoming packets are appearing. Since we use OnSent to regulate sending packets in the nonblocking manner required by both mbed3 and libwebsockets, this slows network traffic to a crawl.

But the actual traffic and notifications are correct and stable, just artificially delayed.

mbed3 libwebsockets port

Last week I updated libwebsockets

http://github.com/warmcat/libwebsockets

to also support mbed3 properly: it's able to be build as a yotta module and when run with the mbed3 test app

https://github.com/warmcat/lws-test-server

it's able to perform all the normal lws test server functions, if slowly due to OnSent() being delayed by 500ms at the moment.

The combination of the mbed3 OS / socket stack, lws itself, and the test server assets like PNG, ICO and HTML is only 118KB... the Cortex M4 in the K64F has 1MB of flash. So it's possible to consider meaningful HTML5 networking devices in as little as 128KB flash... this is two orders of magnitude less than required by Linux...