If during an I2C transaction (writing to a I2C display), I get a UART
interrupt that has a possible I2C transaction itself (writing 2 bytes to
I2C RAM), how do I handle that? Is the display transaction lost? Does
the UART I2C transaction get locked because the display has control of
the I2C bus just before the interrupt? Does the display's I2C
transaction time out, drop the bus, and then the UART's I2C transaction
take over? I'm trying to figure out how best to handle it. Or, should
I just try not to do an I2C transaction in the UART interrupt? Or maybe
I'm just missing something and both work?
Sutton
--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
800-207-6269, 770-514-7999, 770-514-1285 FAX
s...@lookoutportablesecurity.com
interrupting an I2C transaction with a UART interrupt using LPC2148
Started by ●March 28, 2013
Reply by ●March 29, 20132013-03-29
It all depends on timing requirements but I would try to move I2C out of
interrupt handler. In UART interrupt handler I would just set some flags
and do the I2C transaction in main loop. If display code is allso in main
loop all is well. If display code is in another interrupt handler I would
move it to main loop, just like in UART case.
On Fri, Mar 29, 2013 at 2:58 AM, Sutton Mehaffey <
s...@lookoutportablesecurity.com> wrote:
> If during an I2C transaction (writing to a I2C display), I get a UART
> interrupt that has a possible I2C transaction itself (writing 2 bytes to
> I2C RAM), how do I handle that? Is the display transaction lost? Does
> the UART I2C transaction get locked because the display has control of
> the I2C bus just before the interrupt? Does the display's I2C
> transaction time out, drop the bus, and then the UART's I2C transaction
> take over? I'm trying to figure out how best to handle it. Or, should
> I just try not to do an I2C transaction in the UART interrupt? Or maybe
> I'm just missing something and both work?
>
> Sutton
>
> --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr. #100
> Kennesaw, GA 30144
> 800-207-6269, 770-514-7999, 770-514-1285 FAX
> s...@lookoutportablesecurity.com
>
>
interrupt handler. In UART interrupt handler I would just set some flags
and do the I2C transaction in main loop. If display code is allso in main
loop all is well. If display code is in another interrupt handler I would
move it to main loop, just like in UART case.
On Fri, Mar 29, 2013 at 2:58 AM, Sutton Mehaffey <
s...@lookoutportablesecurity.com> wrote:
> If during an I2C transaction (writing to a I2C display), I get a UART
> interrupt that has a possible I2C transaction itself (writing 2 bytes to
> I2C RAM), how do I handle that? Is the display transaction lost? Does
> the UART I2C transaction get locked because the display has control of
> the I2C bus just before the interrupt? Does the display's I2C
> transaction time out, drop the bus, and then the UART's I2C transaction
> take over? I'm trying to figure out how best to handle it. Or, should
> I just try not to do an I2C transaction in the UART interrupt? Or maybe
> I'm just missing something and both work?
>
> Sutton
>
> --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr. #100
> Kennesaw, GA 30144
> 800-207-6269, 770-514-7999, 770-514-1285 FAX
> s...@lookoutportablesecurity.com
>
>
Reply by ●March 29, 20132013-03-29
Or, you could set up an I2C queue, like one would do for a UART, and do all
of the I2C stuff in its own interrupt.
Mike
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Mario Ivancic
Sent: Friday, March 29, 2013 1:01 AM
To: l...
Subject: Re: [lpc2000] interrupting an I2C transaction with a UART
interrupt using LPC2148
It all depends on timing requirements but I would try to move I2C out of
interrupt handler. In UART interrupt handler I would just set some flags
and do the I2C transaction in main loop. If display code is allso in main
loop all is well. If display code is in another interrupt handler I would
move it to main loop, just like in UART case.
On Fri, Mar 29, 2013 at 2:58 AM, Sutton Mehaffey <
s...@lookoutportablesecurity.com> wrote:
> If during an I2C transaction (writing to a I2C display), I get a UART
> interrupt that has a possible I2C transaction itself (writing 2 bytes to
> I2C RAM), how do I handle that? Is the display transaction lost? Does
> the UART I2C transaction get locked because the display has control of
> the I2C bus just before the interrupt? Does the display's I2C
> transaction time out, drop the bus, and then the UART's I2C transaction
> take over? I'm trying to figure out how best to handle it. Or, should
> I just try not to do an I2C transaction in the UART interrupt? Or maybe
> I'm just missing something and both work?
>
> Sutton
>
> --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr. #100
> Kennesaw, GA 30144
> 800-207-6269, 770-514-7999, 770-514-1285 FAX
> s...@lookoutportablesecurity.com
>
>
of the I2C stuff in its own interrupt.
Mike
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Mario Ivancic
Sent: Friday, March 29, 2013 1:01 AM
To: l...
Subject: Re: [lpc2000] interrupting an I2C transaction with a UART
interrupt using LPC2148
It all depends on timing requirements but I would try to move I2C out of
interrupt handler. In UART interrupt handler I would just set some flags
and do the I2C transaction in main loop. If display code is allso in main
loop all is well. If display code is in another interrupt handler I would
move it to main loop, just like in UART case.
On Fri, Mar 29, 2013 at 2:58 AM, Sutton Mehaffey <
s...@lookoutportablesecurity.com> wrote:
> If during an I2C transaction (writing to a I2C display), I get a UART
> interrupt that has a possible I2C transaction itself (writing 2 bytes to
> I2C RAM), how do I handle that? Is the display transaction lost? Does
> the UART I2C transaction get locked because the display has control of
> the I2C bus just before the interrupt? Does the display's I2C
> transaction time out, drop the bus, and then the UART's I2C transaction
> take over? I'm trying to figure out how best to handle it. Or, should
> I just try not to do an I2C transaction in the UART interrupt? Or maybe
> I'm just missing something and both work?
>
> Sutton
>
> --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr. #100
> Kennesaw, GA 30144
> 800-207-6269, 770-514-7999, 770-514-1285 FAX
> s...@lookoutportablesecurity.com
>
>
Reply by ●March 29, 20132013-03-29
My I2C is not interrupt driven. Only my UART. So, what you are saying
is to set a busy flag when I start my display transaction and if my
interrupt kicks in, it will wait until the display I2C transaction is
finished before starting its own I2C transaction with RAM?
Sutton
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
770-514-7999
770-514-1285 (FAX)
www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
On 3/29/2013 3:01 AM, Mario Ivancic wrote:
>
> It all depends on timing requirements but I would try to move I2C out of
> interrupt handler. In UART interrupt handler I would just set some flags
> and do the I2C transaction in main loop. If display code is allso in main
> loop all is well. If display code is in another interrupt handler I would
> move it to main loop, just like in UART case.
>
> On Fri, Mar 29, 2013 at 2:58 AM, Sutton Mehaffey <
> s...@lookoutportablesecurity.com
> > wrote:
>
> > If during an I2C transaction (writing to a I2C display), I get a UART
> > interrupt that has a possible I2C transaction itself (writing 2 bytes to
> > I2C RAM), how do I handle that? Is the display transaction lost? Does
> > the UART I2C transaction get locked because the display has control of
> > the I2C bus just before the interrupt? Does the display's I2C
> > transaction time out, drop the bus, and then the UART's I2C transaction
> > take over? I'm trying to figure out how best to handle it. Or, should
> > I just try not to do an I2C transaction in the UART interrupt? Or maybe
> > I'm just missing something and both work?
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr. #100
> > Kennesaw, GA 30144
> > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > s...@lookoutportablesecurity.com
>
> >
> >
> >
> >
> >
> >
is to set a busy flag when I start my display transaction and if my
interrupt kicks in, it will wait until the display I2C transaction is
finished before starting its own I2C transaction with RAM?
Sutton
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
770-514-7999
770-514-1285 (FAX)
www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
On 3/29/2013 3:01 AM, Mario Ivancic wrote:
>
> It all depends on timing requirements but I would try to move I2C out of
> interrupt handler. In UART interrupt handler I would just set some flags
> and do the I2C transaction in main loop. If display code is allso in main
> loop all is well. If display code is in another interrupt handler I would
> move it to main loop, just like in UART case.
>
> On Fri, Mar 29, 2013 at 2:58 AM, Sutton Mehaffey <
> s...@lookoutportablesecurity.com
> > wrote:
>
> > If during an I2C transaction (writing to a I2C display), I get a UART
> > interrupt that has a possible I2C transaction itself (writing 2 bytes to
> > I2C RAM), how do I handle that? Is the display transaction lost? Does
> > the UART I2C transaction get locked because the display has control of
> > the I2C bus just before the interrupt? Does the display's I2C
> > transaction time out, drop the bus, and then the UART's I2C transaction
> > take over? I'm trying to figure out how best to handle it. Or, should
> > I just try not to do an I2C transaction in the UART interrupt? Or maybe
> > I'm just missing something and both work?
> >
> > Sutton
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr. #100
> > Kennesaw, GA 30144
> > 800-207-6269, 770-514-7999, 770-514-1285 FAX
> > s...@lookoutportablesecurity.com
>
> >
> >
> >
> >
> >
> >
Reply by ●March 29, 20132013-03-29
> My I2C is not interrupt driven. Only my UART. So,
what you are saying is
> to set a busy flag when I start my display transaction and if my interrupt
> kicks in, it will wait until the display I2C transaction is finished
> before starting its own I2C transaction with RAM?
Wow. This is bad. Doing polled I2C transactions in a UART ISR? What could
*possibly* go wrong? :-(
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> to set a busy flag when I start my display transaction and if my interrupt
> kicks in, it will wait until the display I2C transaction is finished
> before starting its own I2C transaction with RAM?
Wow. This is bad. Doing polled I2C transactions in a UART ISR? What could
*possibly* go wrong? :-(
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●March 29, 20132013-03-29
I see a deadlock here :)
The normal software can't poll the I2C while your waiting in an interrupt.
My opinion on polling I2C is don't, the same goes for waiting in an interrupt.
--
Kevin
--- In l..., "Paul Curtis" wrote:
>
> > My I2C is not interrupt driven. Only my UART. So, what you are saying is
> > to set a busy flag when I start my display transaction and if my interrupt
> > kicks in, it will wait until the display I2C transaction is finished
> > before starting its own I2C transaction with RAM?
>
> Wow. This is bad. Doing polled I2C transactions in a UART ISR? What could
> *possibly* go wrong? :-(
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>
The normal software can't poll the I2C while your waiting in an interrupt.
My opinion on polling I2C is don't, the same goes for waiting in an interrupt.
--
Kevin
--- In l..., "Paul Curtis" wrote:
>
> > My I2C is not interrupt driven. Only my UART. So, what you are saying is
> > to set a busy flag when I start my display transaction and if my interrupt
> > kicks in, it will wait until the display I2C transaction is finished
> > before starting its own I2C transaction with RAM?
>
> Wow. This is bad. Doing polled I2C transactions in a UART ISR? What could
> *possibly* go wrong? :-(
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>
Reply by ●March 29, 20132013-03-29
Paul,
That was my question. It seems without making my I2C transactions run by
interrupt, it is probably not a good idea to have I2C transactions in my
UART interrupt.
I would prefer not to rewrite my I2C polling method to an interrupt
(right now anyway), since it's pretty robust and I'm just trying to add
a new feature to our system. One in which the UART grabs valid serial
packets (3 different kinds) and puts them on a queue for background
processing. I was trying to avoid 2 of the 3 queues by storing a few
pieces of packet information in I2C RAM, but discovered there could be a
I2C blowup if I did that.
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
770-514-7999
770-514-1285 (FAX)
www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
On 3/29/2013 10:11 AM, Paul Curtis wrote:
>
> > My I2C is not interrupt driven. Only my UART. So, what you are saying is
> > to set a busy flag when I start my display transaction and if my
> interrupt
> > kicks in, it will wait until the display I2C transaction is finished
> > before starting its own I2C transaction with RAM?
>
> Wow. This is bad. Doing polled I2C transactions in a UART ISR? What could
> *possibly* go wrong? :-(
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
That was my question. It seems without making my I2C transactions run by
interrupt, it is probably not a good idea to have I2C transactions in my
UART interrupt.
I would prefer not to rewrite my I2C polling method to an interrupt
(right now anyway), since it's pretty robust and I'm just trying to add
a new feature to our system. One in which the UART grabs valid serial
packets (3 different kinds) and puts them on a queue for background
processing. I was trying to avoid 2 of the 3 queues by storing a few
pieces of packet information in I2C RAM, but discovered there could be a
I2C blowup if I did that.
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr. #100
Kennesaw, GA 30144
770-514-7999
770-514-1285 (FAX)
www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com
On 3/29/2013 10:11 AM, Paul Curtis wrote:
>
> > My I2C is not interrupt driven. Only my UART. So, what you are saying is
> > to set a busy flag when I start my display transaction and if my
> interrupt
> > kicks in, it will wait until the display I2C transaction is finished
> > before starting its own I2C transaction with RAM?
>
> Wow. This is bad. Doing polled I2C transactions in a UART ISR? What could
> *possibly* go wrong? :-(
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
