| Author |
Message |
rholch
Joined: 23 Feb 2007
|
|
Posted: 23 February 2007, 20:21 PM Post subject: ZX-24a power down current |
|
|
I am currently prototyping a device that uses the ZX-24a. It is battery-powered and minimizes power by putting all peripherals into sleep mode and finally powering down the CPU (later waking up via a watchdog timeout). Current measurements with the CPU powered down compared to the ZX-24a out of the circuit show that the powered-down CPU consumes about 4.1mA. I am powering the circuit via 5V at pin 21. It appears to me that the current contribution of U4, R1, R2, R7 (LEDs off) and other discrete components should be negligible.
What should be the lowest current that the ZX-24a can go to? -- it appears that the AT25256A chip select is left low between accesses and so never goes into standby mode. Its data sheet shows a non-sleep current of up to 7mA -- is this the culprit? |
|
| Back to top |
|
 |
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 24 February 2007, 5:34 AM Post subject: Re: ZX-24a power down current |
|
|
| rholch wrote: | | [I]t appears that the AT25256A chip select is left low between accesses and so never goes into standby mode. Its data sheet shows a non-sleep current of up to 7mA -- is this the culprit? |
It sounds that may be a problem. It may be fairly easy to deselect the EEPROM before going into sleep mode (via CPUSleep()). I'm away visiting relatives this weekend so it will probably be early next week before I can look into this. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 26 February 2007, 4:35 AM Post subject: |
|
|
Modifying the VM to deassert the EEPROM chip select just before entering sleep mode yielded a 2.8mA reduction of current draw. Of course, the reduction with other actual EEPROMs may be more or less.
If you'd like to try the experimental version of the ZX-24a VM with this change, I can make it available. |
|
| Back to top |
|
|
rholch
Joined: 23 Feb 2007
|
|
Posted: 26 February 2007, 16:10 PM Post subject: |
|
|
Thank you very much for getting right on this.
I would like to try the revised VM.
On a related note, I have some data values that must be retained through the power down and watchdog timeout reboot. They change too often to use the persistent memory feature. What would be great would be a PersistentRAM type that would indicate user RAM locations that will not be cleared upon a non-powerdown reset situation.
In this vein, and correct me if I'm wrong, but it would seem to be an easier way to use such RAM (as well as, perhaps, a PersistentEEPROM type) that would read/write data to such areas automatically without the need for subroutine calls such as Get/PutPersistent. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 26 February 2007, 16:54 PM Post subject: |
|
|
| rholch wrote: | | I would like to try the revised VM. |
The new VM for the ZX-24a is at http://www.zbasic.net/download/zvm/2.1/zx24a_2-1-1.zvm. The only difference is that the EEPROM is deselected before going into sleep mode.
| rholch wrote: | | [It]would seem to be an easier way to use such RAM (as well as, perhaps, a PersistentEEPROM type) that would read/write data to such areas automatically without the need for subroutine calls such as Get/PutPersistent. |
What you describe can be easily done using a based variable. For example, say you want to have an UnsignedInteger RAM-based variable at address &H0c00.
| Code: | | Dim myVar as UnsignedInteger Based &H0c00 |
With this definition, you can use 'myVar' in the same was as any other variable. The same can be done for Persistent and Program Memory by using the keywords Persistent and ProgMem between the 'as' and the type name.
For RAM-based variables, the more difficult problem lies in determining a suitable address to use. The compile-time constant Register.RamUsed indicates the size of the statically allocated variables that are allocated beginning at Register.RamStart. The remainder of RAM is used for the task stack for Main() and the heap. The task stack for Main() grows upward toward higher addresses while the heap grows downward toward lower addresses. In most cases, there is some RAM in between the two that is never used. Stevech has used this idea to preserve data across resets: http://www.zbasic.net/forum/post-2474.html |
|
| Back to top |
|
|
stevech
Joined: 23 Feb 2006
|
|
Posted: 01 March 2007, 1:09 AM Post subject: |
|
|
I use this to keep the date/time across resets.
Lose a little time, but for many cases, it's close enough!
I posted that code. |
|
| Back to top |
|
|
Genesis
Joined: 15 Jan 2006
|
|
Posted: 13 May 2007, 19:39 PM Post subject: |
|
|
| Rh, could you post the code snippet you use to go to sleep and then wake up? I've been playing with this for some time without material success..... |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 20 May 2007, 3:42 AM Post subject: |
|
|
| Genesis wrote: | | I've been playing with this for some time without material success..... |
After going into sleep mode, a stimulus of some kind is needed to awaken the processor. It could be a watchdog reset, a level or edge input, Timer 2, etc. Depending on which wakeup stimulus you are going to use, you have to set the sleep mode and then call CPUSleep(). There is additional information, including sample code showing how to use Timer2 to wake up, at http://www.zbasic.net/forum/about691.html. |
|
| Back to top |
|
|
|
