Interrupt drive *MASTER* i2c ?

[mpfj]

I have a 2 PIC design transfering data via the I2C bus.

The slave code has all been written (fairly easily) all using interrupts.

But I'm having a pig of a time trying to get my head round an interrupt driven I2C master.

All the examples on this forum assume the master is just sitting in a tight loop using the CCS functions (i2c_write(), i2c_read(), etc). But these functions are all intended for non-interrupt usage.

Can anyone help me with a fully interrupt driven solution ? Is there any code out there that I could take a look at ?

Or am I destined to go this alone ?

[rnielsen]

Let me see if I understand this correctly....

You are waiting for an interrupt, caused by some other process, to call the i2c_start()... _write() _read() commands or are you wanting an interrupt to actually write the data to the i2c bus?

If you want an interrupt to start the i2c sequence then simply have a flag set and evaluate that flag in the main body of the code (or something like that). You would, normally, want the Slave to be interrupt driven so you don't lose any data that is coming from the Master.

Did I hit the mark or am I out in space again?

I've never had an interrupt controlling the Master portion of the i2c sequence except to set a flag to tell the main body to start it.

Ronald

[mpfj]

The basic design involves a small PIC (18F2220) programmed as an I/O processor - this is the slave.

The master is an 18F8722 doing all sorts of other stuff (e.g. keyboard, display, comms to "outside world").

When some I/O event happens (e.g. security card swipe, digital input change), the i/o processor decodes the event, signals the master, which then polls the slave to see what has happened wince the last poll.

Since both master and slave are performing timing critical / processor intensive tasks, I can't afforf for either of them to be sitting in a bit-banging loop waiting for an I2C byte to be transfered.

Hence I would like *both* master and slave to be interrupt driven.

I didn't think it would end up being such an uphill struggle, and I'm very soon going to have to rethink my approach, as I'm wasting too much time tinkering with the code ... to no avail

[Mark]

I have done lots I2C code but never have had the need to do an interrupt driven master (even though I do lots of time critical stuff too). However, it shouldn't be that hard. I don't know the details of what the message structure looks like, but you will need a state machine inside the interrupt handler. The states might look something like this:

START
SEND_ADDRESS
SEND_COMMAND
REPEAT_START
ADDRESS_READ_MODE
READ_DATA
STOP

You can forget about using the built in I2C functions. You will need to read the datasheet to see how to set up the registers to do starts, stops, reads, writes, ect..

Don't be intimidated by it. It is not as hard as you might think

[rnielsen]

If the I/O processor is the only device setting on the I2C bus then you might considering making it the Master and the 18F8722 as the Slave. That way the I/O processor could say 'Hey! somebody just swipped their card. Now, do something!'

If you have multiple I2C devices that the current Master is talking to then it might be possible to have a multi-master setup. That way when the I/O processor needs the attention it can take control of the I2C bus for a few milliseconds to tell the main Master to collect the information. That would make the Master routine interrupt driven, ie. using the SSP interrupt.

Ronald

[mpfj]