We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Dear All Expert,
I am thinking of programming a PIC MCU for my application as it uses 3V supply which can be power up with 2xAAA batteries. I am using Keil C uVision4 and therefore would like to know any user of PIC had already written the assoicated SFR in a <PIC.h> file. Is it possible to provide me with this file as I am totally new to PIC. Should you have a simple interrupt enabled routine and go_to_sleep routine, it will be great if you can share.
My application need to be low power during sleep and will only wake up through external interrupt. I need 4 external interrupts and a RS232 serial communication for my PIC and DIL package is preferred. Anyone had any recommendation on the model number to use?
Thanks a lot for all your advise. Have a good day ahead.
The point of the TI article is that the power consumption achieved in practice in a real application is very much dependant upon the nature of the application.
It might even be fair to say that the choice of microcontroller has (far) less to do with it than the nature of the application itself.
In other words, simply choosing a so-called "low-power" microcontroller will not, of itself give you a low-power application.
Having said that, it is true that different chips adopt different "low-power" techniques - so you do have to be careful to choose a chip with the right "low-power" modes to suit your particular application!
"power consumption is not a problem for a C programmer"
Yes, it very much is a problem for the programmer - whatever language they use!
As noted above, the choice of microcontroller is only one (small) part of achieving a low-power system - the software (whatever language it's written in) has to be very carefully written to take maximum advantage from the chip's "low-power" features!
The other point is that you can't just take some arbitrary power consumption figure from one data sheet, and compare it to some other arbitrary power consumption figure from another data sheet.
You have to be very careful that you are comparing like with like - and that the figures are relevant to your particular application.
you can take a mathematical process and 'prove' that a another processor is faster than the '51. you can take a binary process and 'prove' that a '51 is faster than another processor.
EVERYTHNG is app dependent, embedded is not pantyhose.
Erik
Hi Andy,
Many thanks for your explanation.
I had not well realized the importance of programmer for low power products.
Since Low Power Consumption can not be accomplished by simply choosing a so-called "low-power" microcontroller. I would give up and ignore this kind of issues.
The industry convention is that the battery should be capable for more than one year usage without replacement. But our products can only last for three months. No one thinks that is a serious problem, which needs to be solved. Neither do I now.
It is funny that some FAE from one of our distributors insisted and tried to convince me that, you can use the internal flash of MSP430 for frequent counter value saving. (100 times per day, 20 years.) Not to mention the Erase/Write cycles, and the Power Consumption, the MSP430 would freeze for 23ms while doing the Flash Erase/Write, but he sees no problem.
Thats probably why he is an FAE and not a programmer/developer :)
It's just a question of time scale for the application.
23 ms lockup while erasing the flash doesn't matter for a device that controls equipment in 1-second timing resolution. And since many embedded designs can sleep the processor for 99% or more, it can matter a lot to go all the way down to the deepest power mode, potentially turning off the core and RAM power and not just stopping the clocks.
This MSP430 device is in charge to decode Low-Frequency signal. The FAE knows this. 23 ms lockup could be considered as 23 bits loss.
since many embedded designs can sleep the processor for 99% or more, it can matter a lot to go all the way down to the deepest power mode, potentially turning off the core and RAM power and not just stopping the clocks.
Per, thanks for your explanation.
I would do something for my MSP430 project to (try to) reduce power consumption; and would ignore issues that I can not handle. For those traditional PIC products, I would stay away from them.
Got an email from management to most software engineers, saying that every software engineer should do a good job, otherwise the company may sue you for professional negligence.
This is really encouraging.
I think I should concentrate on the major functionalities, and ignore all the minor issues like power consumption.
Why do I suddenly think about Dilbert?
WTF?!?!!?!?!? Are you serious?
=> Are you serious?
Yes.
-----
Use Google translator to do a direct translation:
You should have seen the company has already begun on the Software Bug loss requirements, I hope (YOU ALL) not in the punishment of the list. Each software must be reviewed and approved, Do not issue or a problem, the company may pursue professional negligence, please bear in mind.
NOW!!