ZBasic Forum

Is there a published basic power requirement (assuming external regulation) for the V+ supply?

Also, a power spec for the on-board LEDs (how many ma do they draw?)

Also, has there been any thought given to a way through the ZBASIC code to add a function to stick the processor into "sleep" mode (thus radically reducing power drain) for a given period of time?

I know the latter is something I asked about before... just wondering if there's been any further thought on this. I've got another application potentially for the ZX and the only thing I need for user display is actually the onboard LEDs!

However, to make this work, I need very, very low average power consumption so that battery life will be reasonable.

Thoughts?

Genesis wrote:Is there a published basic power requirement (assuming external regulation) for the V+ supply?

The current has been measured in the 30-35mA range (into pin 21) while doing nothing (i.e. not driving external devices).

Genesis wrote:Also, a power spec for the on-board LEDs (how many ma do they draw?)

You can figure on 10-12mA for each LED but slightly less than that when both are on at the same time since they share a limiting resistor.

Genesis wrote:Also, has there been any thought given to a way through the ZBASIC code to add a function to stick the processor into "sleep" mode (thus radically reducing power drain) for a given period of time?

The CPUSleep() subroutine will do what you need. The actual level of power reduction is configurable by setting bits in Register.MCUCR before making the call. The mode that you choose depends on how much power reduction you want and how you want it to wake up from the sleep period. Discussion of the various sleep modes begins on page 30 of the Atmel datasheet for the ATmega32.

Also, you may want to consider running the ZX-24 at a lower voltage since power consumption is proportional to the square of the voltage. The speed/voltage curve published by Atmel indicates that the mega32 can run at about 3.5V at 14.7456MHz and still be within specification. However, I have run it successfully for extended periods at 3.3V and I know that others have as well. The brownout detector will reset the processor at 2.7V.

It appears that calling CpuSleep() with anything other than "Idle" set requires an external interrupt source to be connected to the chip, if I am understanding the basic setup of the VM correctly. Am I correct in this assumption?

I have discovered the 3.3v capability "by accident" in that my other application will happily continue to run even though the voltage is under the +5V dropout range and the LCD display that its connected to has gone dark! That confused me the first time it happened - it turns out to be actually quite useful... and in this case, I may exploit it to get a better power usage profile as well.

Thanks.

If I can get the average power consumption (at, for example, a 10% duty cycle) down in the 5ma range I'll be a very happy camper; I've got a 4-5ma requirement for the other components in the system, leading to a total in the 10ma range. That's very much functional for what I'm trying to do. Will do some breadboarding and see what I get....

Genesis wrote:It appears that calling CpuSleep() with anything other than "Idle" set requires an external interrupt source to be connected to the chip, [...]

It is true that some means of waking up the processor is required. An external interrupt will suffice but the WatchDog timer may be useful for this purpose also. See OpenWatchDog().

Can I not use Timer2 (which IS available in "Idle" state)? Or does the VM's use preempt that?

Genesis wrote:Can I not use Timer2 (which IS available in "Idle" state)? Or does the VM's use preempt that?

Timer2 is only used when one of the "software UART" serial channels is open (Com3-Com6). Otherwise, Timer2 is available. If the device can be awakened simply on timer overflow (as opposed to a timer interrupt) that may serve your purpose.

The V2.0 compiler and VM added support for Register.Timer2Busy, a semaphore that indicates the Timer2 is in use.

Ok.... I'm good then; as things sit right now the existing product DOES use a software COM port, but this application has no need for one (no display - just LEDs for status).

According to the ATML docs timer underflow is sufficient to wake up the processor from an IDLE state. That sounds like it will do what I need without an external "heartbeat" generator.