LIN bus¶

The Local Interconnect Network bus is a simple low-speed bus to ... as the name says: interconnect different different devices. It's used in the automobile industry as low-end alternative for the faster and much more complex CAN bus.

It turns out that even the simplest STM µCs have support for LIN in their USART hardware. And that you can use the LIN protocol without bus drivers: just an internal pull-up and setting the GPIO pin to open-drain mode is enough.

The official LIN bus runs at speeds up to 19,200 baud, with packets payloads of only up to 8 bytes. That gives it very limited throughput, but still snappy response times for things which happen at a "human" timescale, i.e. down to tenths of seconds. The maximum number of devices ("IDs") on one bus is 64.

It should be enough for a decent set of DOBB modules if those IDs are properly managed.

The nice thing about using a standard bus, is that some scopes have a built-in decoder. Including filters for packets with a specific ID or a payload matching specific bytes.

The plan¶

What I have in mind is sending measurements around and controlling some parameter settings via the LIN bus. With a single bus line shared between modules, combined modules start to make sense: one generates some signal, another one measures, a third one controls the settings, and yet more for live displays. Fun when combined with breadboards.

Just as with CAN, the key idea is that devices "shout": they publish whatever they want, using small 2..8 byte messages. The other modules can see this and pick up what they like. It all hinges on proper use of the packet's 64 IDs: a mismatch means nothing happens.

Unlike CAN, the LIN bus does not have bus arbitration. Instead, it relies on a master node which queries IDs according to some time schedule. The schedule can be as simple as querying each ID in rapid succession, or it can divide the limited time in more subtle ways.

Bus master¶

The first task is to set up a bus master which periodically sends out the queries. This is what the LIN Viewer does (despite its name): it has a fixed schedule for now, just to get started: polling IDs 0..7, 32..39, and 48..55 once every 500 ms. A more sophisticated schedule will make buttons and knobs more responsive, but for now a simple fixed 0.5 sec poll will do.

LIN bus packets are very limited:

IDs 0..31 have a 2-byte payload
IDs 32..47 have a 4-byte payload
IDs 48..63 have an 8-byte payload

That's it. No other sizes, no more IDs. It's not a protocol for sending out lots of text or firmware images, although that could be done by sending multiple packets to the same ID.

The intial implementation is a module with a small OLED to show the packets on the bus. There can only (and must always) be one bus master.

Three wires¶

The "official" LIN bus uses 12V signaling and slew-controlled transceiver interface chips, because its main use is in noisy automotive environments. For DoBB, standard logic levels are fine, and simple open-drain outputs with internal pull-ups to 3.3V work well. As more devices are added to the bus, the pull-ups will counteract the increased capacitive load.

The BUS-A line on the expansion bases will be used for LIN, as first informal convention. It's automatically shared between modules, so it's just a matter of plugging one in and making sure it's set up as LIN "slave".

But there's another option: if a circuit only uses a LIN bus connection, then all it needs is 3 wires: +5V, LIN bus, and GND. One example is the rotary module shown here: two rotary knobs and some buttons as "controller", plus an OLED which can indicate what the knobs do.

The cable uses a standard 2.5 mm audio plug: small and widely available.

Bus monitor¶

Although the LIN bus only runs at 19,200 baud, there could be quite a bit going on when more devices are active. The bus master will poll each device every 10 to 2500 milliseconds.

Since there are only 64 possible IDs and each one can only send 2, 4, or 8 bytes, there's a way to (just barely!) fit all the packets from each device on a 240x240 LCD screen. Only the last packet is shown for each ID, with new ones in red, slowly fading to yellow, green, blue, and then grey.

It's cramped and super tiny, but this is what the LIN Monitor module is for. It fits on a 7x3 cm proto board and plugs into an expansion base. And the colours make all the difference!

Background LIN¶

There's a LIN responder implementation in JeeH which runs as task in the background. It's convenient because it stays out of the way of the rest of the application. Everything is done via an dedicated UART in async DMA mode (the uart::Trig driver), and with STM's UART support there's just one interrupt per device poll and when a complete device packet has been received. The prority of these interrupts could be lowered, since there won't be more than one or two every 10 ms, which is the maximum scheduling rate of the LIN bus master.