en bil är en rullande hög med hundratals mikrokontrollers dessa dagar – bara fråga någon greybeardmekaniker och han börjar sin “Carburetor” Rant. Alla dessa system och delsystem måste prata med varandra i en elektriskt fientlig miljö, och det är inte en överdrift att säga att felkommunikation, eller till och med försenad kommunikation, kan få stora konsekvenser. In-car-nätverk är stor verksamhet. Massproduktion av bilar gör många av de relevanta sändtagaren ICS lågkostnad för den icke-automotive hårdvaruhackaren. Så varför ser vi inte mycket mer hackerprojekt som utnyttjar denna anmärkningsvärda resursbas?
Ryggraden i en bils nätverk är Controller Area Network (CAN). Hackaday’s egna [Eric EquiceChick] är en bilhackare extraordinaire, och skrev upp många allt du vill veta om CAN-bussen i en multipartserie som du säkert kommer att vilja bokmärke för att läsa senare. Motorn, bromsar, dörrar och alla instrumentdata recensioner (differential) burk. Det är snabb och hög tillförlitlighet. Det är också komplicerat och lite dyrt att implementera.
I slutet av 1990 hade många producenter egna proprietära bussprotokoll som körs tillsammans med burk för de icke-kritiska delarna av bilnätet: hur en dörrmonterad konsol talar till dörrlås chaufför och fönstermotorer, till exempel. Det är inte värt att röra upp den huvudsakliga bussen med icke-kritisk och lokal kommunikation så, så undernätverk spunnits av huvudburken. Dessa behövde inte hastigheten eller pålitlighetsgarantierna för huvudnätet och av kostnadsskäl måste de vara lätta att genomföra. Den minsta mikrokontrolleren borde räcka för att rulla ett fönster upp och ner, eller hur?
I början av 2000-talet standardiserade den lokala sammankopplingsnätet (LIN) -specifikation en metod till dessa delnät, med fokus på låg kostnad för implementering, medelhastighet, omkonfigurerbarhet och förutsägbart beteende för kommunikation mellan en mastermikrokontroller och ett litet antal slavar i ett kluster. Billiga, enkla, implementerbara på små mikrokontroller, och bara bäst för medelstora projekt? En hackers dröm! Varför använder du inte Lin i dina multipla-mikroprojekt? Låt oss gräva in och du kan se om något av detta är till hjälp för dig.
Linprotokollet
Ett Lin “Cluster”, vilket är vad det lokala mini-nätverket kallas i jargon, består av en enda mastermikrokontroller och ett antal slavar. Lin startar som konventionell 8N1 UART-serie, typiskt vid 19 200 baud och tar bort med en tråd. Därefter lägger den till ett protokoll som gör det möjligt för den här singeln att användas som en buss, delad bland flera slavar. Om du försökte rulla ditt eget nätverksprotokoll för enkel UART-seriekommunikation, skulle du sluta med något som Lin. Gå hämta en kopia av specifikationen (PDF) och läs tillsammans!
Varje LIN-transaktion är fundamentalt densamma: Mästaren skickar en rubrik som innehåller en skyddad identifierare (PID), som anger den uppgift som ska utföras. Uppgifter kan vara något som “Rapport temperatursensor 2” eller “Ställ servo 3-position”. Beroende på uppgiften, mellan en och åtta byte av data följer, med en tvåbyte kontrollsumma. Slavarna måste veta vilka uppgifter som ska svara på och hur man svarar. Så om “set servo 3-position” skickas, behöver servo 3 slaven lyssna efter nästa byte och reagera i enlighet därmed. Alla slavar som inte svarar på kommandot kan bortse från data tills nästa ingress.
I fallet med “rapporttemperatursensor 2” skickar slaven med temperatursensorn sin data direkt efter mottagandet av kommandot. Eftersom bytenden är känd i förväg, och endast sensorn 2 får svara på den här uppgiften, vet befälhavaren att lyssna på exakt, säg fyra byte i reaktion och vet hur länge det borde ta.
Detta pollningssystem med de mastersändningsrubriker och slavarna som skickar reaktioner garanterar att ingen av enheterna kommer att komma åt bussen samtidigt, så kommer Lin med bara en enda RX / TX-linje. Innehållet innehåller en synkroniseringsbyte (0x55) som hjälper slavarna att låsa på huvudklockan, så slavarna kan springa på mindre dyra RC-klockkällor och auto-bauding är möjlig.
Eftersom längden på meddelanden är känd före tid, kan tidpunkten för masterens pollingrutin skrivas ner i ett schema. Huvudmästaren pollar nätverket med definierade intervaller, och om slaven inte svarar inom 1,4 gånger den tid som krävs för transaktionen, antas det saknas i aktion. Hur som helst är mästaren till nästa punkt i sitt schema, och kommer inte att försöka igen den potentiellt defekta slaven tills dess tur kommer runt igen. Detta garanterar en känd uppdateringshastighet för alla enheter, vilket gör livet mycket enklare för programmering av mästaren.
Det är grunderna. Befälhavaren skickar PIDs, och en serie databyte följer. Allt är comfy old uart, ring och svar, anpassad så enkelt som möjligt för att skapa ett litet nätverk.
Extrafunktion
GUI LIN-konfigurationsapp från en lärorik VIdeo.
Keeping the network that easy requires that the master and slaves all agree on the command set and valid reaction lengths. That’s a lot of information needed for the LIN cluster to function, in principle. helping matters out somewhat, there’s a conventional format for notating all of this laid out in the LIN spec.
There’s also a conventional API for C that both the master and slave microcontrollers can use to make handling coding up behavior in a LIN cluster. Combined, this makes a conventional workflow for specifying and implementing LIN busses — very useful for the automakers, and not useless for the hacker either.
There is also a sleep state and behavior that’s defined for the bus, with associated sleep and wakeup signals. all of the slaves ought to respond to the sleep signal, and any of them ought to automatically go to sleep after a timeout of four seconds if they haven’t heard from the master. any node, slave or master, can send the wakeup command, and after that the master ought to go back to its normal polling schedule.
LIN version 2.0 included a number of optional frame types that make the network much more flexible. In particular, “sporadic frames” make the slave’s reaction optional if it hasn’t gotten any new data because the last update. “Event triggered frames” are like sporadic frames, except they can be additionally responded to by any slave node that has new data.
This introduces the possibility of a collision on the bus, in which case hopefully the checksum doesn’t add up and the master falls back to slave-specific frames as before. These two modes speed up the bus when data updates are infrequent, but add some indeterminacy to the schedule and conditional complexity to the code. use them only if you need them.
The master can also have multiple schedules, and switch among them. The slaves don’t care — they just listen for the tasks that are relevant to them anyway. There’s no reason for the master to send servo position data every period if it hasn’t changed, for instance, even if it makes things conceptually simpler. Ditt samtal.
There is even an optional carry layer spec that is compatible with CAN bus and makes it simpler to integrate the local LIN cluster with the bigger network. In short, LIN is a very thoroughly thought through UART bus protocol with good industry adoption. You’ll find good tutorials from every vendor of LIN transceiver hardware. (Here’s a terrific intro from national Instruments.)
Hardware — The Physical Layer
Topping all of this protocol niceness off is a broad variety of LIN transceiver chips ranging from $0.25 to $0.50 for plain transceivers, on up to around a buck or two for “system basis” chips with integrated voltage regulators. These are especially slick, because the transceiver can take care of the sleep/wake logic and turn the power supply to your microcontroller on and off. This makes integrating a slave node that operates at 3.3 V very simple.
Little chip purchases you a lot.
Since the LIN bus is developed for automotive, it’s typically specced for 12 V because that’s what courses through the veins of your car’s wiring harness. LIN transceiver hardware needs to be able to accommodate even higher voltages, because automobile electrical systems can be spiky environments. They also have to cope with bus contention, when the transceiver chip may be trying to pull the LIN line down while someone else is trying to pull it up, so there’s overheating protection built in as well. LIN transceivers are robust little beasties.
In contrast to I2C lines, which are pulled up with puny resistors, an automotive LIN bus is pulled up to 12 V with a 1 kΩ resistor. To pull this line down fast enough, LIN transceivers need to be able to conduct tens of milliamps, so they have slightly beefy (for ICs) transistors built in. The combination of a high voltage and relatively high line current implies that an automotive-spec LIN bus is good for 40 meters, rather than the couple meters that I2C gives you without resorting to drivers. If you need the distance or the noise immunity, LIN is there for you.
But nothing forces you to run your bus at 12 V, even the transceiver hardware. The Microchip transceivers that I’ve seen run down to 5.5 V, while the ones from NXP and Melexis run down at an Arduino-compatible 5 V.
And nothing forces you to use transceiver hardware at all! You could simply connect a PNP transistor (or P-channel MOSFET) to the bus line and drive that with the UART TX, sampling the bus with the RX line. This has the drawback of local echo, but that could be handled in software. Or, with only a few much more parts, there’s this service that we’ve seen before. I couldn’t find any hacker projects implementing LIN transceivers from scratch, though. maybe that’s because the industrial ones are just so cheap.
Styrkor och svagheter
No bus is ideal for all occasions, and LIN is no exception. LIN is not particularly fast, being developed around 19,200 baud UART. Uppdateringar kommer ganska sällan, från en mikrokontrollers perspektiv. En full längd transaktion, med timeout, tar cirka tio millisekunder. Om master polls sexton enheter, är det en uppdateringshastighet på cirka Seven Hertz värsta fall. Naturligtvis behöver mästaren inte polla varje enhet varje gång, och många gånger kommer meddelandena att vara hälften av den längden, men du kommer inte att få mycket mer än 200 Hz. Å andra sidan är uppdateringshastigheten konstant på grund av förmågan att utföra snäva timeouts för flakiga enheter, vilket är fantastiskt för tillförlitlighet och enkelhet, och det är inte så mycket långsammare än i2c.
Det finns två huvudversioner av Lin som du ser i det vilda, 1.x och 2.x. Förutom de valfria ramtyperna som diskuterats ovan har de två versionerna olika kontrollsummedel – och den i 2.x är verkligen bisarrt – vilket kräver en webbaserad räknare för att du gör det rätt. I stället för tillsats MOD-256 subtraherar de 255 från vilket värde som helst 256 eller högre. Det är som en 8-bitars överflöde som sätter runt till 1 istället för 0. Är det meningsfullt för någon av er?
Lin-enheter är inte så vanliga utanför bilindustrin som I2C eller SPI, med ett långt skott, så du har nog aldrig tvingats hantera protokollet. Men om du vill ställa upp ett litet antal mikrokontrollerbaserade moduler, så enkelt och billigt som möjligt, med bara en tråd (plus mark), är det svårt att tänka på något enklare. Att skriva i2c slavkod är verkligen ingen picknick. Skrivningskod för att lyssna på en viss byte på en UART-linje och sedan reagera kunde inte vara enklare.
Vill du vända din vanliga vanilj i en buss? Ta en sida eller två ut ur Lin-boken! Har du redan gjort det? visa oss!