[zeromq-dev] Implementation of ZeroMQ on a Spark Core (Arduino)

Pieter Hintjens ph at imatix.com
Tue Jan 28 06:57:46 CET 2014

The simplest option will be to rewrite small ZMTP stacks from scratch.
It's not hard, if you don't care about high performance and
concurrency. https://github.com/zeromq/zmtp has some examples. The
PicoZMQ project likewise has a simple ZMTP stack.

You can dispense with the whole socket paradigm and aim for SUB
objects, PUB objects, etc.

On Mon, Jan 27, 2014 at 7:51 PM, Axel Voitier <axel.voitier at gmail.com> wrote:
> Hello,
> I am looking to have an implementation of ZeroMQ on a Spark Core (spark.io).
> These modules are made of STM32 microcontroller (ARM 32bits Cortex M3 @
> 72MHz) and a WiFi chip from TI. More info here:
> http://docs.spark.io/#/hardware. They also run Arduino by default.
> Despite the scarce resources compared to a usual computer, I am hopeful of
> getting at least a small subset of ZeroMQ's features on it :).
> There are some socket functions available which seems rather correct for
> such a small device. Here are their definitions:
> https://github.com/spark/core-common-lib/blob/master/CC3000_Host_Driver/socket.h
> In brief, only AF_INET domain is supported, SOCK_STREAM, SOCK_DGRAM and
> SOCK_RAW types, and IPPROTO_TCP, IPPROTO_UDP and IPPROTO_RAW protocols. You
> have the rest of the API: accept, bind, listen, connect, select, recv, send,
> [g/s]etsockopt, gethostbyname, and a few others.
> I have two questions now:
> - Do you think with this socket API we can fairly well implement main
> features of ZMQ? (all ZMQ sockets over tcp at least)?
> - If yes, I will have two options to do it. Either I attempt to recompile
> some parts of the original libzmq. Or I implement from scratch 23/ZMTP (or
> maybe starting with 15/ZMTP?).
> In the former case, I will have to deal with other restrictions in the
> system API. It is simply not a full fledged one. And it don't have
> multitasking. They are planing to implement at least two tasks, one for the
> application-logic, one for the communication layer. They are also talking
> about having more "real" multitasking, but at the cost of very few memory
> left for the user program... Therefore, the current architecture of libzmq
> with its IO-thread(s) and API-thread could not have a close match on such
> target :S.
> So, my questions on this one is, if I try to take libzmq and flesh it out to
> only pick what I need, will I stumble upon many "exotic" system calls? Is it
> realistic considering your knowledge of the internals of libzmq? Also, will
> the threading approach of libzmq get in my way, in your opinion?
> Looking forward to reading your answers,
> Axel
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list