The Kermit Project
Now hosted by
New York City USA • firstname.lastname@example.org
|Using C-Kermit with HP Calculators:|
We assume here that the PC side operating system runs Linux.
./wermit ; Start C-Kermit ; The following commands are entered at the "C-Kermit>" prompt... set port /dev/ttyUSB0 set speed 9600 ; Serial port speed, HP48 defaults to 9600, also supports 4800 2400 1200 set carrier-watch off ; It's not a modem connection so ignore carrier signal state. set modem type none ; No modem is involved; don't send AT commands. set flow none ; Flow control is not supported by HP48. set parity none ; 8 data bits, no parity set control prefix all ; HP48 Kermit requires all control characters to be encoded in printable form. set file type binary ; Might not always be needed.*
|*||Safe default IMHO because it avoids the transfer program to corrupt the transferred data believing we expect it to change line feed characters and the like.|
Note that it is not necessary to type all these commands every time you want
to set up a file-transfer connection with the HP48. You can copy the
commands into a file (e.g. "hp48.ksc") and then tell C-Kermit to
"take hp48.ksc". Or you can define a macro in your
From that on, it's up to your knowledge of the Kermit protocol.
For example to send from PC to HP48, on the HP48 start a kermit server
Or to send from HP48 to PC, on PC type
and on the HP48 put a file name on the stack (with VAR and
possibly NXT, find your object in the menu, press '
and the A-F key showing the object) and
Tested today on a PC running Xubuntu 20.04.
Sending files to the HP50G using C-Kermit, may result in NAKs being sent from the calculator (receiver) back to C-Kermit (sender). It was observed that small files with data packets around 50 bytes were ok, but larger ones (approx 100 byte data packets) would fail with "Protocol Error" being displayed on the calculator.
According to section D-4 of "HP 50g / 49g+ / 48gII graphing calculator advanced user's reference manual", it mentions:
Controls whether receive pacing is used: a nonzero real value enables pacing, while zero disables it. Receive pacing sends an XOFF signal when the receive buffer is almost full, and sends an XON signal when it can take more data again. Pacing is not used for Kermit I/O, but is used for other serial I/O transfers.
Controls whether transmit pacing is used: a nonzero real value enables pacing, while zero disables it. Transmit pacing stops transmission upon receipt of XOFF, and resumes transmission upon receipt of XON. Pacing is not used for Kermit I/O, but is used for other serial I/O transfers.
So it appears HP50G Does not support XON/XOFF for kermit I/O.
Via some testing, and consultation with the C-Kermit maintainer, it was suggested that the HP50G may have an incoming packet length limit but does not tell the file sender (C-Kermit in this case) about it in the negotiation phase.
To avoid filling the small receive buffer of the HP50G, resulting in repeated NAKs and Protocol Errors, we can tell C-Kermit (sender) to send smaller packets.
Adding the following line to
[Ed. - If C-Kermit is to be used for other applications besides this one, the "set send packet-length 80" command would go in any scripts written for HP50G interaction, rather than in the
set send packet-length 80
Reference: hp50gshell: Use Python to expose a simple interactive shell for HP 50G calculator.
|Last update: Tue May 24 07:08:53 2022||[ Validate ]|