> 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).
I did comment that to be safe even interrupts might need an exit strategy.
> 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.
To me it does mean something. Even if I didn't have to use low power I
would if I could. I once calculated that if the CPU in your PC used the
same pricipals of low power operation as the MSP and other similar
micros that the energy reduction globally would be equivalent to
removing something like 16m vehicle from the road. I have 14
grandchildren, and I fear for their future
> 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...
I didn't say I never used polling, but generally I keep it to the
scenario you describe, ie developing a first run at a function. Oddly
SPI is one area where I find that polling simply won't work at all. Here
I'm specifically talking about the MSP430. I have one app for example
that logs multiple 3 axis sensors at 4000 samples a second and records
to SD card in SPI mode. This would simply not work if any of the devices
were allowed to hog the CPU. Especially the SD crad which can sit in
loops for relatively prolonged periods.
Al
MSP430F55xx interface with EEprom by I2C
Started by ●January 28, 2013
Reply by ●January 29, 20132013-01-29
Reply by ●January 29, 20132013-01-29
At the end it comes back to bad design. If the hardware guys did this
knowing the system needed IIC then fire the idiot. Also if you're
building so many boards at this early a stage of development that you
can't afford to chuck them then again bad planning. personally I'd bit
bang to test the overall concept, but you can bit bang an IIC without
having to sit in polled loops. Interrupts can work for you here too. Oh,
and as soon as I discovered the cock up I'd have the boards relaid and
make the guy who stuffed it up work all night to do it. His mistake his
dollar.
Al
knowing the system needed IIC then fire the idiot. Also if you're
building so many boards at this early a stage of development that you
can't afford to chuck them then again bad planning. personally I'd bit
bang to test the overall concept, but you can bit bang an IIC without
having to sit in polled loops. Interrupts can work for you here too. Oh,
and as soon as I discovered the cock up I'd have the boards relaid and
make the guy who stuffed it up work all night to do it. His mistake his
dollar.
Al
Reply by ●January 29, 20132013-01-29
> > 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.
> To me it does mean something. Even if I didn't have to use low power I
> would if I could. I once calculated that if the CPU in your PC used the
> same pricipals of low power operation as the MSP and other similar micros
> that the energy reduction globally would be equivalent to removing
> something like 16m vehicle from the road. I have 14 grandchildren, and I
> fear for their future
This only applies if the energy you save from device deployment is more than
the energy required to make that saving during development. For many
low-volume products, the extra engineering required to save more energy is
not recouped over the lifetime of the deployed devices. I have no idea how
you energy-reduce Windows, but at least Apple is having a bash with OS X.
But you know this. Case in point: LED bulbs and solar panels.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> "designed for ULP" means nothing when it is acting as a USB peripheral
> with 500mA at its disposal.
> To me it does mean something. Even if I didn't have to use low power I
> would if I could. I once calculated that if the CPU in your PC used the
> same pricipals of low power operation as the MSP and other similar micros
> that the energy reduction globally would be equivalent to removing
> something like 16m vehicle from the road. I have 14 grandchildren, and I
> fear for their future
This only applies if the energy you save from device deployment is more than
the energy required to make that saving during development. For many
low-volume products, the extra engineering required to save more energy is
not recouped over the lifetime of the deployed devices. I have no idea how
you energy-reduce Windows, but at least Apple is having a bash with OS X.
But you know this. Case in point: LED bulbs and solar panels.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●January 29, 20132013-01-29
How do you measure ROI?
I spent 3 hours once shaving off 15 uS.
Was it worth it?
In my particular case, NO!!, but in a further combined team effort, YES.
I spent 3 hours once shaving off 15 uS.
Was it worth it?
In my particular case, NO!!, but in a further combined team effort, YES.
Reply by ●January 29, 20132013-01-29
Sometimes you might actually have to shave off that 15uS, in which case
the 3 hours is worth it. Sometimes it may not be necessary, but if you
are selling 100k units and that 15uS saves a 0.1% on mean energy
consumption then it might also be worth it. At other times the energy
you burn in doing it outweighs any benefits, which was the point Paul
was making, and I agree, but, as with pauls comment on LEDs and Solar
panels.
LEDs are claimed to save 80% over incandescents, but in practice you can
reduce that to close to 95% very simply. Solar panels without energy
storage are only worth so much, but combine solar and wind, using
something like a compact VAWT, and you've opened up a whole new can of
worms that could redefine energy distribution for the next genration.
Let's face it the $10b or so in lost energy each year simply moving that
energy from the place it is generated to the place it is consumed is a
ludicrous outdated concept.
Sorry, whole new topic here, my apologies, but, if you haven't guessed
by now energy consumption is kind of a passion!.
Al
the 3 hours is worth it. Sometimes it may not be necessary, but if you
are selling 100k units and that 15uS saves a 0.1% on mean energy
consumption then it might also be worth it. At other times the energy
you burn in doing it outweighs any benefits, which was the point Paul
was making, and I agree, but, as with pauls comment on LEDs and Solar
panels.
LEDs are claimed to save 80% over incandescents, but in practice you can
reduce that to close to 95% very simply. Solar panels without energy
storage are only worth so much, but combine solar and wind, using
something like a compact VAWT, and you've opened up a whole new can of
worms that could redefine energy distribution for the next genration.
Let's face it the $10b or so in lost energy each year simply moving that
energy from the place it is generated to the place it is consumed is a
ludicrous outdated concept.
Sorry, whole new topic here, my apologies, but, if you haven't guessed
by now energy consumption is kind of a passion!.
Al
Reply by ●January 29, 20132013-01-29
Reply by ●January 30, 20132013-01-30
Okay gentlemen here is my further question please. If you interface the
MSP430F5529 with an EEPEOM in interrupt mode how do you detect the acknowledge
bit generated with EEPROM please?
Thanks,
John.
Thanks,
John.
Reply by ●January 31, 20132013-01-31
Hello!
> I thought that the reason people posted questions here was to get advise
> from those with more experience then they have.
Indeed. There are many ways to reply:
- The "Your method is dumb, mine is smart" reply. Do what I say, I know what's good
for you, I know you'll thank me later etc...
- The straight to the point reply,
I notice that you allow yourself what you would like to ban for others:
> I didn't say I never used polling, but generally I keep it to the
> scenario you describe, ie developing a first run at a function.
What tells you that the original poster doesn't want a first run of some
experiment? I remember having used this method the first time I had to deal
with I2C, one eye on the debugger and the other on the oscilloscope, and I
also use polling for a first run because I think it's simpler to get something
working in an early development stage. And apparently you do also think it's
simpler, otherwise you wouldn't bother using polling at all, would you?
And if you know how to do, why not replying straight with warnings dictated
by your long experience?
Pascal
> I thought that the reason people posted questions here was to get advise
> from those with more experience then they have.
Indeed. There are many ways to reply:
- The "Your method is dumb, mine is smart" reply. Do what I say, I know what's good
for you, I know you'll thank me later etc...
- The straight to the point reply,
I notice that you allow yourself what you would like to ban for others:
> I didn't say I never used polling, but generally I keep it to the
> scenario you describe, ie developing a first run at a function.
What tells you that the original poster doesn't want a first run of some
experiment? I remember having used this method the first time I had to deal
with I2C, one eye on the debugger and the other on the oscilloscope, and I
also use polling for a first run because I think it's simpler to get something
working in an early development stage. And apparently you do also think it's
simpler, otherwise you wouldn't bother using polling at all, would you?
And if you know how to do, why not replying straight with warnings dictated
by your long experience?
Pascal
Reply by ●February 1, 20132013-02-01
Actually I thought my reply was on the lines of "why would you do this,
do you understand the dangers of it".
If you don't understand what you're doing then it is wise to avoid as
many pitfalls as you can, once you do understand then the dangers are
not great. When I was young and dumb I used polling because I didn't
know better, even though I understood the use of interrupts then. Now I
understand the difference between when it is safe to use it and when it
isn't. Sometimes there is simply no choice, such as with the early PIC
parts, which had no interrupts, but, even then there were ways to
protect against the failed condition. From his various posts the OP
doesn't, or didn't get it.
I don't necessarily use polling because I think it is easier as a first
run, especially if I plan to ultimately use interrupts, that is just a
waste of effort. I generally use it if I am trying a new function and am
not 100% clear about how a device might operate. For example when Ti
first took over Chipcon there was virtually no information available on
the CC1100. most of the Chipcon guys seemed to have left adnw ere not
disposed towards supporting Ti, and Ti themselves were pretty clueless
at the time. the amount of information available was minimal, sometimes
acontradictory, and always incomplete. Add to that the number of errata
associated with these early parts and life was going to be fun. So in
this case I developed my first run code using some polled loops and some
interrupts, this was done to allow me to develop a more complete
understanding of what was going on under the covers. Polling was used
more as a debugging tool.
It is not 'my method' vs 'your method'. I didn't invent any of these,
but I do know how to determine which of many methods is likely to be
safer, by analysing various failure modes, and who ever mentioned being
thanked? I don't post here for the applause, if I did I'd have left the
group long ago, since most responses i get, usually off line, are
aggressive and rude. I post here because I've enjoyed doing this since I
was 9 years old, over 50 years ago, and I still enjoy it, and would like
to pass on some of what I've learned over the years in the hope that it
might increase somebody elses enjoyment.
Al
do you understand the dangers of it".
If you don't understand what you're doing then it is wise to avoid as
many pitfalls as you can, once you do understand then the dangers are
not great. When I was young and dumb I used polling because I didn't
know better, even though I understood the use of interrupts then. Now I
understand the difference between when it is safe to use it and when it
isn't. Sometimes there is simply no choice, such as with the early PIC
parts, which had no interrupts, but, even then there were ways to
protect against the failed condition. From his various posts the OP
doesn't, or didn't get it.
I don't necessarily use polling because I think it is easier as a first
run, especially if I plan to ultimately use interrupts, that is just a
waste of effort. I generally use it if I am trying a new function and am
not 100% clear about how a device might operate. For example when Ti
first took over Chipcon there was virtually no information available on
the CC1100. most of the Chipcon guys seemed to have left adnw ere not
disposed towards supporting Ti, and Ti themselves were pretty clueless
at the time. the amount of information available was minimal, sometimes
acontradictory, and always incomplete. Add to that the number of errata
associated with these early parts and life was going to be fun. So in
this case I developed my first run code using some polled loops and some
interrupts, this was done to allow me to develop a more complete
understanding of what was going on under the covers. Polling was used
more as a debugging tool.
It is not 'my method' vs 'your method'. I didn't invent any of these,
but I do know how to determine which of many methods is likely to be
safer, by analysing various failure modes, and who ever mentioned being
thanked? I don't post here for the applause, if I did I'd have left the
group long ago, since most responses i get, usually off line, are
aggressive and rude. I post here because I've enjoyed doing this since I
was 9 years old, over 50 years ago, and I still enjoy it, and would like
to pass on some of what I've learned over the years in the hope that it
might increase somebody elses enjoyment.
Al
Reply by ●February 2, 20132013-02-02
Hello!
> I don't necessarily use polling because I think it is easier as a first
> run, especially if I plan to ultimately use interrupts, that is just a
> waste of effort. [...] For example when Ti first took over Chipcon [...]
You don't have to justify yourself for using polling like if you
were caught with your hand in a box of biscuits. The fact is that you
(even you!!!) sometimes use this technique. And so do I.
And I don't consider it as a waste of effort, it's simply no effort at
all. Just a matter of calling a function written once and only once
for a given processor family, therefore good enough for experiments.
Anyway, you also started like this (when you "didn't know better").
I also started like this, and most programmers do. After all, I guess
most programmers learn how to make a loop before they learn how to deal
with interrupts.
> I don't post here for the applause, if I did I'd have left the
> group long ago, since most responses i get, usually off line, are
> aggressive and rude.
Without any intention to offend you at all, but with the tonality of some of your
replies or comments, I'm not surprised that some may feel hurt. This of course
does not justify to be rude or aggressive, but it can explain it. That said, you're
not alone in this case.
Pascal
> I don't necessarily use polling because I think it is easier as a first
> run, especially if I plan to ultimately use interrupts, that is just a
> waste of effort. [...] For example when Ti first took over Chipcon [...]
You don't have to justify yourself for using polling like if you
were caught with your hand in a box of biscuits. The fact is that you
(even you!!!) sometimes use this technique. And so do I.
And I don't consider it as a waste of effort, it's simply no effort at
all. Just a matter of calling a function written once and only once
for a given processor family, therefore good enough for experiments.
Anyway, you also started like this (when you "didn't know better").
I also started like this, and most programmers do. After all, I guess
most programmers learn how to make a loop before they learn how to deal
with interrupts.
> I don't post here for the applause, if I did I'd have left the
> group long ago, since most responses i get, usually off line, are
> aggressive and rude.
Without any intention to offend you at all, but with the tonality of some of your
replies or comments, I'm not surprised that some may feel hurt. This of course
does not justify to be rude or aggressive, but it can explain it. That said, you're
not alone in this case.
Pascal
