HP-41CL Remote Keyboard / Scripting

[Monte Dalrymple]

(04-17-2021 07:50 PM)rocket.scientist Wrote:  The updating of a 41CL is a good example, and fairly well known. There is an elaborated dance that needs to happen between a PC and a 41CL to manage the periodic updates, with commands at the PC coordinated with commands on the 41CL. While Sylvain and Monte (and others I am sure) have developed the excellent "clupdate" tool to facilitate, there is still a lot of manual coordination between PC and calc. It would be nice, since the full process is so well known, to have the PC more fully automate the process.

**BIG GOTCHA HERE** This highly automated approach does not accomodate any error conditions that may arise. I am not sure it is possible to permanently brick a 41CL, but I do not want to find out.

-Pat (KG5YPQ)

The "elaborated (sic) dance" is actually quite simple compared to what happens behind the scenes when, for example, plugging anything into a USB port on a PC. So are you asking for a "plug it in and it beeps when done" type of operation?

I designed the protocol deliberately to make the user aware of what is going on, and to give the user the opportunity to modify the process if desired:

"CMOPEN" to make sure that the PC is connected properly and aware of the CL.
"*" "FLCHK?" to check the compare the status of the CL Flash with what the PC thinks it should be.
"FLUPD" to actually update the Flash, giving the user the opportunity to verify or modify the updated pages. Perhaps the user doesn't want something updated.
"CMCLOSE" to signal to the program running on the PC that the CL is done.

Of course, there are options along the way. "CPONLY" to simplify the compare process if the user knows that the FLDB on the CL is current. "OSUPDT" protects the user because the OS sector is critical.

The only way to brick the machine is to muck up the update of the OS sector. I made it as foolproof as I can. The downloaded pages in the OS sector are always checked for the proper CRC, even though the comm channel itself is very reliable. The user must specifically enable the OS sector update. The battery status is checked before the sector is erased (this happens with every sector) and the process is aborted if the battery is low. I can't protect against the battery suddenly failing, or being removed, during the OS sector erase or write, but I have tried to account for every other possibility.

Perhaps it's a philosophical thing. As a user, I want control of what happens at each step. I am the first to admit that I may be odd in this regard.

Monte