Configuration via power cycling?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I may have a requirement to send a small amount of configuration data (<= 16 bits) to some small/cheap AVR boards, which have no interface to the outside world except power and ground. It seems feasable to send this configuration data by cycling power to a board in a controlled manner. The AVR could use a combination of EEPROM and time from powerup to receive and decode the data.

I haven't worked out any details yet, this is more a thought experiment at this point. Any comments?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

and time from powerup

Doesn't this require it to have some external timing reference like an RTC or similar? Otherwise if you "blip the power" how does it know how long it was off for?

Also if they are going to get new software that enables this mechanism why cannot the 16bit config data be provided at the same time as the new software?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

and time from powerup

Doesn't this require it to have some external timing reference like an RTC or similar? Otherwise if you "blip the power" how does it know how long it was off for?

It won't know how long it was off for, but it will know how long it was last on for. So perhaps the configuration value 123 could be represented as ON 100ms, OFF, ON 200ms, OFF, ON 300ms, OFF, ON forever (i.e. > 1sec). Again, I'm not wedded to this exact encoding by any means, it's just an example. Whatever the exact encoding, the EEPROM would be changed at regular intervals (100ms in this example) to remember how long the system was powered on each ON cycle (up to the forever time, after which the EEPROM would no longer be touched), for referencing on the next cycle powerup.

Quote:
Also if they are going to get new software that enables this mechanism why cannot the 16bit config data be provided at the same time as the new software?

The configuration can change daily.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So would the idea be that as soon as it powers up, it checks an EEPROM location that is the "data" byte. It copies that value to another location for later processing then clears the "data" byte. Then, at 100ms it writes a '1' to that location. If it counts to 200ms it writes a '2' and so on basically allowing you to encode data one bit (or byte I guess... if you went out to 1600ms) at a time? If it reaches 1000 ms it knows it is done receiving data and it can process everything that was previously received?

I think it could work. My concern would be the potential loss of power during an eeprom write cycle. I know it is generally pretty sensitive to voltage and I don't know if you risk corrupting the location if power drops mid-cycle. You might also need some scheme to move the "data" bit around so you don't wear out one memory location. It would seem pretty easy to hit 10K or more write cycles if every bit of data could be 3 or 4 writes and the config could change daily.

I would be interested in seeing this if you implement it. I think it is an intriguing idea. The programming harness... the device you would use to cycle the power to accomplish the target device programing... would be interesting too. The time it takes to program could become a factor as well... clocking in a single bit or a single byte could take a while even for a trivial amount of data at 100ms or 200ms/bit. Still, for a highly confined application with a need to update data... I think it is a great idea.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting idea.

Perhaps add a check sum to the data packets. Only process the data with an EEPROM update if you get all of the data bits and a valid checksum.

Start with all of the EEPROM bytes cleared, one BYTE for each BIT of data. On each power up you scan the EEPROM block to see the first one without an FF, and store that time period in that location. First power cycle time interval goes in EEPROM location 1, next power cycle interval goes in location 2, ...

When all of the locations have data, not FF, you know you (might) have a valid data packet, so then decode it, store it, and clear the EEPROM locations to FF again.

Another EEPROM location can hold 0 to FF, or whatever, to point to which block of EEPROM is currently being used, (wear leveling). Each block includes a counter that tells how many times that block was used.

Is there any feedback mechanism to validate that the data packet was correctly received and proecessed?

I'd view this scheme as a clever trick, but not something I'd use for a mission critical application.

One would ponder why you can't respin the PCB(s) with either a larger micro with a spare pin for I/O comm's, or re-evaluate the option of doubling up on some I/O pin usage to free up a pin.

I would certainly develop this system on a larger micro, so that I could have either a USART or LCD to display data and monitor the process while developing it!

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are these pre-existing devices? If not, perhaps a better way to go would be to incorporate a fair amount of capacitance in each device fed via a diode from the power supply, then add a sense line (with suitable protection to prevent overvoltage on the MCU input) from upstream of the diode to the mcu. You can then use shorter interruptions of the power supply that the device can ride out, but can detect through the sense line, to send your configuration. With a bit more circuitry, keeping the remote devices alive during the interruptions could even allow them to talk back to the master device.

Alternatively, you could power the devices from an H-bridge with a full-wave rectifier at each device, and use the power supply polarity to carry your configuration data. It's more complicated, but would potentially allow you to send more power and more data down the line. I believe the DCC systems used in model trains use such a system to communicate with locomotives through the tracks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If there was an extra pin to sense interruptions or polarity reversal why not just directly drive that pin and skip all the complications of encoding the data over the power line?

Assuming there is some physical limitation that only allows a "connection" of the power line, why not do some sort of line-carrier type data stream? Overlay the data as an RF signal or something like that and pick it off with some external circuitry. A little filtering would keep it out of Vcc.

I think the modern model trains actually use this system. I know the Lionel O-Gauge CAB controllers inject the commands as RF into the DC rail power. Even the old legacy stuff would inject an A/C "command" signal to drive the whistles.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The limitation I would be trying to work around here is the absolute requirement that only power and ground are supplied to the boards. I can lay out new boards, that's not a problem. Another scheme I'm considering is just twiddling the supply voltage by 10-20%, and measuring rapid changes in voltage as data (while ignoring longer-term changes).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Twiddling the supply voltage is basically what jgleim suggests :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Twiddling the supply voltage is basically what jgleim suggests :)

Right, that was what prompted me to comment on my ideas re that approach. I see that my lead-in didn't make that very clear.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can also use MCUCSR for that.
I wrote an application which sensed LM317 thermal shut-down (Vcc goes down to 1,25V). That triggered BORF but not PORF. No external components needed.

No RSTDISBL, no fun!