final results

On the picture you can see my test equipment for the FTDI. Three parts are involved:

1. Asus EEE PC as platform
2. FTDI interface board ( small one)
3. I2C I/O board ( big one )

The final test I did was based on the fact that I simulated the real domotic logic as close as possible to the final program logical blocks. I also included the fact of worse case timings. The best way to explain this is by showing you the piece of test code I wrote:

void TestWorstCaseTiming(void)

{
 UCHAR in [5]; //I2C InBuf
 UCHAR out [5]; //I2C OutBuf
 UCHAR ad [1]; //Int

 //*********INIT BLOCK
 status = FTDI_I2C_STARTUP( _400KHZ );
 //*********PREPARE IN AND INVERT
 status = FTDI_I2C_PCA_READN_ALL( PCA9698_INPUT_READ , in );
 BitSetExtended<40> InSet(in);// start with real values
 InSet.flip();// invert push = 1
 //*********PREPARE OUT ALL TO ZERO
 BitSetExtended<40> OutSet(CmdOut);
 //OutSet.none();
 OutSet.ToByteBuf(CmdOut);
 status = FTDI_I2C_PCA_WRITE_ALL( PCA9698_OUTPUT_WRITE , CmdOut );//16ms
 //*********MAIN LOOP
 while (1)
 {
  //*********POLL LOOP
  status = FTDI_2XX_READN_ADBUS(ad);
  while ( (ad[0] & INT_MASK_FLAG) != 0 )
  {
  //overwrite time to have total chain time at the end
  GetSystemTime(&begin);
  status = FTDI_2XX_READN_ADBUS(ad);//2ms
  }
  //*********DOMOTICS LOGIC READ
  status = FTDI_I2C_PCA_READN_ALL( PCA9698_INPUT_READ , in );//22ms
  //*********DOMOTICS LOGIC COMPARE AND MODIFY
  BitSetExtended<40> InNew(in);
  InNew.flip();
  for ( int input = 0 ; input <>
  {
  if ( (InSet[input] != InNew[input]) && (InNew.test(input)) )
  {
  OutSet.flip(input);
  }
  }
  //*********DOMOTICS LOGIC UPDATE LAST IN
  InSet = InNew;
  //*********DOMOTICS LOGIC PREPARE AND OUT
  OutSet.ToByteBuf(CmdOut);
  status = FTDI_I2C_PCA_WRITE_ALL( PCA9698_OUTPUT_WRITE , CmdOut );//16ms
  status = FTDI_I2C_DAC_SET(0,0);//10ms
  //*********CHECK TIME
  //Sleep(30); simulate cpu charge
  GetSystemTime(&end);
  printf ("cpu time : %d ms\n",end.wMilliseconds-begin.wMilliseconds);
  // should be ca 50ms + Xms logic
 }
}

The program flow is very simple. I poll on interrupt flag change in the inner while loop. As soon this becomes signals I leave the loop to read in the values of the PCA-IN. I check upon which bits are changed and also if this bit equal to 1. Due to the fact I use the inputs as button device I'm not interested if this bit is zero because this indicates the released state. I'm only act upon state pushed here. I invert the PCA-OUT accordingly to have a toggle behaviour on the leds. I didn't use a complex mapping for the in and out simply in-bit[0] relates to out-bit[0] etc for all 40 of them. Finally I write the new output state to the I/O board. I also added the DAC write just for timing simulating purposes but has no further meaning in this test. As you can see in the code I use the BitSetExtended<40> InNew(in) class. This one I wrote to ease the work with atomic bits. It's an extended (derived) STD class of BitSet:

template class BitSetExtended : public bitset<_n>
{
 typedef __int64 _Ty;
 public:
  BitSetExtended ( );
  BitSetExtended ( __int64 ll );
  BitSetExtended ( PUCHAR pC );
  void ToByteBuf ( PUCHAR pC);
 private:
  enum { _Nb = CHAR_BIT * sizeof (_Ty),_Nw = _N == 0 ? 0 : (_N - 1) / _Nb };
  void _Treat64( __int64 _X);
  void _Tidy(_Ty _X = 0);
  void _Trim( void );
  _Ty _A[_Nw + 1];

};

My estimated 50ms total time was quite correctly. I tried pretty much with a real button switch connected on several inputs to check if the program was fast enough to trigger all interrupt coming from the PCA-IN. And it worked very well I must say ! I can in some unreal conditions trigger an error but this really testing as a fool and can not be compared to the usual real life application. I inserted a sleep line in the code to simulate higher domotic logic execution time. I went even to 30ms and my system continued working stable. I need this test to be sure that with the final code ,which will be much more than what I have now, the program will not suffer any timing site effects.

Conclusion:

I find this a very good result even with quit slow communication of the FTDI USB device. In this test I wrote the code chained one block after the other. I didn't use any optimizations on the code flow and avoided working with multiple threads. I can think of a couple changes in terms of logic and threading which can optimize the program a little bit eg seperate the poll code into one thread using events and syncronizations on the FTDI object. Perhaps writing the read-in bits to a queue system and trait the changes in an other thread. I will look into this possibilties soon and report in my blog as usually do. But I must say I'm one step closer to my decision for taking this approach as my future domotic server.