Re: OpenRPN Hardware Specifications Message #30 Posted by Bill Wiese on 2 Dec 2005, 1:19 p.m., in response to message #29 by hugh steers
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
|