configuration infuser

Added by wjcarpenter about 6 years ago

I’ve been thinking about this idea for a few days. Looking for feedback, including possible pointers to someone who has already done all the hard design work for this. :-)

I’d like to develop a general purpose sensor sketch for JeeNodes. By that, I mean a sketch that knows how to read most common sensors if I tell it what sensors it has and where/how they are attached. This would be in some software layer that is mostly independent of the software layer that decides when to read and report the sensors, deal with the radio, etc. The idea is that I run exactly this same sketch on all my JeeNodes. When I deploy one (heh, I said “deploy” … that sounds so totally cool), I’d just wire up the sensors I wanted, give it power, and it would start doing its thing.

In general, I don’t think we could expect software to reliably detect all the sensors. For a few devices, especially I2C stuff with fixed addresses, you might be able to probe and guess. But I don’t think you can do that for everything. Also, I’m not sure the probing could be done without possibly wedging some of the sensors.

So, instead, I’m thinking of a way to tell the particular JeeNode what it has. Something like “You are on battery; you may sleep; Port 1 has a DHT22 temp/hum sensor; I2C has a BMP085 pressure sensor; ….”

My first thinking was wiring up a few DIP switches or jumpers. That could maybe tell the JeeNode some kind of node ID, and it could ask some central server what its config was. But even to wire up 8 bits or so of DIP switches is either going to use a lot of pins or is going to need something like an I2C pin expander. I don’t want to spend much money compared to the cost of the JeeNode and sensors, and I’d prefer something off the shelf.

The idea I am currently turning over in my thoughts is to repurpose a real-time clock. You can get an RTC chip on a breakout board with an I2C interface for a couple dollars. The DS1307 RTC chip has, in addition to its time functions, 56 bytes of NV RAM that you can use for whatever you want. Since it’s an I2C interface, you could temporarily plug it into the I2C chain on the JeeNode without losing any pins. My idea is to encode the configuration data into those bytes using a plain vanilla Arduino. Then yank the RTC board out and plug it into the JeeNode I2C. Either look for that RTC at the start-up of the JeeNode sketch, or periodically look for it, or maybe use an interrupt to tell the running/sleeping JeeNode to have a look. The JeeNode reads those 56 bytes (and maybe the clock data if there is some use for it) and stores it in local storage. At that point, pull out the RTC board and walk away. (I haven’t checked the current requirements, but the DS1307 has a square wave output that I might use to blink an LED so I can tell what the JeeNode is up to.)

I haven’t really designed any of the encoding for the configuration, but I’m guessing that 56 bytes will be a lot. If it’s not enough, I might figure out a way to do more.

To recap the ideas:

  1. Universal sketch to run permanently on the JeeNodes for common sorts of sensors
  2. Some simple encoding sketch to load up the “configuration infuser”
  3. Modify a DS1307 RTC board to add an LED
  4. Develop a configuration encoding scheme for common sorts of sensors plus whatever else needs configuring

Replies (4)

RE: configuration infuser - Added by martynj about 6 years ago

Some interesting thoughts there. The buses always available are I2C and SPI - neither are designed for ‘hot-plugging’, so in the general case, you will need a couple of power cycles to attach/detach the infuser. So why not use this Restart to request and download a customised sketch from “Node Central”? Seems less demanding on precious memory resource.

RE: configuration infuser - Added by wjcarpenter about 6 years ago

I think the memory situation is probably pretty much a wash either way. Whether it is from the configuration infuser or OTA from the central server, the JeeNode is going to have to have its own copy of the information. For the configuration infuser case, I was thinking of putting a copy of the config into EEPROM so it would survive a restart.

The other problem with asking the central server is that each node has to know some kind of individual node ID. That works against having a single sketch that runs on them all. But some of the ways I have been thinking about using the configuration infuser might require telling the node what its ID is ahead of time anyhow (instead of as part of the 56-byte config data). For example, if I have a few identical nodes and want to add a new sensor to all of them, I could program the configuration infuser once and then walk around sticking it into each of those nodes at the same time I added the new sensor.

About I2C hot-plugging … I realize there isn’t some protocol-level stuff so that the processor will notice a change of devices on the I2C bus. My plan was to try to use an interrupt to tell the processor to look around on the I2C bus(es) to see if the configuration infuser was present at a well-known I2C address. However, what I don’t know is whether there is a danger of damaging the processor circuitry or any of the I2C devices if I plug or unplug while power is on. I expect my nodes to be sleeping most of the time, but I also don’t know if that matters.

RE: configuration infuser - Added by martynj about 6 years ago

Hot plugging needs designing in all the way down to the connector. Just look at the ‘pins’ on a USB connector and you will see that physically the pin connect order is sequenced for the few milliseconds it takes to insert the plug.

If you were careful to discharge any static build up and equalise the ground potentials before inserting an I2C header into a ‘live’ but sleeping JNode, it may well work, but that is certainly off the spec sheet… Plugging into an active bus - all bets are off, it is unreasonable to expect the lightweight drivers to recover from a glitched transaction. Just imagine a scaled down version of this hilarious demo from jeroenb

What is wrong with a power off and discovery on restart?

RE: configuration infuser - Added by wjcarpenter about 6 years ago

>> What is wrong with a power off and discovery on restart?

Probably nothing. Just exploring the possibilities in early days. Thanks for the thoughts about hot-plug I2C.