Computing stuff tied to the physical world

Modular nodes, revisited

In Software on Oct 16, 2010 at 00:01

As pointed out in the comments yesterday, “nodes” in a WSN should to be more parametrized. With ports, it’s very easy to mix and match different sensors – creating nodes which are not all the same should be equally easy.

I’ve touched on a related topic before in a post titled Modular nodes.

Ideally, you want to write interface code for say a PIR motion sensor once, and then re-use it in different nodes. Same for an SHT11 temperature/humidity sensor, an IR send/receive sensor, a barometer, door switches, an OOK receiver, and so on – the list is bound to grow considerably over time.

Even “more ideally” (heh), you probably would like someone else to already have written that interface code, so you can just fill in the parameters and incorporate it into your own room-or-other node.

In fact, the whole (modular!) Plugs & Ports concept of JeeNodes is yearning for this type of modularity to be carried through to the software.

To achieve such modularity all the way through, several questions need to be answered:

  • are these interface code “snippets” always very small and self-contained, or do they need additional C/C++ source files?
  • can interfaces depend on other interfaces / is a class hierarchy the best way to modularize such dependencies and derivations?
  • can we have multiple instances of the same interface in a single node? (answer: yes, for example multiple door-open sensors, attached to different I/O pins)
  • how do we deal with a mix of interfaces which use different timing periods for readout?
  • how do we compose packets to send, if the information types vary?

One way to implement this modularity, is what I’ve been doing in the Ports library until now: define and implement C++ classes for each interface, and then create (static) instances of each interface needed in a particular node.

This is an extract of the Ports.h library header file:

Screen Shot 2010 10 15 at 21.54.25

It works – and I think it’s a decent start – but it doesn’t go far enough:

  • Many configuration parameters are variables (and data members inside C++ objects), even though they are essentially contant (the port number, an I2C device ID, I/O pin choices, etc). This eats up scarce RAM space, and prevents the compiler from fully optimizing the code. The “heavy” solution to this is C++ templates, as I’ve written about in threeolderposts. Trouble is: C++ templates are “viral”, once you start on that path, everything tends to become a template. Not my idea of simplicity…

  • I want to figure out what a good set of reporting periods is, to minimize the number of packets sent, for example. This task comes back with every type of node, so having some automated tool to help with that effort would be useful.

  • There can be severe resource constraints in low-power nodes. I’d like to see what the RAM and EEPROM (and FLASH) usage is when choosing a specific mix of interfaces. I’d also like to find out whether the interrupts can co-exist and still service everything sufficiently quickly. And I’d like to get estimates for battery life. None of this is impossible, even if unnecessary for a first implementation.

  • Implementing pin-change interrupt handlers is not easy to fit into C++ as run-time mechanism, even though for any given interface mix it is very simple to generate the interrupt handler code for it.

  • The result of a choice of interfaces is not just a sketch – it also implies specific packet structures, as used for getting data across. And indirectly, it also means there has to be something node-specific at the central node (not necessarily in that receiving node, it could be code that runs on an attached PC).

  • If the number of interfaces grows considerably, and if more people were to start implementing such interfaces, then the management and versioning of all these interface definitions (code, data, docs) needs to be addressed.

What this points to IMO, is the need for a “configurator” or “wizard” type tool, which knows about a large number of interfaces, and which produces a sketch when given a bunch of configuration choices. An even more convenient tool would let me manage my entire collection of nodes, so I can make most configuration choices once, and then manage all node definitions together. It’d let me add and update interfaces and nodes as needed, over time:

Screen Shot 2010 10 15 at 22.30.14

What comes out is still a C/C++ coded sketch, since that’s what needs to be uploaded to the node.

What should also come out (not included in the above diagram), are one or more packet structure definitions, as well as the code (or data definitions) needed to decode those packets again.

With this approach, you can pick the hardware needed for a specific node, enter your choices into the configurator, and be done with it. Upload the sketch it generated, turn the node on, and launch the central server with the information it needs to understand the new incoming data packets. For other nodes, or to make changes, simply rinse and repeat…

I haven’t decided yet whether I’ll actually go for this. It’s fairly ambitious, even for a simple first implementation. But it sure would scratch an itch of mine…

  1. I hope you find the time to give this a try. That would definitely help out the rest of us with much less embedded programming experience.

    BTW, drop the “Even more” and just use “Ideally”. Ideal refers to perfection, so you can’t get any better.

  2. Ideal refers to perfection, so you can’t get any better.

    I know – it was meant as a joke, but I’ve changed it a bit anyway :)

  3. This sounds very ambitious. Maybe to ambitious for version 0.1? Why not start with just the “drivers” for the most common plugs and a general RF “framework” to transmit (as a series of bits) the samples they produce in the same order as they are “defined” in the RF-framework? If this is combined with good documentation it would bee a wonderful starting point for the rest of us to help out by writing more “drivers” offloading that work from you. It goes without saying that not so experienced people get a decent change to alter the configuration of the node to if the documentation is good. The configurator etc. could be constructed much later.

  4. I’m a bit ashamed of my solution to the problem. This is my private version of rooms.pde in pseudo code (don’t hit me; I know that globals are a pain in the a** but it saves RAM). It works for me and I have a half finished python program that generates nodes of type X form a XML file by rewriting the configuration block, calling the compiler, calling the firmware uploader etc.

    Note (by jcw) – see next comment, code moved to forum.

  5. Sounds like you are looking for MDA with a DSL.

    Maybe something like Myhdl

    Doable, but of a steep learning curve for most readers I think.

  6. Thx for all the comments. I’ll be looking into everything, but I won’t go there right away. It is more important to first get a good low-power room node sketch working, even if it isn’t the final, most flexible solution one could possibly wish for.

    Perfection is the enemy of done… as they say.

  7. A very important charme of the JeeNode and Arduino in general to me is it’s simplicity and easy to understand examples. I really do not like code generators, because they tend to generate code, that is much more difficult to understand or to replicate manually, if one needs to. If you go for this way, PLEASE, ALWAYS provide for simple, well-documented, standalone examples for every plug.

    To put it another way: what is JeeNode aiming for (in the long run) ? The perfect home automation solution to be permanently installed ? Or lots of nice modular plugs for dynamically playing with, just like lego bricks, and a good focus on learning and experimenting ?

    • what is JeeNode aiming for (in the long run) ?

      Both. Playing 1st, home automation 2nd.

      In my book, creative activities will always have precedence. The joy of exploring, tinkering, learning, and trying out new ideas is the reason Jee Labs exists!

Comments are closed.