HP Forum Archive 20

[ Return to Index | Top of Index ]

has 16C memory increased? Message #1 Posted by designnut on 5 Sept 2011, 8:09 p.m. As I recall iot was a little short of programmable memory space. I am unable to find if that has changed, anyone know? Sam

Re: has 16C memory increased? Message #2 Posted by Eric Smith on 5 Sept 2011, 8:39 p.m., in response to message #1 by designnut The 16C has been discontinued since 1988, so none of its specifications have changed since then. If you are referring to the new 15c limited edition, AFAIK the only specifications that are changed are the speed (much faster) and the batteries (two CR2032, vs. three 357 button cells). The available memory is unchanged: up to 65 registers or 448 program steps.

Re: has 15C memory increased? Message #3 Posted by kc on 6 Sept 2011, 5:54 a.m., in response to message #2 by Eric Smith So that's the question: Isn't it much easier nowadays to have say, 32k RAM than to have less than 2k?

Re: has 15C memory increased? Message #4 Posted by Paul Dale on 6 Sept 2011, 6:01 a.m., in response to message #3 by kc The CPU in the modern 12c and almost certainly the 15c has exactly 2kb of battery backed RAM. So, no it isn't always easier to have more RAM. The 15c firmware uses less than this BTW. - Pauli

Re: has 15C memory increased? Message #5 Posted by uhmgawa on 6 Sept 2011, 5:32 p.m., in response to message #3 by kc Quote: So that's the question: Isn't it much easier nowadays to have say, 32k RAM than to have less than 2k? It depends on the SoC and whatever other functionality is competing for finite silicon real estate. Most notably the current ARM SoCs have rather limited RWM capacities. Also the lowest achievable system power reduction in which RWM data is retained differs considerably between designs. The power-down-data-retained leakage current varying in proportion to the RWM size is another motivation to limit its size. Unfortunately with present SoCs applicable to this application area you are limited to on-die ROM/RWM in practical terms for direct access/execute memory. However for firmware emulator applications, serial interconnect (eg: SPI) RWM can be acceptable for firmware (vs. emulator) sourced access without much of a performance penalty. To a lesser extent this can be true for ROM (flash) as well but in my experiments I've found some internal caching was needed to avoid getting bogged down in SPI addressing overhead as well leverage repetitive localized instruction fetching. To frustrate matters caching itself consumes internal SRAM so an application specific balance needs to be struck.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall