Hi guys

I need some help here.

Here is my system:

• My system has one master and many slaves
• Each slave is assigned a unique ID
• In my system, the master need to be able to tell if a slave is off line
• Each slave send a hearbeat to the master in a fix interval to inform the slave is alive (current every 30mins)
• The master keep an record of all slaves and their latest check-in-time
• The master flag a slave off-line if the slave doesn't check in within the pre-determined time.

Here is how my struct looks like in a master:

struct
{
  uint16_t lastCheckInTime;
  uint16_t id : 12;
  uint16_t isOnline : 1;
  uint16_t isInstalled : 1;
  uint16_t reserved1 : 1;
  uint16_t reserved2 : 1;
}CHECK_IN_RECORD

The problem I have is I need to monitor 200 or more slaves, and I need more ram to monitor all the slaves. So I am thinking I can put these into my SPI EEPROM on the board. But I am worry that it's too slow, and the EEPROM will wear out.

A typical have 1M Program/Erase cycles, if I write data on it every second, it only last for 11 days. Which is not good.

Any one have some better ideas on how I can do these?

Thanks guys

 

I guess speed is not a problem, I can write a driver to put the data I want to write/read in a buffer. The driver monitor the buffer and write/read the EEPROM in the background when the MCU is not busy.

Any idea on how to deal with the EEPROM wear and tear problem?

 

EEPROM is probably unsuited for your application. Change processors or implement external storage.

 

EEPROM is probably unsuited for your application. Change processors or implement external storage.

Everything is done, this feature is an after thought. It would be good if I can pull it off

 

It wouldn't be the first time a finished product had to be redone. Trying to put a Band-Aid on this one is a losing proposition. No matter how much EEPROM you have you're going to run out of bytes and erase/wite cycles at some point. How's your customer service hotline going to maintain your reputation in the face of such a failure?

 

How's your customer service hotline going to maintain your reputation in the face of such a failure?

Good point!

 

At first you said the slaves check in every 30 minutes, then there's a need to store data every minute. I don't see the need for such frequent storage. And why re-write the memory if nothing changed? You'd probably do better to write a record of when a slave either became available, or stopped being available, but don't store anything otherwise.

If you have a large EEPROM, there are techniques to use a larger section of the chip than just one or two bytes per slave, always in the same place.

 

You don't want to use an EE.

Your project is similar to a CAN project I did awhile ago that had the same things to do i.e. one master, lots of slaves, lots of messages and the necessity of not only knowing if a slave dropped out but also validating messages sent on a PIC with 3K RAM or so. I did it like this:

Each of the hundreds of CAN channels had a structure something like yours. Included in the channel data was something from the master saying what message had been sent to the slave (via a big CAN buffer). Slave responses came whenever the slave got its message and replied. Information about the reply was also stored in the structure. The master and slave comms were disjoint i.e. one never waits on nor checks the other. The monitoring was done by a THIRD task - I called it the SpiderTask.

SpiderTask ran at known intervals independently of the transmit and reply handlers. Its job was to inspect each of the channel records to determine if there was any mismatch between status conditions left by transmit and reply tasks. Since it ran at intervals, it knew how many TIKs had elapsed - and hence the time - and if a slave was non-responsive, it could take action.

The way I drew it in the documentation was a two-column table, each row was a channel and columns for transmit and receive records. SpiderTask ran down the middle, examining both columns in each row and ensuring things matched up. In my system, there was enough stored data in the channel records to do things like validation of the response and retry the transmission a few times before throwing in the towel.

Your thing seems similar. Maybe a Spider will work for you. Granted, this was done in assembler but even then, I would have run out of space if I hadn't limited the records to the minimum necessary not tried to maintain 1:1 send-reply constraints and instead let the spider interpret the channel records and figure out what to do.

Good luck.

 

The monitoring was done by a THIRD task - I called it the SpiderTask..

I like that you called your 3rd task Spider Task

 

I liked your original idea of using a cleaver, ,,, but it seems my sarcastic humour doesn't always carry well.....

 

The slaves object.

 

I liked your original idea of using a cleaver, ,,, but it seems my sarcastic humour doesn't always carry well.....

ha ha ... just noticed that...

 

Your project is similar to a CAN project I did ... ...

Just out of interest, what CAN transceiver do you use on your project? How many nodes and what's your baud rate? I may have a project coming up will need a CAN bus

 

It used a PIC18F4685 with internal CAN. The final transceiver used a PCA82C250 through an intrinsicly-safe bus isolator. The prototype work was done with a direct connection using Microchip MCP2551 transceiver which worked fine. Overall baud rate was 125KHz as required by the legacy industrial CAN cards in use. The firmware supported something like 960 CAN COB_IDs sparsely scattered over a user-determined mix of cards. Cards would send a ping (CAN message saying I'm here and not initialized) and the firmware would go through the, frankly, insane set of commands (about 800 messages) to initialize each card and configure it. During development, it was found that the cards' internal message buffers were not big enough to support all of the channels on the board - for example you could send messages to 8 channels and only 6 would reply with no other indication that something went wrong. The card received the CAN message OK so no CAN errors, it just lost the message internally and that had to be detected by my firmware and the message re-sent. With that many channels to manage, it was not practical to send 1 message and wait an indeterminate amount of time for a 1:1 reply. Decoupling send and receive into independent, asynchronous tasks that sent and received messages for each channel and with the Spider Task looking after things on its own was the solution to that and several other problems, performing the re-tries and logging lost messages, dead cards etc.

It was coded in MPASM and made use of large, adaptive tables in the writable flash ROM. It came in at around 95K of program space. All of the RAM not used in the actual program was automatically allocated to CAN buffers. I consider it one of my better programming efforts.

Good luck!

 

Those aren't really slaves as they seem to be able to initialize communications.

A far simpler approach is for the master to poll the slaves periodically. It will save considerably the amount of data to be saved, especially if you can index the slave Id in flash.

 

EEPROM is not a good substitute for RAM. If you want to save memory - save memory.

First, you probably do not need 16-bit precision for the slave "wait to kill" period. 8-bit should be plenty. You can give each slave an 8-bit counter. When the counter is done, you kill the slave. If you want to give each slave an hour, your period is 3600/255 = 14. So, every 14 sec you go through the slaves incrementing their conters. Each slave will be alive for about an hour since last check in.

Second, if you use array indexed by slave id's you do not need to store the ids any more. Flags are redundant too.

What is left is this:

#define MAX_SLAVE 512

uint8_t slave[MAX_SLAVE];

When a slave checks in, you do:

slave[id] = 255; // load the slave counter

Every 14 sec (or whatever) you do:

if (slave[id] > 0) slave[id]--;

If a slave checks out prematurely, you do:

slave[id] = 0; // kill the slave

To figure out if a slave is active, you do:

if (slave[id]) {
  // slave is active
} else {
 // slave is not active
}

This gives you 1 byte per slave. This is 4 times less than the original structure.

You can go from 1 byte per slave to 1/2 byte per slave, which will change counters from 255 to 15, but working with half-bytes is harder.

If that's not enough, you need a bigger chip.

 

Those aren't really slaves as they seem to be able to initialize communications.

A far simpler approach is for the master to poll the slaves periodically. It will save considerably the amount of data to be saved, especially if you can index the slave Id in flash.

Slaves are battery powered wireless devices, they only wake up if some data need to send to the master.

 

EEPROM is not a good substitute for RAM. If you want to save memory - save memory.

First, you probably do not need 16-bit precision for the slave "wait to kill" period. 8-bit should be plenty. You can give each slave an 8-bit counter. When the counter is done, you kill the slave. If you want to give each slave an hour, your period is 3600/255 = 14. So, every 14 sec you go through the slaves incrementing their conters. Each slave will be alive for about an hour since last check in.

Second, if you use array indexed by slave id's you do not need to store the ids any more. Flags are redundant too.

What is left is this:

#define MAX_SLAVE 512

uint8_t slave[MAX_SLAVE];

When a slave checks in, you do:

slave[id] = 255; // load the slave counter

Every 14 sec (or whatever) you do:

if (slave[id] > 0) slave[id]--;

If a slave checks out prematurely, you do:

slave[id] = 0; // kill the slave

To figure out if a slave is active, you do:

if (slave[id]) {
  // slave is active
} else {
// slave is not active
}

This gives you 1 byte per slave. This is 4 times less than the original structure.

You can go from 1 byte per slave to 1/2 byte per slave, which will change counters from 255 to 15, but working with half-bytes is harder.

If that's not enough, you need a bigger chip.

I like this idea, this can actually save me a lot of RAM. But unfortunately I don't have much ram left, so still not enough. But I found there are actually SPI RAM like these, I may use one of these.
(I never know there are SPI/I2C RAM available until now )

http://www.digikey.com/product-sear...uantity=&ptm=0&fid=0&pageSize=25&pkeyword=ram

 

I would just use MCU with more RAM. It should be easy to find a model compatible with your current MCU, but with more RAM.

 

I would just use MCU with more RAM. It should be easy to find a model compatible with your current MCU, but with more RAM.

Have never thought of a compatible one with more RAM (I just assume a new one won't be compatible), I will have a look