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
I'm using IIC between master and slaves (albeit, this time, not with a 668) and use the code generated by the CodeArchitect for LPC932 (free http://www.esacademy.com) all that I needed was to change a few SFR names and the whole clocking setup. One of the 3 processors is a LPC the other 2 ruj the same code adapted. Erik
Thanks Erik, but I think the code from CodeArchitect will have the same problem. In fact I have fixed the speed issue by using lots of IF's instead of the switch, I don't know that should be faster but it is. The switch statement I was using had 9 cases and if the correct one was the last one it would take about 100us to get to it. Looking at the assembly there is an LCALL to a library routine to select between the cases and that seems to be what is taking all the time.
Thanks Erik, but I think the code from CodeArchitect will have the same problem. In fact I have fixed the speed issue by using lots of IF's instead of the switch, I don't know that should be faster but it is. The switch statement I was using had 9 cases and if the correct one was the last one it would take about 100us to get to it. Looking at the assembly there is an LCALL to a library routine to select between the cases and that seems to be what is taking all the time. yes, switch is slow; however there are means. I think to recall, but do not recall when or where, and have not been succseful since (Jon/Reinhard please chime in) I succeeded making a C switch where with the cases being 0-2-4... (which can be accomplished in the HW IIC by a shift) it actually generated a jmp @a+dptr Erik
anyhow, if you are starved for time, write it in assy. Shifting the status value right 2 gives a nice jump table. Erik
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.