CAN-bus - Deel 2

Mijn enthousiasme voor de CAN-bus heb ik in het vorige blogbericht niet onder stoelen of banken geschoven. De conclusie is dat het hier om een efficiënte en zeer betrouwbare communicatieverbinding gaat. Maar hoe gaat deze bus ingezet worden in mijn Burton. Hiervoor zijn in ieder geval twee belangrijke vragen te beantwoorden:

1. Wat voor berichten ga ik versturen?
2. Wat voor apparatuur ga ik toepassen?

De eerste vraag heeft natuurlijk alles te maken met de onderdelen binnen de Burton die via de CAN-bus aangestuurd gaan worden. In eerste instantie denk ik dan aan de verlichting en de bediening hiervan. Er zijn dus CAN-berichten nodig om alle lampen aan en uit te schakelen en hier misschien nog wel wat andere dingen mee uit te halen (spoiler alert).

Een CAN-bericht bevat naast de zaken uitgelegd in het vorige blogbericht o.a. nog een datablok. Hierin kan maximaal 8 bytes aan data verstuurd worden. Hoeveel data-bytes in het uiteindelijke bericht zitten wordt bepaald door de controle-bits. Met vier van de vijf controle-bits (het vijfde bit wordt niet gebruikt) wordt de lengte van het datablok (in aantal bytes) bepaald.

Het volledig standaard CAN-bericht op schaal (klik op het plaatje om het te vergroten).

Wat duidelijk wordt is dat het datablok het grootste deel van het CAN-bericht uitmaakt. Maar zoals in het plaatje aangegeven wordt, kan het datablok ook lengte 0 hebben. Da's fijn want om lampen aan en uit te zetten is niet zoveel data nodig. Maar hoe gebruiken autofabrikanten de CAN-berichten? Er zijn aardig wat pogingen ondernomen om de CAN-berichten van diverse automerken te reverse engineeren, omdat die fabrikanten hier niet mee te koop lopen. Wat mij daarbij steeds weer opvalt is dat er niet zo heel veel structuur zit in die berichten. Vaak worden maar relatief weinig berichten (lees: identificatiecodes) ingezet, maar wel met grote datablokken. Dit terwijl er méér dan 2000 identificatiecodes mogelijk zijn. In die datablokken worden veel bits gebruikt om zaken aan en uit te zetten of te monitoren. Zou ik dezelfde strategie volgen, dan heb ik met slechts één CAN-bericht de beschikking over 8 x 8 = 64 bits; méér dan genoeg bits om alle lampen van een Burton aan en uit te schakelen.

Ik moet dus een keuze maken: weinig berichten met relatief veel data, of relatief veel berichten met weinig data. Voorbeeld: het aansturen van het groot licht. Ik kan hiervoor één berichtidentificatie reserveren. Laten we zeggen berichtnummer 100. Dit bericht krijgt één databyte waarvan het eerste bit gebruikt wordt om de lamp aan (bit = 1) of uit (bit = 0) te schakelen. De alternatieve opzet zou zijn om gebruik te maken van twéé berichtnummers - 100 en 101 - beide zonder databytes. Berichtnummer 100 schakelt het groot licht aan en berichtnummer 101 schakelt het groot licht uit. Dat is toch om het even zou je zeggen, en dat is natuurlijk ook zo. Ik neig er trouwens naar om voor de alternatieve opzet te kiezen. Elke 'discrete opdracht' (lees: aan/uit) krijgt zijn eigen berichtnummer zonder datablok. Alleen als iets analoog aangestuurd of uitgelezen wordt, zal het bericht ook één of meerdere bytes bevatten voor de gewenste of actuele waarde.

Nu deze principiële keuze gemaakt is kan ik een lijst met berichtindentificatienummers (3 x woordwaarde) en bijbehorende functies gaan maken, rekening houdend met het feit dat lage nummers voorrang hebben op hoge nummers. Spreadsheetje vullen dus:

Eerste berichten in de lijst.

Het lijstje hierboven is nog heel prematuur. De 16 laagste berichtnummers heb ik nog even open gelaten. Verder zijn er nog wat nummers die niet gebruikt mogen worden:

• 2032..2047: beginnen binair allemaal met zeven enen (111 1111 xxxx). Heeft vast iets te maken met de zeven recessieve stopbits.
• 2015..2031: OBD (On Board Diagnostics) requests en responses. Heb ik niet echt mee te maken, maar toch maar vrij houden.

Blijven er nog ruim 2000 berichtnummers over. Méééér dan genoeg.

De tweede vraag (wat voor apparatuur ga ik toepassen) sluit wel een beetje aan op het vorige. Een van de hoofddoelen van CAN-bus is het reduceren van de hoeveelheid koperdraad in de auto. Het lijkt erop dat vooral de verlichting aangestuurd gaat worden en die zit zo'n beetje op elke hoek van de auto. Verder zitten er veel knoppen en lampjes e.d. bij het dashboard. Een mooie centrale plek. Dus op de volgende locaties komen CAN-nodes:

• Vóórin, onder de motorkap. Misschien eentje rechts en eentje links, of is dat overkill?
• Achterin, in de achterbak. Misschien ook wel eentje rechts en eentje links.
• Centraal, achter het dashboard.
• Mogelijk nog eentje bij het schutbord, onder de motorkap.

Maximaal zes nodes op de bus. En dan een mooi kabeltje daartussen. Bijvoorbeeld de speciale buskabel van Lapp:

Buskabel, maar dan tweedraads.

Doorsnede van de buskabel.

En dan de nodes zelf. Die spreken natuurlijk het meest tot de verbeelding. Een microcontroller is hier op zijn plek. Liefst eentje met een CAN-interface aan boord. Zo is er de PIC18F26K83 van Microchip, een 8-bits controller. Of - aan de andere kant van het spectrum - de ESP32 van Espressif. Zoals de naam al doet vermoeden, een 32-bits controller.

Een van de ESP32-modules.

Deze module wordt aangeboden in veel verschillende varianten en is voor de zelfbouw-hobbyist beschikbaar op een ontwikkelbord. De ESP32 heeft aardig wat mogelijkheden onder de motorkap. Zo is deze microcontroller standaard voorzien van bijvoorbeeld wifi, bluetooth, CAN-bus, I2C, een groot aantal GPIO's en nog enkele interfaces. Het is een dual-core processor met een real-time besturingssyteem (FreeRTOS) aan boord. Multi threaded programmeren wordt zo wel heel 'gemakkelijk'. Hoewel ook hier weer het woord overkill op zijn plaats is, wordt dit 'm. In de volgende variant:

ESP32 DevKit

Zo, de hoofdonderdelen van het CAN-bus-systeem zijn bepaald. In volgende blogberichten komen nog de software en bijbehorende tools aan bod. En misschien ook nog wel wat over de bouw van de Burton zelf, want die is nog lang niet klaar ;-).