David Brown wrote: > On 02/10/2010 15:43, Bob Paddock wrote: > > On Sat, Oct 2, 2010 at 8:24 AM, Simone Zamboni<simo.zamb...@alice.it> > > wrote: > > > >> By the way, a note for me: Bob, how much time does the XMEGA take to > >> verify all the code (roughly)? Reading all the flash data seems to take > >> a few seconds. > > > > I will have to measure the time. I'd guess a little less than two > > seconds with my current code, at 8 MHz. > > I only run the CRC when the PORF bit (Power Applied) is set, rather > > than at all resets. > > I have to meet some regulations that require the system to be "fully > > operational in under one second". > > > > In the XMega you could switch to the 32 MHz Osc. to run the start up > > code, I don't for power reasons. > > > > I can't comment on this case in particular (having not used an XMega > yet), but from a power-consumption viewpoint there will be little > difference between running for 2 seconds at 8 MHz, or running for 0.5 > seconds at 32 MHz and sleeping for 1.5 seconds - most often, running > faster for shorter times and sleeping longer will give you lower total > power consumption. >
Yes, this is right but there are a couple of situations where you couldn't switch to full speed: - If you have a battery powered application that uses 2 NiMH cells you have to operate at about 2.4V and perhaps lower so you can't push the microcontroller to 32MHz because you need at least 2.7V to do so. In this case it is safe to run at 12MHz maximum. - And what about a solar cell powered application? In extreme situations you have to face the limited current the cells can supply and draining the current needed to run the uC at 32MHz (that is about 4 times the current used at 8MHz at the same supply voltage, accordingly to datasheet) would drop the voltage under the safe operating value thus resetting the device or to make it worse, lead to undefined behavior. I think that Bob, while talking about "power reason" would not mean overall power consumption but maximum power that the uC should drain. _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
