MicroPython Forum (Archive)

I have two wishes for uPython: zmq and zigbee. The first is a "simple" issue of programming a low level zmq packet handler, the second is significantly more difficult.

For those who don't know, zigbee is a highly reliable and ultra low power communication method that is used (mostly) in industrial applications. It is a mesh networking, self repairing protocol. For more information, this is a good overview: https://docs.zigbee.org/zigbee-docs/dcn ... erview.pdf

I was researching possible Zigbee chips that could run uPython and I came across this: http://www.ti.com/product/cc2538

Features: Zigbee SOC ARM M3 implementation, 32kB of RAM, 512kB flash. Can be reprogrammed over the air, less than $6 on digikey

uPython is currently aiming to support a different TI chip, the CC3200 Series. How difficult (apart from developing the drivers for the zigbee protocol) would it be to port to the CC2538? Major differences are that it has even less memory and is slower, but I think it is not SO small that uPython can't run on it, is it? Any guesses as to whether the same compiler/developer stack would work for both devices?

Until now I have not seen ANY chips with free compiler stacks -- this is a pretty big leap in open zigbee technology.

I also have interest in 0mq but did not get very far thinking about how to do it.

Compiling for the CC2538 should in principle be easy: just use arm-none-eabi-* tools, as per CC3200. The difficulty will be in getting the drivers for the zigbee part of the MCU. Other difficulty could be downloading your firmware, since that might need a special program.

Porting uPy to any MCU is not that difficult. Basic steps are:

1. Get gcc working for your board (or any sensible C compiler).
2. Have ability to download firmware.
3. Make a simple program in C that can print "hello world" and that can read bytes in (eg through USB VCP or UART).
4. Use your "hello world" program to make stdout_tx_strn and stdin_rx_chr functions.

Once you have step 4 done then it's just a matter of importing all the uPy files and hooking up the REPL code to your stdio functions. Then it should just work.

Beyond that, getting peripheral driver support for all the components of the MCU is a lot more work

The CC2538 might fit uPy. It depends how much RAM/ROM the zigbee driver needs. A 16k heap for uPy is small but would let you do some things.

Damien wrote:I also have interest in 0mq but did not get very far thinking about how to do it.

from what I have read, it should be relatively easy to implement some of the core features (i.e. pub/sub) ... just that no one has done it yet. I am not super familiar with the protocol, just that it is extremely powerful and perfect for iot (and that it is written in pure C or C++).

This page gives an overview for how to create a new binding:
http://zeromq.org/docs:bindings

Here is a document on the overall archetecture:
http://zeromq.org/whitepapers:architecture

From what I have read all you need is a socket implementation and it should be relatively straightforward to create a binding. Obviously uPython has new requirements (it has to be REALLY lightweight), so I'm sure it's not quite that straightforward -- but I'm sure it's possible.

Compiling for the CC2538 should in principle be easy: just use arm-none-eabi-* tools, as per CC3200. The difficulty will be in getting the drivers for the zigbee part of the MCU. Other difficulty could be downloading your firmware, since that might need a special program.

Awesome, thanks for the overview of requirements. Maybe this will be my next goal as soon as tinymem is completed.

The CC2538 might fit uPy. It depends how much RAM/ROM the zigbee driver needs. A 16k heap for uPy is small but would let you do some things.

I don't think this first implementation would have to do too much. The whole point of these is that there is a whole bunch of them doing very small tasks. You need a bunch to make a good mesh network after all.

Do you have an estimate as to how many objects you could have with 16k of heap? Assume all objects are integers, floats, etc. with a few lists and dictionaries (very few strings)