That's not the only problem I have with using a large cap. I also desire to limit the inrush current when the battery is connected, so as to have a nice, smooth, quick rise to Vdd (3.3V, in this case). This design is supposed to sit quietly for many, many weeks on end, with periodic wake-ups to jot down a little info before going back to sleep. It seems to me that putting a giant cap in there just to cover the situation where a user is actually handling it just isn't the best way to go. I may just let the data stored in the buffer go away, and the user can blame himself for being foolish enough to yank the battery before downloading the data. ;-) Seriously, though, the switchable button cell idea would provide a fairly strong safety net, even for the case in which the primary battery just fails. Does anyone have any input on that? Mike H. >Ah, but here is the rub: What do you do about voltage management with >these super-caps? > >Not a trivial question. I have tested products designed elsewhere that >had serious brownout problems with these super-caps. The cap will slowly >bleed down to a point where the processor will not work correctly, the >processor hangs or starts impersonating Napoleon, and the super-cap never >bleeds off enough to actually reset the processor. It can literally be >days before the processor resets. Meanwhile the LCD display is covered >with chicken tracks. > >This was, of course, not in a PIC, and not with the handy brownout >protection feature included in most modern PICs, and also not designed by >any reputable PIClister (or me either). > >I would expect that watchdog and brownout protection would be a minimum >requirement, but I still worry about partial reset when there is 3-4 volts >on the PIC between power-ups. > >Anyone who has experienced partial reset in a PIC will now believe in >ghosts, fairly tales, and goblins because those are the creatures that >inhabit the PIC's brain after a partial reset instead of carefully crafted >ASM code. It certainly does not act in a deterministic manner nor obeys >it's software whatsoever. Quite dangerous if the PIC is hooked up to, say, >a motor spinning sharp blades or a high temperature heating element. > >Have other people had power management issues with super-caps and PICs? > >-- Lawrence Lile > > > > > >Jake Anderson >Sent by: pic microcontroller discussion list >02/08/2004 10:02 PM >Please respond to pic microcontroller discussion list > > > To: PICLIST@MITVMA.MIT.EDU > cc: > Subject: Re: [EE:] Post battery pull runtime > > >put the cap on the battery side >then set a battery monitoring thingie up on an interupt pin, or poll it. >hows that work out for you? > > > -----Original Message----- > > From: pic microcontroller discussion list > > [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of James Nick Sears > > Sent: Monday, 9 February 2004 8:59 AM > > To: PICLIST@MITVMA.MIT.EDU > > Subject: Re: [EE:] Post battery pull runtime > > > > > > Check out the Digikey catalog pages 728-729: > > http://dkc3.digikey.com/PDF/T041/0728.pdf > > http://dkc3.digikey.com/PDF/T041/0729.pdf > > > > Nick > > > > ways. See http://www.piclist.com/#archives for details. > >-- >http://www.piclist.com hint: The PICList is archived three different >ways. See http://www.piclist.com/#archives for details. > > > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >email listserv@mitvma.mit.edu with SET PICList DIGEST in the body _________________________________________________________________ Get some great ideas here for your sweetheart on Valentine's Day - and beyond. http://special.msn.com/network/celebrateromance.armx -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body