From: Chris M. <ch...@fo...> - 2010-12-23 20:24:09
|
Hi All, I've got an Overo Water on a Tobi expansion board and I'm attempting to use a battery to keep the RTC going in the event the device is powered down. I've been reading through manuals and I've established that the BB_CFG register must be changed to allow for charging of the backup battery, and BOOT_CFG can be changed to save some power by putting a 32kHz clock in low power mode (this is all from http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf). I'm running in to problems actually writing values using I2C. I'm using i2cget/i2cset from the command line to read and write registers, and as a test, I can run root@overo:~# i2cget -y -f 1 0x4a 0xee 0x33 root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00 root@overo:~# i2cget -y -f 1 0x4a 0xee 0x00 root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33 root@overo:~# i2cget -y -f 1 0x4a 0xee 0x33 and all appears well; the power LED turns off and back on as expected. However, when I attempt to change the values of BB_CFG, as far as I can tell, nothing happens root@overo:~# i2cget -y -f 1 0x4a 0x6d 0x00 root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14 root@overo:~# i2cget -y -f 1 0x4a 0x6d 0x00 and this should enable charging at 25uA, stopping at 3.1V; I'm not sure if it's supposed to return 0x00 or not (I'm assuming not though). The same is true when I try to set BOOT_CFG (always returns 0x00). In the reference manual for the TPS65950 both registers are said to be write-protected using KEY_CFG, and as far as I can understand from the TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and reading from PROTECT_KEY will return values indicating whether writing to protected registers is enabled. I've tried this and PROTECT_KEY always returns 0x00. It seems to me that I'm doing something wrong here, but I don't know what. Does anyone see a problem with this approach? Has anyone done this before, who might be able to shed some light on either what I'm doing wrong, or what they've done to enable this functionality? Thanks in advance, Chris |
From: Steve S. <sa...@gm...> - 2010-12-23 21:53:17
|
On Thu, Dec 23, 2010 at 11:59 AM, Chris MacDonald <ch...@fo...> wrote: > Hi All, > > I've got an Overo Water on a Tobi expansion board and I'm attempting > to use a battery to keep the RTC going in the event the device is > powered down. I've already configured the Overo kernel to enable battery charging @ 3.1V 25uA: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=a6484075fcf9e406a84a7903c65b30784fcbeda8 So you shouldn't need to do anything. Steve > I've been reading through manuals and I've established > that the BB_CFG register must be changed to allow for charging of the > backup battery, and BOOT_CFG can be changed to save some power by > putting a 32kHz clock in low power mode (this is all from > http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf). > > I'm running in to problems actually writing values using I2C. I'm > using i2cget/i2cset from the command line to read and write registers, > and as a test, I can run > > root@overo:~# i2cget -y -f 1 0x4a 0xee > 0x33 > root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00 > root@overo:~# i2cget -y -f 1 0x4a 0xee > 0x00 > root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33 > root@overo:~# i2cget -y -f 1 0x4a 0xee > 0x33 > > and all appears well; the power LED turns off and back on as expected. > However, when I attempt to change the values of BB_CFG, as far as I > can tell, nothing happens > > root@overo:~# i2cget -y -f 1 0x4a 0x6d > 0x00 > root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14 > root@overo:~# i2cget -y -f 1 0x4a 0x6d > 0x00 > > and this should enable charging at 25uA, stopping at 3.1V; I'm not > sure if it's supposed to return 0x00 or not (I'm assuming not though). > The same is true when I try to set BOOT_CFG (always returns 0x00). In > the reference manual for the TPS65950 both registers are said to be > write-protected using KEY_CFG, and as far as I can understand from the > TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and > reading from PROTECT_KEY will return values indicating whether writing > to protected registers is enabled. I've tried this and PROTECT_KEY > always returns 0x00. > > It seems to me that I'm doing something wrong here, but I don't know > what. Does anyone see a problem with this approach? Has anyone done > this before, who might be able to shed some light on either what I'm > doing wrong, or what they've done to enable this functionality? > > Thanks in advance, > Chris > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Chris M. <ch...@fo...> - 2010-12-23 22:11:50
|
On Thu, Dec 23, 2010 at 1:53 PM, Steve Sakoman <sa...@gm...> wrote: > On Thu, Dec 23, 2010 at 11:59 AM, Chris MacDonald > <ch...@fo...> wrote: >> Hi All, >> >> I've got an Overo Water on a Tobi expansion board and I'm attempting >> to use a battery to keep the RTC going in the event the device is >> powered down. > > I've already configured the Overo kernel to enable battery charging @ 3.1V 25uA: > > http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=a6484075fcf9e406a84a7903c65b30784fcbeda8 > > So you shouldn't need to do anything. > > Steve > Haha awesome, thanks Steve! I was wondering about that, as I sent the email I was checking pads with a multimeter and was slightly confused as to why it was already measuring ~3.1V, and regardless of what I sent via I2C. I suppose this explains it! Thanks again, Chris >> I've been reading through manuals and I've established >> that the BB_CFG register must be changed to allow for charging of the >> backup battery, and BOOT_CFG can be changed to save some power by >> putting a 32kHz clock in low power mode (this is all from >> http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf). >> >> I'm running in to problems actually writing values using I2C. I'm >> using i2cget/i2cset from the command line to read and write registers, >> and as a test, I can run >> >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> 0x33 >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00 >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> 0x00 >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33 >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> 0x33 >> >> and all appears well; the power LED turns off and back on as expected. >> However, when I attempt to change the values of BB_CFG, as far as I >> can tell, nothing happens >> >> root@overo:~# i2cget -y -f 1 0x4a 0x6d >> 0x00 >> root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14 >> root@overo:~# i2cget -y -f 1 0x4a 0x6d >> 0x00 >> >> and this should enable charging at 25uA, stopping at 3.1V; I'm not >> sure if it's supposed to return 0x00 or not (I'm assuming not though). >> The same is true when I try to set BOOT_CFG (always returns 0x00). In >> the reference manual for the TPS65950 both registers are said to be >> write-protected using KEY_CFG, and as far as I can understand from the >> TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and >> reading from PROTECT_KEY will return values indicating whether writing >> to protected registers is enabled. I've tried this and PROTECT_KEY >> always returns 0x00. >> >> It seems to me that I'm doing something wrong here, but I don't know >> what. Does anyone see a problem with this approach? Has anyone done >> this before, who might be able to shed some light on either what I'm >> doing wrong, or what they've done to enable this functionality? >> >> Thanks in advance, >> Chris >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Bob C. <bco...@ve...> - 2010-12-24 03:09:17
|
Chris, What size and type of battery are you using? Thanks Bob Cochran On 12/23/2010 02:59 PM, Chris MacDonald wrote: > Hi All, > > I've got an Overo Water on a Tobi expansion board and I'm attempting > to use a battery to keep the RTC going in the event the device is > powered down. I've been reading through manuals and I've established > that the BB_CFG register must be changed to allow for charging of the > backup battery, and BOOT_CFG can be changed to save some power by > putting a 32kHz clock in low power mode (this is all from > http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf). > > I'm running in to problems actually writing values using I2C. I'm > using i2cget/i2cset from the command line to read and write registers, > and as a test, I can run > > root@overo:~# i2cget -y -f 1 0x4a 0xee > 0x33 > root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00 > root@overo:~# i2cget -y -f 1 0x4a 0xee > 0x00 > root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33 > root@overo:~# i2cget -y -f 1 0x4a 0xee > 0x33 > > and all appears well; the power LED turns off and back on as expected. > However, when I attempt to change the values of BB_CFG, as far as I > can tell, nothing happens > > root@overo:~# i2cget -y -f 1 0x4a 0x6d > 0x00 > root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14 > root@overo:~# i2cget -y -f 1 0x4a 0x6d > 0x00 > > and this should enable charging at 25uA, stopping at 3.1V; I'm not > sure if it's supposed to return 0x00 or not (I'm assuming not though). > The same is true when I try to set BOOT_CFG (always returns 0x00). In > the reference manual for the TPS65950 both registers are said to be > write-protected using KEY_CFG, and as far as I can understand from the > TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and > reading from PROTECT_KEY will return values indicating whether writing > to protected registers is enabled. I've tried this and PROTECT_KEY > always returns 0x00. > > It seems to me that I'm doing something wrong here, but I don't know > what. Does anyone see a problem with this approach? Has anyone done > this before, who might be able to shed some light on either what I'm > doing wrong, or what they've done to enable this functionality? > > Thanks in advance, > Chris > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Chris M. <ch...@fo...> - 2010-12-24 06:56:10
|
On Thu, Dec 23, 2010 at 7:09 PM, Bob Cochran <bco...@ve...> wrote: > Chris, > > What size and type of battery are you using? > > Thanks > > Bob Cochran > Hi Bob, http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=728-1057-ND It's the closest I've been able find that matches the 3.1V/25uA characteristics of the charger... it's nominal charge current is only 15uA (the max discharge is 25uA, so I might have to sort something out there. Chris > > On 12/23/2010 02:59 PM, Chris MacDonald wrote: >> Hi All, >> >> I've got an Overo Water on a Tobi expansion board and I'm attempting >> to use a battery to keep the RTC going in the event the device is >> powered down. I've been reading through manuals and I've established >> that the BB_CFG register must be changed to allow for charging of the >> backup battery, and BOOT_CFG can be changed to save some power by >> putting a 32kHz clock in low power mode (this is all from >> http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf). >> >> I'm running in to problems actually writing values using I2C. I'm >> using i2cget/i2cset from the command line to read and write registers, >> and as a test, I can run >> >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> 0x33 >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00 >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> 0x00 >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33 >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> 0x33 >> >> and all appears well; the power LED turns off and back on as expected. >> However, when I attempt to change the values of BB_CFG, as far as I >> can tell, nothing happens >> >> root@overo:~# i2cget -y -f 1 0x4a 0x6d >> 0x00 >> root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14 >> root@overo:~# i2cget -y -f 1 0x4a 0x6d >> 0x00 >> >> and this should enable charging at 25uA, stopping at 3.1V; I'm not >> sure if it's supposed to return 0x00 or not (I'm assuming not though). >> The same is true when I try to set BOOT_CFG (always returns 0x00). In >> the reference manual for the TPS65950 both registers are said to be >> write-protected using KEY_CFG, and as far as I can understand from the >> TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and >> reading from PROTECT_KEY will return values indicating whether writing >> to protected registers is enabled. I've tried this and PROTECT_KEY >> always returns 0x00. >> >> It seems to me that I'm doing something wrong here, but I don't know >> what. Does anyone see a problem with this approach? Has anyone done >> this before, who might be able to shed some light on either what I'm >> doing wrong, or what they've done to enable this functionality? >> >> Thanks in advance, >> Chris >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Robert V. IV <ro...@io...> - 2010-12-24 07:35:04
|
Hi Chris, I've used the 621 battery before, as well as it's smaller cousin, and I have to say I have not been impressed by it's retention time with a 'real' RTC (DS1307); I'd be curious to hear your results with the Overo. Robert Vogt IV CEO IOSiX, LLC 2375 Parkwood Ave Ypsilanti, MI 48198 ro...@io... P: 734-730-9690 F: 734-482-2337 On Fri, Dec 24, 2010 at 1:56 AM, Chris MacDonald <ch...@fo...>wrote: > On Thu, Dec 23, 2010 at 7:09 PM, Bob Cochran <bco...@ve...> > wrote: > > Chris, > > > > What size and type of battery are you using? > > > > Thanks > > > > Bob Cochran > > > > Hi Bob, > > > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=728-1057-ND > > It's the closest I've been able find that matches the 3.1V/25uA > characteristics of the charger... it's nominal charge current is only > 15uA (the max discharge is 25uA, so I might have to sort something out > there. > > Chris > > > > > On 12/23/2010 02:59 PM, Chris MacDonald wrote: > >> Hi All, > >> > >> I've got an Overo Water on a Tobi expansion board and I'm attempting > >> to use a battery to keep the RTC going in the event the device is > >> powered down. I've been reading through manuals and I've established > >> that the BB_CFG register must be changed to allow for charging of the > >> backup battery, and BOOT_CFG can be changed to save some power by > >> putting a 32kHz clock in low power mode (this is all from > >> > http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf > ). > >> > >> I'm running in to problems actually writing values using I2C. I'm > >> using i2cget/i2cset from the command line to read and write registers, > >> and as a test, I can run > >> > >> root@overo:~# i2cget -y -f 1 0x4a 0xee > >> 0x33 > >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00 > >> root@overo:~# i2cget -y -f 1 0x4a 0xee > >> 0x00 > >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33 > >> root@overo:~# i2cget -y -f 1 0x4a 0xee > >> 0x33 > >> > >> and all appears well; the power LED turns off and back on as expected. > >> However, when I attempt to change the values of BB_CFG, as far as I > >> can tell, nothing happens > >> > >> root@overo:~# i2cget -y -f 1 0x4a 0x6d > >> 0x00 > >> root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14 > >> root@overo:~# i2cget -y -f 1 0x4a 0x6d > >> 0x00 > >> > >> and this should enable charging at 25uA, stopping at 3.1V; I'm not > >> sure if it's supposed to return 0x00 or not (I'm assuming not though). > >> The same is true when I try to set BOOT_CFG (always returns 0x00). In > >> the reference manual for the TPS65950 both registers are said to be > >> write-protected using KEY_CFG, and as far as I can understand from the > >> TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and > >> reading from PROTECT_KEY will return values indicating whether writing > >> to protected registers is enabled. I've tried this and PROTECT_KEY > >> always returns 0x00. > >> > >> It seems to me that I'm doing something wrong here, but I don't know > >> what. Does anyone see a problem with this approach? Has anyone done > >> this before, who might be able to shed some light on either what I'm > >> doing wrong, or what they've done to enable this functionality? > >> > >> Thanks in advance, > >> Chris > >> > >> > ------------------------------------------------------------------------------ > >> Learn how Oracle Real Application Clusters (RAC) One Node allows > customers > >> to consolidate database storage, standardize their database environment, > and, > >> should the need arise, upgrade to a full multi-node Oracle RAC database > >> without downtime or disruption > >> http://p.sf.net/sfu/oracle-sfdevnl > >> _______________________________________________ > >> gumstix-users mailing list > >> gum...@li... > >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > >> > > > > > ------------------------------------------------------------------------------ > > Learn how Oracle Real Application Clusters (RAC) One Node allows > customers > > to consolidate database storage, standardize their database environment, > and, > > should the need arise, upgrade to a full multi-node Oracle RAC database > > without downtime or disruption > > http://p.sf.net/sfu/oracle-sfdevnl > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Chris M. <ch...@fo...> - 2010-12-24 19:16:45
|
On Thu, Dec 23, 2010 at 11:34 PM, Robert Vogt IV <ro...@io...> wrote: > Hi Chris, > I've used the 621 battery before, as well as it's smaller cousin, and I have > to say I have not been impressed by it's retention time with a 'real' RTC > (DS1307); I'd be curious to hear your results with the Overo. > Interesting; based purely off the battery specifications I'd have figured it would be alright, but I'll keep an eye on this and post back once I've run some tests. Thanks for the heads-up! Chris > Robert Vogt IV > CEO > IOSiX, LLC > 2375 Parkwood Ave > Ypsilanti, MI 48198 > ro...@io... > P: 734-730-9690 > F: 734-482-2337 > > > On Fri, Dec 24, 2010 at 1:56 AM, Chris MacDonald <ch...@fo...> > wrote: >> >> On Thu, Dec 23, 2010 at 7:09 PM, Bob Cochran <bco...@ve...> >> wrote: >> > Chris, >> > >> > What size and type of battery are you using? >> > >> > Thanks >> > >> > Bob Cochran >> > >> >> Hi Bob, >> >> >> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=728-1057-ND >> >> It's the closest I've been able find that matches the 3.1V/25uA >> characteristics of the charger... it's nominal charge current is only >> 15uA (the max discharge is 25uA, so I might have to sort something out >> there. >> >> Chris >> >> > >> > On 12/23/2010 02:59 PM, Chris MacDonald wrote: >> >> Hi All, >> >> >> >> I've got an Overo Water on a Tobi expansion board and I'm attempting >> >> to use a battery to keep the RTC going in the event the device is >> >> powered down. I've been reading through manuals and I've established >> >> that the BB_CFG register must be changed to allow for charging of the >> >> backup battery, and BOOT_CFG can be changed to save some power by >> >> putting a 32kHz clock in low power mode (this is all from >> >> >> >> http://focus.ti.com.cn/cn/general/docs/lit/getliterature.tsp?literatureNumber=swca025&fileType=pdf). >> >> >> >> I'm running in to problems actually writing values using I2C. I'm >> >> using i2cget/i2cset from the command line to read and write registers, >> >> and as a test, I can run >> >> >> >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> >> 0x33 >> >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x00 >> >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> >> 0x00 >> >> root@overo:~# i2cset -y -f 1 0x4a 0xee 0x33 >> >> root@overo:~# i2cget -y -f 1 0x4a 0xee >> >> 0x33 >> >> >> >> and all appears well; the power LED turns off and back on as expected. >> >> However, when I attempt to change the values of BB_CFG, as far as I >> >> can tell, nothing happens >> >> >> >> root@overo:~# i2cget -y -f 1 0x4a 0x6d >> >> 0x00 >> >> root@overo:~# i2cset -y -f 1 0x4a 0x6d 0x14 >> >> root@overo:~# i2cget -y -f 1 0x4a 0x6d >> >> 0x00 >> >> >> >> and this should enable charging at 25uA, stopping at 3.1V; I'm not >> >> sure if it's supposed to return 0x00 or not (I'm assuming not though). >> >> The same is true when I try to set BOOT_CFG (always returns 0x00). In >> >> the reference manual for the TPS65950 both registers are said to be >> >> write-protected using KEY_CFG, and as far as I can understand from the >> >> TRM to enable writing I need to send 0xc0 then 0x0c to PROTECT_KEY and >> >> reading from PROTECT_KEY will return values indicating whether writing >> >> to protected registers is enabled. I've tried this and PROTECT_KEY >> >> always returns 0x00. >> >> >> >> It seems to me that I'm doing something wrong here, but I don't know >> >> what. Does anyone see a problem with this approach? Has anyone done >> >> this before, who might be able to shed some light on either what I'm >> >> doing wrong, or what they've done to enable this functionality? >> >> >> >> Thanks in advance, >> >> Chris >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Learn how Oracle Real Application Clusters (RAC) One Node allows >> >> customers >> >> to consolidate database storage, standardize their database >> >> environment, and, >> >> should the need arise, upgrade to a full multi-node Oracle RAC database >> >> without downtime or disruption >> >> http://p.sf.net/sfu/oracle-sfdevnl >> >> _______________________________________________ >> >> gumstix-users mailing list >> >> gum...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > >> > >> > ------------------------------------------------------------------------------ >> > Learn how Oracle Real Application Clusters (RAC) One Node allows >> > customers >> > to consolidate database storage, standardize their database environment, >> > and, >> > should the need arise, upgrade to a full multi-node Oracle RAC database >> > without downtime or disruption >> > http://p.sf.net/sfu/oracle-sfdevnl >> > _______________________________________________ >> > gumstix-users mailing list >> > gum...@li... >> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > >> >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, >> and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Bob C. <bco...@ve...> - 2010-12-24 19:46:38
|
> Hi Bob, > > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=728-1057-ND > > It's the closest I've been able find that matches the 3.1V/25uA > characteristics of the charger... it's nominal charge current is only > 15uA (the max discharge is 25uA, so I might have to sort something out > there. > > Chris Hi Chris, Are you using the battery holder B1 on the expansion board? Or did you solder the battery in somewhere? Forgive me if I seem confused, I am... Bob |
From: Chris M. <ch...@fo...> - 2010-12-24 22:02:48
|
On Fri, Dec 24, 2010 at 11:46 AM, Bob Cochran <bco...@ve...> wrote: > >> Hi Bob, >> >> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=728-1057-ND >> >> It's the closest I've been able find that matches the 3.1V/25uA >> characteristics of the charger... it's nominal charge current is only >> 15uA (the max discharge is 25uA, so I might have to sort something out >> there. >> >> Chris > > Hi Chris, > > Are you using the battery holder B1 on the expansion board? Or did you > solder the battery in somewhere? Forgive me if I seem confused, I am... > > Bob > Bob, I was originally looking for something that would fit in the battery holder but I've found it's easier to source batteries with leads on them for surface mount applications. As a result I've just been putting longer leads on them and soldering them in to VBACKUP and GND on the 40-pin array on the expansion board. For the moment (testing) this seems to be doing the trick. Chris > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |