←back to thread

322 points DamonHD | 7 comments | | HN request time: 0s | source | bottom
1. shrubble ◴[] No.41830558[source]
A friend who works in embedded systems pointed out that XMODEM protocol communication is used everywhere in embedded; it may be that the protocol is more widely shipped now than it has been in the past!

Many Cisco, Adtran, Juniper etc switches and routers have it in their firmware also.

replies(2): >>41833347 #>>41841927 #
2. cmptrnerd6 ◴[] No.41833347[source]
We just upgraded from Xmodem to Kermit last week in our embedded device.
replies(1): >>41833448 #
3. shrubble ◴[] No.41833448[source]
Kermit is interesting also, though my understanding was that it was not quite as good as taking advantage of higher available data rates; am I wrong about that?
replies(2): >>41833571 #>>41843920 #
4. cmptrnerd6 ◴[] No.41833571{3}[source]
Entirely possible I don't understand something as I'm not sure what you mean by taking advantage of higher data rates. We're sending data over UART at the max rate that doesn't introduce too many bit errors. Mainly we needed a protocol to correct for the bit errors (by rerequesting data) and I've always used x/y/z modem for that purpose.

I picked Kermit this time because I didn't want to implement x/y/z modem again and had never used Kermit.

This [1] claims Kermit is faster in some instances depending on what features you have enabled.

[1] http://www.columbia.edu/kermit/perf.html

replies(1): >>41840950 #
5. shrubble ◴[] No.41840950{4}[source]
I was wrong, and you are correct! I had thought that XMODEM was more efficient as the bandwidth increases but I was wrong; due to the fixed length of time for the ACK response, the efficiency drops to under 80% at a data rate of 9600bps; Kermit does not have this issue.
6. HeyLaughingBoy ◴[] No.41841927[source]
Yup, two years ago I worked with someone who was implementing it at the time. I think on an nRF52-series device, of all things.
7. devilbunny ◴[] No.41843920{3}[source]
Kermit defaulted to settings that would transmit 8-bit data over 7E1 through a noisy 110 bps channel (not really, but that gives the flavor - though it could do that if asked). Much-maligned because most terminal programs implemented the base case and nothing more, which was awful.

It was not trivial to reconfigure, but if you did, it had very good throughput. And if you had to make an EBCDIC/ASCII translation, it did that well. Kermit always works. That's the point of the protocol. If you want it to be fast, that's up to you. I did not realize this until I met Kermit gurus who taught me.