undefined | Better HN

0 pointsaddaon3y ago0 comments

RS-485 is a serial interface, at the physical layer.

8N1 as a line code introduces all sorts of other issues, assuming you're passing messages instead of byte streams over it. In particular, how do you do packetization? How do you synchronize? So many "serial interfaces" have implicit timers (corresponding to interpacket gap for ethernet) used for sync'ing, or play horrible games with embedded CRCs… there's a huge amount of hidden complexity here, especially if you do it implicitly without understanding the dependencies.

By the time you've solved reliable packetization over 8N1, you're going to have something that looks a lot more like an Ethernet-level-complexity line code.

0 comments

icedchai3y ago

Why reinvent the wheel? Just look at some older protocol, like SLIP.

addaonOP3y ago

SLIP uses byte stuffing to reserve its end-of-frame sequence, which leads to data-dependent packet transmission times, which is not acceptable in my application.

madars3y ago

Is this a big deal? Say, if character 0 is reserved you can encode everything in base255 and transmit encoded bytes shifted by 1. (Or, for simpler encoding, transfer an appropriately encoded bitmask of which characters are 0, then a copy of that data where 0 is replaced by anything else.)

Edit: this HN comment by KMag suggests a much simpler encoding https://news.ycombinator.com/item?id=12550584 (you'd need to process your packets in 254 byte chunks)

> replace first null with 255. Every later null, replace with the index of the previous null. Make the final byte the index of the last null (or 255 if no nulls were replaced). In this way, you've replaced the nulls with a linked list of the locations where nulls used to be. To invert the transformation, just start at the final byte and walk the linked list backward until you hit a 255.

Looks like this is https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuff...

1 more reply

j / k navigate · click thread line to collapse