HP Forums

Full Version: Future I/O capabilities in WP-34S v3.x
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

IIRC, there are printed circuit pads connected to analog input pins of the Atmel processor in the 20B/30B. Granted, such pads are not easy to reach, but it may be interesting to consider a couple of extra functions for future development (perhaps as a separate evolutive branch, because not all users will be interested). I guess some of the code is already there, supporting the BATT function. Perhaps we just need a function to select the active analog input channel, and another function to read the A/D value.

Given that internal wiring of the serial port, or installing a crystal are seen as "acceptable surgery", enabling analog input may also be.

Of course, users of such inputs should be warned about electrostatic discharge risks and also about acceptable signal levels. Eventually, some resistors and zener diodes may be added for some protection.

Just my 0.02 mV DC

Please be aware the capacity and will of the design team to support "separate evolutive branches" is very limited.

If we support more hardware we need to drop some other functionality so it will be a WP 34X instead of 34S. BTW, the voltage detection is done via the brownout detector: You program a threshold, wait some time, and check it the brownout detector has set a bit in a register. If not, try another threshold. No analog/digital converter involved here.

Thank you for the clarification... but "BATT" gives a voltage as answer, doesn't it? So you are doing A/D via brownout and timing?

Accepted, but...

:-)

Flash is full. Very very full. I can't see such a change coming from us.

If we were to add some additional hardware, it would have to be a serial RAM or flash device to increase the available memory -- ideally both.


- Pauli

Not timing, more trial and error. If the detector triggers at 2.4V but not at 2.3V I assume that the battery voltage must be between these two limits and take the lower for BATT.

Something on the line of classic BASIC commads PEEK and POKE, allowing to access arbitrary memory locations. Then, the user code may (perhaps) access I/O ports or devices via these commands.

Again, this is just an idea without any supporting, specific research.