In deel 1 en deel 2 van de 'serie' over de CAN-bus is al wat verteld over het principe van deze communicatiebus. In dit deel wil ik wat vertellen over het praktisch meten aan de bus. De ESP32-microcontroller bevat hardware aan boord voor het CAN-protocol. Mijn software gebruikt deze hardware via een driver die door Espressif (de bouwer van de ESP32) aangeboden wordt. De CAN-hardware van de chip gebruikt twee GPIO's - TX en RX - voor de verbinding met de bus. De ESP32 kan echter niet rechtstreeks aan de bus gekoppeld worden, hier moet nog een transceiver tussen.
Om de CAN-bus te kunnen debuggen kan gebruik gemaakt worden van een protocol analyser of een oscilloscoop. Ik heb de beschikking over een HP 54603B digitale scope met nog zo'n prachtig groen schermpje. Deze heeft twee ingangskanalen, ideaal om de CAN-High en CAN-Low signalen gelijktijdig te bekijken. Ben wel benieuwd of alles op beeld er een beetje netjes uit ziet en of ik het allemaal snap.
Mijn testopstelling |
Om te testen wordt de knipperlichtaansturing gebruikt. Vanuit de centrale dashboard-node (in bovenstaande foto het bread board) worden achtereenvolgend twee CAN-berichten verstuurd: knipperlicht-links-aan en knipperlicht-links-uit. In mijn CAN-berichtenlijst zijn dit de berichten met respectievelijk de berichtnummers 14hex en 15hex. De scope wordt zo ingesteld dat deze triggert op een opgaande flank van CAN-high en plukt zo een volledig bericht van de bus:
Een volledig CAN-bus-bericht. |
Op het plaatje is te zien dat voordat het bericht begint er geen verschil is tussen de spanning op kanaal 1 en kanaal 2. Zowel CAN-High als CAN-Low voeren een spanning van iets minder dan 2.5 volt. Da's ongeveer de helft van de voedingsspanning van 5 volt. Dit is de recessive status en komt overeen met een digitale '1'. Het bericht begint met een startbit waarbij CAN-high en CAN-low actief uit elkaar getrokken worden. Er staat nu iets meer dan 2 volt spanning tussen CAN-low en CAN-high. Dit wordt de dominant status genoemd en komt overeen met een digitale '0'.
Knipperlicht aan. |
In bovenstaande plaatjes heb ik bij de elektrische niveaus de digitale nullen en enen geplaatst. Wat direct opvalt is dat de twee berichten niet dezelfde lengte hebben, het knipperlicht aan-bericht is een bit langer... Het koste even wat hoofdbrekens om te achterhalen wat dit zou kunnen veroorzaken. Google bracht het antwoord, maar eigenlijk had ik het moeten weten. Leeftijd zullen we maar zeggen.
0 Extended Format
0010110001110011 CRC + delimiter
- Het berichtnummer klopt, 000 0001 0101 komt overeen met 15hex.
- Het RTR-bit klopt. Het is geen Remote Transmission Request maar een normaal bericht.
- Het Extended Format wordt niet gebruikt. Gewoon 11-bits berichtnummer.
- Er wordt geen gebruik gemaakt van data-bytes, de Data Length staat dus op 0.
- De Cyclic Redundancy Checksum zal juist zijn, anders wordt het bericht niet geaccepteerd.
- Het Acknowledge-bit wordt door de ontvangende node(s) naar '0' geforceerd.
Rare term vind ik, mijn associatie met 'stuffing' is dat het erbij gestopt kan worden, omdat er nog plaats is, maar het is eigenlijk bit 'adding', want er komt gewoon iets bovenop/erbij.
BeantwoordenVerwijderenJa dat heb ik ook wel een beetje met de term 'stuffing'. Terwijl het eigenlijk op zijn Brabants "er tussen frommelen" is. En later weer weghalen. Maar wel goed bedacht...
BeantwoordenVerwijderen