Hi everyone,
I need help interfacing the eeprom to MSP430F5529 through I2C please. I have
looked at the sample codes offered by TI but they are done through interrupts.
I was wondering how to do it through poll mode. Thanks for your helps in
advance,
John.
MSP430F55xx interface with EEprom by I2C
Started by ●January 28, 2013
Reply by ●January 28, 20132013-01-28
Why do you want to poll? This is normally not a great idea, since it
requires loops until a condition is met, if the condition fails to be
met then you have an infinite loop.
Putting timers and loop counters on every conditional check is dumb and
wasteful. Interrupts exist for a very good reason, you should learn how
to use them.
Al
requires loops until a condition is met, if the condition fails to be
met then you have an infinite loop.
Putting timers and loop counters on every conditional check is dumb and
wasteful. Interrupts exist for a very good reason, you should learn how
to use them.
Al
Reply by ●January 28, 20132013-01-28
I echo Al's comments and add this: interrupts are the easy way to do it --
and you have the examples. Maybe there are no polling examples because that is
not the way anybody (who knows enough that you would want their examples) does
it.
I repeat: Use the examples you have and return with specific questions when it does not work.
Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor
I repeat: Use the examples you have and return with specific questions when it does not work.
Emmett Redd Ph.D. mailto:E...@missouristate.edu
Professor
Reply by ●January 28, 20132013-01-28
Hi Emmett, I think the problem is that a lot of people simply can't get
their heads around the fact that interrupts are asynchronous. They don't
'sit in the normal program flow'. It's very easy to understand a polled
system because everything is forced to happen sequentially. Of course
while it's polling, the micro can't do anything else, but this is what
seems to throw people. How can it go away from this point where it needs
a response, and somehow come back to exactly the right point at almost
the instant the response is there?
Cheers
Al
their heads around the fact that interrupts are asynchronous. They don't
'sit in the normal program flow'. It's very easy to understand a polled
system because everything is forced to happen sequentially. Of course
while it's polling, the micro can't do anything else, but this is what
seems to throw people. How can it go away from this point where it needs
a response, and somehow come back to exactly the right point at almost
the instant the response is there?
Cheers
Al
Reply by ●January 28, 20132013-01-28
I agree with Al.
The concept is hard to grasp unless it is taught and explained and seen
as it happens.
That's why I think an assembler class is imperative, to show the basics
of how things work at the lowest level, and show the stack as an
interrupt comes in, and what happens to it, and what happens when you
RTI and miraculously go back to where you were. AND explain the
miraculous part as expected behaviour.
After having asked new grads if they learned this, I got a 0%
affirmative reply.
How can kids learn?
The concept is hard to grasp unless it is taught and explained and seen
as it happens.
That's why I think an assembler class is imperative, to show the basics
of how things work at the lowest level, and show the stack as an
interrupt comes in, and what happens to it, and what happens when you
RTI and miraculously go back to where you were. AND explain the
miraculous part as expected behaviour.
After having asked new grads if they learned this, I got a 0%
affirmative reply.
How can kids learn?
Reply by ●January 28, 20132013-01-28
On 28.01.2013 14:42, Onestone wrote:
> Why do you want to poll? This is normally not a great idea, since it
Hey, why not poll, why not doing bitbanging at all? Sometimes
interrupts add unnecessary complexity (so poll), sometimes there are not
enough interfaces (so bitbang - which of course is worse than polling).
I think, actual implementation does - as usual - depend on more
circumstances than just "doing it the most elegant way". (and actually
what is "elegant" in what meaning and context?)
Hardy
> Why do you want to poll? This is normally not a great idea, since it
Hey, why not poll, why not doing bitbanging at all? Sometimes
interrupts add unnecessary complexity (so poll), sometimes there are not
enough interfaces (so bitbang - which of course is worse than polling).
I think, actual implementation does - as usual - depend on more
circumstances than just "doing it the most elegant way". (and actually
what is "elegant" in what meaning and context?)
Hardy
Reply by ●January 28, 20132013-01-28
IMHO you can do what you want, and it is not a problem to poll or bitbang
if you realize that it is better for your project.
Interrupts have several advantages over polling, in special concerning
scalability of your project. Polling have the advantage of the lowest
latency of your communication.
In special at MSP430 there are not many advantages on using polling over
interrupt concerning simplicity as you are going to poll exactly the same
flags that your hardware would be. You can find a code example at
MSP430ware.
Regards,
--
Lu Filipe Rossi
Electrical Engineer
Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
Escola Politnica
Universidade de S Paulo
Cel. +55 (11) 7662-9234
if you realize that it is better for your project.
Interrupts have several advantages over polling, in special concerning
scalability of your project. Polling have the advantage of the lowest
latency of your communication.
In special at MSP430 there are not many advantages on using polling over
interrupt concerning simplicity as you are going to poll exactly the same
flags that your hardware would be. You can find a code example at
MSP430ware.
Regards,
--
Lu Filipe Rossi
Electrical Engineer
Biomechatronics Lab. / Grupo de Sensores Integreis e Sistemas
Escola Politnica
Universidade de S Paulo
Cel. +55 (11) 7662-9234
Reply by ●January 28, 20132013-01-28
Hi all,
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).
High Regards,
John.
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).
High Regards,
John.
Reply by ●January 28, 20132013-01-28
That is just the point. If you understand them interrupts are not
complex, they are the simple way to do things, why else do you think
desiners and manufacturers of micros have spent so much effort
developing this function?
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
level, thus, in the posters IIC example, there are multiple points at
which the program will need to poll, whereas an interrupt system can be
simply designed with a single exit mechanism covering all poll points,
and will thus always be simpler and more robust to use interrupts.
Elegance doesn't come into it. It is about designing robust reliable
code. Every time you write something like:_
You are inviting the test to fail and the program to hang forever. OK
you can use a watchdog to get out of the loop, but that's compensating
for bad design by using a sledge hammer to crack a walnut. This is
especially the case when the condition being looped on depends upon an
external device, like an IIC part, and an even bigger risk when the
condition depends on an external system. There may be a little extra
thought required to implement more complicated functions using
interrupts, but that is part of the skill every programmer should have.
Al
complex, they are the simple way to do things, why else do you think
desiners and manufacturers of micros have spent so much effort
developing this function?
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
level, thus, in the posters IIC example, there are multiple points at
which the program will need to poll, whereas an interrupt system can be
simply designed with a single exit mechanism covering all poll points,
and will thus always be simpler and more robust to use interrupts.
Elegance doesn't come into it. It is about designing robust reliable
code. Every time you write something like:_
You are inviting the test to fail and the program to hang forever. OK
you can use a watchdog to get out of the loop, but that's compensating
for bad design by using a sledge hammer to crack a walnut. This is
especially the case when the condition being looped on depends upon an
external device, like an IIC part, and an even bigger risk when the
condition depends on an external system. There may be a little extra
thought required to implement more complicated functions using
interrupts, but that is part of the skill every programmer should have.
Al
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.
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.
Al
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.
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.
Al
