43s status

[brouhaha]

(10-01-2015 02:49 PM)Kinma Wrote:  Question; how much flash and ram do you need for the 41CX

RAM:
Native firmware: 7KB
For simulated RAM registers (status, main registers, extended memory), 8KB
Stack: probably under 100 bytes

Flash:
Bootloader w/ LCD, keyboard, USB, MicroSD support, FAT filesystem, rudimentary diagnostics: 45KB out of 64KB reserved
Native firmware: 75KB
Base 41CX ROM: 48KB (six ROM pages, 8KB per page)
Port ROMs: typically 24KB per port to support HP 12K word ROMs (32KB for HEPAX), plus 8KB per page for hard-addressed ROMs

Note: ROM images could be packed to 5KB per page, with minor performance hit

Since flash memory has limited endurance, in order to allow user to change ROM selection, it may be advantageous to put some port ROMs in RAM instead, but RAM size tends to be the limiting factor.

Quote: and how much do you need for the free42 running on the Gecko microcontroller?

RAM:
Native firmware and Free42: 16KB
Stack: unknown
User memory: as much as possible

Note: Free42 is unlikely to work well with less than 32KB of user RAM. Giant Gecko provides 128KB total RAM.

Flash:
Bootloader w/ LCD, keyboard, USB, MicroSD support, FAT filesystem, rudimentary diagnostics: 45KB out of 64KB reserved
Frmware, native plus Free42 (has MicroSD, FAT fs, but no USB support): 257KB

Since this code is under active development, the flash requirements could grow a fair bit before release, expecially if the USB stack is added.


I have not attempted to optimize RAM usage any more than was necessary to get the firmware to be generally functional.

For both 41CX and Free42, the bootloader when running uses 14KB of RAM. In an ideal world, that would be RAM reserved for the bootloader only, so that it would be possible to run the bootloader without losing the user memory. Due to the general scarcity of RAM, the memory is not presently dedicated in that manner. With some effort, a portion of the bootloader RAM, including the exception vector table and LCD buffer, could be shared with the calculator RAM.

I have not attempted to optimize RAM usage any more than was necessary to get the firmware to be generally functional.

Free42 was in general not written for use in low-memory environments. The original 42S had 8KB of RAM, but Free42 will not work well with that little. Free42 depends heavily on dynamic memory allocation from the standard C library, even for things like floating point numbers in the stack. As a result, it is quite possible for Free42 to fragment the limited memory of a microcontroller. For this reason, I consider Free42 on the XC-42 to be experimental. To avoid fragmentation problems, it is advisable to periodically write the full state of the calculator to an SD card, and reload it. Unfortunately when running from CR2032 coin cells, use of the SD card under low battery conditions could cause the calculator to lose all memory, because SD cards can draw 100mA, which is well beyond the spec of even a fresh CR2032. This is one reason why the evolution of the case design is moving to a wedge shape with a pair of alkaline AA cells instead of the CR2032 coin cells.