Hi, I am working on a project for a piece of laboratory equipment where we will have one main processor sequencing events and communicating with a PC vis RS232 and 4 sub-processors controlling temperatures, motor speeds, looading system and the like. Our intention is to use P89C668's for all the processors. My plan *was* to use RS232 between the main processor and the PC (which provides a GUI for the instrument) and I2C between the master processor and the slaves using the hardware I2C interfaces on the 668's. However I have got one of the 668's talking to some I2C IO expanders just to test the I2C routines and the performace is not that good. I have more or less copied the I2C routines from Phillips app note 10155 (http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN10155_1.pdf) The transfers work OK but at about half the speed I was hoping for. Also one of the hardware devices I tested it against seems to timeout occasionally. I haven't tried master to sleave comms yet. I think it is being slowed down by the switch statement in the I2C ISR, there is a 90-100us delay at the start of each call to the ISR which seems like a heck of a long time to me. I was wondering if anyone else had implemented something like this and if they had any suggestions. I am thinking of maybe using the UARTS for master to slave comms instead and adding a seperate memory mapped UART on the master to talk to the PC. How do you wire the UARTS for multiprocessor comms like this? What happens if you get contention on the serial lines? TIA, John
anyhow, if you are starved for time, write it in assy. Shifting the status value right 2 gives a nice jump table. I know, I guess thats why Philipps designed the status register so that the status codes are multiples of 8 so that you could have a jump table or just code in the 8 byte gaps. As far as writing it in assy, the I2C messages I'm sending/receiving are stored in structs with pointers to them, I'd rather not do that in assy, its why I have a C compiler ;-) I'm just curious as to why the switch...case construct seems to be much slower that a bunch of IF's. I would have assumed that they lead to more or less the same object code, but evidently not.