Stuttgart HP Meeting 2024 (replacement Allschwil)

[AnnoyedOne]

In my experience software/engineers/programmers/computer scientists assume a machine with infinite speed and memory. With 64-bit CPU's, gigabytes of RAM, etc. large programs simply aren't an issue anymore. For those of use who've programmed 8051 type SoC's with 128 bytes of RAM, or less, limitations are a challenge to be overcome

IMHO checksums can be useful if they're actually validated by comparison to a known value or by a human. Otherwise "why bother"?

In the 1980's processors were slow and LRC (aka XOR type), simple addition etc, checksums were the norm. Reasonably fast but although the coverage wasn't great they caught most simple errors. In those days ROM/EPROM/etc weren't as reliable as they are now so they served a purpose. Reset on any error and try again.

By the 1990's I'd moved to 16-bit CRC's. Better coverage but slower to calculate. In my case 1-2 secs which was acceptable.

Before I retired I used two 32-bit CRC's on firmware images. Downloadable so one covered the "header", which indicated a valid firmware image before erasing the old version, while the other was over the firmware itself (to validate memory reprogramming). [The latter was also checked, by the bootloader, after reset.]

Then there's the "human" type like on my HP-20S. Enter a program and a checksum is shown at the end so a user can check for entry mistakes. Those may also be useful during product manufacture and/or an end-user for firmware validation.

A1