[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?
http://www.sics.se/~adam/pt/
- 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.
http://www.edaboard.com/thread143052.html
- 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
development.
- 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.
Rudie
> 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