OpenRPN Hardware Specifications

I have created a set of hardware specifications that I would like to present to this community for feedback. I will be passing these specifications on to an embedded hardware designer to prepare a DIMM-sized development board which will eventually become the mainboard for both of our calculator models.

Sharp LH7A400 (ARM9TDMI)
*USB Device
16MB Flash ROM
4xAAA (2250mAh@3V)

Here are a few pages from the OpenRPN documentation site, which include more detail and links. I'm only looking for feedback on the core electronics (don't comment on LCD resolution, keyboard layouts, etc.)

General Hardware Specifications
Landscape Feature Set
Portrait Feature Set

Best Regards,


Nice choice! I like the I/O selections. Did I misread the LH7A400 docs to say it has a color LCD controller, or is that just an option? I note you are specifying greyscale LCD.

The MMU means you could run Linux or WinCE on this thing, given more RAM. 8) I assume that is "no value add" for this project.

Edited: 1 Dec 2005, 12:07 a.m.


The I/O seems to be the right mix to satisfy everyone. Indeed, the onboard LCD controller can do 15 grayshades or up to 64k color at a maximum resolution of 1024x768. Grayscale will be used extensively to simulate antialiasing characters.

Another reason for putting the mainboard on a DIMM is that virtually every feature on the CPU can be accessed from the 144 edge connections making it an excellent development kit for the LH7A400 (alternative market). While we won't be using SDRAM, color LCDs, running Linux or Windows CE, our mainboard could be adapted to use all of them. Theoretically, one could probably pull a DIY qonos with it!


Yes, that's a very cool form factor. I had read about it before, somewhere. I guess it may allow some economy in packaging, using COTS parts for stuff that might otherwise be custom?

Shifting gears to software, have you read the recent
threads that talk about the sad, neglected state of RPN calculator development? I thought they might provide ideas, when the time comes to think about system software. 8)


I don't know allot about electronics and how you can package it in a small enough area to make it work. Reading over the specs, I see that you are specifying using 4xAAA batteries. I thought the idea around this project was to make calculators that would fit in the shirt pocket. I equate shirt pocket with the use of button type batteries like the 15C or 42S used or the quarter size batteries like the 33S uses. Once you move away from these types of batteries you loose the ability to carry a calculator in the shirt pocket. Am I wrong?


Congratulations to Hugh and all OpenRPN-people. I thought the project was dead (some functions of the homepage didn't work for a long time, and there were no news).
I am now happy to see you are still working at it. Once hardware prototypes are available, the number of contributers on the software side will certainly increase!

Well done and go on!


The machines are 0.625" thick, nearly identical to a voyager. We could have used button or coin cells, but by using 4xAAA you can go for at least a year between changes. To answer your question: Both models will fit in your pocket.



So in other words, the electronics are much more compact than they were with the voyagers?

Edited: 1 Dec 2005, 12:44 p.m.





I am curious about what level of usage you are assuming when you say that the batteries will last a year. If a AAA has 900mAHr capacity, that allows you 102uA average current drain over a year.

With this device, just keeping the RTC alive will use half of that capacity.



> With this device, just keeping the RTC alive will use half of that capacity.

Maxim/Dallas' new DS3232 consumes <4uA in battery back-up mode. They claim +/-1 minute per year accuracy and tout integrated crystal, temperature sensor (to keep it accurate over the temperature range), power management, and 256 bytes of RAM, for $2.70 in 1K-pc qty. They have quite a long line-up of integrated RTC products.


I know the Maxim devices. The openRPN hardware spec doesn't say anything about an external RTC, but it touts the one internal to the LH7A400. That one draws 45uA typical. Of course, you can completely power down the device (and lose the time-keeping capability) to save the 45uA. But than you have to deal with the 2 second startup time, which I would consider unacceptable for a calculator.

The point I was trying to make was that batteries aren't going to last anywhere near a year in this thing.



I like the idea of being able to transfers to/from a computer, but don't some of the other specs such as an ARM processor, 16mb flash rom and a compact flash port seem like overkill for a scientific? I understand the importance of using the same board in a graphing model later, but I don't think that the thought of using 4 AAA batteries which last "at least a year" in a scientific will attract much interest.


There was some limited discussion on this topic once. The LH7A400 RTC isn't very well suited to functioning as a timepiece/calendar. If that is a desired feature I would opt to add a separate chip dedicated to that purpose. As a side note, the RTC only consumes 5uA.

The power consumption figure I quoted is achievable thanks to fully static operation. Only a handful of ARM9 devices feature it. In fact the S3C2410 used in the 49g+ is the only other viable choice for our application. Unfortunately it has terrible availability outside of southeast asia. Back to topic: Current draw is somewhere in the neighborhood of 0.675mA/MHz. The MCU has much more processing power than we need, but it is also highly efficient, so by throttling it back to 66MHz or so during execution gets us up to ~45mA for a few ms at a time. During entry very little clock speed is needed at all. Assuming 2 hours of use per day, with execution making up perhaps 5% of that time you can start to see how small the power consumption really is.

Another very useful feature for many of us is the ability to run off an external power supply, temporarily bypassing the batteries and further prolonging their life.

Hopefully that clears things up for you a bit more.

So is a good clock/calendar something that most people here would like to have? That's a very cheap thing to add and I have no qualms with adding one.



Sorry, I meant standby current of ~45uA.



There are enough graphing machines on the market right now that I don't even have one on my long-term to-do list. My personal hope is that Hydrix will pull off getting qonos to market. In fact, I won't even consider doing a graphing machine unless they declare qonos dead.

As far as the ARM goes, what do you have against it? It's the most reasonable way to impliment 96-bit BCD, which is what we're using. One of my personal rules in designing these machines is: If it seems like a little bit of overkill, go with it. The compactflash port will be internal. I'll be using mine strictly as a USB mass-storage device to carry around my files.

Also, the lithium AAA batteries I have selected weigh less than standard alkalines (11.5g ea) and have a shelf life of 15 years. My question is, what's the problem using AAAs?

I suspect some users will see battery life of up to 5 years.


I suspect some users will see battery life of up to 5 years.

AAA lithium cells are rated at about 1250 mAh.
Assuming that you use a pulse-skipping buck converter to produce
3.3V, and that you get 80% average efficiency, that's effectively
2045 mAh at 3.3V.

Your calculator is likely to draw at least 75 uA in standby,
which results in a battery life of 3.1 years only if you never
turn on the calculator at all.

The calculator will draw about 250 times more current when on but
idle, and about 1000 times more current when active. Assuming
that the calculator is used for 30 minutes a day, with an
actual running duty cycle of 10%, the battery life would be just
shy of three months.


Whoops, you're right on the ~3 years without being used I checked my figures and noticed I was reading off an old calculation I did for an ARM7 core. However, my calculations show that the batteries will last for a bit over a year. We'll see for sure once the first prototypes are tested.



What voltage range with the processor and other ICs handle? If they're all 3V parts, it might be better to go with a couple of AA's and forgo the switching (or any) regulator between the batteries and the circuit. The reason is that a switcher is only efficient for a comparatively narrow range of current, and the actual time the processor spends thinking (the high-current time) will be a small percentage of the total "on" time. You might need to turn the processor speed down a little to keep it working reliably down to 1.8V when the two AA cells are just about dead, but you'll still have plenty of processing power for a calc. Since most of the time would be spent at a current much too low for the switching regulator to pay for itself in terms of battery life, and you can't justify keeping the voltage at max all the time since you don't need maximum processing speed, I'd just leave the switcher out.


Our embedded HW designer has mentioned planning to use 3V throughout. The only part I know of that drops out below 3V is USB, but since the machine will be using external juice in that mode it's a non-issue. I don't even remember mentioning a switcher outside of it being mentioned during a discusion once.

I'm still inclined to use 4xAAA due to size. I can't get a AA into the current enclosure unless I increase the thickness to 3/4" or so. If lithium polymer ever becomes standardized I will be inclined to retrofit a pack in, 3-5Ah should be possible in the same space!



So is a good clock/calendar something that most people here would like to have?

In my opinion, yes, a clock and some basic calendar/appointment functions would be useful. Something along the lines of the capabilities of the 17B/BII would be adequate.

it looks sensible to me. i have a couple of ideas to add in,

have you got a rough cost estimate of the parts. also the display.

do you need rs232 as well as IrDa as well as USB? i know sometimes interfaces are already in the package, in which case it makes sense to use them. otherwise is more cost justified?

is the ROM memory mapped or do you have to copy into RAM to use it? otherwise you might need more RAM. you might consider adding some DRAM and have less SRAM. the idea being that the DRAM is lost when it sleeps, but it can be used for workspace and to hold stuff copied from ROM if that is necessary.

why compact flash and not SD? this might be a question of cost or availability again.

personally, i agree with the battery choice. it means it can run on regular batteries and also on rechargeable ones. otherwise you have to ship a charger. years ago i had an old handspring palm pilot, it worked fine on rechargeable batteries, but one charge didn’t last all that long (by then standards), and when travelling, i used regular batteries since i didn’t have to carry a charger. sadly, they are all built-in Li ones now.

on standby you should manage a very low current draw. with dry cells, you ought to have good life expectancy (due to their shelf life and low self-drain).

could it run on 3 AAA cells? if 4 fits comfortably in the package then have 4 as it means it will last longer, but i've seen a lot of home gadgets with 3 (eg cordless phones). some even have 2 now. so i guess they must have some voltage multiplier in them. i'm just wondering about the fitting with 4 and the CF and other connects?

nevertheless a good choice. i think you will actually need the 200Mhz. i know this sounds like madness when compared to calculators of old and their respective speeds, but it will make for a much nicer experience. of course, the unit will sleep when not actually calculating to save power.

just recently i've been playing with the lygea 12c emulator ( i've been running some IIR calculations for cashflows. the real device can take minutes but the emulator is there virtually instantly. for these sorts of thing, i've actually started using it over the real machine despite the fact that it has no real keyboard – which is usually the reason to not use a PDA.

good luck and happy hacking!


If lithium polymer ever becomes standardized I will be inclined to retrofit a pack in, 3-5Ah should be possible in the same space!

VARTA EasyPack. 3.7V, 500, 750, 1000, and 2000 mAh. Available
from Mouser, not too expensive. TI (Benchmarq) chips can be
used to control charging. Reference design kit costs $259 and
includes one of each pack.

The 750, 1000, and 2000 mAh are all 64.5 by 36.3 mm, but vary
in thickness, 5.2, 6.4, and 11.4 mm.

For my own purposes, I wish they had a pack with 2000 mAh or
greater capacity, but that was wider and/or longer rather than
being thicker.


A few comments...

Probably overkill for 90+% of calc applications - hope you aren't trying to do another 48/49.

- Don't try to do an HP48/49 calc. Those are available and there's a ton on the used market. (I've given away two myself. To me, they're better as wheel-chocks than calculators.) Plus this is a bigger project. Do a smaller more achievable calc to get something right early.

- A moderately fast HP41/42S-style true RPN calc can do perfectly well using a capable 8 or 16 bit microcontroller, esp if CPU has a built-in basic LCD driver. This includes emulation of original HP 'microcode'.

- Emulation of an orig HP calc w/uncopyrighted ROMs can be very very helpful to getting something "right", early. The emulator can have traps in it to break out into real-code world for ease of implementing new functions or for overall system management. More important than calc operation routines are the actual quality math routines. We'd be hard pressed here to create transcendental functions that match the quality of HP's on even Spice or 11C/12C/15C calcs - let alone that of Solve & Integrate.

- Avoid USB. Expense, etc. Don't use the calc as a USB memory stick, that's a dud application as these sticks are $20 items that fit on keychains and smaller ones are even being given away as promotional items even...

Most PCs can read/write to many types of memory cards (SD/MMC, CF, xD, etc) either directly (or thru a $10 USB dongle) so do the write or read on the card at the PC and move the card to the calc. Less firmware, less grief, no one's bothered.

- Use SD instead of CF cards (and avoid xD!!). CF connectors are more expensive and the speed advantage of CF devices (esp as inplemented in MicroDrives) is not terribly relevant here. Free FAT12/16/32 filesystem open source is available - search SourceForge for EFSL (Embedded FileSystem Library), just write a low level SPI driver to fetch/write n*512 bytes to card sector address...

- Hugh Steers' question/comment about copying ROM to RAM is an important one. In the devices using embedded ARMs, generally attached RAM is faster than ROM, so it behooves one to copy to RAM at boot.

However, I see this as a system integrity issue. Without elaborate realtime continious memory image checks, the paranoid amongst us prefer code in ROM. Wild pointers don't overwrite it, etc. Your car's engine control software and pacemaker software all run directly out of ROM, often uncached.

- Attack power management at very low level. Power mgmt routines should be programmable and configurable for keystroke operation vs running programs at various speeds.

Bill Wiese

San Jose, CA USA


I don't even remember mentioning a switcher outside of it being mentioned during a discusion once.

If you use 4xAAA, and don't use a switcher, you'll be wasting a third of the available battery capacity. A 3.3V linear regulator (or LDO) will take your 4-6V in, and give you 3.3V out, but the voltage difference is being converted to heat. So if the batteries are 1250 mAh at 6V, you get 1250 mAh at 3.3V out.

Some buck-mode switchers that use burst mode or pulse skipping have efficiency above 80% even for low (negligible) loads. With one of those, you get 1818 mAh at 3.3V out.

With a 3.6V lithiun-ion or lithium-polymer rechargeable cell (pack), it makes sense to use an LDO. But then you also need a "fuel guage" chip in order to have a reliable indication of low battery status for the user.


Some buck-mode switchers that use burst mode or pulse skipping have efficiency above 80% even for low (negligible) loads.
I can't say I've looked into ultra-low-power switching regulator use much, but does that include the I(Q)? I have to doubt it. In any case, using more than two AAA's will still require a linear regulator as well to supply the RAM and clock in power-down mode, unless a tap is taken off the first or second battery (which would only give about 1.6V or 3.2V when alkaline cells are brand new). One thing I tried almost 20 years ago for getting the few microamps needed to keep RAM and RTC alive during powerdown is to use a JFET for regulation, with the only I(Q) being what gets through the 2M trimmer used for the voltage divider at the gate. The minor problem with that proved to be that the JFET's pinch-off voltage varied quite a lot across the temperature range. In order to avoid losing data at the cold end, the voltage at the hot end had to be close to the regular operating voltage. I suppose a very high value of thermistor could fix that, if they exist. (I haven't looked.)

If no switcher is used, then four AAA's to end up with 3V would give no real benefit over three AAA's. The energy from the fourth would just go into heating up the linear regulator. Its space might as well be given to something else.

As far as having both USB and RS-232, I'm all for it. While USB is good for connecting to a PC, RS-232 is much, much easier to cobble together projects to control or take data from things on the workbench.


In any case, using more than two AAA's will still require a linear regulator as well to supply the RAM and clock in power-down mode

No, everything runs on the switcher (though extra stuff like the EIA-232 level shifter might be turned off by a FET). In "power off" mode, everything still gets 3.3V, but the main oscillator is stopped so only the RTC and its oscillator are drawing power. The quiescent current of a modern switcher is around 20 uA.

For example, look at the data sheet for the Linear Technology LTC3405, and particularly at the graph of "power lost vs. load current" on page 10.


The MCU has USB 2.0 full-speed, IrDA, and RS232. USB is well suited to interfacing with PCs, IrDA is ideal for wireless communications, and RS232 will make life much easier for those who like to tinker.

An internal CF II slot would allow support for everything from microdrives to expansion devices (since it is really just a mini-pcmcia controller). It may be going a bit overboard, though. There is also a MMC controller on board and if a bit of extra storage space is all anyone wants we can certainly go that route.

I don't have an answer for you on the ROM. We sorely need more hardware design help, if anyone reading this thread would like to lend their talent please send me an email. 512KBytes of SRAM should be more than enough. If for some reason we need more I would lean towards using PSRAM at $10 for 16MB.

As far as batteries go, the more we can stuff in the better. Since the MCU has a battery monitor interface, I believe we should use it.

Execution speed is a big can of worms. I don't think we can make any decisions until the development boards become available. What we can be sure of is that plenty of control will be necessary.


personally, i agree with the battery choice. it means it can run on regular batteries and also on rechargeable ones. otherwise you have to ship a charger. years ago i had an old handspring palm pilot, it worked fine on rechargeable batteries, but one charge didn’t last all that long (by then standards), and when travelling, i used regular batteries since i didn’t have to carry a charger. sadly, they are all built-in Li ones now.

Seconded. I always thought it's a big plus of the HP-48G and its relatives that it can run off standard batteries. You can use disposables when travelling, or dirt-cheap rechargeables otherwise, plus you can recharge them outside the calc.

OT: I, too, mourn the disappearance of AAA-powered PDAs... I ended up settling for a Palm Zire 21: also a non-replaceable built-in Li battery, but the machine uses very little power (no backlight and other such frills) so it will actually run quite a while before it needs recharging.


PSRAM has higher standby current consumption than SRAM. I think you really want low-power SRAM.

I don't know about other people, but I'm not looking for 16 MB of RAM in a 15C/42S replacement. If it has an SD slot, I'll plug in a 2GB SD card if I for some reason need to store lots of programs or data.

And I *much* prefer SD/MMC over CF. The SD/MMC slot can easily be
made accessible from the outside. The cards take up much less room, so I can carry several of them around more easily.


CF is a generic peripheral bus, but it's arguable whether you need the flexibility in a machine like this. My dream calculator would have WiFi, desktop-equivilant RAM and storage and the fastest processor available. Oh, and it would be solar powered and never need recharging under constant use. Essentially, I want a calculator sized package with a calculator keyboard and power consumption, but a fast grid's computing power and a game machine's graphic performance. But a real calculator doesn't need real-time network connectivity, as long as it has some way of reaching the outside world. It shouldn't need a huge anount of storage, but SD/MMC is there with a smaller form factor and lower power than CF in case it does. And while the fastest possible computation speed would be nice, the trade-off for power consumption is always present.

On the other hand, it makes sense to choose a platform that will scale for other projects beyond the initial two machines. Perhaps something approaching my dream machine, or someone else's, will be feasible in the future. It would be nice not to have to throw out all the hardware and software design work to get to a better platform. Besides saving effort in development, sticking with the same hardware platform could make it possible to have the newer system upward compatible with the older. So I say don't design the CF slot out unless it will cost an awful lot to leave it in.



I believe the second generation of openrpn machines will be the ultimate dream calculators. Several ultra-low power technologies should be available within the next 5-10 years such as: bistable displays (e-ink), non-volatile memory (NRAM, MRAM, FeRAM), and ever more energy-efficient PLDs. However, I don't want to worry about any of that until our first generation devleopment is finished!

No one seems to be clamoring for CF, and the general concensus is clearly in favor of MMC/SD. However, if we can make them both fit we'll use them! This is another good example of why I want to build the mainboard on a DIMM. If all else fails we have 144 pins for easy access to unused goodies in the MCU.

I don't plan to use the same mainboard for the second generation, but I would like to make an upgrade that consists of a simple board swap.


This may have been discussed before, but it cannot be overstressed. The two most important features of a calculator are its display and its keyboard:

* Use the HIGHEST contrast display you can find. The main reason i have my 48SX is the low-contrast display. Also, remember that many of us owned HP calculators when they were coming out, and that can tell you something about the state of our eyes :) An option to have a single line of large characters as opposed to two lines of smaller characters `a la HP42 would be nice. The 32SII got it right there.

* While you probably don't have much of a choice on the hardware of the keyboard, you still have much choice on the color scheme. Think HIGH CONTRAST. I suspect someone at HP did a lot of usability research before they settled on the orange ("gold") and blue scheme. It's not perfect, and the choice of colors should depend on the color of the bezel and calculator keys, but the pastel colors in the 48GX and the later 32SII for example were a disaster.

Thanks, and good work!



This is a bloody calculator. Why would you want to run linux on a calculator?

Make it do one thing right, avoid creeping featurism!


I'm not seriously proposing it run Linux. I was looking at the feature set and noticing it had an MMU, which seems like overkill for a calculator.

On the other hand, who knows what will seem like overkill for any partcular device five years from now? Moore's law continues, though they can't easily crank up the clock with current materials and fabs. Maybe a calculator of 2011 will crack public keys with quantum computations, or create ciphertexts impervious to such attacks with related techniques.

So what I really want to know is, what would a QMMU(tm) look like? 8)


Maybe a calculator of 2011 will crack public keys with quantum computations, or create ciphertexts impervious to such attacks with related techniques.

I'm pretty sure that such a device would be banned not only from exams but from general usage. Intelligence agencies around the world will neither want everybody to be able to crack any encryption nor to encrypt their private data in an indestructible way.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Dedicated HP calculator programming-hardware-bug website? Geoff Quickfall 12 2,042 10-12-2013, 11:34 PM
Last Post: Les Koller
  OpenRPN Matt Agajanian 3 1,175 09-09-2013, 12:42 AM
Last Post: Paul Dale
  HP Prime (DVT Prototype) Hardware Details Adrien Bertrand 7 2,189 08-10-2013, 12:04 PM
Last Post: Eric Smith
  [wp34s] Minor Issue with Stopwatch on real hardware RalfGeiger 3 1,404 04-16-2013, 04:12 PM
Last Post: Eric Smith
  HP 10s+ hardware Mic 1 815 04-07-2013, 07:52 PM
Last Post: Eddie W. Shore
  SY-41CL: Hardware Difference Between V2 and V3 Gerry Schultz 2 1,061 05-26-2012, 11:54 AM
Last Post: Monte Dalrymple
  Program works in emulators but not on HP-15c hardware Marcel Samek 32 5,493 05-11-2012, 08:46 PM
Last Post: Jeff O.
  HP-41 keyboard issue - help from the hardware gurus here Geir Isene 7 1,844 04-16-2012, 05:06 PM
Last Post: Geir Isene
  HP48S, different hardware construction Cristian Arezzini 5 1,414 01-12-2012, 04:29 PM
Last Post: Mike Morrow
  OpenRPN Prototyping In Progress Hugh Evans 19 3,553 10-20-2011, 09:16 AM
Last Post: Oliver Unter Ecker

Forum Jump: