Programs as data and "Smart Sensors"

I know that the Arduino can be reprogrammed via the serial port but I wonder how versatile that is.

For example, suppose I have a sensor that has some conditioning circuitry and some EEPROM on board. Let’s say it has an I2C interface as well. How difficult would it be to get the Arduino to read an object file from the sensor and execute that code?

A number of years ago the measurement industry was all abuzz about “Smart Sensors”. There were some standards proposed and a little progress was made as we have sensors like the SHT75 and the SCP1000, to name just two, that contain ASICs and are actually little data acquisition systems. However, the dream never really came up to the potential, as I see it.

Of course, having a sensor with AVR binary in it would limit the sensors application a bit. But, how hard would it be to design a little p-code interpreter for the Arduino and then when a sensor was plugged in, the Arduino would download the p-code and would instantly be able to acquire data from the device?

Just a ramble, I suppose, with no likelihood of happening soon, but it would certainly be nice to just pick up a pressure transducer, plug it in, and have the controller read the control code from the device and update its index of available sensors all automatically.

A network master would be able to query the network for various resources and use them if they became available. Those of you familiar with the inner workings of CAN will see the similarity between this and what devices on a CAN bus can be made to do.

That would open up the use of products like the Arduino to an even broader audience. And imagine the help-me threads it would generate for this forum. :smiley:

I think it's a neat idea. But there would need to be some standardization on I2C and SPI protocols among sensor families. Some SPI devices, for example, use raw 8-bit packets, some use 16, 24, 32, etc. Some like to have the chip select line pulsed low between bytes, while others want it held low all the time. Then there's the whole CPHA/CPOL thing. Yech.

And how would you know when an I2C sensor was plugged in? Or any sensor for that matter?

Yes, definitely would require some standardization. I2C would be my interface of choice for starters because there is no SPI standard at all and at least I2C would have a known interface to build on.

The “instruction set” for I2C is pretty small too. Basically, the functions from the Wire library would do it, although that class may be a little to abstract, but something like that. Tokens for each command and the registers could all be byte or smaller entities, much like machine language.

One would have to standardize on a list of attributes that a sensor object could have and the sensor would when queried return a structure that defined it in terms of those attributes. For example.

As far as how you would know when the sensor was plugged in, since I2C supports multiple masters, when the sensor powered up it could announce its presence on the bus. Not sure what to do about SPI. I think SPI should just be relegated to things like ADCs and DACs and such anyway. It’s just a glorified shift register. :slight_smile:

Your proposal sounds like has some of the stuff that the process control industry uses with the HART protocol that connects their field instrumentation to central controls. They don't store executable code there, but rather complete description device and sensor data, user data, history and diagnostic data. Works great, but took a long time to change from a proprietary protocol to a standards protocol. It wouldn't apply to Arduino because it's electrical layer is based on two wire 4-20ma signal loop with FSK superimposed onto it. Anyway sensor transmitters that utilize HART are marketed as 'smart' devices.

http://en.wikipedia.org/wiki/Hart_Protocol

Lefty

Does the Wire library handle multi-mastering? I suppose it can be added if not.

SPI is nice for higher speed operation than I2C. Nice for audio and multi-channel ADC's, etc. Maybe a "smart sensor" should have an I2C bus for sure and optional SPI bus? Then the whole chip select proliferation problem shows up...when you plug in an SPI sensor, how do you know which chip select line to activate?

Sounds like you'd need a lot of vendor co-operation.

@lefty Yes, I'm familiar with HART. That's the sort of thing I'm suggesting although bring it into the 21st century. I'm afraid 4-20 is going to be with us for a while though, as that industry is very slow to accept change. One nice thing about current loop is it's easy to make intrinsically safe with just a zener barrier. It's kind of cool to be able to hook sensors in series too as long as you got sufficient compliance. But I digress.

@RC

Does the Wire library handle multi-mastering? I suppose it can be added if not.

That's a good question. I'm not sure how much of the standard it supports. I don't know if you can use receiveEvent() with a master or not.

Yeah, I think of SPI devices as chips, not sensors. Just a personal prejudice or maybe a preference, yeah, that's it, a preference. :)

Definitely have to get the vendors on board. Just a matter of telling their marketing department about it before you told engineering. ;D