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.
I did write nanowatt - not microwatt.
Look at this link: ww1.microchip.com/.../39941d.pdf
The company I am working for, uses a lot of Microchip PICs. I am currently working with TI's MSP430.
After reading Per's reply in this thread, I did some comparison among Cortex-M0+, MSP430, and XLP PIC several months ago. And I found that XLP PIC does provide the lowest power consumption.
I am trying to contact our PIC MCU distributor for XLP PIC EV-board at the moment, but ten minutes earlier, I found the below TI pdf. Due to my lack of fundamental knowledge, especially the hardware knowledge, I am not able to understand this kind of stuff.
www.ti.com/.../slay015.pdf Microchip’s application report and video compares the PIC24F XLP specifically to the MSP430. The fundamental claim is that the PIC24F XLP is lower power compared to the MSP430F2xx – this is also demonstrated in a video using a special Microchip measurement board. What is misleading and causes error are the unrealistic use-case conditions. For example, testing at 1.8V is unusual with few real-world sources – perhaps two discharged alkaline batteries? Most ultra-low power systems are powered directly from a 3V lithium coin-cell battery for low cost and a long run time because of its very low leakage. Another common battery solution is two fully charged alkaline batteries at 3.3V. The benchmark needs to be shifted closer to a real-world 3V supply. In the report and in the video, modes of operation are shown that disable BOR protection and remove power to RAM – these techniques will reduce power but are both a dangerous and an inconvenient practice. The importance of brown out is clear for any application in which batteries could be replaced or power could be disrupted for any reason. In the example where RAM is de-powered and the content lost, this lost data would likely be stored temporarily into on-chip Flash. With the PIC24F XLP, this would be a Flash program operation that needs 10mA for 2ms for each 96-Byte block – this adds significant power consumption that is never mentioned.
However, power consumption is not a problem for a C programmer like me. I am fine with MSP430 or Cortex-M0+. The mentioned TI pdf is written in 2009, maybe it is quite old. My intention to reply this thread, is just for curious and information sharing.
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!!