Can someone explain in detail where an IRQ can interrupt my program?

I need to add 6 more RS232 serial port instruments to the 6 I’ve already got on my Raptor board. After a fair amount of self-education it looks like adding one I2C UART per instrument might work (like the Max3107). It looks like I should be able to write a class that looks pretty much like the built-in NETMF SerialPort that I use for the 6 native UARTs. The I2C UART can generate an interrupt when 1 (or a user selectable amount of) character shows up in its receive FIFO. I can write an I2CSerialInstrument class with an event handler for that interrupt that has the same interface to the rest of my program as my SerialPortInstrument class.

My program would work something like this. Step 1) sequentially send out to each of the I2C instruments whatever character string is required to generate a sample. Step 2) characters show up at random times at each of the I2C UARTs. Step 3) the event handler for each UART drains the FIFO in each UART.

Here’s the question raised by one of my colleagues. What happens if I’m in the middle of an I2C transaction sending the generate sample character string to one I2C instrument (Step 1 above) and a second I2C instrument that has already received a generate sample string starts sending it’s sample characters (Step 2 above). Characters from the second instrument would generate an IRQ which calls the IRQ event handler that will try to execute an I2C transaction to empty the second instruments I2C UART FIFO (Step 3 above). Can this second transaction conflict with the I2C transaction in step 1?

Another way to ask the question is how atomic is an I2C transaction, i.e., can an IRQ that generates an I2C transaction interrupt an ongoing I2C transaction?

I know I can sidestep the problem by only querying and reading one instrument at a time but that puts all the sample time delays in series which adds up to a fair amount for the 12 instruments I have to deal with.

If someone has a cleaner way to add RS232 serial ports, I’d be happy to hear it.

Thanks - Gene

@ Gene - So you’re asking if the I2C transfer can be interrupted? Technically yea. Your program design has to know not to interrupt certain operations (I don’t recommend locks). If it’s in the managed stack the interrupt isn’t executed immediately. If it’s RLP it is.

I have thought about this problem as well for my project and here is my 2 cents: Have a thread that deals with the transactions running in an infinite loop taking it’s information from a queue. If the queue is empty the the thread should self suspend. When an interrupt happens let it add the request to the queue and resume the suspended thread if it is suspended. This way you’re not wasting time polling.

@ Mr. John Smith - I like the queued transaction approach. I already have one queue that all my UART event handlers dump their data into. Adding one to coordinate the I2C activities shouldn’t be too hard.

Out of curiosity, why don’t you recommend locks?

@ Gene - They are computationally more expensive than well written code; and in embedded development make every nano second count.

@ Gene -
Dear Mr. Gene
I’m planning to use MAX3107 to my new design.
I highly Appreciated to have your recommendations based on your pervious experiments about using this chip.
Best Regrads!