Tuesday, May 17, 2011

Sometimes a skeleton...

Sometimes it's good to look at the skeleton of an idea... adding the flesh (the substance we normally see) is the fun part, but if the foundation isn't good... well, problems happen later...

On the alpha backplane I am using I2C to control the power enable, device enable and reset states of the cards.

I'm putting up two incomplete/untested code sets: one for the msp430 controllers on the cards here and one for the pic18LF26K22 backplane controller here.  Neither is finished, but they are highly linked in function and yet quite different.

For the card controller I decided to use one large file with a choice of multiple defines in the beginning to have the small amounts of unique code to each card complied as needed.  Internally the I2C interface is handled through the msp's interrupt with a rather classic state machine handler - and unlike almost everything I do... I used global variables (it actually makes more sense to use them here for the code size and limited complexity).  Internally the cards keep track of the intended state (passed from the master controller) and the current state and just adjust in whatever unique way is needed for that card to get to where they need to be...

For the backplane controller I decided to put all the card data into a structure and pass it through pointers to the necessary functions.  I haven't written the I2C code for this one yet (or the fun "fleshy" serial monitor interface, spi inter card message passer and resource handlers).  I did write the scan code for the special I2C setup logic. 

The cards usually use the I2C interface for handling only the power enable/disable and run enable/disable signals from the backplane controller, I decided to have each one start with the same address (usually not a good thing on an I2C bus).  What happens here is that when the backplane is idle (MSTEN is low), each card will respond the the same initial address (0xD0) if the ENx line is high (same as the spi enable line) -> if the master writes to it, then that byte sent will become the new I2C address for the card.  This way the controller also "knows" exactly where each card is by the I2C address.  If a single card is hotplugged it can be handled in flight but multiple cards would need to be done with the bus idle (which ought to be idle anyway when changing cards).


Time is at a premium in the spring but I'll update the code when I get the cards built and I can test them correctly.