Computing stuff tied to the physical world

JeeNodes and complexity

In Hardware, Software on Dec 29, 2009 at 00:01

In yesterday’s post, I commented on a couple of aspects of the Arduino world which are giving me some trouble.

Now it’s time to do the same for all this “JeeNode” and “JeePlug” stuff I’ve been working on in 2009. Because there too, there are some ugly edges, uncomfortable trade-offs, and unsolved issues.

Let me start by pointing out the obvious: the Arduino world and Jee Labs are totally and utterly incomparable in scale. In terms of number of people involved, money involved, business interests, variety, maturity, promotion, reach, ambition, … they really differ in every aspect you can think of.

Except technology: Arduino’s and JeeNodes both live in the space of Physical Computing. And JeeNodes are compatible to Arduino’s in terms of software and PC interfacing. That’s not so surprising, since I designed JN’s to get going as fast as possible with as few key changes as possible.

These key changes were:

  • Voltage levels – run at 3.3V to support more sensors and wireless
  • Hardware ports – multiple identical interface connectors
  • Hardware extension – I2C buses which allow daisy-chaining
  • Software – connector-independence through the “Ports” library
  • Physical shape – a much smaller RBBB-like form factor

Two key additions driving some of this were:

  • Wireless – built-in bi-directional wireless link
  • Low power – selecting all hardware so it can run off batteries

Because one major use for all this is remote battery-powered operation, a minimal PC interface was chosen (3.3V signals for use with an FTDI adapter).

So is all this Jee stuff merely about creating wireless nodes? Not really. That just happens to be my area of interest. Staying focused is good, and I definitely intend to stick to this for quite some time.

So far so good. I thought I had it all figured out.

Then reality – and complexity – set in. Here are a number of issues:

  • Connector choices – ports use 6-pin 0.1″ headers as connectors: cheap and widely available. Not polarized, so you can plug things in the wrong way (and you will) – it took a while, but it has been standardized, and the POF approach solves polarization where it matters most: during experimentation.
  • Library dependencies – the “Ports” and “RF12” (wireless) libraries have become inter-dependent, so you now have to include both of them all the time. As far as I can tell, this is not a software modularity issue but an Arduino IDE problem. This is starting to become a major inconvenience for small projects.
  • Class dependencies – classes such as “MilliTimer” are very small and self-contained but the more they get used, the more they lead to the above library dependency troubles. If adding modular and useful code leads to headaches, then something is definitely wrong.
  • Wireless functionality – a small driver takes care of packet reception and transmission in the background. It’s very low level but an easy transmission layer on top now adds robust communication for sensor networks. More convenience functions like these need to be added.
  • Multi-node development – it’s tedious to deal with multiple interfaces when more than one JN is plugged in, because USB interface names are meaningless. There is currently no way to auto-detect when a JN is plugged in or removed, let alone do something specific depending on what sketch that JN is running.
  • I2C ≠ I2C – ports support a software (bit-banged) I2C bus, but the ATmega also has pins which support hardware I2C. The underlying driver code is completely different. There is no generalized layer yet to hide these differences, so right now code written to use I2C plugs via the Ports library needs to be changed to work with hardware I2C and the Arduino’s “Wire” library. This must be fixed.
  • Ports vs. Plug Shield – due to the I2C differences described in the previous item, code written for ports on a JN needs to be adapted to work with the Plug Shield on an Arduino, and vice-versa. Tedious.
  • External power – the various power pins on a JN are all tied together, because the voltage drop of diodes would hamper ultra-low power use. That means you can’t hook up a JN to FTDI while a battery is tied to one of the other power pins (unless the battery has an on/off switch and you’re careful).

Some of the above issues have already been sorted out. Others can be addressed in future hardware designs. Some, such as “external power” are likely to remain as is for now. And some just need more or better software.

Adding or modifying software is easy. The hard part is avoiding restrictive decisions which have long-term consequences. Here’s the most challenging one: should I maintain 100% software compatibility with the Arduino world and benefit from all the shared knowledge already built up, or should I start off on a new journey and redo whatever is needed from scratch to reach a workable level again? I haven’t decided.

Screen shot 2009-12-28 at 00.33.52.png

When you hit a wall, do you look for a way around it or do you tear it down? Depends on the wall, I s’pose.

  1. I’ve realized a while ago that the entire Arduino ecosystem that makes it “simple” to get started in micro controllers is its greatest strength and its greatest weakness. Once you get past the basics you start to realize that the Arduino does not scale very well at all. You only have to look at all the examples that use polling as a way to interface to the outside world. The ones that know better write libraries that are event driven/interrupt based but it seems everybody has their own methodology of an event driven system so mixing libraries with two different event driven systems is complicated and/or inefficient. At some point someone will come along and create an Arduino-like system that takes all this into account to begin with. I do not want to sound like I am completely knocking the Arduino since it has given so many people the ability to get into physical computing but once a lot of those people advance they realize there are underlying issues that are hard to overcome.

    • Nice summary. There is a lot of fun and success to be had, even with limited means. And not everyone wants to move into more advanced territory. Exploring the edges of technology, no matter where they lie, can be highly educational and extremely rewarding. But yeah, there’s a huge gap with any PC/Mac.

      It’s hard to look into the future – maybe 32-bit chips will eventually take over and let us do everything we do today with much more sophisticated software inside. Or maybe cell phones or their successors will become the center of functionality and all interfacing.

      Incidentally, I’ve got an another weblog post queued up about polling/event-driven code.

      Thanks for your comment and insights. I’ll keep exploring the software aspects of physical computing.

  2. I wasn’t sure yesterday if you were talking about something as extreme as switching to other micro platform, or only wishing to stop trying to have 100% compatability with Arduino.

    I think you should progress the wireless sensor mission. You have already made specializations to your Arduino platform to support wireless sensors. Split your offerings maybe. You can have libs for HUB and NODE. Support the Arduino 100% as a HUB only (no ports) and make a Jeelink type RF shield with flash memory on-board.

    For wireless sensor NODES do as you please. Keep pushing your hardware and software forward on these.

  3. Of course ^ I meant no support for hardware ports on the HUB. Wireless ports will be required.

    • Ah, interesting idea to separate hub and node software aspects w.r.t. Arduinos. I’m not considering changing micro platform at this point, there is still a lot a room to extend with AVRs. And yes, I’d like to work on a couple more hardware/interfacing ideas next year. Thanks.

Comments are closed.