[zeromq-dev] 0MQ on embedded devices - Quadrocopter project

Rudie Shepherd rudie at globalpro.co.za
Thu Nov 24 16:04:05 CET 2011

Hi Martin,

Thanks for the nudge in the right direction.

It looks like there are a number of different "projects" possible here.
I'm going to have to decide how much each is going to be worth i.t.o. time
and effort:

- Bare Metal implementation. This could be a "client-only" protocol for
PUSH. It would lose most of the 0MQ benefits though. Just a packet pusher
- but still useful for things like sensors. How hard is it to PULL?

- Bare Metal with "pseudo threads" and sockets in hardware. Could one stub
something like pthreads out and use ProtoThreads instead?

- Bare Metal on micro embedded POSIX implementation. No "real" O/S yet,
but support for threads. Sockets can be handled in a device-specific lib.
This guy seem to be brave enough.

- Bare Metal port to .Net Micro Framework. NETMF supports threads and
sockets - but it would take a complete port to C# (not just a binding). A
CLR version of 0MQ - is there interest in that?

- Appliance on Embedded Linux - running on ARM. Seems to be a good
middle-of-the road initial solution. Could have wide appeal for device

- Appliance on a VM platform. This is interesting to me from an enterprise
perspective... A fine tuned Queueing host. Anybody have an Amazon EC2 0MQ
image or LiveCD type distro?

I'm still convinced that a basic InProc version should be doable on bare
metal. I guess there's no other way to find out than to dig into the code
and go understand it - line by line.

Any pointers (no pun intended) is greatly appreciated.


> Hi Rudie,
>> I'm new to 0MQ but have been devouring the documentation for the past
>> two
>> days. I can easily relate to it in my day job (and will use it in an
>> Enterprise setting), but I have something more interesting in mind for
>> it
>> right now.
>> It seems to be the perfect missing link in the embedded world to bring
>> devices and cloud services together - but that means it needs a port to
>> microprocessor platforms like PIC, AVR and ARM. I'm talking about
>> running
>> 0MQ on a device with no operating system and an embedded TCP/IP stack
>> (or
>> no TCP/IP at all).
> Nope. Nobody tried running 0MQ on a raw metal AFAIK and I guess it'll be
> pretty hard, given that 0MQ uses quite a lot of POSIX functionality (at
> least TCP/IP and pthreads)
> What you can try to do though on such devices to implement the wire
> protocol on the device. It's not complex. See here:
> http://www.zeromq.org/bindings:bash
>> Has this kind of thing been tried? The source seems portable enough to
>> attempt this.
> The source is rather portable, but again, you need at least BSD sockets
> and pthreads (or similar) to make it work.
>> As a proof of concept I'd like to port it to a LPC2387 processor running
>> .Net Micro Framework. The core 0MQ lib would be native C, layered with
>> NETMF in C# over the API. This will basically give the ability to run
>> native C real-time routines and elegantly interact with the C# "business
>> logic" layer above it using messages instead of threads or callbacks.
>> Initially I don't need TCP and will only use Inproc. It would be
>> interesting to see if it would be possible to implement a Serial
>> transport
>> for device to device comms too.
> Great! Let us knows how it goes.
>> The architecture has me all excited because it solves a great many
>> problems in the embedded world and I think 0MQ should be a foundational
>> component in the "The Internet Of Things" movement.
> Yes. I have the same idea. Controlling swarms of devices without running
> into unmanageable complexity is one of the crucial problems with IoT and
> the concept of standardised "messaging patterns" as used in 0MQ seems to
> be a neat way to address that problem.
>> I'd like to build a real device in the form of a Quadrocopter. See
>> http://www.tinyclr.com/forum/2/4454/ . It is early days, but if you look
>> at the architecture I am proposing there, you'll immediately see why 0MQ
>> is the right choice... It just needs to run on a tiny little chip, in a
>> deterministic way, and a crash in the software would mean a crash in the
>> hardware (by falling out of the sky :) )
> :)
> Martin

More information about the zeromq-dev mailing list