I2C Timings and Mains Disco Lighting Control

My maths is terrible, so I need a little help here please.
I need to dim 40 mains lamps from 1 PIC. Because I want to spread the mains switching over several PCB's, I would like to use the Philips PCF8574 I2C to 8 output chip, and I would of course need 5 of these. These 8574's would in turn drive opto isolated Triacs, driving each lamp. There would also be a opto isolated zero crossing detector connected directly back to a PIC pin. My idea is to start a counter in the PIC at the start of each cycle, and turn on the required lamps at various times within the cycle, to give me the different brightnesses. At the end of the cycle I would turn all the outputs off, and start the whole sequence again at the next crossing.
My questions is, would the I2C write cycle be too long for me to get sufficient control of the lamps?

PS. I think I can live with the lamps not being absolutely full brightness!

TIA

Mark in Spain.

I2CWRITE runs at about 200Khz, and sending a command involves at least 2 bytes (address + data). I2CWRITE has a short delay between bytes as well. Your actual throughput will be about 150 Kbits/sec = 15 Kbytes/sec = 66 uSec per command. 5 chips = 5* 66 = 330uSec. One half-cycle in Spain (I assume 50Hz) takes 10 mSec. That is 180/10 = 18 degrees per mSec or 6 degrees every 330 uSec. Once you fire the SCRs/TRIACs, you can turn them off at any time before the end of the half-cycle, since the SCRs/TRIACs will keep things going until the next zero crossing.

Keep in mind that at the above rate, your PIC will be running "flat out" and will have time to do NOTHING else. If you have background processing to do, you will either have to slow down the update rate or else use the PIC hardware to to the WRITE. And I always advocate using 18F chips and running them at 40Mhz.

Noticed a mistake in my earlier post. Two bytes are needed for control (address + data). My numbers above figure one byte. 15Kbytes/sec = 66 uSec per BYTE, but two bytes are needed = 132uSec * 5. So your system update time is 660uSec = 12 degree resolution - assuming you write all 5 "channels".

prolly a dumb question, but why not just use a pic with enough I/O to drive the opto's direct?

Bert's question is a good one. I find that it is almost always easier and better to use a "bigger" PIC to do what I need done.
Even if you need the power controller to work remotely, use a 64 or 80 pin PIC as an I2C slave. Having local intelligence might do you a lot of good. You could store up thousands of patterns, then call up any one of those patterns with a single command.

(And I wasn't going to answer any more posts.)

For now you won't have the last post here.

Quote:

---

Originally Posted by Charles Linquis

(And I wasn't going to answer any more posts.)

---

Keep posting Charles, you always have good stuff, I am taking notes.

Although I have a specific application for the 40 way version of the controller, I was going to make the 8 Way Mains triac driver boards, universal for other projects, and have proper PCB's made for them. On reading Charle's much appreciated reply, I think just having I2C inputs to the boards (and 1 zero crossing output) is too limiting. I think I may crank up the project a little and use CNCMachineGuys suggestion of using a PIC instead to do the driving, with I2C, & Serial inputs to the board. At this time I might also have a go at cutting my teeth on USB interfacing, and add a USB input by using a PIC18F2458.

I dont have PBP3 (yet), does EasyHID work with version PBP 2.5 and Micro Code Studio Plus V2.2.1.1?

Regards
Mark in Spain

Hi Mark,

Yes EasyHiID works with PBP2.5, and Micro Code Studio

Bob