> I see everyone agrees with Al. I do not doubt
Al's intelligence but I agree with Hardy. Interrupt does add complexity
specially when you are in time constraint. It is a good idea to use interrupt
when you need it. If you have a single task running and do not want any other
task disturb it then using the polling is the way to go (maybe in my case).
A program looping on a failed condition can lose you your market. Time
constraints are artificial barriers usually imposed by external forces,
like managers.
It's nothing about intelligence, more about 40+ years experience, most
of that spent chasing down and correcting other peoples programming, and
hardware design, stuff ups. And failed polling loops are among the top 5
reasons for failure on my all time list.
Al
MSP430F55xx interface with EEprom by I2C
Started by ●January 28, 2013
Reply by ●January 28, 20132013-01-28
Reply by ●January 28, 20132013-01-28
Hello!
I never agree with replies like "why do you want to do that ?" which always
look (at best) condescending.
If you want to do polling, you may (or may not) have a good reason for it but
anyway if you try and realize by yourself that interrupts have some advantages,
you will learn more than having followed advices and done it "the right way" at
once, without actually bumping into polling drawbacks.
So your question was how to do I2C without interrupts, let's reply to it instead
of preaching the "truth".
TI does have code without interrupts (at least without USCI) interrupts, some of the
examples without interrupts at all, which should indicate that using I2C without
interrupts is not necessarily as dumb as one could think. I have seen that, but
years ago when using F169...
Wait... A grep in the sample code to find I2C related files without USART.*VECTOR...
The result is fet140_i2c_01.c, 08.c, 13.c, 14.c, 15.c. You have 5 examples in this
archive.
There are probably examples with more recent processors, but these are the
only examples I have actually seen in the past. Try to grep in more recent sets
of sample codes. You will find the above samples in the F169 sample archive.
You will have to replace the register names that have been changed in the later
cihip versions. Ex: UxCTL -> UCAxCTL or UCBxCTL, etc...
That said, polling has drawbacks (program freeze), but this has already been said
extensively. You have been warned!
Pascal
I never agree with replies like "why do you want to do that ?" which always
look (at best) condescending.
If you want to do polling, you may (or may not) have a good reason for it but
anyway if you try and realize by yourself that interrupts have some advantages,
you will learn more than having followed advices and done it "the right way" at
once, without actually bumping into polling drawbacks.
So your question was how to do I2C without interrupts, let's reply to it instead
of preaching the "truth".
TI does have code without interrupts (at least without USCI) interrupts, some of the
examples without interrupts at all, which should indicate that using I2C without
interrupts is not necessarily as dumb as one could think. I have seen that, but
years ago when using F169...
Wait... A grep in the sample code to find I2C related files without USART.*VECTOR...
The result is fet140_i2c_01.c, 08.c, 13.c, 14.c, 15.c. You have 5 examples in this
archive.
There are probably examples with more recent processors, but these are the
only examples I have actually seen in the past. Try to grep in more recent sets
of sample codes. You will find the above samples in the F169 sample archive.
You will have to replace the register names that have been changed in the later
cihip versions. Ex: UxCTL -> UCAxCTL or UCBxCTL, etc...
That said, polling has drawbacks (program freeze), but this has already been said
extensively. You have been warned!
Pascal
Reply by ●January 28, 20132013-01-28
> Define better? In this context. In the context of
a good program there
> is only robust and reliable, once it is robust and reliable then you can
> look for compact and efficient. A polled loop without a means to exit if
> the test fails is always going to be poor programming.
I have to disagree here. A pend waiting an interrupt that never fires would also be poor programming, then? The interrupt buys you nothing in this case. And it depends whether you do all your programming in ISRs (I2C interrupt loads next thing to do into I2C controller) or whether you use tasks (I2C interrupt signals an I2C task that it needs attention), or even if you use device drivers (I2C interrupt takes care of queued high-level I2C transaction, signals semaphore on completion, mainline pends semaphore).
> Yes your reponse to the single event you are waiting for is faster, but
> the CPU can do nothing while it sits there spinning its wheels, so
> potentially tens, or hundreds of thousands of programming cycles are
> wasted. In addition you are sitting there in active mode when you could
> well be running in one of the low power modes, so the gain is simplicity
> and response at a single instance compared to efficiency of execution
> and power consumption across the program.
Many designs do not care for power consumption. The fact the MSP430 is "designed for ULP" means nothing when it is acting as a USB peripheral with 500mA at its disposal.
Just take a look at many of the available USB and other device stacks, busy-wait on peripherals is rife. And in Linuxland, spin locks are all over the place.
Personally, I code up things using polled mode on complex microcontrollers, more complex than MSP430, to test things out. Once I have a working polled-mode implementation, I then investigate using interrupts (typically for I2C and Ethernet which do not have a high IRQ overhead). For things like SPI, there's no real advantage of running them with interrupts because I run SPI at 40MHz and by the time the FIFO load completes, the data has already disappeared down the wire...
-- Paul.
> is only robust and reliable, once it is robust and reliable then you can
> look for compact and efficient. A polled loop without a means to exit if
> the test fails is always going to be poor programming.
I have to disagree here. A pend waiting an interrupt that never fires would also be poor programming, then? The interrupt buys you nothing in this case. And it depends whether you do all your programming in ISRs (I2C interrupt loads next thing to do into I2C controller) or whether you use tasks (I2C interrupt signals an I2C task that it needs attention), or even if you use device drivers (I2C interrupt takes care of queued high-level I2C transaction, signals semaphore on completion, mainline pends semaphore).
> Yes your reponse to the single event you are waiting for is faster, but
> the CPU can do nothing while it sits there spinning its wheels, so
> potentially tens, or hundreds of thousands of programming cycles are
> wasted. In addition you are sitting there in active mode when you could
> well be running in one of the low power modes, so the gain is simplicity
> and response at a single instance compared to efficiency of execution
> and power consumption across the program.
Many designs do not care for power consumption. The fact the MSP430 is "designed for ULP" means nothing when it is acting as a USB peripheral with 500mA at its disposal.
Just take a look at many of the available USB and other device stacks, busy-wait on peripherals is rife. And in Linuxland, spin locks are all over the place.
Personally, I code up things using polled mode on complex microcontrollers, more complex than MSP430, to test things out. Once I have a working polled-mode implementation, I then investigate using interrupts (typically for I2C and Ethernet which do not have a high IRQ overhead). For things like SPI, there's no real advantage of running them with interrupts because I run SPI at 40MHz and by the time the FIFO load completes, the data has already disappeared down the wire...
-- Paul.
Reply by ●January 28, 20132013-01-28
> That said, polling has drawbacks (program freeze),
but this has already been said
> extensively. You have been warned!
If you application is blocked waiting for an I2C transaction to complete, whether by polling or by interrupts, you're blocked. You can't go forward. Dead. Interrupts gain you bugger all in this case, you're still dead. As I2C SCL can remain static low, by design, until the end of time, there is no way to recover, and it would be better to use SMBus /by design/.
-- Paul.
> extensively. You have been warned!
If you application is blocked waiting for an I2C transaction to complete, whether by polling or by interrupts, you're blocked. You can't go forward. Dead. Interrupts gain you bugger all in this case, you're still dead. As I2C SCL can remain static low, by design, until the end of time, there is no way to recover, and it would be better to use SMBus /by design/.
-- Paul.
Reply by ●January 29, 20132013-01-29
On 29.01.2013 01:53, Onestone wrote:
:
> There is a place for bit banging, but polling, without an exit mechanism
> is poor programming, and a disaster waiting to happen. The exit
> strategies require additional resources and are required at a per event
:
I'm thinking of a bootloader with waiting watchdog (sledgehammer exit
strategy) doing I2C polling (or bitbanging), while the actual firmware
is doing communication with the I2C interface through interrupts (to
save CPU resources).
:
> Elegance doesn't come into it. It is about designing robust reliable
> code. Every time you write something like:_
>
> FOO:
> BIT.B #FLAG,ISTER
> JNZ FOO
:
Unfortunately even the interrupt driven piece of software will at some
place wait for a received packet of data (or at least some action is not
triggered, because communication is hanging).
Hardy
:
> There is a place for bit banging, but polling, without an exit mechanism
> is poor programming, and a disaster waiting to happen. The exit
> strategies require additional resources and are required at a per event
:
I'm thinking of a bootloader with waiting watchdog (sledgehammer exit
strategy) doing I2C polling (or bitbanging), while the actual firmware
is doing communication with the I2C interface through interrupts (to
save CPU resources).
:
> Elegance doesn't come into it. It is about designing robust reliable
> code. Every time you write something like:_
>
> FOO:
> BIT.B #FLAG,ISTER
> JNZ FOO
:
Unfortunately even the interrupt driven piece of software will at some
place wait for a received packet of data (or at least some action is not
triggered, because communication is hanging).
Hardy
Reply by ●January 29, 20132013-01-29
You didn't look hard enough. Hopefully because you were looking for the
wrong thing. The term you're looking for is 'bit banging'.
There are lots of examples out there. This is the 1st I found (which was posted to this list at some point in the past). Be aware that you can get stuck waiting -- plan for it and set up a safety net. You'll will get bit if you don't understand how I2C works, I promise.
To all the grumpy programmers who pontificated about your question but failed to answer it -- there are legitimate uses for bit banging i2c. Say, for example your hardware guys wire up your SDA and SCL lines to the wrong net and suddenly you don't have pullups (try initializing the hardware module without them). Do you
A) Disable a major fature
B) Re-spin the board or
C) Bit bang away and ship on time, saving tens of thousands of dollars?
There are lots of examples out there. This is the 1st I found (which was posted to this list at some point in the past). Be aware that you can get stuck waiting -- plan for it and set up a safety net. You'll will get bit if you don't understand how I2C works, I promise.
To all the grumpy programmers who pontificated about your question but failed to answer it -- there are legitimate uses for bit banging i2c. Say, for example your hardware guys wire up your SDA and SCL lines to the wrong net and suddenly you don't have pullups (try initializing the hardware module without them). Do you
A) Disable a major fature
B) Re-spin the board or
C) Bit bang away and ship on time, saving tens of thousands of dollars?
Reply by ●January 29, 20132013-01-29
> You didn't look hard enough. Hopefully
because you were looking for the
> wrong thing. The term you're looking for is 'bit banging'.
Don't think so. Bit banging would be to emulate I2C using pure GPIO and
polling with some timing thrown in for start and stop condition hold times.
However, the MSP430 has an I2C peripheral that does not need to be
bit-banged, it just needs to be fed instructions and polled to wait for
completion, and it does all the hard work.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> wrong thing. The term you're looking for is 'bit banging'.
Don't think so. Bit banging would be to emulate I2C using pure GPIO and
polling with some timing thrown in for start and stop condition hold times.
However, the MSP430 has an I2C peripheral that does not need to be
bit-banged, it just needs to be fed instructions and polled to wait for
completion, and it does all the hard work.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●January 29, 20132013-01-29
> Don't think so. Bit banging would be to
emulate I2C using pure GPIO and
> polling with some timing thrown in for start and stop condition hold times.
> However, the MSP430 has an I2C peripheral that does not need to be
> bit-banged, it just needs to be fed instructions and polled to wait for
> completion, and it does all the hard work.
I2C-Master isnt hard work. ;-)
M.
> polling with some timing thrown in for start and stop condition hold times.
> However, the MSP430 has an I2C peripheral that does not need to be
> bit-banged, it just needs to be fed instructions and polled to wait for
> completion, and it does all the hard work.
I2C-Master isnt hard work. ;-)
M.
Reply by ●January 29, 20132013-01-29
> I2C-Master isnt hard work. ;-)
I2C Master *is* harder work *if* you operate in a multi-master system! :-)
Single master, of course, little problem.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
I2C Master *is* harder work *if* you operate in a multi-master system! :-)
Single master, of course, little problem.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●January 29, 20132013-01-29
I thought that the reason people posted questions here was to get advise
from those with more experience then they have. Whether or not they
choose to use any advice is up to them, as is how much they value that
advice. The concept of doing things anyway you like until you learn
better methods is a great one, as long as there aren't people relying on
your products to work reliably. I thought the objective was to try and
guide people away from such potenitally catastrophic paths.
The thing to understand about Ti's app notes is that they are not
intended to be, nor are they even close to the best practice or the best
way of doing things. Their purpose is to give a starting point on how to
use a feature, or implement a basic task. One of the worst pieces of
coding I've seen, from a manufacturer, comes from a Ti app note on bit
banging IIC.
Al
from those with more experience then they have. Whether or not they
choose to use any advice is up to them, as is how much they value that
advice. The concept of doing things anyway you like until you learn
better methods is a great one, as long as there aren't people relying on
your products to work reliably. I thought the objective was to try and
guide people away from such potenitally catastrophic paths.
The thing to understand about Ti's app notes is that they are not
intended to be, nor are they even close to the best practice or the best
way of doing things. Their purpose is to give a starting point on how to
use a feature, or implement a basic task. One of the worst pieces of
coding I've seen, from a manufacturer, comes from a Ti app note on bit
banging IIC.
Al
