[33] Paul Goossens. Elektuur. Seriële poorten onder Windows (met Delphivoorbeeldprogramma)

[33] Paul Goossens. Elektuur. Seriële poorten voorbeeldprogramma). april 2002, p. 70-75.

onder

Windows

(met

Delphi-

[34] Allen Denver. MSDN Library. Serial Communications in Win32 (Files and I/O Technical Articles). 11 december 1995. [35] Reliable Software. Visual C++ Tutorials. URL: http://www.relisoft.com/cpp.html [september 2003] [36] Stef Potters, Arne Vandenberghe. Automatisering van vending machines. Eindwerk 2002-2003, p. 49-60. [37] Laurent Janssen. A/D D/A - Converter voor PCI-kaart. Eindwerk 2002-2003, p. 4658.

110

[15] MicroCANopen.com. http://www.microcanopen.com/ [september 2003] [16] Embedded for CAN

Systems Academy. frame transmission

Worst and best case calculations times and interrupt response times.

URL: http://www.esacademy.com/faq/calc/can.htm [mei 2004] [17] Kvaser AB. URL: http://www.kvaser.com/can/ [september 2003] [18] Kvaser AB. PCIcan Hardware Reference Manual. 26 januari 2002. [19] Website ST Microelectronics. URL: http://www.st.com/. [20] Website Fairchild Semiconductor. URL: http://www.fairchildsemi.com/. [21] Website Newport Components. URL: http://www.dc-dc.com/. [22] Website Infineon. URL: http://www.infineon.com/. [23] Website Cygnal. URL: http://www.silabs.com/index.html. [24] ST Microelectronics. L9615 CAN Bus Transceiver. Datasheet. september 2003. [25] Fairchild Semiconductor. High speed-10 Mbit/s Logic Gate Optocouplers (6N137). Datasheet. september 2001. [26] Newport Components. NMV Series 3kVDC Isolated 1W Single and Dual Output DC/DC Converters. Datasheet. 2001. [27] Siemens/Infineon. Stand-alone Full-CAN Controller SAE81C90/91. Datasheet. januari 1997. [28] Siemens/Infineon. Connecting C166 and C500 Microcontrollers to CAN. Application Note AP2900-v02. juni 1997. [29] Cygnal. C8051F120/1/2/3/4/5/6/7 High-Speed Mixed-Signal ISP FLASH MCU. Datasheet v0.9b. februari 2003. [30] Cygnal. C8051F12x Development Kit. User’s Guide. april 2003. [31] Philips. SJA1000 Stand-alone CAN controller. Product specification (datasheet). januari 2000. [32] Philips. SJA1000 Stand-alone CAN controller. Application Note AN97076. december 1997.

109

Bibliography [1] Bernd vom Berg, Peter Groppe. Elektuur. 80C537-µP-systeem. juni 1997, p. 24-29. [2] Bernd vom Berg, Peter Groppe. Elektuur. De CAN-bus, intelligente datacommunicatie in de praktijk. september 1999 tot januari 2000. [3] Reiner Lock. Elektuur. CAN-bus-interface voor PC’s. juni 2000, p. 58-62. [4] Benoˆıt Bouchez. Elektuur. PC-CAN-interface. december 2000, p. 62-68. [5] K. J. Thiesler. Elektuur. RS485 meets CAN. november 2001, p. 57-59. [6] Svetlana Josifovska. Electronics World. Understanding CAN. oktober 1997, p. 874876. [7] Robert Bosch GmbH. CAN Specification. Version 2.0 (met addendum maart 1997). [8] R. Hulsebos. Veldbussen, Industriële netwerken en hun toepassingen. Kluwer Bedrijfswetenschappen (KLUb), 1993. Hoofdstuk 13 (Controller Area Network). [9] Konrad Etschberger. CAN Controller Area Network - Grundlagen, Protokolle, Bausteine, Anwendungen. Hanser, 2001. [10] Wolfhard Lawrenz. CAN Controller Area Network - Grundlagen und Praxis. H¨ uthig, 2000. [11] CAN-CiA (CAN in Automation). URL: http://www.can-cia.org/ [september 2003] [12] CAN-CiA (CAN in Automation). TTCAN URL: http://www.can-cia.org/can/ttcan/ [april 2004]

(time-triggered

[13] CANbus.us. URL: http://www.canbus.us [september 2003] [14] CANopen.us. URL: http://www.canopen.us [september 2003]

108

CAN).

hardware. De application note van de Philips SJA1000 CAN-controller is vanzelfsprekend niet van toepassing voor de SAE81C90, maar heeft ook een aantal ideetjes opgeleverd voor dit eindwerk. De handleiding [30] van het C8051F120 ontwikkelbord is interessant omwille van de uitleg over de mogelijkheden van het bord en de bijgeleverde ontwikkelomgeving. De handleiding van de PCIcan-kaart van Kvaser [18] vermeld ik voor de volledigheid. Over de programmering in Visual C++ 6.0 waren volgende bronnen noodzakelijk. Het eindwerk van Laurent Janssen [37] bevat een korte uitleg over het gebruik van Visual C++ en de site van Relisoft [35] biedt nog meer hulp en voorbeelden aan over Visual C++. Specifiek voor seriële communicatie verwijzen we naar het eindwerk van Stef Potters en Arne Vandenberghe [36] dat een uitleg en een voorbeeld bevat hierover en naar een artikel uit Elektuur [33]. In de MSDN-bibliotheek is nog wat meer informatie te vinden over de gebruikte Windows-routines voor seriële communicatie [34].

107

tuur [2]. Een andere goede introductie tot CAN is terug te vinden in een application note van Siemens over enkele van hun CAN-componenten [28]. De volledige CAN-specificatie door ISO is nogal moeilijk leesbaar door de specifieke terminologie, maar de specificatie van CAN v2.0 door Bosch [7] is toegankelijker. Op internet circuleren er meerdere versies van dit document. Let er voor op dat je de recentste versie te pakken krijgt, namelijk die uit 1997. De beste boeken over CAN zijn het boek van Konrad Etschberger [9] en dat van Wolfhard Lawrenz [10]. De versies die ik heb gevonden en in de literatuurlijst heb opgenomen zijn de duitstalige versies, maar er bestaan wel degelijk Engelse vertalingen van. Hoofdstuk 13 uit het boek van de nederlandstalige auteur R. Hulsebos gaat ook over CAN [8]. Op het einde van dat hoofdstuk geeft de auteur een aantal valkuilen en verkeerde veronderstellingen mee in verband met het CAN-protocol en zijn implementatie. Ook op het internet is veel informatie te vinden over CAN. De site van Kvaser [17] heeft een uitgebreide, maar toch luchtige behandeling over het protocol. Interessant is ook de pagina met oscilloscoop-afbeeldingen waarop zowel een goed als een slecht functionerende CAN-bus worden getoond. Het is niet makkelijk om een goed overzicht te vinden van de belangrijkste applicatielaag-protocollen. Het overzicht op de site van Kvaser lijkt nog het beste te zijn en bovendien zijn er ook links naar meer informatie voor elk van de besproken protocols. CAN in Automation (CiA) is een overkoepelende organisatie die een schat aan informatie biedt op hun website [11]. Voor een belangrijk deel van de website, moet je betalend lid zijn van CiA, maar de meeste zaken die van nut zijn voor ons zijn vrij beschikbaar. Als startpunt voor een zoektocht naar meer informatie is ook de website van CANbus.us interessant [13]. Hetzelfde geldt voor de site van CANopen.us [14], maar dan specifiek voor het CANopen applicatie-laag protocol. Deze site biedt ook een antwoord op algemene vragen over hoger niveau protocols, maar is natuurlijk gericht op CANopen. Voor de hardware en de software werden volgende bronnen geraadpleegd. De Elektuurreeks van vijf artikels over CAN [2] was de inspiratie voor de originele opdracht van dit eindwerk. Andere artikels uit Elektuur die voorbeelden geven van CAN-realisaties zijn de referenties [3], [4] en [5]. Het artikel uit Elektuur over het 80C537 microcontrollersysteem [1] kan dienen als inspiratie voor een eigen microcontrollerbord. De afgedrukte datasheets van de SAE81C90 CAN-controller [27] en de C8051F120 microcontroller [29] en de application note waarin het gebruik van o.a. de SAE81C90 in uitgelegd wordt, hebben al vrij veel ezeloren door het frequente opzoekingswerk. Deze documenten waren van groot belang bij het realiseren van zowel de hardware als de software van de CANanalyser, terwijl de datasheets van de L9615 CAN-transceiver [24], de 6N137 optocoupler [25] en de NMV0505SA DC-DC converter [26] enkel nodig waren bij het ontwerp van de

106

het verkeer op de CAN-bus en de datasnelheid kan het volstaan wat extra extern geheugen te voorzien voor de microcontroller. Op vlak van hardware kunnen we de microcontroller en de CAN-interface (CANcontroller, CAN-transceiver, . . . ) op één bord zetten. Het voordeel is dat er een bord en een communicatie-kabel wegvalt. Dit betekent dat de kans op communicatieproblemen vermindert en dat het CAN-knooppunt als geheel makkelijker op te stellen en te transporteren is. Normaal gezien zou je verwachten dat we zonder microcontroller-ontwikkelbord meer moeilijkheden zouden hebben om fouten in de programma-code te ontdekken, aangezien de code gedownload wordt in de microcontroller en we vervolgens geen zicht meer hebben op de werking ervan. Met een JTAG-interface op het CAN-interface-bord kunnen we de C8051F120 echter blijven aansturen via de gebruiksvriendelijke Cygnal ontwikkelomgeving. Om te kunnen communiceren met een applicatie op PC-niveau moet de microcontroller een RS232- of een USB-verbinding ter beschikking hebben. Voor RS232 bijvoorbeeld volstaat een sub-D9 connector en een RS232 driver/receiver-chip. Andere uitbreidingsmogelijkheden voor de hardware zijn o.a. extra data- of code-geheugen. Er zou ook kunnen gewerkt worden met een microcontroller die CAN-communicatie als ingebouwde mogelijkheid heeft. Dit heeft vele voordelen, maar we mogen niet vergeten dat dergelijke microcontrollers niet altijd de CAN-mogelijkheden hebben van een Stand-alone CAN-controller zoals pakweg de Philips SJA1000. Een uitbreiding die gemakkelijker gemaakt wordt door het op één bord plaatsen van microcontroller en CAN-controller is het automatisch aansturen van de chip select pin (#CS) van de CAN-controller. Met behulp van wat digitale logica kunnen de adresbits die de microcontroller naat buiten stuurt, gebruikt worden om #CS te bepalen. Voor de microcontroller-code worden de externe geheugentoegangen alvast eenvoudiger. De geheugenmode moet daarbij ingesteld worden zodat alle bits van de adresbus uitgestuurd worden en dit op basis van de inhoud van het EMI0CN-register (geheugenmode “split mode with bank select”). De registers van de CAN-controller bevinden zich dan in een vast adresbereik van 256 bytes in het externe datageheugen wat betreft de microcontroller. Het manuele aansturen van de #CS-lijn valt weg. Dit werd wat uitgebreider besproken in de delen 4.2.2 en 4.2.5. Tot slot gaan we de literatuurlijst overlopen en wat uitleg geven over het nut van elk van de referenties, vooral van diegene die nog niet expliciet gerefereerd werden in de tekst tot hier toe. Voor informatie over het CAN-protocol zijn de volgende referenties interessant. Het artikel [6] uit het Electronics World tijdschrift biedt een eenvoudige inleiding tot het CAN-protocol, net als de eerste twee artikels uit een reeks van vijf uitgaven van Elek-

105

van de bus ontdekt. We kunnen ook zelf sporadisch of periodiek boodschappen op de bus sturen om te bekijken wat er mee gebeurt. Door het versturen van veel CAN-boodschappen kunnen we onderzoeken hoe het systeem reageert op een hogere bus-belasting. Wanneer de prestatieparameters aangeven dat het plafond voor de bus bijna bereikt is, kan er beslist worden om het netwerk te splitsen in twee of meer delen, verbonden door brug- of routercomponenten. Zolang het aantal verschillende boodschap-identifiers niet te groot wordt, kunnen we de werking van meerdere CAN-knooppunten simuleren door één CAN-bus analyser. De SAE81C90 CAN-controller probeert zijn boodschappen te verzenden in volgorde van prioriteit van de identifiers. Dit levert hetzelfde resultaat op alsof meerdere CANcontrollers samen dezelfde verzameling boodschappen proberen te verzenden, omwille van de niet-destructieve arbitrage. Wanneer we ons CAN-knooppunt aansluiten op een systeem dat een applicatielaagprotocol implementeert, moeten we opletten dat we de werking van het systeem niet verstoren. Er moet sowieso opgelet worden dat de ingestelde CAN-bus snelheid correct is en dat we aanvankelijk in luister-mode werken zodat de CAN-controller geen error frames op de bus kan plaatsen. Bij hoger niveau protocols zijn er automatische bepaalde afspraken gemaakt, die niet bekend zijn wanneer we net op het systeem aansluiten. Een hoger niveau protocol kent bijvoorbeeld aan alle knooppunten een pakket boodschapidentifiers toe om te gebruiken. Aangezien de implementatie van ons CAN-knooppunt zich bevindt op de onderste twee lagen van het OSI-model, moet er een manier gevonden worden om problemen te vermijden. Hoger niveau protocols werken tijdsbesparend voor grotere netwerken, maar op ons niveau vormen ze een overbodige extra complexiteit om te implementeren. MicroCANopen is een “lichte” versie van het CANopen-protocol en biedt misschien de mogelijkheid om toch wat met applicatie-laag protocollen te experimenteren [15]. Een nuttige en misschien noodzakelijke mogelijkheid is het inbouwen in de applicatie van een soort zelf-test van het CAN-knooppunt. Het kan zijn dat de CAN-controller niet meer reageert of dat de communicatie tussen microcontroller en CAN-controller gestoord is. Vooraleer het uitvoeren van de initialisatie van de CAN-controller, zou de communicatie met de SAE81C90 kunnen worden getest. Als laatste mogelijke uitbreiding van de software kunnen we het hebben over het buffer waarin we de CAN-boodschappen opslaan bij logging of filtering. Dit buffer heeft een beperkte grootte, namelijk 8 kbyte. Af en toe zou de inhoud van het RAM-geheugen op de microcontroller gekopieerd moeten worden naar de PC-applicatie. Afhankelijk van

104

Hoofdstuk 5 Besluit Het gerealiseerde CAN-knooppunt of de CAN-bus analyser bestaat uit de combinatie van het C8051F120DK microcontrollerbord, het CAN-interface-bord en de software die op de microcontroller draait. Een grafische gebruikersinterface op PC niveau voor interactie met de CAN-bus zou conceptueel ook deel uitmaken van het “CAN-knooppunt”, maar is wegens tijdsgebrek niet voltooid. De demo-applicatie op de microcontroller toont de mogelijkheden van onze CAN-interface. De gedemonstreerde functies kunnen gebruikt worden voor het loggen en analyseren van het verkeer op de CAN-bus. Daarbij kan een bepaalde subset van de boodschappen uitgefilterd worden. Het loggen of filteren kan ook beginnen bij een bepaalde gebeurtenis (een trigger). Dit kan een bepaald bericht op de bus zijn of een extern aan de CAN-interface aangelegd signaal. Met behulp van een buffer kunnen zelfs pre- en posttriggering ge¨ımplementeerd worden. Wanneer we in “listen-only” mode werken, kunnen we controleren of het CAN-systeem waarop we aansluiten naar behoren werkt. Indien we dat wensen, kunnen een heleboel statistieken verzameld worden over de werking van het CAN-systeem. Voor de hand liggend zijn daarbij het aantal ontvangen en verstuurde berichten op de bus, de procentuele bus-belasting, de gemiddelde bericht-lengte, het aantal fouten op de bus. Als de CAN-hardware dit toelaat, kunnen we proberen te weten te komen hoeveel keer de arbitrage verloren werd en hoeveel retransmissies van boodschappen er nodig waren. Met behulp van timestamps kunnen we de responstijd knooppunten en de latentie van boodschappen bepalen. Op die manier kan er gezocht worden naar een optimale verdeling van de boodschap-identifiers aan de CAN-knooppunten. Nog een niet-ge¨ımplementeerde functie is de automatische bit-rate detectie. Dat kan door de CANcontroller op luister-mode en op de hoogste snelheid in te stellen en vervolgens de snelheid te laten dalen tot er geen fouten meer optreden. Dan hebben we de juiste datasnelheid

103

het seriële kanaal in te stellen. De belangrijkste acties in de initialisatie van de seriële communicatie zijn de volgende. Eerst wordt de procedure “CreateFile” toegepast op de handle “seriele poort” met als argument “COM2”. Dit betekent dat de tweede COMpoort verbonden wordt met de variabele “seriele poort”. Daarna wordt deze variabele op zijn beurt verbonden met de DCB-structuur door de procedure “GetCommState”. Na het invullen van alle paramaters van deze datastructuur worden de veranderingen doorgevoerd met de procedure “SetCommState”. Tot slot worden de time-out waarden ingevuld met “GetCommTimeouts” en “SetCommTimeouts”. De andere subroutines zijn korter en eenvoudiger. De procedure om het seriële kanaal te sluiten en te dealloceren gebruikt de procedure “CloseHandle”. De procedures voor het lezen en schrijven van en naar het seriële kanaal gebruiken respectievelijk de procedures “ReadFile” en “WriteFile” met als argument de handle “seriele poort”.

102

4.3

Programma op PC-niveau

Het was de bedoeling om op PC-niveau met Visual C++ 6.0 een grafische applicatie te maken, die kon interageren met een CAN-bus-systeem. Zoals in deel 3.1 en deel 3.1.1 reeds werd uitgelegd, vormde de applicatie-software op PC-niveau de minst grote uitdaging voor mij. Vanuit een puur technisch standpunt brengt een dergelijke applicatie ook niet veel bij aan het hele systeem. De voornaamste voordelen zijn dat de grafische “schil” op PC-niveau de complexiteit van de achterliggende software en hardware verbergt en het gebruiksgemak een stuk verhoogt. Dit is analoog aan wat de CanKing-applicatie doet voor de PCIcan-kaart van Kvaser (cfr. deel 3.5). Het is dan ook logisch dat dit onderdeel van het eindwerk het eerst zou sneuvelen bij een eventueel tijdsgebrek. Gezien de grote opgave is het niet verwonderlijk dat er effectief een tekort aan tijd is geweest en dat de originele opdracht dus niet volledig kon gerealiseerd worden. Een deel van de applicatie werd toch al geprogrammeerd, namelijk de seriële communicatie tussen de PC en de microcontroller. Een Visual C++ programma dat een seriële verbinding opzet met een microcontroller en er een testje mee uitvoert, is terug te vinden op de CD die bij dit eindwerk bijgevoegd is. Daarbij hoort een assembler-programma dat op de microcontroller moet draaien waarmee de PC communiceert. Ook dit programma staat op de CD. Het microcontrollerbordje waarop deze code getest werd, was een Siemens 80C537 bordje, zoals beschreven in Elektuur [1]. Het testprogramma voor de 80C537 werkt normaal gezien ook op elke andere microcontroller van de 8051-familie. We gaan de beide testprogramma’s even overlopen en bespreken. Het testprogramma op de microcontroller doet niet veel meer dan luisteren naar de seriële poort en wanneer er een byte binnenkomt dat overeenstemt met de ascii letter ’A’, wordt een string van drie karakters teruggestuurd, met name ’BCD’. Het testprogramma aan de zijde van de PC zet de seriële verbinding met de microcontroller op en verstuurt een ascii karakter ’A’. Daarna worden de binnenkomende karakters ingelezen en uitgeschreven naar het scherm. Tot slot wordt het kanaal voor seriële communicatie gedealloceerd. Na elke opdracht met betrekking tot het seriële kanaal wordt de exitcode uitgeschreven. Deze geeft aan of er al dan niet fouten opgetreden zijn bij de uitvoering van de opdrachten. Het programma aan de PC-zijde gebruikt voor zijn werking de standaard-windows-routines voor seriële communicatie. Deze worden voorzien door de bibliotheken van de Visual C++ compiler. Het programma heeft drie belangrijke datastructuren. De variabele “dcb” van het type “DCB” is een datastructuur die het seriële kanaal en al zijn aspecten omvat. De “handle” met als naam “seriele poort” is een soort wijzer naar deze datastructuur. De variabele “tout” van het type “COMMTIMEOUTS” dient om de time-out tijden van

101

de hoogst mogelijke waarde volgens het CAN-protocol. Ook de communicatie tussen de microcontroller en de CAN-controller verliep volgens een vrij voorzichtige timing. De datasnelheid op de CAN-bus was bij de meeste testen 100 kbit/s. De applicatie die we in dit hoofdstuk besproken hebben, blijkt echter ook correct te werken bij snelheden van 250 kbit/s, 500 kbit/s en 1 Mbit/s. M.a.w. de maximale snelheid van het CAN-protocol wordt behaald. De timing tussen de microcontroller en de CAN-controller wordt o.a. be¨ınvloed door de kloksnelheid van de microcontroller. De interne oscillator wordt normaal gezien gedeeld door 8. Via het OSCICN-register (internal oscillator control register) kunnen we deze deling opheffen zodat aan de volle kloksnelheid wordt gewerkt. In dit geval werkt de communicatie met de externe CAN-controller nog altijd vlekkeloos. Om de timing van de controlesignalen nog verder te verkorten, passen we het EMI0CF-register en het EMI0TC-register aan, waarvan reeds sprake. De breedte van de ALE-puls kan en mag vier keer korter gemaakt worden dan de standaard timing. De “address setup time” en de “address hold time” mogen drie keer korter gemaakt, maar mogen niet 0 worden. De breedte van de #WR- en de #RD-puls mogen tot vier keer korter gemaakt worden, terwijl ze 16 maal korter zouden kunnen worden ingesteld. We moeten opletten bij het veranderen van de configuratie van de interface naar het externe datageheugen van de C8051F120. Een kleine verandering daarin kan grote veranderingen in de code met zich meebrengen. Veel instructies hebben immers te maken met het lezen of schrijven van of naar het externe datageheugen, en dan vooral van of naar de SAE81C90 CAN-controller. Ook wanneer we de hardware wijzigen zodanig dat de #CSpin van de SAE81C90 automatisch geactiveerd en gedeactiveerd wordt, moeten we de software aanpassen. Het voordeel bij deze wijziging is dat de software er wel eenvoudiger door wordt. Alle instructies die de #CS-lijn manueel instellen, mogen verdwijnen. Een laatste opmerking betreft het aansluiten van ons CAN-knooppunt op een CANbus-systeem dat een applicatielaag-protocol implementeert. Dit soort protocols neemt een deel van het werk van de systeembeheerder uit handen aangezien de verdeling van de identifiers meestal automatisch gebeurt, net als enkele andere instellingen van de CANbus en de CAN-knooppunten. In het CAN-systeem uit dit eindwerk weten we perfect wat de snelheid van de CAN-bus is en wat de verdeling van de identifiers is. We hebben alle instellingen bij gebrek aan een hoger niveau protocol zelf moeten instellen. Wanneer we ons CAN-knooppunt aansluiten op een systeem met een onbekende snelheid en onbekende identifiers zou dat systeem verstoord kunnen raken. Om dit zeker te vermijden, moeten we de CAN-interface op “listen only” mode instellen op zijn minst tot we weten wat de bus-snelheid is.

100

toepassing zijn het deze 8 hoogste bits die bepalen welk extern geheugen we aanspreken. Bij de omschakeling tussen communicatie met de externe CAN-controller enerzijds en het werken met het externe RAM-geheugen op de microcontroller zelf moeten we niet alleen het EMI0CN-register aanpassen. We mogen ook niet vergeten om de #CS-pin te activeren en te deactiveren. Het EMI0CN-register vertelt de microcontroller met welk “geheugen” we communiceren terwijl de #CS-lijn dezelfde taak heeft, maar dan voor de CAN-controller. Een laatste belangrijk software-struikelblok dat we bespreken en dat in werkelijkheid één van de eerste software-problemen vormde, was het bestaan van SFR-pagina’s. Deze staan wel beschreven in de datasheet van de C8051F120 microcontroller, maar dit werd over het hoofd gezien. Bepaalde “special function registers” (SFR’s) die we wilden initialiseren, bevinden zich niet op SFR-pagina 0 die de standaard SFR-pagina is. Bijgevolg ging de correcte configuratie van de microcontroller de mist in. Hieruit vloeide het eerste echt mysterieuze probleem van dit eindwerk voort. Na gebruik van de configuratie-tool van Cygnal (config v2.04) viel op dat het enige verschil tussen de eigen initialisatiecode en de gegenereerde code lag in de SFR-pagina’s. Bij de door de configuratie-tool geproduceerde code werd het SFRPAGE-register telkens aangepast om de correcte registers aan te spreken. De eigen initialisatiecode zocht alle special function registers op SFR-pagina nul. Er moet wel op gelet worden dat het SFRPAGE-register telkens terug op 0 gezet wordt na een toegang tot één van de andere SFR-pagina’s. Elders in het programma en in de interrupt routines verwachten we immers dat het SFRPAGE-register naar de standaard SFR-pagina wijst. Resultaten We hebben reeds aangehaald dat de resultaten voor ons CAN-knooppunt positief zijn. Hier overlopen we nog een aantal speciale situaties. Een eerste punt is de verwerking van extended frames. Dit zijn frames met een identifier van 29 bits en komen overeen met CAN-specificatie v2.0B. De SAE81C90 CAN-controller is 2.0B passief. Dit betekent dat het ontvangen van frames met een uitgebreide identifier geen fouten veroorzaakt aangezien de SAE81C90 berichten met een identifier van 29 bits herkent. Er wordt evenwel nooit op gereageerd omdat dergelijke extended frames gewoon weggegooid worden. Verschillende testen bevestigen dit gedrag. De SAE81C90 slaat nooit in paniek bij het ontvangen van extended frames, maar kan er ook niks mee aanvangen. Aangezien het tot stand brengen van de CAN-communicatie niet van een leien dakje liep, werden bepaalde vereisten afgezwakt. De CAN-bus snelheid lag doorgaans niet op

99

4.2.5

Resultaten en tips

Dit deel komt ongeveer overeen met deel 3.2.5 uit het vorige hoofdstuk. Daar werden de problemen annex oplossingen i.v.m. de hardware besproken en werden een aantal tips gegeven. In dit onderdeel doen we ongeveer hetzelfde voor de software en hebben we het over de resultaten van de applicatie. Uiteindelijk hebben we alle aspecten van de applicatie aan de praat gekregen, zodat we kunnen afleiden dat zowel de software als de hardware als de combinatie ervan naar behoren functioneren. Om tot dit resultaat te komen, moesten nog een aantal valkuilen ontweken en problemen opgelost worden. We overlopen er hier een aantal van, deels als tips om toekomstige fouten te vermijden. Vervolgens behandelen we enkele specifieke aspecten van het eindresultaat, zoals o.a. de ondersteuning voor CAN v2.0b, de haalbare CAN-bus snelheden en het aansluiten van het gerealiseerde CAN-knooppunt op een systeem dat een applicatielaag-protocol implementeert. Problemen en oplossingen Een eerste belangrijk probleem dat door de software veroorzaakt werd, maskeerde een hardware probleem. Om de communicatie tussen de microcontroller en de CAN-controller te testen, werd een rudimentaire voorloper gebruikt van het eerste testprogramma waarvan hierboven sprake. De cruciale fout hierbij was het gebruik van een MOV-instructie i.p.v. een MOVX-instructie. Er werd dus geschreven naar het interne RAM van de microcontroller en niet naar de externe CAN-controller en bij het terug lezen van de data kwamen er nooit fouten voor. Het leek dus enkel alsof het lezen en schrijven van en naar de registers van de CAN-controller correct verliep. Geen wonder dat de SAE81C90 op dat moment zijn werk niet deed zoals verwacht. Het heeft evenwel een hele poos geduurd vooraleer de fout opnieuw gezocht werd in de communicatie tussen de microcontroller en de CAN-controller. Deze stond immers boven alle verdenking door de ogenschijnlijk positieve test. Het vergeten van de X bij de MOV-instructie lijkt in deze context een domme fout, maar het is me in de loop van de tijd nog meerdere keren overkomen. Daarom is het niet slecht om bij problemen of eigenaardige resultaten eerst te controleren of er geen fout gemaakt werd bij het werken met de externe data-interface. Naast het vergeten van de MOVX-instructie moet er ook op gelet worden dat de werkingsmode van de interface naar het externe “geheugen” wel correct ingesteld staat. De vier werkingsmodes werden in deel 3.4 besproken. Een ander mogelijk probleem is een verkeerde invulling van het EMI0CN-register dat de 8 meest significante bits van het externe data-adres bevat. In onze

98

wanneer een bericht geen databytes bevat. Dan moeten enkel de descriptor registers opgeslagen worden, zoals altijd voorafgegaan door een byte dat het aantal databytes aangeeft, in dit geval 0.

4.2.4

Testprogramma’s

In de loop van de tijd zijn er een aantal testprogramma’s gemaakt, waarvan er twee op de CD terug te vinden zijn. Het eerste programma test de communicatie tussen de microcontroller en de CAN-controller. Eerst worden twee schrijf-operaties uitgevoerd naar twee verschillende registers van de CAN-controller. Na een korte wachttijd worden deze opnieuw gelezen van de SAE81C90 en wordt het resultaat vergeleken met wat er geschreven werd. Als beide waarden gelijk zijn wordt de teller R6 verhoogd. Bij een fout wordt de teller R7 verhoogd. Op die manier kunnen we controleren of er fouten optreden. De waarde in register R7 moet onder alle normale omstandigheden op 0 blijven staan. We moeten wel opletten dat we niet te vlug conclusies trekken uit wat de software ons vertelt. Een concreet probleem was dat bij het gebruiken van andere waarden om weg te schrijven naar de CAN-controller het aantal optredende fouten enorm schommelde. Bij sommige waarden traden er meer fouten op dan correcte schrijf-lees-cycli en bij andere data traden dan weer helemaal geen fouten op. De overspraak die er toen nog tussen de lijnen was, bleek erger door te wegen bij sommige bitpatronen dan bij andere. Zoals we in het volgende deel (4.2.5) zullen vertellen, kan er overigens ook een fout zitten in de geprogrammeerde code waardoor het enkel maar lijkt dat de hardware correct werkt. Het tweede testprogramma gaat over het echte werk, namelijk het testen van de communicatie via de CAN-bus. Het programma is vrij rudimentair. Eerst wordt een CAN-boodschap met identifier 31 verzonden door ons CAN-knooppunt. Daarna blijft het programma wachten op een boodschap met identifier 21 en leest het een aantal databytes van die boodschap ter controle. Met de PCIcan-kaart konden we controleren of de verzonden boodschap correct op de CAN-bus kwam. Daarna verstuurden we via het monitor programma van Kvaser een boodschap met identifier 21 en een aantal databytes terug naar ons eigen CAN-knooppunt. Na het verhelpen van het communicatieprobleem tussen de microcontroller en de CAN-controller raakten de problemen met de rest van de CAN-interface relatief vlug opgelost.

97

is tussen de identifier van de boodschap en de gewenste identifier. Daarna wordt met een AND-bewerking een masker gelegd op het resultaat van de XOR-bewerking. Op die manier kunnen we aangeven dat bepaalde bits van de identifiers niet van belang zijn voor de filtering en is het mogelijk om een bepaalde groep identifiers uit te filteren. Wanneer de binnengekomen boodschap voldoet aan de eisen van het filter springen we naar het logging-gedeelte, anders wordt de routine beëindigd. Wanneer we een bericht loggen, slaan we achtereenvolgens het aantal databytes op in een eerste byte, de descriptor registers (met identifier, RTR en datalengte) in de volgende twee bytes en tenslotte alle databytes. Het aantal databytes zit ook vervat in de descriptor registers, maar wordt nog eens afzonderlijk opgeslagen om de verwerking en de interpretatie van de opgeslagen boodschappen makkelijker te maken. Aangezien we de CAN-controller en het externe RAM-geheugen van de microcontroller niet op hetzelfde moment kunnen aanspreken, moeten we een omweg maken bij het loggen van de boodschappen. We slaan de boodschap tijdelijk op in het interne RAM op adres 20 tot 2A (hexadecimaal). Het is hierbij van belang dat we eerst het hoogste byte van het message object lezen. Zoals reeds meerdere malen aangehaald, is er een schaduwregister dat de toegang regelt tot de inhoud van de databytes van alle message objects. De bedoeling hiervan is de consistentie van de gelezen databytes te garanderen. Enkel wanneer we byte 7 (het hoogste byte) van een message object lezen, wordt het schaduwregister aangepast met de laatste waarden van de databytes. Er werd dieper ingegaan op de reden hiervoor in het onderdeel “geheugenruimte berichten” in het deel 3.3. De interface naar het externe datageheugen wordt nu omgeschakeld om het externe RAM tussen 0 en 8 kbyte te adresseren. Bij het doorkopiëren van de boodschap naar het externe RAM worden de registers R6 en R5 respectievelijk als meest en als minst significante byte gebruikt van het eerste vrije adres in het externe log-buffer. De registers R6 en R5 vormen als het ware een pointer naar de vrije ruimte in het log-buffer. Deze “pointer” wordt in het begin van het hoofdprogramma ingesteld op adres 100 (hexadecimaal) en schuift telkens verder op. Bij het einde van het doorkopiëren, laten we via het EMI0CN-register de externe geheugen-interface opnieuw naar de CAN-controller wijzen. We hebben de keuze gemaakt om EMI0CN in onze applicatie standaard te laten wijzen naar de CAN-controller en houden ons consequent hieraan. Overal in de code waar we het externe RAM-geheugen op dat moment niet aanspreken, moet EMI0CN dus op 20 (hexadecimaal) ingesteld worden. Tot slot wordt het RR-bit (receive ready bit) van message object 0 gewist. Zoals vaak in dit programma worden een aantal details nog beter toegelicht in het commentaar bij de code zelf. Daarbij gaat het dan bijvoorbeeld over het speciale geval

96

In principe zou er een soort zelfcontrole moeten komen om te achterhalen of het CANknooppunt waarop de code draait niet defect is. In dat geval omzeilen we immers de bepaling van het CAN-protocol dat een CAN-knooppunt dat zich niet goed gedraagt van het CAN-systeem moet verwijderd worden. Het kan ook dat het hele CAN-netwerk in de soep gedraaid is en ook dan is het niet nuttig om telkens terug op de bus te komen. Wanneer we te vaak in de bus-off toestand terechtkomen, moeten we onze conclusies trekken en het CAN-knooppunt definitief van de bus verwijderen. De huidige versie van de code is zich op dat vlak van geen kwaad bewust. Op het einde van de interrupt service routine herstellen we de originele waardes van de registers A, R0 en R2 door ze van de stack te halen. We beëindigen de interruptverwerking en springen terug naar het punt van de code waar de interrupt was opgetreden met de RETI-instructie. Ontvang interrupt De code voor de subroutine die de ontvang interrupt verwerkt, bevindt zich tussen de code van het hoofdprogramma en die van de (algemene) interrupt service routine ISR0. De verwerking van deze interrupt vergt meer werk dan de andere interrupts en daarom behandelen we deze subroutine afzonderlijk. We herhalen nog even dat deze routine opgeroepen wordt door de algemene interrupt service routine. De structuur wordt weergegeven in het stroomdiagram in figuur 4.4. Bij het begin van de verwerking van een binnengekomen bericht kijken we eerst of het gaat over een boodschap met als identifier 25, 26 of 27. Deze worden ontvangen door respectievelijk message objects 1, 2 en 3. In elk van die gevallen wordt de overeenkomstige verzendvlag ingesteld. Dit zijn de laagste bits van register R7. Het RR-bit (receive ready bit) dat bij het message object hoort, wordt terug op 0 gezet. Alle andere CAN-boodschappen worden opgevangen door message object 0. Afhankelijk van de waarde van de constante LOG FIL, gedefinieerd bij het begin van het programma, zullen we geen, alle of sommige berichten opslaan in het 8 kbyte grote externe RAM-geheugen van de microcontroller. Eerst wordt gecontroleerd of de constante de waarde 0 heeft. In dat geval springen we naar het label niet loggen en zetten we het RR-bit van message object 0 op nul. Van daar springen we dan verder naar het einde van de verwerkingsroutine. De controle of de LOG FIL-constante gelijk is aan 1 gebeurt door er 1 van af te trekken en vervolgens te kijken of het resultaat 0 is. Als dat zo is, springen we naar het label logging. In het andere geval komen we terecht in het stuk code met als label filtering. In dit stuk passen we filtering toe op de descriptor registers van de binnengekomen boodschap. Met een XOR-bewerking wordt gekeken of er een verschil

95

om te controleren of één van de andere verzendvlaggen ondertussen op 1 gekomen is. Het einde van het hoofdprogramma bestaat uit de oneindige lus einde: JMP einde en wordt normaal nooit bereikt. Dit is een soort ingebouwde veiligheid van het programma om geen code uit te voeren die zich na het programma bevindt. Deze plaats in het codegeheugen kan immers om het even wat bevatten. Verwerking interrupts De interrupts van de CAN-controller arriveren op de microcontroller via de #INT0-lijn. Ze worden dan ook verwerkt door de interrupt service routine voor deze interruptbron (label ISR0). Deze code bevindt zich op het einde van het programma. Het eerste wat gebeurt is het opslaan van een aantal registers die in de interrupt routine gebruikt zullen worden. Dit zijn de accumulator (register A) en de registers R0 en R2. De inhoud van deze registers moet bewaard worden, aangezien de interrupts volledig transparant moeten zijn voor het hoofdprogramma. Het hoofdprogramma kan eender waar onderbroken worden en mag dat niet merken. Het eerste echte werk dat de interrupt service routine zal doen, is het lezen van het INT-register van de CAN-controller en de inhoud ervan wegschrijven naar register R2. Dit register geeft de reden aan voor het ontstaan van de interrupt. Aangezien er nieuwe interrupts kunnen optreden in de SAE81C90 en het INT-register dus kan van waarde veranderen, moeten we van de huidige waarde een kopie maken. Op die manier weten we welke interrupt het eerst opgetreden is. Bovendien sparen we wat tijd uit omdat we het INT-register niet telkens moeten lezen van de CAN-controller. Dit is belangrijk omdat de interrupt routine zo vlug mogelijk moet afgelopen zijn om nieuwe interrupts een kans te geven. De rest van de interrupt routine bestaat uit opeenvolgende controles van de verschillende mogelijke interrupt-bronnen. Voor de verzend en de ontvang interrupt wordt een subroutine opgeroepen om de verdere verwerking te doen. Voor de verzend interrupt betekent dit in deze applicatie niet veel meer dan het vaststellen van de succesvolle verzending van een CAN-boodschap en het resetten van de overeenkomstige interrupt-vlag. De subroutine voor de ontvang interrupt is wat complexer en bespreken we straks in een afzonderlijk deel. Bij een remote frame interrupt zetten we de interrupt-vlag gewoon weer op 0. Voor de warning level en de error passive interrupts hebben we geen speciale maatregelen ge¨ımplementeerd. Bij de bus-off interrupt springen we terug naar het begin van het programma en herinitialiseren we zowel de microcontroller als de CAN-controller. Om de fouttellers van de CAN-controller terug op 0 te laten komen en dus terug op de bus te mogen, moet de SAE81C90 128 keer 11 opeenvolgende recessieve bits detecteren.

94

site een klein programma aan om de vereiste registerwaarden te laten berekenen. Dit programma staat op de CD en een eventueel recentere versie kan gezocht worden met de zoektermen “CAN bit timing calculation SAE81C90”. Het OC-register (output control) wordt ingesteld zodat zowel de negatieve als de positieve output transistor actief zijn. Dit komt overeen met push-pull werking van de pinnen. De CLKOUT-pin wordt gedeactiveerd. De waarde van RIMR-registers (receive interrupt mask register) bepaalt dat enkel de message objects 0, 1, 2 en 3 interrupts genereren wanneer ze een boodschap ontvangen hebben. De message objects zelf worden eerst allemaal ingevuld op de hoogste identifier waarde. Dit komt overeen met de laagste prioriteit en we veronderstellen dat deze identifier niet zal voorkomen in het CAN-systeem. In het daaropvolgende stuk code initialiseren we de descriptor registers en de databytes van message objects 1 tot en met 7 op die waarden die het gedrag besproken in deel 4.2.1 realiseren. Zoals we aangehaald hebben in het onderdeel “geheugenruimte berichten” in deel 3.3 moeten we een bepaalde volgorde respecteren bij het schrijven van de databytes om de consistentie van de data te garanderen. Message object 0 wordt bij het begin van de initialisatie geconfigureerd als basic-CAN ontvangstbuffer. Daartoe werd het MM-bit (monitor mode) geactiveerd. Basic-CAN werking houdt in dat alle berichten ontvangen worden door één buffer zonder enige hardware-filtering. De monitor mode van de SAE81C90 gelijkt op basic-CAN, in die zin dat alle berichten die nog niet door een ander message object behandeld werden, terechtkomen in de geheugenplaats van message object 0. De eventuele filtering moet dan nog door de software uitgevoerd worden. Bij deze applicatie zal dit gebeuren in de verwerkingsroutine van de ontvang interrupt. Hoofdprogramma De structuur van het hoofdprogramma hebben we reeds bekeken en besproken in deel 4.2 aan de hand van het stroomdiagram in figuur 4.2.1. In een kort initialisatiestukje worden de verzendvlaggen in register R7 gewist. Register R6 en R5 vormen samen het startadres voor het log-buffer waarin we de ontvangen boodschappen zullen schrijven. De log-functionaliteit zit vervat in de code voor de verwerking van de ontvang interrupt. Tot slot wordt het globale interrupt bit (EA) geactiveerd. Voor elk van de drie verzendvlaggen is er een stuk code dat een CAN-boodschap verzendt. In elk van die stukken worden dezelfde operaties uitgevoerd. De externe interrupt wordt tijdelijk afgezet om problemen te vermijden. De #CS-lijn wordt eveneens tijdelijk geactiveerd om het overeenkomstige TRS-bit (transmit request set) op 1 te plaatsen. De externe interrupt wordt terug geactiveerd en de verzendvlag wordt op 0 gezet. Daarna keren we terug naar de polling-lus

93

bevinden zich op SFRPAGE #0Fh. Het concept van de SFR-pagina’s werd besproken in deel 3.4. Nadat alle registers ingesteld zijn, plaatsen we het SFRPAGE-register terug op zijn oorspronkelijke standaard-waarde (nul). Onder andere op dit punt in de code is het van groot belang dat de interrupts van de microcontroller niet actief zijn. Een interrupt kan om het even wanneer optreden en veronderstelt in deze applicatie dat de huidige SFR-pagina wijst naar de standaard pagina. Wanneer de SFRPAGE-waarde niet correct is, kan dit voor problemen zorgen. Het alternatief zou zijn om de interrupt service routine een backup te laten maken van de inhoud van het SFRPAGE-register door hem op de stack te plaatsen. Dat vertraagt de kritische interrupt-code nog wat meer en is in deze applicatie bovendien overbodig. Het is eenvoudiger om de interrupts gewoon te deactiveren tijdens de initialisatie-stukken. Een oudere versie van de applicatie gebruikte de configuratie-tool van Cygnal (config v2.04) om de initialisatie van de microcontroller uit te voeren. Met dat programma kunnen we de microcontroller configureren zonder naar de datasheet te moeten kijken. Het configuratie-programma zorgt ervoor dat alle registers met de correcte waarden ingevuld worden. Voordat de door dit programma geproduceerde assembler-code ge¨ıncludeerd wordt, moeten er nog enkele kleine aanpassingen gebeuren. De code bevat immers naast de initialisatie van de registers ook het geraamte voor een programma. Enkel het invullen van de registers is voor ons nuttig. Het is overigens toch beter om de instelling van de registers zelf te doen aan de hand van de datasheet omdat je dan ook beter weet wat er echt aan de hand is. De configuratie-tool kan gebruikt worden om eventuele fouten in de eigen initialisatiecode op te sporen. Initialisatie CAN-controller Bij de aanvang en het einde van de initialisatiecode voor de CAN-controller moet op een aantal zaken gelet worden. Het eerste wat we doen is de reset-pin van de CAN-controller deactiveren. De #CS-pin (chip select) wordt op een laag (actief) niveau geplaatst en na het initialisatie-stuk terug op een hoog niveau. De registers MODE en CTRL worden zo ingevuld dat er een harde software reset optreedt. Enkel in deze mode kunnen bepaalde registers van de CAN-controller beschreven worden. Na afloop van de initialisatie plaatsen we het MODE-register in de normale werkingsmode. De controleregisters van de CAN-controller werden behandeld onder de gelijknamige titel in deel 3.3. Hier overlopen we kort even welke registers we initialiseren en waarom. De datasnelheid van de CAN-bus werd gekozen op 100 kbit/s en het samplingpunt op 56,25 % bij een klokfrequentie van 16 MHz. Zoals vermeld biedt Infineon op zijn web-

92

Na het label main: begint de echte initialisatiecode van de microcontroller. Deze code bestaat uit 5 delen. Eerst wordt de watchdog timer uitgeschakeld. Deze kan van belang zijn in een toepassing die continu moet blijven werken. In deze applicatie kunnen we de microcontroller gemakkelijk resetten wanneer de code vastloopt en bijgevolg is de watchdog timer overbodig. Het tweede deel van de initialisatie gaat over de seriële communicatie met de PC. Deze code is in commentaar geplaatst omdat er geen applicatie op de PC gerealiseerd werd. Daarna worden de interrupt-maskers ingevuld en de interruptvlaggen op 0 gezet. We wachten nog met het EA-bit (global interrupt enable) te activeren tot de initialisatie van zowel de microcontroller als de CAN-controller voltooid zijn. Bij het begin van het hoofdprogramma wordt dit bit op 1 gezet. Als vierde in de rij initialiseren we de registers voor de toegang tot het externe datageheugen. We kiezen voor een gemultiplexte adres/databus op poorten P0 tot P3 met als werkingsmode “split mode without bank select”. Deze werkingsmodes werden besproken in het vorige hoofdstuk in deel 3.4 en de mode die we hier gebruiken werd nog eens nader toegelicht in het voorgaande deel (4.2.2). De keuze voor de mode zonder “bank select” i.p.v. de mode met “bank select” is gemaakt omdat we de hoogste 8 adresbits toch niet zouden gebruiken indien ze zouden uitgestuurd worden. De timing van de controlesignalen wordt op de maximale breedte ingesteld. Het EMI0TC-register werd niet ingevuld omdat de standaard waarde in dit register sowieso al overeenkomt met de breedst mogelijke timing-pulsen. Het EMI0CN-register werd ingevuld met de hexadecimale waarde 20. Dit betekent dat niet het externe datageheugen op de microcontroller zelf geadresseerd wordt, maar wel de externe (geheugen-)component, meer bepaald de SAE81C90 CAN-controller (adres 2000 hexadecimaal). In de applicatie zullen we EMI0CN consequent op deze waarde houden. Wanneer we het externe RAM willen adresseren, veranderen we de inhoud van dit register even en herstellen achteraf dan meteen de originele waarde. Als vijfde en laatste initialisatie wordt de “priority crossbar decoder” ingesteld, zodat de pinnen van de poorten P0 en P3 de juiste functies en werking hebben. Deze poorten worden gebruikt voor de communicatie met de CAN-controller. Het grootste deel van de vereiste pinnen werd al naar buiten gebracht door de instellingen voor de externe geheugen-interface hierboven. Hier brengen we nog de #INT0-pin en de ALE-pin naar buiten. De werking van de poorten wordt ingesteld op open-drain en de spanning op de pinnen op een hoog niveau (3,3V). De pinnen moeten werken als open-drain om conflicten met de uitwendig op het CAN-interface-bord aangebrachte pull-up weerstanden te vermijden. Tenslotte wordt het XBR2.6-bit op 1 geplaatst. Pas wanneer dit gebeurd is, worden de crossbar en dus ook de poortpinnen geactiveerd. De registers die instaan voor de configuratie van de crossbar

91

4.2.3

Bespreking applicatie

In de volgende 4 deeltjes behandelen we de vier onderdelen van de applicatie zoals voorgesteld in het stroomdiagram in figuur 4.1. Elk van die 4 deeltjes komt overeen met een rechthoek in het diagram. Het vijfde deeltje van de bespreking geeft wat meer toelichting over de subroutine voor de verwerking van de ontvang interrupt. Deze subroutine is wat complexer en wordt daarom afzonderlijk bekeken. Ze komt voor in stroomdiagram 4.3 en de interne flow wordt verder uitgewerkt in figuur 4.4. De applicatie-code is in zijn geheel op de CD terug te vinden die bij dit eindwerk bijgevoegd is. Bepaalde details zoals exact welke bits van een register voor welke functie dienen, zijn grondiger gedocumenteerd in de code zelf. Hier doen we een bespreking van de code in mensentaal. Initialisatie microcontroller De eerste regels van het code-bestand tonen de definitie van de registernamen. De voorgedefinieerde standaard 8051 microcontroller-registers worden weggegooid en vervolgens worden de registers voor de SAE81C90 CAN-controller en de C0851F120 microcontroller ingeladen. Voor de registers van de SAE81C90 was er nergens een geschikte include-file te vinden. Om toch gemakkelijk te kunnen werken met deze registers werd dan maar een eigen include-bestand gemaakt om de namen van de SAE81C90-registers te vertalen in de adressen ervan. Dit bestand staat vanzelfsprekend ook op de CD. De adressen van de registers in het include-bestand zijn dezelfde als de adressen in de datasheet van de CAN-controller. Het adresbereik gaat dus van 0 tot 255, terwijl de microcontroller deze registers verwacht in het bereik vanaf adres 2000 tot 20FF hexadecimaal (8 kbyte tot 8 kbyte + 256 bytes). Dit is geen probleem aangezien we telkens met een 8-bit MOVXinstructie werken (MOVX A,@R0; MOVX @R1,A; ...). De hoogste 8 bits (en dus de keuze tussen CAN-controller en extern RAM) worden bepaald door het EMI0CN-register. Op de daaropvolgende regels worden een aantal constanten gedefinieerd. Deze constanten vormen een soort hardgecodeerde parameters voor de werking van de applicatie. De constante LOG FIL bepaalt of we de CAN-boodschappen gaan loggen, filteren of geen van beide. De overeenkomstige waarden voor LOG FIL zijn 1, 2 en 0. Bij filtering wordt een filter-masker en een filter-code toegepast op de descriptor registers van het binnengekomen message object. De filter-code bepaalt waarmee de descriptor registers moeten overeenkomen om aanvaard te worden. Het filter-masker op zijn beurt bepaalt welke bits uit de filter-code gebruikt zullen worden bij het filteren. De bitposities in het masker waar er een 0 staat, zijn posities in de descriptor registers waarvoor het niet uitmaakt welke waarde er staat.

90

De stack van de C8051F120 microcontroller bevindt zich in het interne RAM-geheugen en begint op adres 8. Dit komt overeen met register R0 in registerbank 1. Wanneer we meerdere registerbanken willen gebruiken naast registerbank 0 moeten we dus goed opletten dat de stack niet overschreven raakt. In dat geval initialiseren we de stack beter op een andere plaats in het interne RAM. De stack kan groeien tot aan het einde van de adresruimte van het RAM en kan dus in principe een maximale diepte hebben van 256 bytes. Elke oproep naar een subroutine plaatst twee bytes op de stack, namelijk het terugkeeradres van de subroutine. Na afloop van de subroutine worden deze twee bytes gebruikt als doeladres om naar toe te springen zodat het programma kan verderlopen vanaf de plaats waar de oproep gedaan werd. De C8051F120 microcontroller heeft een adresruimte voor het externe datageheugen van 64 kbyte. De toegang tot het 8 kbyte grote externe RAM-geheugen en tot de registers van de CAN-controller gebeurt telkens via deze zelfde adresruimte. Er zijn vier mogelijke werkingsmodes voor de toegang tot de externe data-adresruimte zoals besproken in het vorige hoofdstuk in deel 3.4. In onze opstelling gebruiken we de “split mode without bank select”. Dit betekent dat afhankelijk van de hoogste 8 bits van het 16-bit adres de microcontroller enerzijds leest en schrijft van en naar het externe RAM op de microcontroller zelf of anderzijds het adres en de controlesignalen op zijn pinnen naar buiten laat komen. De hoogste 8 bits worden daarbij niet uitgestuurd. Wanneer we deze 8 meest significante bits wel zouden meesturen en wat decodeerlogica voorzien, kunnen we de #CS-pin van de CAN-controller automatisch laten aansturen. De decodeerlogica moet de #CS-pin laag trekken wanneer we communiceren met de CAN-controller. M.a.w. de logica moet als uitkomst een laag signaal geven als het adres dat uitgestuurd wordt zich in het adresbereik bevindt (256 bytes) waarop de registers van de CAN-controller geprojecteerd zijn. In onze applicatie gebeurt deze mapping op het adresbereik 2000h tot 20FFh (hexadecimaal, vanaf 8 kbyte tot 8 kbyte + 256 bytes). De werkingsmode van de externe geheugentoegang van de microcontroller moet dan wel ingesteld worden op “bank select” zodat de hoogste 8 adresbits ook uitgestuurd worden. In de code die we zullen bespreken, gebeurt het activeren en deactiveren van de #CS-pin van de CAN-controller manueel. Dit maakt de code wat gevoeliger voor programmeerfouten. Bij de overschakeling tussen communicatie met het externe RAM en communicatie met de CAN-controller moeten we telkens ook het EMI0CN-register aanpassen. Dit register bevat de 8 meest significante bits van het externe datageheugen adres. Hier kunnen we niet onderuit. In tegenstelling tot het aansturen van de #CS-pin kan deze omschakeling niet automatisch gebeuren.

89

eerst of het overeenkomstige “transmission request” bit wel op 0 staat. Als dat niet zo is, stoppen we het bericht dat we wensen te verzenden in een tijdelijk buffer en zetten we een bepaalde vlag op 1 om aan te geven dat er nog berichten te verzenden zijn. Wanneer de verzending van het oorspronkelijke bericht geslaagd is, treedt er een verzend interrupt op. Wanneer de verwerkingsroutine voor deze interrupt merkt dat de vlag waarvan sprake op 1 staat, wordt het bericht dat we wilden verzenden uit het tijdelijke buffer gehaald en in het message object gestopt. Tevens wordt het “transmission request” bit weer op 1 geplaatst. Op deze manier kan een boodschap die nog niet verzonden is, beschermd worden. Als we de applicatie interactief zouden willen maken via RS232 communicatie met een PC, moet de structuur van het programma aangepast worden. Het hoofdprogramma zou een oneindige lus blijven met als voornaamste doel te luisteren naar wat de PC zegt. Wanneer een opdracht van de PC binnenkomt, wordt deze verder verwerkt in subroutines. Het grootste deel van de CAN-functies zal echter in de interrupt routines gerealiseerd worden. Kortom, de beste structuur voor een dergelijk programma is via polling naar de PC toe en met behulp van interrupt routines naar de CAN-bus toe. Ook de hardware legt een aantal beperkingen op. Met de Philips SJA1000 CANcontroller is het gemakkelijker om een overflow-situatie te detecteren. Hiertoe heeft de SJA1000 een afzonderlijke “data overrun” interrupt. Zoals besproken in het vorige hoofdstuk heeft de SJA1000 nog een aantal andere extra mogelijkheden op vlak van fout-analyse en foutafhandeling. Deze kunnen voor een extra belasting zorgen voor de microcontroller, wat misschien ongewenst is.

4.2.2

Bijzonderheden van de SAE81C90 en de C8051F120

In hoofdstuk 3 werd de SAE81C90 CAN-controller zowel vanuit hardware-oogpunt (deel 3.2.2) als vanuit software-oogpunt (deel 3.3) bekeken. In dit deel halen we een aantal bijzondere details aan over deze CAN-controller die blijken bij het gebruik ervan en die niet altijd in de datasheet terug te vinden zijn (of op zijn minst toch goed verborgen zijn). De eerste bijzonderheid is dat wanneer alle “receive ready” bits via software terug op 0 gezet zijn de “receive interrupt” vlag van de CAN-controller automatisch eveneens terug op 0 komt. Wanneer in de CAN-controller geen andere interrupts actief zijn, wordt de #INTpin hoog (niet actief dus). In dat geval betekent het resetten van het “receive ready” bit dat ook het IE0-bit (externe interrupt 0) in het TCON-register van de microcontroller automatisch op 0 gezet wordt. Hierbij veronderstellen we dat de CAN-controller en de hardware verbonden zijn zoals beschreven in het vorige hoofdstuk.

88

Figuur 4.4: Stroomdiagram ontvang interrupt. 2 wordt de identifier van de binnenkomende CAN-boodschap eerst vergeleken met het ingestelde filter (eveneens een constante bij het begin van het programma). Op basis daarvan wordt beslist of logging al dan niet toegepast wordt. Mogelijke uitbreidingen De demo-applicatie zoals we ze beschreven hebben, heeft een aantal beperkingen. Het verzenden van de boodschappen gebeurt in het hoofdprogramma, maar houdt geen rekening of het bericht dat zich in een bepaald message object van de CAN-controller bevindt reeds verzonden is. Het programma zou dus als volgt uitgebreid kunnen worden. Wanneer we in het hoofdprogramma beslissen om een bericht te verzenden, controleren we

87

Figuur 4.3: Stroomdiagram interruptverwerking. achtereenvolgens gecontroleerd of één van de eerste drie message objects (MO1, MO2 en MO3) een boodschap ontvangen heeft. Deze drie message objects werden ingesteld om berichten te ontvangen met als identifiers 25, 26 en 27. Als dat het geval is, wordt een verzendvlag actief gemaakt en wordt de interrupt-routine beëindigd. De term “LOG FIL” slaat op een constante die bij het begin van de applicatie gedefinieerd is. Wanneer deze op 0 staat, wordt er geen logging of filtering toegepast. Wanneer “LOG FIL” de waarde 1 bevat, worden alle boodschappen die niet opgevangen werden door MO1, MO2 of MO3 opgeslagen in het externe RAM-geheugen van de microcontroller. Voor een waarde van

86

Figuur 4.2: Stroomdiagram hoofdprogramma. de CAN-controller die dan verder verwerkt worden door de interrupt service routines. De initialisatie-code zullen we verder bespreken in deel 4.2.3, net als het hoofdprogramma en de interrupt-verwerking. De structuur van het hoofdprogramma is weergegeven in figuur 4.2 en de interrupt-verwerking verloopt in grote lijnen zoals in figuur 4.3. Zoals vermeld bestaat het hoofdprogramma uit een oneindige lus. Er wordt telkens gecontroleerd of één van de vlaggen in register R7 verschilt van nul. Als dat zo is, wordt gecontroleerd welke van de drie vlaggen actief is en wordt het overeenkomstige “message object” verstuurd. De message objects 4, 5 en 6 worden in de initialisatie ingesteld met als identifiers respectievelijk 28, 29 en 30 en als databytes degene die we hierboven aangehaald hebben. De interrupt service routine is eigenlijk niet meer dan een geraamte waarin de ene na de andere mogelijke interrupt-bron gecontroleerd wordt. Bij het identificeren van de interrupt-bron wordt dan een oproep gedaan naar de procedure die de verdere verwerking doet voor dat bepaalde type interrupt. De rest van de code wordt uitgebreider behandeld in deel 4.2.3. Hier gaan we enkel nog even in op de structuur van de procedure die de ontvang interrupt verwerkt. Deze interrupt treedt op bij het ontvangen van om het even welk data frame en de verwerkingsprocedure is wat complexer dan de andere onderdelen van het programma. De structuur van deze verwerkingprocedure wordt afgebeeld in figuur 4.4. Bij het begin van de procedure wordt

85

Figuur 4.1: Stroomdiagram applicatie (hoogste niveau). zelf. Wanneer we gekozen hebben voor filtering, wordt voor elk bericht eerst gecontroleerd of de identifier wel voldoet aan het filter. Als dat zo is, wordt het eveneens in het externe RAM van de microcontroller opgeslagen. In het hoofdprogramma worden de drie vlaggen waarvan daarnet sprake voortdurend gecontroleerd. Wanneer vlag 1 actief is, wordt een boodschap op de CAN-bus geplaatst met als identifier 28 en databytes 10, 20 en 30 (hexadecimaal). Vlag 2 komt overeen met het versturen van een boodschap met als identifier 29 en databytes 40 en 50 en voor vlag 3 is dit identifier 30 en databytes 60, 70, 80 en 90 hexadecimaal. De drie vlaggen worden bijgehouden in de onderste drie bits van register R7. De applicatie is zo ingesteld dat bij het ontvangen van een remote frame met identifier 16 een dataframe teruggestuurd wordt (met identifier 16 vanzelfsprekend), met als inhoud één databyte, namelijk 238 (hexadecimaal EE). Het testen van de applicatie kan bijvoorbeeld gebeuren met de PCIcan-kaart van Kvaser (cfr. deel 3.5). Stroomdiagramma We zullen de structuur van de applicatie bekijken aan de hand van een aantal stroomdiagramma. Figuur 4.1 toont in grove lijnen de structuur van de volledige applicatie. Na de start van het programma wordt eerst de microcontroller ge¨ınitialiseerd en daarna de CAN-controller via de parallelle interface tussen beide controllers. Het hoofdprogramma bestaat uit een oneindige lus. Tegelijkertijd kunnen er interrupts optreden afkomstig van

84

ageren op opdrachten van op het PC-niveau. We stippen daarbij aan dat ook de hardware voor een stuk de mogelijkheden een beetje beperkt. Zo biedt een CAN-controller zoals de SJA1000 nog een aantal leuke extra functies. Vervolgens bekijken we een aantal specifieke bijzonderheden van de SAE81C90 CAN-controller en de C8051F120 microcontroller, die nog niet aan bod waren gekomen bij de algemene bespreking van deze componenten in het vorige hoofdstuk, maar die van belang zijn voor het schrijven van de microcontroller-code. Daarna onderzoeken we de code zelf, onderverdeeld in vijf delen die overeenstemmen met de blokken uit de stroomdiagramma. Twee testprogramma’s die ook op de CD staan en die misschien nog nuttig kunnen blijken, worden ook even besproken. Tot slot gaan we enkele problemen en oplossingen aanhalen in verband met de software, zoals we in het vorige hoofdstuk ook voor de hardware gedaan hebben. Aansluitend worden nog een aantal opmerkingen gegeven met betrekking tot het eindresultaat. We kijken hierbij iets breder en dus niet enkel naar de software, maar naar de werking van het geheel (het analyser-knooppunt). In het derde en laatste deel van dit hoofdstuk gaat het over de applicatie die we op PC-niveau wilden realiseren. Het grafische gedeelte van de applicatie om de opdrachten in te geven en de resultaten te bekijken is niet gemaakt. Het gedeelte dat de communicatie met de microcontroller zou verzorgen is wel gedeeltelijk afgewerkt en wordt besproken in dit laatste deel.

4.2 4.2.1

Programma op microcontroller-niveau Inleiding

Voor we de structuur van de applicatie van wat dichterbij zullen bekijken, overlopen we eerst kort hoe de demo precies moet reageren op boodschappen op de CAN-bus. Het programma bestaat eigenlijk uit een oneindige lus die boodschappen op de bus zet als reactie op bepaalde binnenkomende boodschappen. Naast de code van het hoofdprogramma bevindt er zich ook een groot deel van de functionaliteit in de interrupt routines van de applicatie. Bij het ontvangen van een data frame wordt gecontroleerd of een bericht als identifier de decimale waardes 26, 26 of 27 heeft. In elk van die gevallen wordt een overeenkomstige vlag op 1 gezet. De inhoud van de boodschap is daarbij van geen belang, enkel de waarde van de identifier. Wanneer we de log-mogelijkheid aangezet hebben, zal iedere andere boodschap (behalve die met identifier 25, 26 of 27) opgeslagen worden in het 8 kbyte grote externe RAM-geheugen op de microcontroller. Daarbij wordt eerst het aantal databytes opgeslagen, daarna de twee descriptor-registers en tenslotte de databytes

83

Hoofdstuk 4 Software 4.1

Inleiding

In de vorige twee hoofdstukken hebben we achtereenvolgens het CAN-protocol en de gerealiseerde hardware voor onze CAN-bus analyser onder de loupe genomen. In dit hoofdstuk behandelen we de software-aspecten van de CAN-bus analyser. We verwijzen opnieuw naar het blokschema in figuur 3.1 voor de algemene structuur van de analyser. Het is vooral de software op microcontroller-niveau die uitgewerkt geweest is. Het programma op PC-niveau dat als grafische schil moest dienen voor de CAN-bus analyser, is niet voltooid. Op het niveau van de Cygnal C8051F120 microcontroller werd een applicatie gemaakt om de functionaliteiten te demonstreren van het CAN-knooppunt dat in het vorige hoofdstuk werd besproken. We demonstreren het ontvangen en verzenden van CAN-boodschappen (data frames), de basic-CAN en full-CAN werking, het filteren en loggen van boodschappen, remote frames en boodschappen met extended identifiers. De demo-applicatie is louter bedoeld om aan te tonen wat er allemaal met de hardware kan gedaan worden. Ze heeft dus op zich geen enkel nut, ook al omdat er geen verbinding is met de PC. In tegenstelling tot een interactieve applicatie is de werking van dit demo-programma hardgecodeerd. Wanneer we de werking willen wijzigen, moet de assembler-broncode hercompileerd worden met de Cygnal ontwikkelomgeving en opnieuw gedownload worden in het flash-geheugen van het microcontrollerbord. Het grootste deel van dit hoofdstuk gaat bijgevolg over de applicatie op de C8051F120 microcontroller. In de inleiding van dat deel wordt de gewenste werking en de structuur van deze demo-applicatie bekeken, deels aan de hand van enkele stroomdiagramma. De mogelijke uitbreidingen voor de software werden daar reeds behandeld. Het gaat daarbij o.a. over de verandering in structuur die zou moeten worden doorgevoerd om te kunnen re-

82

aan beide uiteinden is het niet mogelijk om een commerciële kabel te gebruiken. Het is overigens toch goedkoper om ze zelf te maken. Het is onmogelijk om de connectoren van de kabel verkeerd aan te sluiten aangezien de sub-D9 connector van de PCIcan-kaart van het mannelijke type is en die van het CAN-interface-bord van het vrouwelijke type.

81

bus gesoldeerd worden op de kaart. Dit werd niet gedaan omdat dit de gebruiksmogelijkheden van de kaart beperkt. De kaart zou eventueel niet meer aangesloten kunnen worden op een CAN-bus waar er reeds aan beide uiteinden een afsluitweerstand aanwezig is. Een goede oplossing zou zijn om een afsluitweerstand extern aan te brengen dicht bij de sub-D9-connector van de PCIcan-kaart. Testen wijzen uit dat dit geen noodzaak is in het systeem dat hier beschreven wordt. Vermoedelijk is dit te wijten aan het geringe aantal CAN-knooppunten en de korte totale lengte van de CAN-bus. Die bedraagt immers slechts een tweetal meter en bestaat uit één kabel. • Microcontrollerbord: Voor de opstelling van het microcontrollerbord en het gebruik van de ontwikkelomgeving verwijzen we naar deel 3.4 en meer bepaald naar deel 3.4.1. De applicatie waarmee we dit CAN-systeem zullen testen, bespreken we in hoofdstuk 4. • Communicatiekabel tussen CAN-interface en microcontrollerbord: De koppeling tussen het CAN-interface-bordje en het C8051F120DK microcontroller-ontwikkelbord is bedoeld voor de communicatie tussen de SAE81C90 CAN-controller en de C8051F120 microcontroller. De kabel die hiervoor gemaakt werd, heeft een aantal veranderingen ondergaan en heeft vooral ook door de ontbrekende voorkennis over de pin-volgorde aan beide uiteinden van de kabel een “speciaal” uitzicht gekregen (zoals besproken in deel 3.2.3). Aan de zijde van het microcontrollerbord heeft de kabel twee 10-pins connectoren. Op beide stukken is aangeduid voor welke poorten ze bestemd zijn (de ene voor poort P0 en de andere voor P3). Figuur 3.22 toont de nummering van de pinnen op een 10-pins connector. De pin-nummering van de poorten van het Cygnal ontwikkelbord in figuur 3.17 toont hoe de twee 10pins connectoren op de poorten moeten worden aangesloten. Aan de andere zijde heeft de kabel een 16-pins connector. De vormgeving van enerzijds deze connector en anderzijds die van de 16-pins header op het CAN-interface-bord is zodanig dat er geen fout kan gemaakt worden bij het aansluiten (zie ook figuur 3.10). • CAN-bus-kabel: De koppeling van het CAN-interface-bord met de CAN-bus werd besproken in deel 3.2.4. Voor de aansluiting van de PCIcan-kaart op de CAN-bus gebeurde dit in deel 3.5. De kabel die gefabriceerd werd om te dienen als CAN-kabel tussen het CAN-interface-bord en de Kvaser PCIcan-kaart is een tweetal meter lang en heeft drie lijnen, namelijk CAN H , CAN L en massa (respectievelijk rood, bruin en wit gekleurd in dit geval). Door de ongelijke pin-nummering van de connectoren

80

Figuur 3.22: Connector 10-pins header. dit systeem en leggen uit hoe deze moeten opgesteld en geconfigureerd worden (of we verwijzen naar het onderdeel waar we dit reeds besproken hebben). • CAN-interface-bord: Dit bord is de link tussen de microcontroller en de CAN-bus. De belangrijkste componenten op dit bord zijn de SAE81C90 CAN-controller en een CAN-transceiver. De microcontroller treedt op als master van de CAN-controller, maar bevindt zich niet op dit CAN-interface-bord. Het ontwerp en het gebruik van dit bord werd besproken in deel 3.2. Let er op dat de jumpers correct ingesteld staan. De voeding voor de componenten aan de zijde van de CAN-bus, moet van de andere kant van de galvanische scheiding komen. De jumpers JP11 en JP12 moeten zo geplaatst worden dat de voedings- en de massa-lijn doorgegeven worden via de DC-DC omzetter (zoals aangegeven in figuur 3.7). De afsluitweerstand op het bordje moet aanwezig zijn tussen de CAN H- en de CAN L-lijn. M.a.w. de jumper JP2 moet gesloten worden. Jumper JP4 bepaalt de spanning op de ASC-pin van de CAN-transceiver en stelt dus de flanksteilheid van de transceiver in. In dit kleine CAN-systeem maakt dit niet veel verschil uit. De voeding van het bordje gebeurt via twee draadjes met banaanstekkers die op het bordje zelf gesoldeerd zijn. Deze twee stekkers moeten worden aangesloten op een labovoeding, waarbij de negatieve pool aan de grond van de labovoeding moet verbonden worden. Dit is van belang voor de digitale communicatie tussen dit bordje en het microcontroller-bordje. Op deze manier is er immers een gemeenschappelijke grond die als referentieniveau dient voor de digitale signalen. De labovoeding moet een spanning leveren van ongeveer 5 V en (als alles goed werkt) ongeveer 50 mA stroom leveren. • PCIcan-kaart: De Kvaser PCIcan kaart moet ingebouwd zijn in een PC, waarop ook de drivers van de fabrikant en het CanKing monitor/analyzer-programma ge¨ınstalleerd moeten zijn. De werking van de PCIcan-kaart werd besproken in deel 3.5. Voor deze applicatie moet er eigenlijk nog een afsluitweerstand voor de CAN-

79

kanaal) is op deze kaart. Bij “Bus Speed” kunnen we instellen wat de snelheid is van het CAN-bus-systeem waarop we aansluiten. Rechts naast dit veld kunnen we klikken op de knop “Suggest . . . ”. Het is aangeraden om hiervan gebruik te maken aangezien de waarden voor “Sampling Point” en “SJW” niet willekeurig ingesteld kunnen worden, maar gedeeltelijk afhangen van de snelheid van de CAN-bus. In het veld “Driver Mode” kunnen we bepalen of er gewerkt wordt in de normale of de stille mode. In de stille mode luistert de CAN-controller enkel naar de CAN-bus, maar kunnen er geen boodschappen verstuurd worden. Er worden ook geen acknowledgements of error frames op de bus gezet in deze mode. Dit is handig in het geval we enkel het CAN-verkeer op een bus willen loggen en analyseren zonder dat het CAN-systeem daarbij gestoord wordt. Op het derde tab-blad kunnen we invullen hoe we de binnenkomende berichten willen filteren. We kunnen zowel voor de normale 11-bit identifiers als voor de “extended” 29-bit identifiers aangeven of we dergelijke boodschappen al dan niet willen ontvangen. Daarbij kunnen we ook nog een waarde ingeven als filter-masker en filter-code. Het filter-masker bepaalt welke bits belangrijk zijn voor de filtering. Bits die op 0 staan in het filter-masker zijn “don’t care” bits wat de filtering betreft. De filter-code bepaalt de waarde waaraan een bericht moet voldoen om aanvaard te worden. Figuur 3.18 toont ook nog de vensters “Universal Page”, “Output Window”, “Log To Text File” en “History List”. Het eerste venster is de meest universele manier om een boodschap op de bus te plaatsen. In tegenstelling tot de andere mogelijkheden die door het CanKing programma geboden worden, werkt dit venster zuiver op laag 2 van het OSI-model (de datalinklaag). We kunnen de identifier, het aantal databytes en de databytes zelf invullen en daarna versturen. Met “Log To Text File” kunnen we de naam van een tekstbestand opgeven om alle CAN-boodschappen weg te schrijven naar een logbestand. Figuur 3.21 toont een output-venster in werking. Men kan zien wat de identifier van een boodschap is en of het RTR-bit ingesteld is. De volgende kolommen tonen de lengte van een boodschap en de databytes. Als laatste wordt het tijdstip van de boodschap getoond en de richting ervan (R voor ontvangen, T voor verzenden). Het venster “History List” toont hetzelfde als het output-venster, maar dan enkel de berichten die verzonden werden.

3.6

Opstelling CAN-bus-systeem

In dit deel zullen we nog kort eens overlopen wat er vereist is om een klein CAN-bussysteem op te stellen. Dit systeem zal bestaan uit twee CAN-knooppunten en een korte CAN-bus-kabel. We bespreken welke hardware en software nodig is voor de realisatie van

78

Figuur 3.20: Kvaser CanKing: instelling boodschap-filters.

Figuur 3.21: Kvaser CanKing: output venster. applicatie. Er zijn drie tab-bladen in dit venster, waarvan het eerste getoond wordt in figuur 3.18 en de andere twee in figuren 3.19 en 3.20. Het eerste tab-blad toont statistieken i.v.m. de CAN-bus, zoals de procentuele bezetting van de bus, het aantal correct verzonden en ontvangen CAN-boodschappen en of de CAN-controller al dan niet te druk bezet is. In dit tab-blad kan aan de CAN-controller de opdracht gegeven worden om op de bus te gaan of zich van de bus te verwijderen. Naast deze knoppen wordt aangegeven in welke toestand de bus zich bevindt. Ook de eventuele fout-passieve toestand wordt hier aangeduid. Op het tweede tab-blad kunnen we de busparameters ingeven. Het veld “CAN Channel” is niet van toepassing aangezien er maar één CAN-controller (en dus één

77

Figuur 3.19: Kvaser CanKing: instelling busparameters. heid tot 1 Mbit/s. De aansluiting met de CAN-bus gebeurt via een sub-D9 connector. De CAN L-lijn komt naar buiten op pin 2 en de CAN H-lijn op pin 7. De grond van deze 2 signalen komt naar buiten op pin 3 (pin-nummering zie figuur 2.6). Standaard is er bij deze versie geen afsluitweerstand van 120 Ω voorzien. Dicht bij de sub-D9 connector is er op de kaart wel plaats voorzien om een afsluitweerstand te solderen. De PCIcan-kaart kan op twee manieren gebruikt worden. De eenvoudigste manier is gebruik maken van het CanKing programma dat bij de kaart bijgeleverd wordt (enkel voor Windows). Dit is een interactieve monitor en analyzer voor de CAN-bus. Het programma kan ook gedownload worden op de website van Kvaser, maar werkt enkel met de kaart van Kvaser zelf. Er is specifieke ondersteuning voor de applicatielaagprotocols CanKingdom en DeviceNet, maar dit is voor ons van minder groot belang. Wij maken enkel gebruik van de mogelijkheden op niveau van de datalinklaag. De tweede manier om met de kaart te werken, is door ze zelf te programmeren met de Kvaser CANLIB SDK (Software Development Kit). Dit is een bibliotheek met functies voor alle CANkaarten van Kvaser voor een aantal uiteenlopende programmeertalen. De CANLIB SDK ondersteunt C, C++, Delphi, Visual Basic en C#. Om de mogelijkheden en de werking van de PCIcan-kaart te illustreren, tonen we een aantal screenshots van het CanKing programma. Figuur 3.18 toont de voornaamste onderdelen van dit programma. Het venster “CAN Controller” is zenuwcentrum van de

76

Figuur 3.18: Kvaser CanKing: monitor-applicatie. werken met de IDE verwijzen we naar de user guide [30]. Daar staan de verschillende stappen om een project aan te maken, te compileren, in flash te downloaden en uit te voeren op een erg bevattelijke manier uitgelegd aan de hand van een voorbeeld.

3.5

Kvaser PCIcan-kaart

In dit onderdeel bekijken we kort even de PCIcan-kaart van Kvaser AB [17] [18]. Bij aanvang van het academiejaar werd een PCIcan-S aangekocht (single channel) om een CANnetwerk te kunnen onderzoeken en te testen. Toen was dit het enigste CAN-knooppunt waarvan we zeker wisten dat het correct functioneerde. Zoals de naam al verklapt, moet deze kaart in een PC ingebouwd worden in een leeg PCI-slot. Dankzij de goede drivers verloopt dit vrij probleemloos. Er is ondersteuning voor Windows 95 tot en met Windows XP en zelfs voor Windows NT 4.0 en Linux. De CAN-controller die op deze kaart gebruikt wordt is een SJA1000 en ondersteunt dus zowel CAN 2.0A als 2.0B actief. De busaansturing is conform met de ISO 11898 standaard en kan dus werken aan een snel-

75

Figuur 3.17: Cygnal microcontrollerbord C8051F120DK. van een PC. Het andere uiteinde verbinden we met de DB-9 connector op de seriële adapter die bij het ontwikkelbordje hoort. Vervolgens hangen we de seriële adapter aan de JTAG-connector van het ontwikkelbord via de 10-pins flatcable. Tenslotte sluiten we de voedingsadapter aan op de jack-connector P1 en starten we de Cygnal IDE op (Integrated Development Environment). Deze ontwikkelomgeving omvat een broncode-editor, een assembler compiler, een C compiler, een programma-debugger en een in-system flashprogrammer. De debugger is een instrument dat veel mogelijkheden biedt (gezien het feit dat we niet met programmacode werken die zich op de PC zelf bevindt) en bijgevolg erg nuttig is om fouten in een programma op te sporen. Klassieke functies zijn het plaatsen van breakpoints en watchpoints in een programma en er kan ook instructie per instructie door het programma gewandeld worden. Het krachtige van deze debugger zit hem in de mogelijkheid om alle mogelijke interne geheugenplaatsen van de microcontroller te bekijken en te wijzigen. Alle SFR’s zijn beschikbaar, gegroepeerd per functie (alles i.v.m. timers, interrupts, PCA, . . . ). Alle geheugens zijn zowel te bekijken als te wijzigen via de IDE, voor zover ze zich op de microcontroller-chip bevinden. Hierbij gaat het dus over het 256 bytes grote interne RAM-geheugen, het 8 kbyte grote externe RAM-geheugen en ook het 128 kbyte grote flash codegeheugen. De 4 registerbanken R0-R7 en de stack die zich in het interne RAM bevinden, kunnen nog eens apart getoond worden. Om te leren

74

I/O poorten. Elk van deze poorten heeft ook een output-mode register dat bepaalt welke pinnen als open-drain geconfigureerd worden en welke als push-pull. Bij pushpull zal het schrijven van een logische 0 naar een bit in het dataregister van de poort de overeenkomstige pin naar 0 V trekken. Het schrijven van een logische 1 zal de pin naar het niveau trekken van de voedingsspanning. In de open-drain configuratie krijgen we hetzelfde gedrag bij het schrijven van een logische 0, maar bij een logische 1 zal de pin een hoog-impedante toestand aannemen. De pinnen van poort 1 kunnen dienst doen als analoge inputs. In dat geval worden deze pinnen overgeslagen bij het alloceren van digitale functies. Wanneer we enkel het 8 kbyte RAM-geheugen op de microcontroller-chip zelf gebruiken, is de interface naar het externe datageheugen niet actief. In alle andere situaties moeten de adresbus en de databus naar buiten gebracht worden, net als de controlesignalen om het off-chip externe geheugen aan te sturen. De #RD- en de #WR-lijn worden respectievelijk op pin P0.6 en P0.7 geplaatst. Wanneer de adres- en de databus gemultiplext zijn, wordt ook nog de ALE-lijn naar buiten gebracht op pin P0.5. De databus bevindt zich altijd op poort 3 (P3). Bij een gedeelde adres/databus brengt de microcontroller de 8 laagste adresbits eveneens op poort 3 naar buiten en de 8 hoogste adresbits op poort 2. Wanneer de adresbus en de databus afzonderlijk van elkaar zijn, wordt de databus zoals gezegd op poort 3 naar buiten gebracht en zijn de 16 bits van de adresbus te vinden op de poorten 1 en 2 (zie figuur 3.16).

3.4.1

Microcontrollerbord Cygnal C8051F120DK

Figuur 3.17 toont de componenten op een Cygnal C8051F120DK ontwikkelbord. De 64 GPIO-pinnen van de C8051F120 komen naar buiten op poort 0 tot poort 7. Elk van de poorten heeft 10 pinnen, waarbij pin 9 de voeding is (3.3V) en pin 10 de massa. Het bordje heeft twee drukknoppen. De ene knop is de resetknop en de andere kan via jumper J1 verbonden worden met GPIO-pin P3.7. Er is een LED aanwezig dat via jumper J3 kan verbonden worden met pin P1.6. Connector J4 is een JTAG-connector en J5 is een DB-9 connector voor een UART RS232 interface. Component P1 is de aansluiting voor de voeding van het ontwikkelbord. Bijna alle pinnen en signalen die op deze development kit te vinden zijn, worden naar buiten gebracht op de 96-polige connector J24. Voor de pinaansluitingen verwijzen we naar de user guide die bij het bordje bijgeleverd wordt en die ook op de website van Cygnal te vinden is. Om het ontwikkelbord te gebruiken, moeten we volgende stappen doen. Eerst verbinden we het ene uiteinde van de bijgeleverde RS232 kabel met één van de seriële poorten

73

Figuur 3.16: Werking van priority crossbar decoder. wordt in figuur 3.16. De eerste digitale functie (van bovenaf) die geactiveerd wordt, krijgt pin 0 op poort 0 toegewezen. Uit de tabel blijkt dat wanneer UART geactiveerd wordt de functies van TX0 en RX0 altijd naar buiten komen op P0.0 en P0.1 aangezien UART de hoogste prioriteit heeft. Bepaalde functies moeten in groep toegewezen worden. Het is dan ook niet zinvol om bv. enkel TX0 naar buiten te brengen en RX0 achterwege te laten. Deze groepen komen naar voren uit de tabel door het ontbreken van een horizontale lijn tussen de verschillende functies (bv. tussen TX0 en RX0, tussen SDA en SCL, . . . ). De registers XBR0, XBR1 en XBR2 (crossbar registers) bepalen welke digitale functies actief zijn. Alle pinnen die niet gealloceerd werden aan een digitale functie kunnen dienst doen als GPIO door het lezen en schrijven van en naar de dataregisters van de verschillende

72

Er zijn vier mogelijke configuraties voor de adresruimte van het externe datageheugen. Een eerste mogelijkheid bestaat erin om enkel het externe RAM op de microcontrollerchip zelf te gebruiken (8 kbyte). Adressen boven de grens van 8 kbyte worden geprojecteerd op een adres onder deze grens. Zo wijzen de adressen 8100 en 16100 (decimaal) beiden naar geheugenplaats 100. De tweede en de derde mogelijkheid hebben als respectievelijke namen “split mode with/without bank select”. Hierbij wordt de adresruimte gesplitst in twee delen. De onderste 8 kbyte komen overeen met het externe RAM-geheugen op de microcontroller-chip zelf terwijl een adres boven deze grens toegang verleent tot off-chip “geheugens”. Met geheugen bedoelen we dan echte externe geheugenchips of anderzijds externe componenten die een mapping krijgen in de adresruimte van het externe datageheugen. Beide werkingsmodes gebruiken de inhoud van het EMI0CN-register om de 8 meest significante bits van het geheugen-adres te bepalen. Het zijn ook deze 8 meest significante bits die het onderscheid maken tussen een toegang tot het RAM op de microcontroller en een off-chip lees- of schrijfbewerking. Het verschil tussen beide modes ligt in de manier waarop de hoogste 8 adresbits aangestuurd worden bij een toegang tot off-chip geheugen. Bij de mode met “bank select” wordt de inhoud van het EMI0CNregister gebruikt. Bij de mode zonder “bank select” kan men zelf de 8 hoogste adreslijnen aansturen door het instellen van de poort latches. De vierde en laatste mode maakt geen gebruik van de 8 kbyte RAM op de microcontroller-chip en beschouwt de volledige externe adresruimte als off-chip geheugen. De timing van de controlesignalen van de externe datageheugen-interface is instelbaar via registers. Daarbij gaat het over de breedte van de ALE-puls, de breedte van de #RDen de #WR-puls, de adres-insteltijd (address setup time) en de adres-houdtijd (address hold time). De registers waarover sprake zijn EMI0TC en een deel van EMI0CF. Dit laatste register wordt ook gebruikt voor o.a. het instellen van de multiplexing-mode en de configuratie van de externe datageheugen-adresruimte. De C8051F120 microcontroller heeft 64 digitale I/O pinnen, verdeeld in acht poorten die elk 8 bit breed zijn. Deze pinnen kunnen gebruikt worden als GPIO-pinnen (General Purpose I/O). De onderste vier poorten (P0-P3) kunnen ook gebruikt worden voor een hele reeks digitale functies zoals UART, SMBus, PCA, timers, interrupt-lijnen, . . . . De interface naar het externe geheugen kan naar buiten gebracht worden op de onderste vier poorten of de bovenste vier. Via registers kunnen we bepalen welke digitale functies naar buiten gebracht worden op de I/O pinnen. De exacte toekenning van I/O pinnen aan de digitale functies gebeurt via een component die men de “Priority Crossbar Decoder” noemt. Deze decoder alloceert de I/O pinnen volgens de prioriteitentabel die getoond

71

3.4

Microcontroller Cygnal C8051F120

In de blokschema’s bij het begin van dit hoofdstuk was er sprake van een microcontroller die optreedt als master voor de SAE81C90 CAN-controller. Om het debuggen van de applicatie te vergemakkelijken, werd gekozen voor een microcontroller op een ontwikkelbord waarbij de communicatie met de CAN-controller via een stuk flatcable gebeurt. Aanvankelijk werd gewerkt met een Siemens SAB80C537-testbordje, daarna werd het mogelijk om een C8051F120DK-bordje te gebruiken van Cygnal [23]. Voor de C8051F120 microcontroller is er een heel uitgebreide datasheet beschikbaar [29] die ettelijke honderden pagina’s omvat. Wij zullen hier enkele punten bespreken die voor onze toepassing van belang zijn en we vangen aan met de geheugenorganisatie van deze microcontroller. De geheugenorganisatie van de C8051F120 is gelijkaardig aan die van een standaard 8051 microcontroller. Er is een afzonderlijk data- en programmageheugen. Het interne datageheugen is 256 bytes groot en het interne programmageheugen bestaat bij deze microcontroller uit 128 kbyte in-system herprogrammeerbaar flash geheugen. Het interne datageheugen is verdeeld zoals bij de standaard 8051. De onderste 128 bytes zijn bedoeld voor general purpose registers en als geheugen. De adressering mag direct of indirect zijn. De bovenste 128 bytes van het interne RAM kunnen enkel op indirecte manier geadresseerd worden. Wanneer deze bovenste 128 bytes op directe manier geadresseerd worden, krijgen we toegang tot de SFR-ruimte (special function registers). Deze ruimte is onderverdeeld in vijf pagina’s. Om een bepaalde pagina te adresseren, moet men het adres van die pagina invullen in register SFRPAGE. Dit register bevat na een reset het adres van SFR-pagina 0. Deze pagina bevat de SFR’s van een standaard 8051 microcontroller. De andere vier SFR-pagina’s bevatten registers die overeenkomen met uitbreidingen ten opzichte van het standaard model. De adresruimte voor het externe datageheugen is 64 kbyte groot bij de C8051F120. De onderste 8 kbyte daarvan bestaat uit RAM-geheugen dat zich op de microcontroller-chip zelf bevindt. De interface naar het externe datageheugen kan dienen voor o.a. off-chip geheugen en/of “memory-mapped” componenten en kan werken in een gemultiplexte of niet-gemultiplexte mode. In de gemultiplexte mode worden de 8 onderste (minst significante) bits van de adresbus gedeeld met de 8-bit brede databus. Om de laagste 8 bits van het RAM-adres bij te houden terwijl de data op de bus gezet wordt, moet er een externe latch aangebracht worden. Het ALE-signaal (Address Latch Enable) bepaalt of de 8 bits die naar buiten gebracht worden de 8 databits of de 8 (laagste) adresbits zijn en stuurt de latch aan. Bij de niet-gemultiplexte mode worden de adresbus en databus strikt gescheiden van elkaar.

70

is een bekende CAN-controller met vrij veel mogelijkheden. Interessant zijn ook de hele goede application note [32] en datasheet [31] over deze controller. Deze blinken uit in duidelijkheid en volledigheid en bieden veel interessante voorbeelden. De extra mogelijkheden van de SJA1000 situeren zich vooral op het vlak van fout-analyse en foutafhandeling. Bij de SJA1000 zijn de beide fouttellers (verzend-foutteller en ontvangst-foutteller) leesbaar. Zoals bij alle andere CAN-controllers gebeurt de foutafhandeling volledig automatisch, maar bij de SJA1000 zorgt elke foutsituatie op de CAN-bus voor een fout-interrupt naar de microcontroller toe en wordt de reden voor de fout vastgelegd in het ECC-register (Error Code Capture). Dit register bevat eveneens de plaats waar de fout is opgetreden in de bitstroom. Dit levert een schat van informatie op voor fout-analyse en eventueel systeem-optimalisatie. Wanneer bij verzending van een CAN-boodschap de arbitrage verloren wordt, genereert de SJA1000 een “Arbitration Lost” interrupt en wordt de bitpositie onthouden waar de arbitrage verloren werd. Dit kan van nut zijn bij analyse van latentie van boodschappen en bij het uitdelen van identifiers (en dus prioriteiten) aan de verschillende CAN-knooppunten. Het CAN-protocol voorziet dat berichten bij het optreden van fouten en bij het verlies van arbitrage automatisch telkens opnieuw verzonden worden. Dit gedrag kan soms vervelend zijn. In sommige situaties verliest de data na verloop van tijd zijn betekenis en hoeft de boodschap niet meer verstuurd te worden. Een mogelijke oplossing daarvoor is de “Single Shot Transmission”-functie van de SJA1000. Wanneer bij een dergelijke boodschap de eerste verzending niet succesvol is, wordt die boodschap niet meer automatisch opnieuw uitgezonden. Met behulp van de reeds besproken voorzieningen kan de programmeur zelf beslissen of een bericht al dan niet opnieuw verzonden wordt. De tot hier toe behandelde mogelijkheden vormen een extra belasting voor de microcontroller die als master optreedt, maar bieden veel meer flexibiliteit aan de applicatie. Als laatste halen we nog twee interessante mogelijkheden aan die de microcontroller niet belasten via extra interrupts. De eerste mogelijkheid is de self-test van de CAN-controller. De tweede mogelijkheid is de automatische bit-rate detectie. Om de werking van de bus niet te verstoren, gaat de SJA1000 eerst in luister-mode. In deze mode worden er geen error frames op de bus gezet. Het detectie-algoritme probeert eerst op de hoogste datasnelheid boodschappen te ontvangen en daalt dan af tot er geen fouten meer optreden. Op dat moment heeft de SJA1000 de juiste bus-snelheid ontdekt.

69

die hier moeten ingevuld worden, is vrij complex. Voor de meeste CAN-controllers, en gelukkig ook voor de SAE81C90, bestaan er programma’s die toelaten om deze parameters te laten berekenen aan de hand van baudrate van de bus en de klokfrequentie van de CAN-controller. Meestal zijn er meerdere mogelijkheden waaruit kan gekozen worden, omdat het bemonsteringspunt binnen een bit kan verschoven worden. Een applicatie die deze mogelijkheden biedt voor de SAE81C90, is beschikbaar op de website van Infineon en tevens op de CD die bij dit eindwerk bijgevoegd is. Het RRR1- en RRR2-register bevatten samen 16 bits die voor elk message object aangeven of er door die geheugenplaats een bericht ontvangen werd. Deze bits moeten telkens door de microcontroller gewist worden. De registers RMR1 en RMR2 (de receive-interrupt mask registers) bepalen samen of het ontvangen van een bericht n (n=0-15) een interrupt zal genereren. Het overeenkomstige RRR1- of RRR2-bit wordt altijd op 1 gezet, ongeacht de instelling van het receive-interrupt masker. Het op 1 plaatsen van één van de 16 bits uit de transmitrequest-set-registers (TRSR1 en TRSR2) vertelt de CAN-controller dat we het bericht in het overeenkomstige message object willen verzenden. Dit bit wordt na succesvolle verzending door de hardware zelf terug op 0 geplaatst. Wanneer meerdere TRSR-bits tegelijkertijd op 1 gezet worden, dan zullen de betreffende berichten één na één verzonden worden, te beginnen met het message object met het hoogste nummer. Met behulp van de TRRR1- en TRRR2-registers (transmit-request-reset) kan een verzend-aanvraag geannuleerd worden, op voorwaarde dat het verzenden van het overeenkomstige bericht nog niet begonnen was. De beide RRPR-registers (remote-request-pending-register) geven aan dat voor een bepaald message object een remote frame ontvangen werd, maar dat het overeenkomstige data frame nog niet teruggezonden werd. Er zijn nog een aantal registers die interessante functies omvatten, maar die binnen dit eindwerk niet gebruikt werden. Het gaat hierbij over de “time stamp” en de “transmit error check” functionaliteiten. Tenslotte zijn er ook voor de twee 8-bit I/O poorten van de SAE81C90 nog enkele registers voorzien. Meer gedetailleerde informatie over de besproken registers en hun functies is te terug te vinden in de datasheet van de SAE81C90 [27]. Ook voor de timing van de communicatie tussen de microcontroller en de CAN-controller verwijs ik naar deze datasheet. Alternatief: de SJA1000 Tot slot van onze bespreking van de SAE81C90 CAN-controller onderzoeken we nog even een alternatief voor deze component, namelijk de SJA1000. Deze component was de eerste keuze voor de CAN-controller, maar kon niet besteld worden. De SJA1000 van Philips

68

komen op deze plaats terecht. Het is duidelijk dat basic-CAN hogere eisen stelt aan de verwerkingssnelheid van de microcontroller. Controleregisters Om de werking van de CAN-controller te bepalen, heeft een microcontroller die als master optreedt een aantal registers ter beschikking op de SAE81C90. De mogelijkheden geboden door deze registers zijn de initialisatie, de controle van de functies, het voorzien van status-informatie en het configureren van de “message objects”. Het OC-register (Output Control) heeft te maken met de configuratie van de output drivers van de verzendpinnen (TX1 en TX0). Pull-up en pull-down werking kunnen onafhankelijk van elkaar geactiveerd worden. De controle van wat er op de CLKOUT-pin naar buiten komt, gebeurt door het register CCR (Clock Control Register). Het CTRL-register (Control) controleert een aantal speciale functies, zoals de monitor mode van bericht 0 en de transmit check. Het “Mode/Status”-register (MOD) bevat het initalisatie- en het reset-bit en een aantal statusbits. Wanneer het initialisatie-bit op 1 gezet wordt, komen we in de initialisatiemode terecht. Alleen dan is het toegelaten om de registers in verband met de outputs (OC) en de bus-snelheid (BL1, BL2, BRPR) aan te passen. Wanneer het reset-bit op 1 gezet wordt, treedt er een zachte software reset op. Als het initialisatiebit op dat moment ook de waarde 1 bevat, gaat het om een harde software reset. Bij een zachte software reset wordt de busactiviteit gestaakt en worden de registers die daar mee te maken hebben gewist (RRR1, RRR2, TRS1, TRS2, RRPR1 en RRPR2). De fout-tellers worden niet gewist. Een harde software reset is hetzelfde als een externe reset-opdracht via de #RES-pin, met dat verschil dat het initialisatie-bit en het reset-bit niet be¨ınvloed worden. Voor de configuratie van de interrupt-werking van de SAE81C90 CAN-controller zijn er twee registers, met name het interrupt register (INT) en het interrupt-mask register (IMSK). In het eerste register bevinden zich de interrupt-vlaggen die aangeven of er een interrupt opgetreden is. Deze vlaggen moeten altijd via software terug uitgewist worden. Zolang er vlaggen zijn die op 1 staan, is de interrupt-pin van de SAE81C90 actief. Het IMSK-register maakt het mogelijk om bepaalde soorten interrupts uit te schakelen. Een aantal mogelijke interrupt-bronnen zijn het correct ontvangen of het succesvol verzenden van een bericht en het veranderen van de werkingsmode van de SAE81C90 (onder invloed van de toestand van de fouttellers). De registers BL1, BL2 (bit-lengte registers) en BRPR (baud rate prescaler register) bepalen de datasnelheid van de CAN-communicatie en enkele instellingen i.v.m. de bittiming en de synchronisatie van de bits. Voor de instelling van deze registers verwijzen we naar de datasheet. De manuele berekening van de waarden

67

schap gewoon weggegooid. Het verzenden van een boodschap gebeurt door een message object in te vullen (data bytes, identifier, datalengte, RTR-bit) en daarna het overeenkomstige TRS-bit in te stellen (transmit-request-set bit). De CAN-controller handelt dan autonoom het verzenden van de boodschap af. Voor 8 berichten kan naast de databytes en de identifier ook de tijd bijgehouden worden (de “time stamp”) wanneer een bericht gearriveerd is. Het gaat hierbij voor elk van de 8 message objects over een 16-bit teller die ge¨ıncrementeerd wordt volgens een instelbaar interval en die zowel gelezen als geschreven worden. Om de consistentie van de data te garanderen bij het lezen of het schrijven van meerdere databytes van een bepaald bericht zijn de message objects niet rechtstreeks bereikbaar. Er wordt gewerkt met een shaduwregister van 8 bytes breed dat een volledig dataveld van een bepaald bericht kan bevatten. De datasheet van de SAE81C90 beweert dat voor leestoegangen het schaduwregister gekopieerd wordt bij de eerste keer dat één van de 8 bytes van een message object gelezen wordt of telkens wanneer het achtste byte (byte 7, aangezien er vanaf 0 geteld wordt) gelezen wordt. Uit de praktijk blijkt dat enkel dit laatste klopt. Voor schrijftoegangen wordt het schaduwregister enkel naar het overeenkomstige message object doorgekopieerd wanneer het laagste byte (byte 0) geschreven wordt. Het is dus aangeraden om alle lees- en schrijftoegangen te beginnen bij byte 7 en te eindigen bij byte 0. Bij het lezen van byte 7 wordt het schaduwregister aangepast met de huidige inhoud van het gewenste message object en daarna niet meer. Dit garandeert dat alle databytes tot hetzelfde bericht horen, ook als er ondertussen een nieuw CANbericht met dezelfde identifier gearriveerd is en het message object dus overschreven is. Bij een schrijftoegang is het pas bij het schrijven van byte 0 dat het schaduwregister doorgekopieerd wordt en is er dus een garantie dat enkel volledige boodschappen verzonden worden. De SAE81C90 ondersteunt zowel basic-CAN als full-CAN werking. Deze werkingsmodes hebben niks te maken met het CAN-protocol op zich, maar zijn ontstaan door ontwerpkeuzes van chipfabrikanten. De meeste hedendaagse CAN-controllers kunnen beide modes aan of zelfs meer. Bij full-CAN zijn er een vast aantal geheugenplaatsen die gebruikt kunnen worden om boodschappen te ontvangen of te verzenden. Elke geheugenplaats komt overeen met één identifier. Dit komt overeen met de 16 message objects (MO0 tot MO15) van de SAE81C90. Het basic-CAN principe gaat uit van één ontvangstbuffer en één verzendbuffer. De filtering gebeurt met een acceptatiecode en een acceptatiemasker. Hiermee kan een subset uit het identifier-bereik gefilterd worden. Bij de SAE81C90 wordt basic-CAN aangeboden door message object 0 in te stellen in “monitor mode”. Alle berichten die door de andere geheugenplaatsen niet aanvaard worden,

66

Figuur 3.15: Descriptor registers SAE81C90. rest dezelfde functionaliteit aan. Er is mogelijkheid om het pad van de parallel opgeslagen CAN-data en de uiteindelijke seriële bitstroom te beveiligen. Het CAN-protocol zorgt voor een enorm hoge integriteit van de data op de bus, maar zegt niks over het pad tussen de CAN-controller en de CAN-bus. Wanneer de SAE81C90 (of de SAE81C91) een boodschap verstuurt, worden de verstuurde bits op hetzelfde moment terug gelezen van de bus. Als de CAN-controller op die manier merkt dat de data op de bus niet overeenkomt met wat er verwacht wordt, dan onderbreekt hij het verzenden van de boodschap en verstuurt hij een error frame. De situatie waarin een CAN-knooppunt de arbitrage verliest omdat er gelijktijdig door een ander knooppunt een bericht met hogere prioriteit op de bus wordt geplaatst, betekent vanzelfsprekend niet dat het verliezende knooppunt een error frame zal versturen. Telkens deze fout optreedt, wordt de “Transmit-Check Error Counter” (TCEC) met één verhoogd. Wanneer de teller de waarde 4 bereikt, genereert de CAN-controller een interrupt en komt hij meteen terecht in de bus-off toestand (ongeacht de stand van de andere fouttellers). De TCEC is leesbaar en schrijfbaar. Geheugenruimte berichten De geheugenruimte van de SAE81C90 kan zoals vermeld 16 verschillende berichten bevatten. Per bericht kunnen tot maximaal 8 databytes bijgehouden worden. Dit is ook het maximum aantal gespecifieerd door het CAN-protocol. Daarnaast worden per bericht 2 descriptorbytes ingevuld. Deze bevatten de 11-bit identifier van een bericht evenals de RTR-bit en de DLC (datalengtecode). Figuur 3.15 toont de descriptor registers van bericht n (met n=0-15). Ze zijn uitgevoerd als associatief geheugen (CAM = contentadressable memory) omwille van de snelheid van dergelijk geheugen. Het geheel van databytes en descriptorbytes wordt ook wel een “message object” genoemd. De identifier van een binnenkomende boodschap wordt vergeleken met de identifiers in het CAM-geheugen. Wanneer er een “match” of een overeenkomst is, worden de databytes van de binnenkomende boodschap in het overeenkomstige message object gekopieerd en wordt het RR-bit op 1 gezet (receive-ready bit). Wanneer er geen enkele overeenkomst is, wordt de bood-

65

“SAE81C90,I,PLCC44”. We zullen hier een component maken met als naam SAE81C90 en als verpakking een PLCC met 44 pinnen. De I is een prefix dat gebruikt zal worden bij de benoeming van de componenten. Het symbool dat we voor onze component gemaakt hebben, moet aangestipt worden aan de linkerkant in de lijst “symbols”. Aan de rechterkant bovenaan bij “New group” vullen we het getal 1 in en we drukken op “add”. De titel van dit vakje verandert nu in “Groups: (1)”. Selecteer nu de regel die we net toegevoegd hebben. In het vakje “Group number” dat zich hieronder bevindt, kunnen we door op de individuele pinnen te klikken de pinnen van het symbool één voor één doen overeenkomen met een pin-nummer van de verpakking. Wanneer alle pinnen toegekend zijn, kiezen we voor “end edit” in het menu “edit” en vervolgens voor “exit” in het menu “file”. Nu kunnen we onze nieuwe component gebruiken in een schema. Als laatste tip bekijken we het maken van massavlakken. Hiervoor moeten we in het layout-scherm kiezen voor “copper” in het “edit”-menu. Aan de rechterkant klikken we het tweede icoontje rechts aan (“create graphic item”) en vervolgens het vijfde icoontje links (“create copper pour area (F5)”). Door een gebied te selecteren op het PCB creëren we nu een massavlak. Let wel op dat je vooraf het goede net selecteert (SPL0, SPL1, . . . ). Er wordt automatisch een zekere afstand (airgap) vrijgehouden tot de baantjes die zich in het massavlak bevinden. Dit is niet altijd gewenst aangezien tot de massalijnen ook een airgap gerespecteerd wordt. Om dit op te lossen kunnen we in het tekstvakje “Agap” bovenaan de airgap op 0 instellen en klikken op het zevende icoontje rechts (Change item/block line width”). Vervolgens klikken we op het icoontje “Change item/block airgap size” en selecteren we alle (massa)lijnen die we willen laten verdwijnen in het massavlak.

3.3

CAN-controller SAE81C90

We verwijzen nog eens naar de datasheet van de Siemens/Infineon SAE81C90 CANcontroller [27] en naar de website van de fabrikant [22]. De mogelijkheden van deze component werden reeds kort overlopen, maar een aantal zaken zijn nog niet aan bod gekomen. Zo is het mogelijk om aan de CAN-controller verschillende verzend-opdrachten tegelijk te geven. Het bericht met de hoogste prioriteit (of dus de laagste identifier) zal eerst verzonden worden. De SAE81C90 heeft twee 8-bit I/O-poorten om bijvoorbeeld de slope control van de CAN-transceiver of de aanwezigheid van de CAN-bus-afsluitweerstand programmeerbaar te maken. In het huidige ontwerp wordt dit manueel ingesteld met behulp van een jumper. De SAE81C91 bezit deze twee poorten niet en heeft dus slechts 28 pinnen in vergelijking met de 44 pinnen van de SAE81C90. De beide varianten bieden voor de

64

Figuur 3.13: Het aanmaken van een nieuw symbool in Edwin32 (resultaat).

Figuur 3.14: Het aanmaken van een nieuwe component (“part”) in Edwin32.

63

Figuur 3.11: Het aanmaken van een nieuw symbool in Edwin32 (stap 1).

Figuur 3.12: Het aanmaken van een nieuw symbool in Edwin32 (stap 2). Het aanmaken van een nieuw symbool kan manueel of automatisch gebeuren. We kunnen ook een eerste versie voor een symbool automatisch laten genereren en er dan nog wat aanpassingen aan doen. Wanneer we in het menu “edit” op “part” klikken, krijgen we het venster te zien uit figuur 3.11. Om een symbool automatisch te genereren op basis van een aantal parameters vul je in het vakje “new” een naam in en druk je op de knop “auto”. Figuur 3.12 toont het volgende scherm. Hier kunnen we het aantal pinnen opgeven, de oriëntatie van de pinnen en de onderlinge afstand tussen de pinnen. In de volgende twee schermen kunnen de oriëntatie en de afstand voor elke pin afzonderlijk nog eens apart ingesteld worden. Het uiteindelijke resultaat wordt getoond in figuur 3.13. Het maken van een nieuw “part” in Edwin32 begint met in het “edit”-menu “part” aan te klikken. Figuur 3.14 toont het venster waarin we zullen werken. Eerst moeten we in het menu “file” voor “new” kiezen. Vervolgens geven we een naam op, bv.

62

de correcte interpretatie bijgevolg de mist in gaat. Eigenlijk zorgt het plaatsen van de pull-up weerstanden er niet voor dat de overspraak verdwijnt, maar wel dat ze minder belangrijk wordt. De overspraak wordt in dit geval immers pas duidelijk merkbaar bij hoogimpedante lijnen en de resterende storing is niet van die grootteorde dat de correcte interpretatie van de logische niveaus verstoord wordt. De pull-up weerstanden zorgen er ook voor dat er te hoge spanningen aan de pinnen van de microcontroller gelegd worden (5 V i.p.v. 3.3 V), maar uit de datasheet van de microcontroller en uit de praktijk leren we dat de betreffende pinnen daartegen bestand zijn. Als een laatste tip voor digitale communicatie geven we mee dat bij problemen ook eens kan gecontroleerd worden of de pinnen wel correct geconfigureerd zijn. Hierbij kan het bv. gaan over de instelling van de pinnen als open-drain of als push-pull. Een pin die als input gebruikt wordt, moet een pull-up werking hebben en moet op een hoog spanningsniveau staan (logische 1). Ook op het niveau van de software zijn er een aantal nuttige tips. Hiervoor verwijs ik naar de bespreking van de microcontroller-programmacode in het volgende hoofdstuk, meer bepaald in deel 4.2.5. Edwin In dit onderdeel zullen we enkele mogelijkheden bekijken van Edwin die misschien minder goed gekend zijn. Het gaat hierbij over de Edwin32 versie 1.1. We hebben het over autorouting en over het creëren van nieuwe “parts” en “symbols”. Wanneer alle componenten ingepakt zijn en dus op het layout scherm hun plaats hebben gekregen, kunnen we Edwin automatisch alle koperbaantjes op het PCB laten plaatsen met behulp van de autorouter. Deze is toegankelijk in het layout-scherm via het menu “auto”. In dat menu moet men achtereenvolgens “autorouter” en “arizona” aanklikken. Eerst moeten we de layout opladen via het menu “file” en de mogelijkheid “load board to route from database”. We moeten ook nog de verschillende routeringsalgoritmes opladen. Dat gebeurt via het menu “strategy” door alle algoritmes één na één aan te stippen en op de knop “load” te drukken. Er is een grote kans dat de routering niet volledig zal lukken. Hieraan kan verholpen worden door afwisselend de PMD en de SMD strategie toe te passen. Via het menu “view” en vervolgens “list of unroutes” kan men controleren of alle verbindingen gemaakt zijn. De autorouter is niet perfect en zal soms rare dingen doen. Een via mag bijvoorbeeld niet onder een chip liggen en het gebeurt ook vaak dat de baantjes te dicht bij elkaar gelegd worden. Het nut van de autorouter is dus dat er een routering gemaakt worden die kan dienen als vertrekpunt en waarbij gegarandeerd alle verbindingen gelegd zijn.

61

gelet worden dat de min-pool van de labovoeding verbonden wordt met de massa van de labovoeding. Voor overspraak zijn er een aantal mogelijke manieren om ze te vermijden. Een eerste belangrijke punt is om de kabel zo kort mogelijk te maken. Hoe langer de kabel hoe groter de capaciteit tussen de verschillende draden. Bij digitale communicatie op een bepaalde frequentie is het alsof er zich een equivalente weerstand tussen de draden bevindt met 1 een waarde gelijk aan jωC . Bij een hogere frequentie en een grotere capaciteit wordt de equivalente weerstand tussen de draden kleiner en bijgevolg de overspraak meer uitgesproken. Een andere oplossing is het plaatsen van een condensator tussen enerzijds de signaallijnen waarop er overspraak is en anderzijds de massa. Op die manier vermindert de (hoogfrequente) storing, maar dit legt beperkingen op aan de communicatiesnelheid over de kabel aangezien de flanksteilheid van de signalen eveneens vermindert. Hetzelfde effect kan bereikt worden door tussen elke twee signaallijnen waar overspraak optreedt een massalijn te leggen. Nog een oplossing voor het probleem van overspraak is het plaatsen van bidirectionele buffers in het signaalpad. Er bestaan chips die dit voor 8 lijnen tegelijk doen. De oplossing die uiteindelijk gekozen werd voor de communicatie tussen de microcontroller en de CAN-controller was het plaatsen van pull-up weerstanden op elke lijn van de kabel ter hoogte van de 16-pins header op het CAN-interface-bord. Via weerstanden van 3.3 kΩ werden de datalijnen en de controlelijnen met de 5V-voeding verbonden. De pinnen van de Cygnal-microcontroller waren als pull-ups ingesteld, maar blijkbaar werkten die niet goed of waren ze niet sterk genoeg. Wanneer bijvoorbeeld gelezen werd van de CAN-controller trok de microcontroller de #RD-pin laag, maar werd de #WR-pin losgelaten zodat de #WR-lijn hoogimpedant was. Door overspraak zakte het signaalniveau van de #WR-lijn onder invloed van de lage spanning op de #RD-lijn. De CAN-controller interpreteert dit alsof de master-microcontroller tegelijk wil lezen en schrijven naar de registers van de CAN-controller en dit is onmogelijk. Het plaatsen van de pull-up weerstanden zorgt er voor dat een lijn die hoogimpedant is, naar een spanning van 5 V wordt getrokken. De pinnen van de microcontroller moeten daarbij als open-drain ingesteld worden. Met andere woorden, de interne pull-ups moeten uitgeschakeld worden anders ontstaan er conflicten. De (externe) pull-up weerstanden zorgen tevens voor een oplossing van het probleem dat de spanningsniveaus tussen de microcontroller (3.3 V) en de CAN-controller (5 V) verschillend zijn. De CAN-controller interpreteert een spanningsniveau van 3.3 V nog net als een logische één, maar er hoeft niet al te veel storing op te treden vooraleer het spanningsniveau onder de grenswaarde van een logische één zakt en

60

de verbindingen wel effectief doorverbonden zijn. Een pin lijkt soms wel goed aan een baantje gesoldeerd, maar maakt toch een slecht contact. Een ander voorbeeld van slechte verbindingen is te vinden bij zelf gesoldeerde kabels. Het kan gebeuren dat één of meer draadjes in een kabel afkraken op de plaats waar ze aan een connector gesoldeerd zijn. Om dit te vermijden, kan een trekontlasting gebruikt worden voor elke connector. Wanneer aan de draad getrokken wordt, is het die trekontlasting die de krachten opvangt en niet het punt waar de draadjes aan de connector gesoldeerd zijn. Hoe goed je ook controleert of je wel alles goed doet, het is toch nog altijd mogelijk om een chip verkeerd op een bord te solderen. Een andere fout of vergetelheid is het tekort of de volledige afwezigheid van ontkoppelcondensatoren in een ontwerp. Een standaard waarde voor een ontkoppelcondensator bij de meeste chips is 100 nF. Bij connectoren is het belangrijk om te weten of de pin-nummering op een figuur slaat op de mannelijke of de vrouwelijke variant van dat type connector. Bij een sub-D9 (bv. CAN-bus) of een sub-D25 connector (seriële poort) zijn de pinnummers bij de twee varianten gespiegeld ten opzichte van elkaar. De SAE81C90 CAN-controller is uitgevoerd in een PLCC44verpakking. Doordat de pinnen daarbij naar binnen “krullen” is dit niet zo gemakkelijk te solderen. Bij een nieuw ontwerp zou er beter een gepast IC-voetje gebruikt worden om het soldeerwerk te vergemakkelijken en zo fouten te vermijden. Bij digitale communicatie kan overspraak optreden tussen de verschillende lijnen, vooral bij grote afstanden en hoge frequenties. Een concreet voorbeeld daarvan is terug te vinden bij de kabel die gebruikt wordt om het CAN-interface-bord en het microcontrollerbord met elkaar te verbinden. Het gaat om een stuk flatcable waarover de 8 adres/datalijnen en de 6 controlesignalen lopen. Oorspronkelijk was het de bedoeling dat ook de massa en de voeding via deze kabel van het microcontrollerbord naar de CAN-interface zouden gebracht worden. Dit kon niet meer aangezien er met een ander microcontrollerbord gewerkt werd dan eerst voorzien en het nieuwe (Cygnal C8051F120DK) en het oude bord (Siemens SAB80C537) op een verschillende voedingsspanning werkten. Meer bepaald werkt het Siemens-bordje op 5 V en het Cygnal-bordje op 3.3 V. De voeding van het CAN-interface moest dus met een labovoeding gebeuren. De voedingslijnen werden op het bordje aan de pinnen van de elco gesoldeerd. Omdat een digitaal signaal altijd een bepaald niveau heeft ten opzichte van een bepaald referentieniveau moet niet alleen het signaalniveau zelf meegegeven worden, maar ook het niveau van de grond van de digitale signalen. Bij de communicatie tussen de microcontroller en de CAN-controller wordt dit niveau niet doorgegeven, maar is er toch een gemeenschappelijke grond, namelijk de aarding van het voedingsnet. Het microcontrollerbord is sowieso geaard. Er moet enkel op

59

een afsluitweerstand en worden de CAN-knooppunten via korte stubs op de CAN-lijnen aangesloten. Dit toont nogmaals de diversiteit van de implementatie-mogelijkheden voor de fysische laag aan. Deze verscheidenheid is tegelijkertijd een sterkte en een zwakte van CAN en is te wijten aan het feit dat het CAN-protocol slechts weinig specificeert op het niveau van de fysische laag. Niet alle pinnen op de sub-D9 connectoren zullen gebruikt worden. Dit hangt af van de kabels die voor de CAN-bus gebruikt worden en die hangen voor hun beurt gedeeltelijk af van de applicatie. In dit eindwerk bestaan de CAN-kabels uit drie lijnen, namelijk de CAN L-lijn, de CAN H-lijn en de massa-lijn.

3.2.5

Problemen, oplossingen, tips

In dit deel gaan we een aantal problemen overlopen die ik al dan niet zelf heb meegemaakt. Daarbij reik ik telkens oplossingen en/of tips aan. Het is een lijstje dat kan gebruikt als een soort checklist bij problemen met o.a. digitale hardware. Soms zit de fout immers in een klein hoekje of is ze zo voor de hand liggend dat je er niet eens meer aan gedacht had. Het is een lijst die vanzelfsprekend oneindig kan aangevuld worden. Om het met een boutade te zeggen: “Zolang we nieuwe elektronica maken, creëren we ook nieuwe problemen.” Voor bepaalde studenten zijn deze tips misschien overbodig, maar niet iedereen die in CAN-communicatie ge¨ınteresseerd is, heeft noodzakelijkerwijs een sterke praktische achtergrond. Daarnaast is dit onderdeel ook belangrijk omdat het de aanpassingen aan het originele ontwerp bevat en de “engineering tricks” die toegepast zijn om het geheel aan de praat te krijgen. Zonder deze aanpassingen is het ontwerp niet volledig en bij een nieuw ontwerp moet er met deze zaken van in het begin rekening gehouden worden. Vaak voorkomende fouten op een bordje zijn kortsluitingen of onderbrekingen. Wanneer een deel van het ontwerp het niet doet, is het raadzaam om dit soort problemen eerst uit te sluiten. Een kortsluiting tussen twee pinnen of twee baantjes op het PCB zijn normaal gezien met het blote oog te zien, als er tenminste op gelet wordt. Wat iets moeilijker is om te ontdekken, en vaak vrij frustrerend, is de situatie waarbij een kort stukje draad van het desoldeerlint los is geraakt tijdens het desolderen en op die manier ergens een verbinding maakt waar er geen moet zijn. Bij het maken van kabels tenslotte is het van belang om de draadjes niet over een te grote afstand te strippen wanneer ze aan een connector gesoldeerd moeten worden. Zo is er immers meer kans dat de draadjes contact maken met elkaar. Bovendien kan in een dergelijke situatie de kortsluiting nu eens niet en dan weer wel optreden, wat het vinden ervan moeilijker maakt. Naast het testen van kortsluitingen is het ook aan te raden om regelmatig te testen of alle bedoel-

58

en ALE (write, read en address latch enable). Ook de #RST- en #CS-lijn hebben een belangrijke functie. De eerste zorgt voor een harde reset van de CAN-controller en de tweede geeft aan dat we met de CAN-controller willen communiceren. De #INT-lijn vertelt aan de microcontroller dat er in de SAE81C90 een interrupt-situatie is opgetreden. De aandachtige lezer zal gemerkt hebben dat er twee lijnen ontbreken aan de kant van de microcontroller, namelijk de GND-lijn en de voedingslijn. Zoals we in deel 3.2.5 zullen uitleggen, zijn er een aantal problemen geweest met de communicatie via deze kabel. Zo was het oorspronkelijk de bedoeling om de voeding en de massa van het microcontrollerbord door te geven via de kabel naar het CAN-interface-bord. Door een verandering van microcontroller en ontwikkelbord was dit niet meer mogelijk. De voedingsspanning van het nieuwe bord was 3.3 V i.p.v. 5 V. Het resultaat is dat deze twee lijnen net als vier andere lijnen van de 20-polige flatcable niet doorverbonden worden naar het CANinterface-bord. Een ander gevolg is dat de CAN-interface uiteindelijk apart gevoed wordt door een labovoeding. Dit gebeurt via twee banaanstekkers die elk met een draadje op het CAN-interface-bord zelf gesoldeerd zijn.

3.2.4

Koppeling met de CAN-bus

Figuur 2.6 uit het vorige hoofdstuk toont de pin-nummering van een 9-polige sub-D connector. Merk wel op dat deze nummering geldt voor de mannelijke connector en dat de nummering voor de vrouwelijke variant gespiegeld is. De CAN-bus connectoren op het CAN-interface bordje zijn beiden van het vrouwelijke type. De functies van de pinnen zijn als volgt. Pin 1 en pin 9 hangen via het bordje aan elkaar en komen overeen met de massa van de CAN-interface en de CAN-bus. Pin 4 en pin 8 zijn respectievelijk de “CAN-high”en de “CAN-low”-lijn van de CAN-bus en worden op het CAN-interface-bordje verbonden met de overeenkomstige pinnen van de CAN-transceiver. De voeding van het bordje aan de kant van de CAN-bus wordt naar buiten gebracht op pin 6. Dit kan nuttig zijn om (afhankelijk van de stand van de jumpers JP11 en JP12) een deel van de CAN-interface of zelfs het volledige bord te voeden vanuit de CAN-bus. De pinnen op beide connectoren zijn met elkaar doorverbonden en er is een afsluitweerstand voorzien van 120 Ω die met behulp van jumper JP2 kan worden weggelaten. Op die manier kan de CAN-interface toegevoegd worden als eindpunt van de CAN-bus of kan het bordje anderzijds ook opgenomen worden in een keten. In dat laatste geval loopt een deel van de CAN-bus over het bordje, aangezien de CAN H- en CAN L-lijn op de ene connector binnenkomen en via de andere connector weer buitengaan. In de situatie die in figuur 2.4 weergegeven wordt, bestaat de CAN-bus uit twee lange lijnen met aan weerszijden

57

Figuur 3.9: Layout van het CAN-interface bordje (soldeerzijde).

Figuur 3.10: Koppeling tussen CAN-interface en Cygnal-microcontrollerbord.

56

Figuur 3.8: Layout van het CAN-interface bordje (componentzijde). betekenis van de 16 pinnen wordt links op figuur 3.10 gegeven. Rechts op de figuur staan de twee 10-pins headers afgebeeld die we zullen gebruiken om de kabel aan de microcontroller te koppelen. De bovenste 10-pins header is P0 op het microcontrollerbord, de onderste komt overeen met P3. Het ene uiteinde van de kabel wordt dus op een 16-pins header aangesloten, het andere uiteinde op twee 10-pins headers. Bij het ontwerpen van het CAN-interface-bord was nog niet geweten hoe de adres/databus en de controlelijnen er exact zouden uitzien aan de kant van het microcontrollerbord. Daardoor zijn beide helften van de kabel die de borden aan elkaar koppelt niet op mekaar afgestemd. Het aantal en de volgorde van de pinnen (en dus ook van de lijnen) is verschillend op beide borden. De individuele lijnen van de flatcable moesten dus één per één aan elkaar gesoldeerd worden. Dat is geen grote moeite, maar een perfect ontwerp houdt hier van bij het begin rekening mee in de mate van het mogelijke. Acht van de 16 lijnen zijn gereserveerd voor de gemultiplexte adres/databus. De communicatie via deze 8 lijnen gebeurt aan de hand van de controlelijnen #WR, #RD

55

ontkoppelcondensatoren zich dicht bij VDD2 en VSS2 bevinden. De derde ontkoppelcondensator staat bij VDD1 en VSS1 . Eén van de condensatoren die zich dicht bij VDD2 enVSS2 bevindt, zou eigenlijk bij de analoge voeding en massa (VDDA , VSSA ) moeten staan. Dit is een kleine tekortkoming in het ontwerp die evenwel geen problemen veroorzaakt. Het is bovendien zo dat er geen afzonderlijke analoge en digitale voeding bestaat. Aan de kant van de CAN-controller is er één voedingslijn en één massalijn die gedeeld worden. De 8 datalijnen en 6 controlelijnen van de SAE81C90 worden naar een 16-polige header (J3) gebracht om de communicatie te verzorgen met de microcontroller die zich op een ander bord bevindt. Ook de voeding en de massa worden via deze header op het CAN-interface bordje gebracht. Tussen voeding en massa plaatsen we als ontkoppeling een elco van 22 µF en 16 V (C9). Aan de SAE81C90 wordt een externe oscillator aangebracht van 16 MHz tussen de pinnen X1 en X2. Aan elk van beide pinnen wordt nog een condensator aangebracht van 22 pF (C4 en C5). Pin MS wordt aan de massa gehangen, waardoor voor de communicatie met de master-microcontroller de parallelle interface geselecteerd wordt. De overige niet-gebruikte pinnen (zoals TX1, RX1, CLKOUT, . . . ) worden aan massa gehangen of worden niet verbonden. Layout De figuren 3.8 en 3.9 tonen respectievelijk de componenten- en de soldeerzijde van het bordje. Aan beide zijden van het bordje bevinden zich twee massavlakken, waarvan telkens één aan de kant van de CAN-controller en één aan de kant van de CAN-bus. Deze massavlakken zijn niet afgebeeld op de figuren. Het volledige ontwerp is terug te vinden op de CD die bij dit eindwerk bijgevoegd is en kan bekeken worden in Edwin. Daar kunnen de massavlakken wel zichtbaar gemaakt worden. De weerstand R5 en de condensator C10 vormen een verbinding tussen de beide massavlakken. De bedoeling hiervan is om de spanning op de massavlakken op hetzelfde niveau te plaatsen. Hiervoor moeten R5 en C10 een hele grote waarde hebben.

3.2.3

Koppeling met microcontrollerbordje

De Cygnal C8051F120 microcontroller zal als master optreden voor de SAE81C90 CANcontroller. Voor de C8051F120 is de CAN-controller een externe component, maar de registers van de SAE81C90 zullen in het geheugen van de microcontroller geprojecteerd worden op een bereik van 256 bytes (memory mapping). De communicatie tussen het CAN-interface-bordje en het Cygnal microcontrollerbordje gebeurt via een flatcable met 16 lijnen. Aan de kant van de CAN-interface eindigt de kabel op een 16-pins header. De

54

datasheet (25A 6 IASC 6 275A). Wanneer de jumper J4 gesloten wordt, ligt de ASC-pin direct aan de grond en werkt de L9615 in hoge-snelheidsmode. De TX0-pin en de RX0-pin van de CAN-transceiver L9615 worden elk via een 6N137 optocoupler (I5 en I6) met de TX0-pin en de RX0-pin van de CAN-controller SAE81C90 verbonden. De input van de ene optocoupler (I5) is via weerstand R3 (met een waarde van 390 Ω) verbonden met de RXD-outputpin van de CAN-transceiver. Bij de andere optocoupler (I6) is de input via weerstand R2 (eveneens 390 Ω) verbonden met de TX0-outputpin van de CAN-controller. Deze weerstandswaarden werden zo gekozen dat de stroom bij een laag logisch input-niveau ongeveer 13 mA bedraagt. Dit voldoet aan de werkomstandigheden die in de datasheet van de 6N137 aangeraden worden (6.3mA 6 IF 6 15mA). De outputs van de beide optocouplers I5 en I6 worden respectievelijk verbonden met de RX0-inputpin van de CAN-controller en de TX0-inputpin van de CAN-transceiver. Deze verbindingen hangen elk via een pull-up weerstand aan de voedingsspanning (respectievelijk R4 en R1). De weerstandswaarden voor R4 en R1 zijn 390 Ω zodat de stroom die door de pull-up weerstanden vloeit bij een lage input ongeveer 13 mA bedraagt. Deze stroom zal ook via pin 6 naar pin 5 van de optocouplers stromen en komt overeen met de typische waarde daarvoor uit de datasheet. De beide optocouplers worden ontkoppeld door een condensator van 100 nF (C1 en C2 respectievelijk). Voor de enable-pin is er inwendig reeds een pull-up weerstand voorzien zodat deze pin direct met de voeding mag verbonden worden. Om de galvanische scheiding te vervolledigen, is er nog de DC-DC omzetter (I2). De jumpers JP11 en JP12 maken de keuze mogelijk of er al dan niet met galvanische scheiding gewerkt wordt. Wanneer de jumpers geplaatst zijn zoals in figuur 3.7 aangegeven, dan is er sprake van galvanische scheiding en worden de componenten aan de zijde van de CAN-bus (I3, en deels ook I5 en I6) gevoed vanaf de kant van de microcontroller via de DC-DC omzetter. In de andere stand van JP11 en JP22 wordt de galvanische scheiding opgeheven en wordt het volledige bordje gevoed vanuit de kant van de microcontroller. Wanneer beide jumpers weggenomen worden, is er ook galvanische scheiding, maar dan moeten de componenten aan de CAN-bus zijde wel op een andere manier gevoed worden. Dat kan bv. via de CAN-kabel, aangezien de voeding op het bordje aan de kant van de CAN-bus verbonden is met één van de pinnen van de sub-D9 CAN-bus connectoren. Tot slot bespreken we nog de SAE81C90 CAN-controller (I4). Zoals vermeld heeft deze controller drie paar voedingspinnen, waarvan twee digitale paren en één analoog paar. Elk van deze paren wordt ontkoppeld door een 100 nF condensator (C6, C7 en C8). Op de componentenzijde van de layout (figuur 3.8) is te zien dat twee van de drie

53

Figuur 3.7: Edwin-schema van het CAN-interface ontwerp. 52

Condensatoren: C1,C2,C3,C6,C7,C8: 100 nF C4,C5: 22 pF C9: 22 F / 16 V elco Halfgeleiders: I2: NMV0505SA I3: L9615 I4: SAE81C90 I5,I6: 6N137 Diversen: I1: 16 MHz kristal J1,J2: 9-polige sub-D-connector J3: 16-polige header JP2,JP4: 2-polige jumper JP11,JP12: 3-polige jumper

Bespreking volledige ontwerp Figuur 3.7 toont het volledige schema van het CAN-interface ontwerp in Edwin. We vangen aan met de bespreking van dit schema aan de zijde van de CAN-bus. De CANkabels worden aan de hand van twee 9-polige sub-D connectoren (J1 en J2) aangesloten op het CAN-interface bordje. De pinnen van deze beide connectoren zijn parallel met elkaar doorverbonden. Voor meer uitleg over de functies van de pinnen van deze connectoren verwijzen we naar 3.2.4. Er is een weerstand van 120 Ω voorzien (R8) die als afsluitweerstand voor de CAN-bus kan dienen bij het sluiten van jumper JP2. De L9615 transceiver (I3) bemonstert de CANH- en CANL-lijn van de CAN-bus en zet deze signalen om tot digitale logische niveaus. Deze component wordt ontkoppeld met een capaciteit van 100 nF (C3). Weerstand R7 en jumper JP4 bepalen zoals reeds vermeld de werkingsmode van de L9615. De weerstandswaarde van 4,7 kΩ is zo gekozen dat wanneer jumper JP4 open is en de ASC-pin dus via weerstand R7 aan de massa verbonden is, er een stroom door R7 loopt van ongeveer 100 A bij een spanning van 5V op de ASC-pin. Dat ligt binnen de grenswaarden die voor deze stroom opgelegd zijn in de

51

5 Mbit/s kan werken. Van het CAN-protocol zijn zowel versie 2.0A als 2.0B ondersteund, maar bij deze laatste gaat het wel over 2.0B passieve ondersteuning. M.a.w. berichten met een 11-bit identifier worden aanvaard en verwerkt terwijl berichten met een 29-bit identifier wel aanvaard worden als correct bericht (en dus geen error frame veroorzaken), maar evenwel niet verwerkt worden. De SAE81C90 heeft geheugenruimte voor 16 berichten met elk 8 databytes en 2 descriptorbytes. De descriptorbytes bevatten de identifier, RTR-bit en datalengte van een bericht. Afhankelijk van het extern aangelegde kristal kan de SAE81C90 een werkingssnelheid hebben van 1 tot 20 MHz. De interface naar de fysische bus toe is programmeerbaar uitgevoerd. Er is wel nog een CAN-transceiver nodig (zoals de L9615 die we net besproken hebben) om tot de echte CAN-bus-signalen te komen. De SAE81C90 is uitgevoerd in een PLCC44 verpakking (figuur 3.6). De pinnen X1 en X2 zijn bedoeld voor de aansluiting van een externe oscillator. Via de CLKOUT-pin kan de klok indien gewenst naar buiten gebracht worden. De laag-actieve #RES-pin zorgt voor een reset van de CAN-controller. De pinnen AD0 tot AD7 komen overeen met de gemultiplexte parallelle 8-bits adres/databus. De eerste vijf van deze pinnen kunnen ook dienst doen als seriële interface. De pinnen #RD, #WR en ALE zijn controlepinnen voor de parallelle interface en hebben geen functie bij gebruik van de seriële interface. De #CS- en de #INT-pin zijn respectievelijk de chip select en de interrupt controlesignalen. De #CS-pin is een input en de #INT-pin is een output. De SAE81C90 heeft twee 8bit I/O poorten die evenwel niet gebruikt werden in dit ontwerp. Het gaat hier over de pinnen P00 tot en met P07 en P10 tot P17. TX0 en RX0 zijn respectievelijk de transmitter output pin en de receiver input pin van de SAE81C90. Daarnaast hebben we nog een extra transmitter en receiver pin in de vorm van TX1 en RX1. Er zijn drie paren voedingspinnen, waarvan twee digitale (VDD1 , VDD2 , VSS1 , VSS2 ) en één analoge (VDDA , VSSA ) voeding en massa. Onderdelenlijst Vooraleer over te gaan naar de bespreking van het volledige ontwerp geven we hier nog even de lijst van componenten mee: Weerstanden: R1,R2,R3,R4: 390 Ω R7: 4.7 kΩ R8: 120 Ω

50

Figuur 3.6: Pinnen SAE81C90. [21]) is een 5V-5V DC-DC converter met single output. Figuur 3.5 toont de pinnen van de NMV0505SA. Pin 1 en pin 2 (VIN en GND) worden omgezet tot pin 7 en 5 (+V en 0V) aan de andere kant. De isolatie bedraagt 3kV DC spanning. Voor een standaard DC-DC converter ligt deze waarde op 1 kV. CAN-controller SAE81C90 De SAE81C90 van Siemens/Infineon [22] [27] [28] is een Stand-alone Full CAN controller (SFCAN) voor datasnelheden tot 1 Mbit/s. Deze component is geen microcontroller en kan dus geen programma-code uitvoeren. De SAE81C90 is een implementatie van het CAN-protocol en kan zelfstandig berichten verzenden en ontvangen. De mastermicrocontroller beheert en controleert alle CAN-functies via de 8-bit brede registers van de SAE81C90. Deze registers kunnen beschikbaar gemaakt worden voor de microcontroller als 256 geheugenplaatsen ergens in de adresruimte van het externe datageheugen. Daartoe zijn er twee mogelijke interfaces. Er is een parallelle interface die bestaat uit een gemultiplexte 8-bits adres/databus en ook nog een seriële interface die aan een snelheid tot

49

Figuur 3.5: Pinnen NMV0505SA. Pinnen 8 en 5 komen overeen met respectievelijk de voeding en de massa van de optocoupler. Pinnen 1 en 4 hebben bij deze versie van de component geen functie. Bij de “dual-channel”-versie daarentegen hebben alle pinnen een functie. Pin 2 en pin 3 zijn de positieve en de negatieve input van de optocoupler waarover een spanning VF staat. De output wordt gevormd door pin 6 (VO ) en is een open collector uitgang. Pin 7 tenslotte maakt het mogelijk om de output uit te schakelen. Dit is dus een “enable”- of “strobe”-pin. Wanneer de spanningsval over pin 2 en pin 3 positief is, loopt er stroom van pin 2 naar pin 3. Wanneer aan de “enable”-pin de voedingsspanning hangt, vloeit er door de koppeling via de LED en de fotodetector ook stroom van pin 5 naar pin 6. Om een hoge spanning (bv. 5V) aan de input overeen te laten komen met een hoog spanningsniveau aan de output en een lage input met een lage output kunnen we het volgende doen. De input wordt verbonden aan pin 3 en pin 2 wordt daarbij aan de voedingsspanning gelegd (5V in dit voorbeeld). Ook de “enable”-pin wordt vast op een hoog niveau ingesteld. Aan pin 6 hangen we een pull-up weerstand. Stel dat er aan de input een hoog spanningsniveau aangelegd wordt. In dat geval loopt er geen stroom door de LED in de optocoupler en is de verbinding tussen pin 5 en pin 6 een open keten. Door de pull-up weerstand bevindt output-pin 6 zich net als input-pin 3 op een hoge spanning. Wanneer we aan de input-pin echter een lage spanning aanleggen, stroomt er wel stroom door de LED en bijgevolg geleidt de output-transistor. De stroom die van de voeding via de pull-up weerstand en de output-transistor naar de massa vloeit, zorgt ervoor dat de volledige spanningsval over de pull-up weerstand komt te staan. Anders gezegd, de output-pin hangt aan massa. DC-DC converter NMV0505SA Voor de galvanische scheiding hebben we ook nog een DC-DC omzetter nodig. De NMV0505SA [26] van Newport Components (overgenomen door C&D Technologies Inc.

48

Figuur 3.4: Pinnen en intern schema 6N137. Slope Control”. De ASC-pin maakt het mogelijk om twee verschillende werkingsmodes in te stellen. Wanneer de ASC-pin aan de massa hangt, werkt de L9615 aan een snelheid van 500 kbit/s of lager. Voor tragere snelheden (6 125 kbit/s) kan deze pin aan de voedingsspanning gehangen worden. Dit brengt met zich mee dat de flanksteilheid van de bus-output kleiner wordt waardoor de elektromagnetische inductie ook kleiner wordt. In onze toepassing hebben we korte CAN-kabels en weinig CAN-knooppunten en is dit dus geen groot probleem. We hoeven de spanning aan de ASC-pin dus niet aan te passen wanneer we de CAN-bus-snelheid veranderen. Het ontwerp voorziet via een jumper toch de mogelijkheid om dit te doen als dit nodig zou blijken. Het gebruik van een afgeschermde twisted-pair kabel kan noodzakelijk zijn om de storing van de CAN-signalen bij de hogere datasnelheden te verminderen. Bij lagere datasnelheden volstaat een niet-afgeschermde twisted-pair kabel. Optocoupler 6N137 Voor het digitale signaal dat verzonden wordt en hetgene dat ontvangen wordt, is er telkens een optocoupler voorzien om de CAN-controller galvanisch te scheiden van de CAN-bus. Hier hebben we gekozen voor de 6N137 van Fairchild Semiconductor [20] [25] (in de “singlechannel”-versie). Figuur 3.4 toont het interne schema en de pinaansluitingen van deze component. De 6N137 gebruikt intern een 850 nm AlGaAs LED die optisch gekoppeld wordt aan een lichtdetector en een logische poort.

47

Figuur 3.3: Pinnen L9615. komen. Daarom is er een galvanische scheiding voorzien tussen de transceiver en de CAN-controller. Dit beperkt de schade in het geval er hoge spanningen op de CAN-bus zouden optreden. De galvanische scheiding bestaat uit twee optocouplers (6N137 van Fairchild Semiconductor) en een 5V-5V DC-DC-converter (Newport Components). De verbinding met de CAN-bus gebeurt via 120 Ω sub-D9 connectoren.

3.2.2

Ontwerp

Vooraleer we het volledige ontwerp van de CAN-interface zullen bekijken, overlopen we eerst summier de functie en de werking van de gebruikte componenten. We verwijzen ook telkens naar de datasheets van de componenten en naar de websites van de fabrikanten. Bij de bespreking van het ontwerp zelf wordt dan verklaard hoe de componenten aan elkaar hangen en waarom bepaalde keuzes werden gemaakt. CAN-transceiver L9615 De eerste component die we bespreken is de L9615 CAN-transceiver van ST Microelectronics [19] [24]. Deze component zet het differentiële analoge signaal van de CAN-bus om tot een digitaal signaal dat door de CAN-controller kan gebruikt worden. De L9615 is een bidirectionele transceiver, m.a.w. één dergelijke chip volstaat om een CAN-controller te koppelen aan een fysische bus. Er wordt een snelheid ondersteund van 500 kbit/s, maar zoals testen uitwijzen, functioneert het ontwerp ook bij de hoogste CAN-snelheid naar behoren, namelijk bij 1 Mbit/s. Figuur 3.3 toont de pinaansluitingen van de L9615. De pinnen GND en VS zijn de grond en de voeding van de chip. De aansluiting op de CAN H- en de CAN L-lijn van een CAN-bus gebeurt via pinnen C L en C H. Pin TX0 is de digitale transmitter ingang en pin RX0 is de digitale receiver uitgang. Er resten nog de pinnen RX1 en ASC. De RX1-pin brengt de digitale referentiespanning naar buiten. De CAN-controller die we gebruiken heeft deze spanning niet nodig. Het letterwoord ASC staat voor “Adjustable

46

Figuur 3.2: Blokschema CAN-interface. microcontroller staat, wordt ook kort even besproken. Om een werkend CAN-bus systeem te hebben, zijn meerdere CAN-knooppunten nodig. Eén van die knooppunten is de combinatie van het CAN-interface-bord met het microcontrollerbord. Een ander knooppunt is de PCIcan-kaart van Kvaser die besproken wordt in het vijfde deel van dit hoofdstuk. Hierbij wordt vooral de bijgeleverde monitor/analyzer applicatie bekeken. In het zesde en laatste deel van dit hoofdstuk wordt een klein CAN-bus-systeem beschreven met behulp van de in dit hoofdstuk besproken hardware. Het enige wat hier nog aan toegevoegd moet worden is de applicatie die we in het volgende hoofdstuk zullen bespreken en die demonstreert wat de mogelijkheden zijn van de gerealiseerde hardware.

3.2 3.2.1

CAN-interface Blokschema

De realisatie van de CAN-interface kan in grote lijnen geschetst worden zoals in het blokschema van figuur 3.2. De interface bestaat dus uit twee borden. Het ene is een microcontrollerbord, waarvoor een ontwikkelbord van Cygnal werd gekozen, namelijk de C8051F120DK. Dit bord wordt geprogrammeerd via een JTAG-interface. Het andere bord heeft als belangrijkste componenten een CAN-controller en een CAN-transceiver (waarvan ook sprake in de inleiding van dit hoofdstuk). Als CAN-controller werd een SAE81C90 van Siemens gekozen. De CAN-transceiver is een L9615 van ST Microelectronics. De communicatie tussen beide borden gebeurt via een stuk flatcable. Bij een slecht functionerende CAN-bus kunnen eventueel hoge spanningspieken voor-

45

De CAN-interface bestaat uit een 8051-microcontroller en de nodige componenten om de koppeling met de CAN-bus te verzorgen. De voornaamste componenten zijn een CANcontroller om het CAN-protocol te implementeren en een CAN-transceiver om het digitale signaal van de CAN-controller om te zetten tot een analoog differentieel signaal voor op de CAN-bus. Hierbij fungeert de microcontroller als master voor de CAN-controller. Zoals aangehaald in het vorige hoofdstuk komen voor de CAN-bus vele mogelijkheden in aanmerking. Voor dit eindwerk werden de kabels voor de CAN-bus niet aangekocht, maar zelf gefabriceerd. Een eerste ontwerp van de CAN-interface bestaat uit de bovengenoemde componenten, met uitzondering van de microcontroller. Om de applicatie op de microcontroller tijdens de ontwikkelfase gemakkelijk te kunnen debuggen, hebben we er immers voor gekozen om met een (aangekocht) ontwikkelbordje te werken. Dat testbordje laat toe om het programma op de microcontroller te onderbreken, stap voor stap te laten uitvoeren en ondertussen de inhoud van de registers en het geheugen te bekijken. Via een flatcable wordt de microcontroller met de CAN-controller op het CAN-interface-bordje verbonden. Op die manier is de gerealiseerde functionaliteit dezelfde alsof de microcontroller en de CAN-controller zich op hetzelfde bordje zouden bevinden.

3.1.2

Overzicht van dit hoofdstuk

We zijn dit hoofdstuk over de hardware begonnen met dit inleidende deel waarin we de te realiseren en de gerealiseerde hardware geschetst hebben. Het volgende deel gaat over de interface tussen de microcontroller enerzijds en de CAN-bus anderzijds en vormt een omvangrijk deel van dit hoofdstuk. We bekijken hierin eerst het blokschema van deze CAN-interface. Wanneer we het vervolgens hebben over het ontwerp behandelen we eerst de componenten elk afzonderlijk om daarna het ontwerp zelf van nabij te bekijken. Daar wordt dan de samenhang van de componenten onderzocht en verklaard. Na het ontwerp van het CAN-interface-bord worden achtereenvolgens de koppeling met het microcontrollerbord en de koppeling met de CAN-bus besproken. Het laatste stuk over de CAN-interface behandelt een aantal mogelijke problemen bij het ontwerp en de realisatie van digitale hardware en geeft daarbij een aantal oplossingen en tips. Het derde deel van dit hoofdstuk gaat over de CAN-controller. Deze component wordt reeds besproken in het voorgaande deel over de CAN-interface, maar daar ligt de nadruk vooral op het hardwareaspect. In deel 3.3 gaat het daarentegen vooral over de mogelijkheden naar de software toe. Dezelfde redenering wordt toegepast in het vierde deel van dit hoofdstuk, waarin de gebruikte microcontroller nader bekeken wordt. Die aspecten van de microcontroller die van belang zijn voor onze applicatie worden toegelicht. Het ontwikkelbord waarop de

44

Figuur 3.1: Blokschema CAN-bus analyser. hardware-gedeelte van dit eindwerk bekijken, en zal ik ook proberen mee te geven wat ik geleerd en ervaren heb.

3.1.1

Blokschema

Figuur 3.1 toont het blokschema dat bij het begin van het academiejaar vooropgesteld werd. Op PC-niveau moest een applicatie geschreven worden die kon communiceren met andere CAN-knooppunten op de bus en die een CAN-bus-systeem kon testen. Daartoe was er een CAN-interface nodig om de kloof tussen PC en CAN-bus te dichten. Bij het begin van het academiejaar was het reeds duidelijk dat dit een vrij ambitieuze opdracht was. Er werd gekozen om de aandacht zoveel mogelijk te concentreren op het realiseren van de mogelijkheden van de CAN-bus en om daar de gebruiksvriendelijkheid van de applicatie gedeeltelijk voor op te offeren. Op PC-niveau was het de bedoeling om een grafische schil te maken voor de applicatie. Via seriële kabel (RS232) moest dan een verbinding opgezet worden met de CAN-interface. De PC is wel degelijk aanwezig in de gerealiseerde applicatie, maar dan in de vorm van de ontwikkelomgeving voor de microcontroller. Deze ontwikkelomgeving heeft uitgebreide mogelijkheden om de werking van de microcontroller te onderzoeken en het is dus via deze omgeving dat we een zicht hebben op het ontwikkelde programma en zijn werking. Het is duidelijk dat een grafische gebruikersinterface op PC-niveau het de gebruiker gemakkelijker maakt, maar de voornaamste uitdaging is gerealiseerd, met name het technische aspect van CAN-communicatie.

43

Hoofdstuk 3 Hardware 3.1

Inleiding

In het inleidende hoofdstuk hebben we aangehaald dat de centrale componenten voor de CAN-bus analyser oorspronkelijk een 8051-microcontroller en een CAN-controller (SJA1000) waren. Het ware ook mogelijk geweest om te kiezen voor een microcontroller met ingebouwde CAN-mogelijkheid. Een voordeel daarbij is dat er minder hardware nodig is. Een stand-alone CAN-controller zoals de SJA1000 wordt immers overbodig aangezien die al in de microcontroller zelf ge¨ıntegreerd is. Door het wegvallen van een aparte CAN-controller wordt de software ook een beetje eenvoudiger. De CAN-functionaliteiten worden dan beheerd door interne registers. Bij een afzonderlijke CAN-controller bevinden deze functionaliteiten zich in het externe datageheugen (nl. in de registers van de CAN-controller die extern zijn voor de microcontroller). Een ander voordeel is dat er een mogelijke bron van fouten en/of vertragingen geëlimineerd wordt. Zo heeft de communicatie tussen de microcontroller en de stand-alone CAN-controller voor een aantal problemen gezorgd. Waarom werd dan toch voor de oplossing gekozen waarbij de implementatie van het CAN-protocol gebeurt door een aparte CAN-controller? Het antwoord heeft te maken met mijn achtergrond als licentiaat informatica. Het creëren van zowel de hardware als de software was geen triviale zaak, maar voor mij was de hardware duidelijk een grotere en bijgevolg meer interessante uitdaging. In zekere zin ben ik op mijn wenken bediend geweest, omdat zoals gezegd de verbinding tussen microcontroller en CAN-controller niet zonder problemen tot stand gekomen is. Die problemen hebben gezorgd voor vertragingen, maar hebben me ook in staat gesteld om veel bij te leren over digitale communicatie. En ook dat bijleren is één van de doelen van een eindwerk. In dit hoofdstuk zullen we het

42

efficiënte communicatie te voeren. Om een taal te specificeren, heb je naast een lijst met de toegelaten woorden een grammatica nodig om zinnen te bouwen. Het CAN-protocol vormt de basis voor de communicatie, maar het is een protocol op een hoger niveau dat de semantiek zal vastleggen. Vooral wanneer het aantal knooppunten in het netwerk toeneemt, is er een nood aan een applicatielaag-protocol dat op papier staat. Dat kan een gestandaardiseerd protocol zijn of een aantal zelf gemaakte regels en afspraken. Eigenlijk pas je bij het gebruik van CAN altijd een soort applicatielaag-protocol toe, zij het dan niet bewust of toch alleszins niet expliciet neergeschreven. Vanaf het moment dat je beslist welke identifiers je zal gebruiken en wat ze zullen betekenen, ben je bezig met het uitvinden van een hoger niveau protocol. Het CAN-protocol op zich is nooit genoeg. Naar verluidt zijn er op dit moment meer dan veertig gestandaardiseerde hoger niveau protocollen. Vijf daarvan kunnen als de belangrijkste beschouwd worden, namelijk CAL/CANopen, CanKingdom, DeviceNet, SDS en J1939. Het CAL en het CANopen protocol werden ontwikkeld door CiA. CAL (CAN Application Layer) is het enige protocol dat zich qua functie zuiver op de applicatielaag bevindt. CANopen is een soort deelverzameling van CAL die wat eenvoudiger en concreter is. Het CanKingdom protocol is vooral bedoeld voor machinecontrole en werd geconcipieerd door Kvaser AB. DeviceNet en SDS werden voorgesteld door respectievelijk Allen-Bradley (nu Rockwell Automation) en Honeywell en zijn beiden geoptimaliseerd voor automatisering en communicatie in fabrieksomgevingen. Het J1939 protocol heeft als toepassing truck en bus controle en communicatie voor ogen en werd ontwikkeld door SAE International. Voor een mooi overzicht van deze 5 protocollen verwijzen we naar de site van Kvaser [17]. Het is moeilijk om te antwoorden op de vraag welk protocol nu het beste is. Uiteindelijk is er geen éénduidig antwoord en hangt het af van de toepassing. Het TTCAN-protocol (time-triggered CAN) is een relatief recent hoger niveau protocol dat misschien het vermelden waard is. TTCAN werd in 2000 gedefinieerd en heeft als bijzonderheid dat voor bepaalde CAN-boodschappen een zekere bandbreedte kan gereserveerd worden. Terwijl de ene boodschap bij wijze van spreken af en toe eens moet stoppen aan de verkeerslichten of in de file kan terechtkomen, krijgt de andere boodschap een eigen strook op de autosnelweg toegewezen. Voor meer informatie over dit protocol verwijzen we naar de CiA-website [12].

41

Figuur 2.14: Toestanden van een CAN-knooppunt. Moest deze uitzondering dus niet gemaakt worden, dan zou het knooppunt direct na het opstarten in de bus-off toestand terecht komen.

2.2.5

Applicatielaag

Het CAN-protocol definieert enkel de onderste twee lagen van het OSI-model, namelijk de fysische laag en de datalinklaag die we net uitvoerig behandeld hebben. Op dat niveau wordt gespecificeerd hoe kleine pakketten data getransporteerd moeten worden over een gemeenschappelijke drager. Het CAN-protocol bevat niks over flow controle (bv. tegen overflow), overdracht van datastructuren groter dan 8 byte, instellen van CAN-bus snelheid, . . . . Om de communicatie in een systeem in goede banen te leiden is er een hoger niveau protocol noodzakelijk, meer bepaald een applicatielaag-protocol. Een dergelijk protocol bepaalt volgende zaken. Bij het opstarten van het systeem wordt de snelheid van de bus afgesproken en ingesteld op dezelfde waarde. Elk knooppunt krijgt een uniek adres en een bepaald pakket identifiers om te gebruiken voor het verzenden van boodschappen. De layout en de betekenis van de boodschappen wordt vastgelegd. Tenslotte voorziet een applicatielaag-protocol ook routines voor status-informatie en foutafhandeling op systeemniveau. Het onderscheid tussen het CAN-protocol en protocollen op de hogere lagen in het OSI-model kan vergeleken worden met het verschil tussen letters en een taal. Letters vormen de basis om een taal te definiëren, maar zijn niet genoeg om betekenisvolle en

40

drie werkingsmodes worden hier besproken: • Fout-actief: In de fout-actieve toestand kan een knooppunt zonder restricties deelnemen aan de communicatie op het netwerk. Wanneer het een fout detecteert dan meldt het deze fout aan de overige knooppunten in het netwerk door het verzenden van een actieve fout-vlag. • Fout-passief: In de fout-passieve toestand kan een knooppunt nog steeds vrij deelnemen aan de communicatie op het netwerk. Het melden van fouten is echter aan beperkingen onderworpen en dient te gebeuren met een passieve fout-vlag die de huidige boodschap niet overschrijft. Het heruitzenden van de beschadigde boodschap mag pas starten na een extra wachttijd. • Bus-off: In deze toestand is een knooppunt afgeschakeld van het netwerk en kan het dus niet meer deelnemen aan de communicatie. Bovendien worden de uitgangsbuffers afgeschakeld zodat de busaansturing de fysische laag niet kan blokkeren. Figuur 2.14 is een toestandsdiagram dat de relatie toont tussen de werkingsmode van een CAN-knooppunt en de stand van de beide fouttellers. Na een hardware reset worden zowel de transmit error counter als de receive error counter op nul ge¨ınitialiseerd waardoor in de fout-actieve toestand wordt gestart. Wanneer één van de tellers de waarde 128 overschrijdt, verandert de werkingsmode naar fout-passief. Enkel wanneer beide tellers terug onder 128 zakken, wordt er teruggekeerd naar de fout-actieve toestand. Loopt de transmit error counter echter nog verder op dan wordt het knooppunt van het netwerk afgeschakeld (bus-off toestand) bij het overschrijden van de waarde 255. Enkel na een softwarematige reset en het 128 keer detecteren van 11 opeenvolgende recessieve bits kan een knooppunt de bus-off toestand verlaten. Tot slot zijn er nog twee opmerkingen te maken. Zoals blijkt uit figuur 2.14 kan een knooppunt enkel in de bus-off toestand terecht komen door het optreden van fouten tijdens het zenden. Verder is ook de behandeling van bevestigingsfouten speciaal. Enkel in de fout-actieve werkingsmode resulteert een dergelijke fout in een toename van de transmit error counter van een knooppunt. Hierdoor kan een knooppunt nooit in de bus-off toestand terecht komen als gevolg van bevestigingsfouten. Deze uitzondering is noodzakelijk aangezien bij het opstarten van een systeem een bepaald knooppunt de initialisatiefase sneller kan doorlopen. Dat knooppunt kan dan bijvoorbeeld reeds een boodschap verzenden op het moment dat alle andere knooppunten nog in de opstartfase zitten. Deze boodschap blijft dan onbevestigd en wordt na de foutmelding heruitgezonden.

39

gunstige en noodzakelijke eigenschappen voor gedistribueerde controlesystemen, zeker in het geval van ware-tijdssystemen. Indamming van fouten Binnen het CAN-protocol is er een fout-indammingsmechanisme dat in staat is om defecte knooppunten te herkennen en ze te isoleren van de rest van het netwerk. Ieder individueel knooppunt houdt daarvoor twee tellers bij, respectievelijk een zendfout-teller (transmit error counter, TEC) en een ontvangstfout-teller (receive error counter, REC). Wanneer een fout herkend wordt dan incrementeren de verschillende knooppunten hun respectievelijke tellers afhankelijk van de toestand waarin ze op dat ogenblik werken (zenden of ontvangen). De tellers worden gedecrementeerd telkens een boodschap door alle knooppunten correct wordt ontvangen. Het incrementeren verloopt echter met grotere stappen dan het decrementeren. Hierdoor kunnen de fouttellers als gevolg van frequente fouten over een langere periode toenemen, ook al is het aantal foutvrije boodschappen op het netwerk groter dan het aantal gedetecteerde fouten. Wanneer een fout echter slechts sporadisch optreedt, dan zullen de tellers als gevolg van de lange foutvrije tussenliggende periodes afnemen. De stand van de fouttellers vormt als zodanig een relatieve maat voor het optreden van fouten. Op basis van dit principe is het CAN-protocol in staat toevallige fouten te onderscheiden van permanente fouten. Naast het zuiver registreren van fouten wordt bovendien ook rekening gehouden met de oorzaak van de fouten. Zoals we reeds aangehaald hebben, kan een knooppunt door het principe van primaire en secundaire foutmeldingen te weten komen of het een fout als eerste herkende. In dat geval is de fout waarschijnlijk een lokale fout en is de kans groot dat het betreffende knooppunt de fout veroorzaakte. Wanneer een knooppunt met een secundaire foutmelding op de hoogte gebracht wordt van een foutieve boodschap, dan heeft dit knooppunt vrijwel zeker niets te maken met het ontstaan van de fout. Door in het eerste geval de fouttellers sterker te incrementeren dan in het tweede geval, wordt er rekening gehouden met lokale fouten die toegewezen kunnen worden aan individuele knooppunten. In een systeem waar één of beide fouttellers van een bepaald knooppunt plots zeer sterk toenemen, is de kans zeer groot dat dit knooppunt beschadigd werd. In de fout-indamming of anders gezegd de fout-encapsulatie staan de waarden van de fouttellers centraal. Afhankelijk van deze waarden zijn er verschillende werkingsmodes waarin een CAN-knooppunt zich kan bevinden. Telkens bij het overschreiden van een vastgelegde grenswaarde wordt er overgegaan naar een andere werkingsmode die dan extra beperkingen oplegt aan de interactie tussen het knooppunt en de fysische laag. De

38

• Bitcoderingsfout : Een bitcoderingsfout is een fout tegen de bit-stuffing coderingsregel. Deze fout treedt op van zodra een knooppunt een opeenvolging van zes bits met hetzelfde niveau detecteert tijdens een veld dat aan deze coderingsregel onderworpen is. Het gaat hierbij over het start-of-frame-veld, het arbitrage-veld, het controle-veld, het data-veld en de 15-bit CRC-waarde. De overige velden hebben een vaste codering (nl. het CRC-afsluitbit, het bevestigingsveld en het end-of-frameveld). Foutmelding en herstelling Na het herkennen van een fout door een bepaald knooppunt wordt deze fout gemeld door het verzenden van een error frame. De verschillende knooppunten voeren de foutdetectie individueel uit, waardoor ook meerdere foutmeldingen gelijktijdig kunnen optreden. De foutmelding wordt waargenomen door alle overige knooppunten in het netwerk onder de vorm van een coderingsfout. Zowel de foutmelding als de herkenning ervan door de overige knooppunten verloopt vrijwel ogenblikkelijk. De foutmelding heeft als gevolg dat de boodschap die verzonden wordt, afgebroken wordt en dat alle knooppunten het tot dan toe ontvangen deel van deze foutieve boodschap wegwerpen. Nadat het netwerk opnieuw vrij is, wordt de volledige boodschap heruitgezonden. Dit betekent dat het zendknooppunt opnieuw aan de arbitragecyclus moet deelnemen. Indien ondertussen een andere boodschap met een hogere prioriteit klaar staat voor verzending door een ander knooppunt, dan zal de heruitgezonden boodschap moeten wachten. Bij het heruitzenden van een boodschap wordt echter wel rekening gehouden met de toestand van het zendknooppunt (fout-actief of fout-passief). Zoals werd besproken moet een fout-passief knooppunt na het verzenden van een foutieve boodschap een extra wachttijd in acht nemen (het transmissieuitstel-veld). Dat veld voorkomt dat een beschadigd knooppunt het netwerk volledig of gedeeltelijk kan blokkeren door het permanent heruitzenden van een in zijn opzicht beschadigde boodschap. In het ergste geval zou deze boodschap nog eens een hoge prioriteit kunnen hebben. Het gevolg van deze vorm van foutmelding en -herstelling is dat er dataconsistentie is binnen het gehele netwerk. Een boodschap wordt ofwel gelijktijdig door alle knooppunten in het netwerk als correct beschouwd of in het andere geval, door alle knooppunten in het netwerk verworpen. Alle knooppunten zien dus consistent dezelfde (correcte) informatie. Een ander gevolg is de uiterst korte fouthersteltijd. De foutmelding vindt immers plaats nog tijdens de boodschap zelf. Dataconsistentie en een korte fouthersteltijd zijn twee

37

De foutbehandeling binnen het CAN-protocol steunt op een combinatie van positieve en negatieve bevestiging. De positieve bevestiging gebeurt per bericht aan de hand van het vroeger besproken bevestigingsveld (acknowledge field). Ieder knooppunt in het netwerk dat een boodschap correct ontvangt, overschrijft het uitgezonden recessief bit in dit veld door een dominant bit. De zender kan hieruit afleiden dat ten minste één knooppunt de uitgezonden boodschap correct heeft ontvangen. De negatieve bevestiging gebeurt onder de vorm van een foutmelding gericht aan alle knooppunten in het netwerk en wordt verzonden direct na het detecteren van de fout (m.a.w. nog tijdens de boodschap die een fout bevat). Het voordeel van deze combinatie van positieve en negatieve bevestiging is de mogelijkheid om fouten te lokaliseren. Hierdoor kunnen knooppunten die veel fouten veroorzaken ge¨ıdentificeerd worden en vervolgens van de bus gegooid worden. Soorten gedetecteerde fouten De CAN-foutbehandeling is in staat vijf verschillende soorten fouten te ontdekken: • Bitfout : Ieder zendknooppunt bekijkt bij het verzenden van een bit of deze ook daadwerkelijk op het netwerk komt. Komen beide waarden niet overeen dan is er een bitfout opgetreden. Uiteraard wordt het overschrijven van een uitgestuurd recessief bit door een dominant bit van een ander knooppunt tijdens de arbitrage of in het bevestigingsveld niet als een bitfout zien. • Formaatfout : Elk type boodschap heeft een strikt gedefinieerd formaat. De consistentie van dat formaat wordt bewaakt door alle knooppunten in het netwerk. Wanneer een knooppunt één of meerdere niet toegelaten bitwaarden detecteert in een veld met een vast formaat, dan wordt dit gemeld als een formaatfout. • CRC-fout : Bij het verzenden van een data frame of een remote frame voert de zender een cyclische redundantietest uit. Het resultaat wordt meegegeven in het CRCveld van de boodschap. De verschillende ontvangers berekenen de CRC-sequentie op dezelfde manier als de zender. Wanneer de boodschap beschadigd wordt, dan zullen de door de ontvangers berekende waarden niet meer overeenstemmen met de waarde in het CRC-veld en treedt er een CRC-fout op. • Bevestigingsfout : Een boodschap dient als correct bevestigd te worden door tenminste één ontvangstknooppunt. Het ontbreken van een dominant bit tijdens het bevestigingstijdslot betekent dat er een bevestigingsfout opgetreden is.

36

de overige knooppunten in het netwerk de kans om hun boodschappen te verzenden. De (normale) situatie waarbij een knooppunt zich in fout-actieve toestand bevindt of waarbij het niet de zender was van de vorige boodschap wordt voorgesteld in figuur 2.12. Bij de voordelen van het CAN-protocol hebben we aangehaald dat het real-time gedrag heel goed is en dat de toegangstijd tot het netwerk voor een boodschap met de hoogste prioriteit ongeveer 125 µs is bij een bitrate van 1 Mbit/s. We hadden beloofd te tonen waar dit getal vandaan komt. Nu we de volledige structuur van de verschillende boodschaptypes besproken hebben, kunnen we die kennis gebruiken om de toegangstijd van een boodschap met hoge prioriteit te berekenen. Aangezien een boodschap met de hoogste prioriteit de arbitrage altijd zal winnen, moet er slechts gewacht worden tot de huidige boodschap op de bus afgelopen is. Het slechtste geval voor de toegangstijd tot de bus is dus wanneer we een boodschap willen verzenden op het moment dat de bus nog maar net bezet is en dit door de langst mogelijke CAN-boodschap. We verwijzen naar figuur 2.7 voor de structuur van een data frame. Het start-of-frame bit en het arbitrageveld omvatten in het slechtste geval 30 bits. Een uitgebreide CAN 2.0b identifier is immers 29 bits lang. Het controleveld is 6 bits groot. Het dataveld is maximaal 8 bytes of dus 64 bits lang. Het CRC-veld, het ACK-veld en het end-of-frame veld zijn respectievelijk 15, 2 en 7 bits lang. Op dit punt begint de interframe space en moeten we op zijn minst 3 bits wachten (pauzeveld) om een nieuwe boodschap op de bus te plaatsen. Alles samengeteld komen we op 127 bits wachttijd. Bij een bitrate van 1 Mbit/s duurt een bit één µs en bedraagt de toegangstijd dus ongeveer 125 µs. Op de website [16] kan onze berekening gecontroleerd worden. Wanneer rekening gehouden wordt met eventuele stuff bits vergroot de toegangstijd nog een beetje. Foutbehandeling Een klassieke techniek om informatie op een veilige manier te transporteren, is het positief bevestigen van een correct ontvangen bericht. Dit gebeurt meestal door het terugzenden van een bevestigingsboodschap (ACK of acknowledgement) van de ontvanger naar de zender. Bij het CAN-protocol is het adres van de zender niet gekend (althans niet op de datalinklaag). Protocols uit de applicatielaag kennen aan elk CAN-knooppunt een aantal bericht-identifiers toe die enkel door dat knooppunt mogen gebruikt worden. Op dat niveau is er dus een verband tussen de identifier van een bericht en de identiteit van de zender. Het CAN-protocol zelf bevindt zich op de datalinklaag en heeft enkel weet van de bericht-identifiers. Bijgevolg kan positieve bevestiging alleen niet gebruikt worden bij de foutbehandeling.

35

Figuur 2.12: De interframe space (in fout-actieve toestand).

Figuur 2.13: De interframe space (in fout-passieve toestand). mogen de verschillende knooppunten een overbelasting signaleren. Het verzenden van een gewone boodschap mag pas tijdens het bus-idle veld. Dit veld heeft een arbitraire lengte en geeft aan dat de bus vrij is. Een fout-passief knooppunt dat de zender was van de voorgaande boodschap moet nog een extra tijd wachten en mag pas na het transmissieuitstelveld (suspend-transmission field) starten met het verzenden van een nieuwe boodschap (figuur 2.13). Dit veld heeft een vaste lengte van 8 recessieve bits. Bij een knooppunt dat zich in de fout-passieve toestand bevindt, is de kans immers groot dat er iets mis is met het knooppunt zelf, waardoor boodschappen als gevolg van de foutbehandeling telkens opnieuw worden verzonden. Hierdoor kan het correct functioneren van het gehele netwerk in het gedrang komen. Door het invoeren van de extra wachttijd als gevolg van het suspend-transmission veld krijgen

34

Zoals we verder zullen bespreken, zal in een dergelijke situatie het knooppunt dat niet goed functioneert in een toestand terechtkomen waarbij de mogelijkheid tot foutmelding beperkt wordt. Een knooppunt mag dan nog enkel passieve fout-vlaggen versturen. Deze bestaan uit 6 recessieve bits die in tegenstelling tot een actieve fout-vlag de niveaus op het netwerk niet verstoren. Na het verzenden van een fout-vlag start een knooppunt met het verzenden van recessieve bits en bekijkt per bit het resulterende busniveau. Nadat het netwerk effectief in recessieve toestand komt, worden 7 recessieve bits verzonden die samen het afsluitveld vormen. Op deze manier kan een knooppunt te weten komen of het als eerste de fout heeft vastgesteld. In dit geval verstuurt het knooppunt immers als eerste een fout-vlag. De hieruit resulterende foutmeldingen door de overige knooppunten zorgen ervoor dat het netwerk niet direct in recessieve toestand zal verkeren. Men spreekt respectievelijk van primaire en secundaire foutmeldingen. Dit principe is van belang voor de fout-indamming die we verder zullen bespreken. OVERLOAD FRAME. Met een overload frame laat een knooppunt aan alle andere knooppunten weten dat het tijdelijk niet in staat is een nieuwe boodschap te verwerken. Hierdoor wordt de start van een volgend data frame of remote frame uitgesteld tot na het einde van het overload frame. Er mogen ten hoogste twee overload frames gegenereerd worden om een volgende boodschap uit te stellen. De opbouw van een overload frame is identiek aan deze van een error frame. Ze bestaat uit een eerste veld dat kan worden opgebouwd uit de superpositie van overloadvlaggen, afkomstig van de verschillende knooppunten in het netwerk. Het tweede veld is het afsluitveld (overload delimiter) dat bestaat uit acht recessieve bits. Een overload-vlag is een opeenvolging van zes dominante bits. Een overload frame kan dus beschouwd worden als een speciaal error frame. Het verschil in interpretatie volgt uit de plaats waar het overload/error frame begint. Een error frame komt voor tijdens een data frame of remote frame. Een overload frame daarentegen wordt verzonden tijdens de boodschap-tussenruimte. INTERFRAME SPACE. De “interframe space” (boodschap-tussenruimte) is niet echt een boodschaptype, maar wordt binnen het CAN-protocol wel op die manier behandeld. Zowel data frames als remote frames worden van elkaar gescheiden door de interframe space. De opbouw ervan is afhankelijk van de toestand van een knooppunt en wordt voorgesteld in figuren 2.12 en 2.13. Het pauzeveld (intermission field) is steeds drie recessieve bits lang. Tijdens dit veld

33

Figuur 2.11: Het formaat van een error frame. ERROR FRAME. Wanneer een willekeurig knooppunt een fout ontdekt in een boodschap dan wordt dit meteen aan alle andere knooppunten in het netwerk meegedeeld. Deze melding gebeurt reeds tijdens de eigenlijke boodschap. Hierdoor weten alle knooppunten dat ergens in het netwerk de huidige boodschap beschadigd werd en ze dus niet verder verwerkt mag worden. Het verzenden van de boodschap wordt stopgezet en de foutbehandeling treedt in werking. Wanneer geen enkele ontvanger een error frame op de bus plaatst, weet het zender-knooppunt dat alle knooppunten op de bus zijn boodschap correct ontvangen hebben. Het signaleren van een fout gebeurt door middel van een error frame (figuur 2.11). Dit bestaat uit twee velden. Het eerste veld wordt opgebouwd uit de superpositie van de verschillende fout-vlaggen, afkomstig van de verschillende knooppunten in het netwerk en is 6 tot 12 bits lang. Het tweede veld is een afsluitveld (error delimiter) dat bestaat uit 8 recessieve bits. Een fout-vlag bestaat uit een opeenvolging van 6 bits met een gelijk niveau. Net zoals bij het end-of-frame veld in een data frame vormt dit een inbreuk op de bit-stuffing regel. Wanneer het knooppunt dat de fout origineel ontdekt heeft een fout-vlag op het netwerk plaatst, dan genereert dit een coderingsfout bij alle andere knooppunten in het netwerk. Deze knooppunten sturen dan op hun beurt ook een fout-vlag uit. De verschillende foutvlaggen overschrijven elkaar en overlappen elkaar in het eerste veld van het error frame. Er zijn twee soorten fout-vlaggen. Normaal gezien verstuurt een knooppunt een actieve fout-vlag die bestaat uit 6 dominante bits. Hierdoor wordt de foute boodschap onder alle omstandigheden overschreven. Wanneer de fout echter niet door het netwerk veroorzaakt wordt, maar wel door het niet correct functioneren van het knooppunt zelf, dan kan dit knooppunt door het sturen van valse error frames het gehele netwerk onbruikbaar maken.

32

zes. Er kunnen dus tot zes enkelvoudige bitfouten gedetecteerd worden. Bevestigingsveld (acknowledge field). Het bevestigingsveld bestaat uit een “acknowledge slot” van 1 bit lang, gevolgd door een recessief afsluitbit (acknowledge delimiter) (figuur 2.10). Knooppunten die na het ontvangen van het CRC-veld het bericht als correct beschouwen, bevestigen dit door het verzenden van een dominant bit tijdens het bevestigingstijdslot. De zender van het bericht zelf zet gedurende dit tijdslot een recessief bit op het netwerk en verwacht dat dit overschreven wordt. Het ontbreken van een dominant bit in dit tijdslot signaleert dat geen enkel knooppunt het bericht ontvangen heeft. De zender zal in dit geval een error frame verzenden (zie verder). De bevestiging van een correct ontvangen bericht gebeurt onafhankelijk van het feit of de ontvanger dat bericht al dan niet effectief binnenneemt. Als er geen enkele bevestiging komt, is het knooppunt dat de boodschap verzonden heeft helemaal alleen op de bus of is het knooppunt door een fysisch probleem afgezonderd van de rest van het netwerk. Einde van de boodschap (end-of-frame). Het end-of-frame (EOF) veld sluit de boodschap af en bestaat uit 7 opeenvolgende recessieve bits. Hierdoor wordt een fictieve bewuste coderingsfout ge¨ıntroduceerd. De bit-stuffing regel laat slechts 5 opeenvolgende bits met hetzelfde niveau toe, maar deze regel geldt niet voor het end-of-frame veld. Wanneer echter een knooppunt een ernstig beschadigde boodschap ontvangt, waarbij de interpretatie van de velden volledig in het honderd loopt, dan zal het end-of-frame veld als een echte coderingsfout aanzien worden en zal dit knooppunt een error frame versturen. Hierdoor komen alle knooppunten opnieuw in dezelfde correcte werkingstoestand. REMOTE FRAME. Met een remote frame kan een willekeurige ontvanger aan een bepaalde zender vragen een bepaald data frame te verzenden. De aangevraagde boodschap wordt gespecifieerd door de message identifier van het remote frame. Een aanvraag naar dezelfde informatie kan in principe gelijktijdig gebeuren door verschillende ontvangers. De aangevraagde boodschap mag echter door slechts één enkel knooppunt verzonden worden. De aanvraag en het antwoord zijn twee afzonderlijke boodschappen die niet noodzakelijk vlak achter elkaar hoeven te komen. Als gevolg van het CAN-communicatiemodel kan naast de eigenlijke aanvrager ook ieder ander knooppunt de aangevraagde boodschap binnenhalen. Dit is van belang voor de dataconsistentie van het netwerk. Het formaat van een remote frame is grotendeels hetzelfde als dat van een data frame, met dit verschil dat het data-veld bij een remote frame ontbreekt. Het DLC-veld staat altijd op 0. Het verschil tussen een remote frame en een data frame zit hem in het RTR-bit van het arbitrage-veld. Een remote frame komt overeen met een recessief RTR-bit.

31

Figuur 2.10: Het CRC-veld en het bevestigingsveld (ACK). hoogste 11 identifierbits van beide frames zijn gelijk, dan zal het uitgebreide frame de arbitrage verliezen. Het SRR-bit van deze is immers recessief. De reden waarom twee verschillende formaten worden ondersteund, ligt in het aantal mogelijk message identifiers. Met de 11 bits uit het standaard formaat kunnen 2048 verschillende soorten berichten verstuurd worden. In het uitgebreide formaat zijn er 229 verschillende identifiers mogelijk. De uitgebreide variant wordt niet zo vaak meer gebruikt omwille van de extra overhead, tenzij er heel veel identifiers nodig zijn. Controle-veld. Het controle-veld dat ook in figuren 2.8 en 2.9 is weergegeven, is opgebouwd uit 6 bits. De functie van het eerste bit is afhankelijk van het formaat van het frame. In het uitgebreide formaat doet dit bit dienst als IDE-bit en in het standaard formaat wordt het niet gebruikt. Het tweede bit wordt in beide formaten niet gebruikt. De laatste vier bits geven aan uit hoeveel bytes het data-veld zal bestaan (DLC, of datalengte-code). Data frames zonder data worden toegelaten door het protocol. In dit geval is het DLC-veld 0. Een data frame mag maximaal 8 databytes transporteren. Data-veld. Het data-veld bevat de eigenlijke informatie die getransporteerd wordt in het bericht. De lengte ervan wordt vastgelegd in het controle-veld. De meest significante bit van elk informatiebyte wordt eerst verzonden. CRC-veld. Het CRC-veld bevat het 15 bit resultaat van een cyclische redundantietest, afgesloten door één extra recessief afsluitbit (figuur 2.10). Deze CRC-test wordt uitgevoerd op alle voorgaande velden en wordt enkel gebruikt voor het detecteren en niet voor het corrigeren van fouten. Het gebruikte CRC-polynoom heeft een Hamming-afstand van

30

Figuur 2.8: Het arbitrage-veld (standaard versie).

Figuur 2.9: Het arbitrage-veld (uitgebreide versie). respectievelijk het standaard en het uitgebreide formaat. Het uitgebreide formaat werkt met een identifier van 29 bits. Die wordt opgesplitst in twee delen. De 11 meest beduidende bits worden eerst doorgestuurd. Zij vormen de basisidentificatie (base ID) en komen overeen met de identifier uit het standaard formaat. Hierna volgt een recessief substituut bit (SRR) voor de RTR-bit die nu verplaatst is naar het einde van het arbitrage-veld. De IDE-bit heeft nu een recessief niveau wat aangeeft dat er nog 18 identifier-bits zullen volgen. Versie 2.0A van het CAN-protocol ondersteunt enkel het standaard formaat. De versie 2.0B ondersteunt zowel het standaard als het uitgebreide formaat. In een netwerk waarbij alle CAN-bouwstenen aan versie 2.0B voldoen kunnen boodschappen dus zowel volgens het standaard als het uitgebreide formaat uitgewisseld worden. Wanneer een data frame in standaard formaat in arbitrage is met een data frame in uitgebreid formaat en de

29

Figuur 2.7: Algemeen formaat van een data frame. in de gegevensuitwisseling, maar zorgen voor de veiligheid en betrouwbaarheid van het datatransport. Een error frame signaleert de detectie van een fout op de fysische laag. Zowel de zender als de ontvangers kunnen fouten melden. Een overload frame wordt gebruikt om aan te geven dat een ontvanger overbelast is. Het resultaat is dat er wat langer gewacht wordt vooraleer het verzenden van het volgende data frame. De data frames en remote frames worden gescheiden van elkaar door de boodschaptussenruimte (de “interframe space”). Elk van de boodschaptypes bestaat uit een bepaald aantal bits, die in verschillende velden opgedeeld worden. In de volgende secties gaan we dieper in op het formaat en de functie van de boodschappen. DATA FRAME. Figuur 2.7 toont het algemene formaat van een data frame. Een data frame bestaat uit 7 velden. Start van de boodschap (start-of-frame). De start van een data frame (of een remote frame) wordt aangekondigd door het start-of-frame (SOF) veld dat bestaat uit één enkel dominant bit. Zoals werd besproken mag een knooppunt enkel starten met het verzenden van een nieuwe boodschap wanneer het netwerk vrij is. Dit is het geval na 11 opeenvolgende recessieve bits. Arbitrage-veld. Het arbitrage-veld bestaat uit de boodschapidentificatie (message identifier) en de remote-transmission-request bit (RTR). De RTR-bit geeft aan of de boodschap een data frame is (RTR-bit dominant) of een remote frame (RTR-bit recessief). Het CAN-protocol voorziet twee formaten voor het arbitrage-veld. In het standaard formaat bestaat de identifier uit 11 bits. Het arbitrage-veld wordt opgebouwd uit de message identifier gevolgd door het RTR-bit. Het standaard formaat wordt aangeduid door een dominant identificatie-extensie-bit (IDE) in het controle-veld. Figuren 2.8 en 2.9 tonen

28

Wanneer een knooppunt een recessief bit heeft verzonden, maar een dominant bit op de bus waarneemt, weet dat knooppunt dat er een ander knooppunt een boodschap op de bus aan het zetten is met een hogere prioriteit. In dat geval zal het knooppunt zich terugtrekken uit het arbitrageproces en zichzelf direct in de ontvangstmode plaatsen om de boodschap met hogere prioriteit eventueel binnen te nemen (afhankelijk van de filtering). Omdat de boodschap-identifiers uniek zijn, blijft er na arbitrage slechts één knooppunt over. Na het verzenden van de boodschap komt het netwerk weer vrij en kan een nieuwe arbitragecyclus beginnen waaraan de eventuele afgevallen knooppunten opnieuw kunnen deelnemen. Als een dominant busniveau overeenkomt met een logische 0 dan verhoogt de prioriteit van een boodschap naarmate haar identifier kleiner is. Het kan ook voorkomen dat een dominant bit wordt uitgezonden, maar dat een recessief bit op de bus wordt waargenomen. Dit is een bitfout op de fysische laag. Deze situatie wordt opgevangen door de foutbehandeling van het CAN-protocol (zie verder). Dit arbitrageprincipe heeft een aantal specifieke voordelen. Ten eerste is er een direct verband tussen de prioriteit van een boodschap en de informatie die ze bevat. Ten tweede is de arbitrage niet-destructief. De boodschap die de arbitrage wint wordt niet beschadigd door het arbitrageproces en het verzenden kan daarom gewoon doorgaan op het punt dat de arbitrage gewonnen wordt (in tegenstelling tot het gewone CSMA-principe bij bv. het ethernet-protocol). Dit verlaagt de toegangstijd tot het netwerk. Het derde voordeel is dat het arbitrageprincipe het mogelijk maakt om een deterministische toegangstijd te hebben. Een boodschap met hoge prioriteit moet enkel wachten tot de huidige boodschap afgelopen is en een CAN-boodschap heeft een vaste en eindige maximale lengte. Deze derde voordelige eigenschap van het arbitragemechanisme is onder andere van belang voor real-time systemen. Boodschaptypes Er bestaan vier soorten boodschappen in het CAN-protocol. Dat zijn de data frames (informatie-boodschappen), remote frames (informatieaanvraag-boodschappen), error frames (fout-boodschappen) en tenslotte de overload frames (overlast-boodschappen). De eerste twee worden gebruikt voor de eigenlijke gegevensuitwisseling. Een data frame transporteert data van één zender naar één of meerdere ontvangers. Het initiatief om informatie te verzenden wordt daarbij genomen door de zender. Een remote kan door één of meerdere ontvangers verzonden worden om een welbepaalde zender te vragen een bepaald data frame op het netwerk te plaatsen. In dit geval wordt het initiatief genomen aan de ontvangstzijde. De overige twee boodschaptypes komen niet rechtstreeks tussen

27

Deze garantie is mogelijk door de principes van positieve en negatieve bevestiging (met behulp van acknowledgements en foutboodschappen). Het communicatiemodel van het CAN-protocol verschilt dus duidelijk van de meeste andere netwerkprotocols, aangezien er klassiek bij een bericht altijd een bron- en/of bestemmingsadres gespecifieerd wordt. Toegang tot de bus Zoals reeds vermeld, werkt het CAN-communicatiemodel volgens het multi-master principe. Dit houdt in dat elk knooppunt zelfstandig het initiatief kan nemen om een boodschap te verzenden wanneer het netwerk vrij is. Hierdoor kunnen busconflicten optreden. Wanneer meerdere knooppunten gelijktijdig beslissen om een boodschap te verzenden over de gemeenschappelijke fysische laag, zijn de overige knooppunten niet meer in staat de verzonden boodschappen correct te ontvangen. De verschillende zenders overschrijven immers elkaars informatie. Daarom moet er dus een vorm zijn van bustoegangsbeheer. Bij CAN is dit gebaseerd op arbitrage. Iedere boodschap krijgt een unieke prioriteit toegewezen die in verband staat met de informatieinhoud. De verschillende knooppunten die een boodschap willen verzenden, doorlopen een arbitragecyclus. Na het beëindigen van die cyclus krijgt de boodschap met de hoogste prioriteit de toegang tot de fysische laag. De prioriteit van een boodschap wordt bepaald door de boodschap-identifier. Dit principe noemt men CSMA/CD+AMP. Dit staat voor Carrier Sense Multiple Access/Collision Detection + Arbitration on Message Priority. De vorm van arbitrage die toegepast wordt, is niet-destructieve bitsgewijze arbitrage. Het feit dat er dominante en recessieve signaalniveaus zijn op de fysische laag is essentieel hiervoor. Wanneer een knooppunt een boodschap wil verzenden dan wordt gewacht tot het netwerk vrij is. Dit wordt gedetecteerd door het ontvangen van een aantal opeenvolgende recessieve bits. Eenmaal dit het geval is, start het knooppunt met het verzenden van het “start-of-frame”-veld (SOF-veld) dat bestaat uit één enkele dominante bit. Dit markeert het begin van een nieuwe boodschap. Stel dat een ander knooppunt op dit moment ook begint met het verzenden van een boodschap. In dat geval plaatsen beide knooppunten een dominant bit op het netwerk, maar ze merken dat niet van elkaar. Na het SOF-bit starten de knooppunten met het arbitrageveld. Het arbitrageveld is opgebouwd uit de boodschap-identifier gevolgd door de “remote transmission request”-bit (zie verder). Na elk verzonden bit uit het arbitrageveld vergelijken de verschillende knooppunten hun bit met de bitwaarde die ze op de bus waarnemen.

26

Een gevolg hiervan is dat ten opzichte van een vast referentiespanningsniveau van 2.5 V een onderscheid kan gemaakt worden tussen een dominant en een recessief bit. Dit laat toe om bij onderbreking van één van de busgeleiders de communicatie als noodoplossing over de andere busgeleider verder te laten gaan. De communicatie gebeurt dan weliswaar niet meer differentieel en is dus foutgevoeliger. De ISO 11519-2 standaard wordt naar verluidt binnenkort ingetrokken. Er wordt gewerkt aan een opvolger. Voor meer informatie verwijs ik naar de website van CAN in Automation [11].

2.2.4

Datalinklaag

Taken Net zoals de fysische laag, is ook de datalinklaag opgebouwd uit een aantal sublagen. Er is de Logical Link Control sublaag (LLC) en de Medium Access Control sublaag (MAC). De LLC-sublaag behandelt de functies die te maken hebben met het filteren van boodschappen, het melden van een busoverbelasting en het herstellen van fouten. De MAC-sublaag is belast met de encapsulatie en de decapsulatie van data, de boodschapcodering, het bustoegangsbeheer, de detectie en signalisatie van fouten, het bevestigen van boodschappen en de serialisatie van data naar de fysische laag toe. Communicatiemodel CAN-knooppunten wisselen informatie uit onder de vorm van boodschappen (messages). Deze boodschappen zijn korte datapakketten die voorzien zijn van een identificatie (identifier). De identifier is een aanduiding van de inhoud van de boodschap. Het is als het ware de naam of het label dat weergeeft welke informatie getransporteerd wordt in de boodschap. De identifier geeft dus niet weer waar de informatie vandaan komt of waar ze naar toe moet. Met andere woorden, ze bevat geen adresinformatie over de zender of de ontvanger van de boodschap. Op basis van de identifier van een boodschap beslist een knooppunt op het netwerk of de informatie in die boodschap al dan niet van belang is. Elk knooppunt past dus een eigen filtering toe op de boodschappen die op het netwerk komen. Dit maakt het mogelijk om op een flexibele manier informatie te verzenden naar één enkel knooppunt (punt-totpunt communicatie) of naar alle knooppunten in het netwerk (multicast-communicatie). De zender plaatst een boodschap op het netwerk en weet in principe niet of enig ander knooppunt zijn informatie zal binnennemen. Hij krijgt van het protocol wel de garantie dat zijn boodschap door alle knooppunten op de bus zonder fouten werd waargenomen.

25

Figuur 2.6: Pinnen van een 9-polige SUBD-connector. zijn differentieel. Een logisch niveau van 1 is recessief en komt overeen met een spanning op beide signaallijnen van 2.5 V. Een dominant logisch niveau 0 komt overeen met een spanningsverschil van 2 V op de twee lijnen. De CAN H-lijn heeft dan een spanning van 3.5 V en de CAN L lijn 1.5 V. De twee draden van de bus mogen parallel, gedraaid en/of afgeschermd uitgevoerd worden. Het voordeel van het gebruik van twee draden en differentiële spanningsniveau’s is de ongevoeligheid voor elektromagnetische storing. Beide draden ondervinden immers dezelfde storing maar de verschilspanning tussen de twee draden blijft gelijk. Een connector om knooppunten op de bus aan te sluiten zou in principe een nominale impedantie moeten hebben van 120 ohm en een nominale transmissieweerstand van 70 mOhm. De CAN-bus-lijnen moeten een nominale impedantie hebben van 120 ohm en een weerstand van 70 mOhm/m en een nominale lijnvertraging van 5 ns/m. De CANstandaard stelt geen verdere eisen aan de gebruikte connectoren. Het is evenwel vaak zo dat een applicatielaag-protocol een voorkeur aangeeft voor een bepaald type connector. Het meest gebruikte type is de 9-polige sub-D connector zoals voorgesteld en aangeraden door CAN in Automation (CiA). Figuur 2.6 toont de pin-nummering en de functies van de pinnen. De pinnen 2 en 7 vormen de CAN L- en de CAN H-lijnen en op pin 3 wordt de gemeenschappelijke grond van deze twee signalen doorgestuurd. Optionele pinnen zijn een extra grondlijn (pin 6) en een voedingslijn (pin 9). De ISO 11519-2 standaard wordt tegenwoordig niet meer zo vaak gebruikt. Deze standaard is de lage-snelheidsversie van ISO 11898. De standaard is ontworpen voor een “korte” bus bij maximale snelheden van 125 kbit/s. Er zijn geen terminatieweerstanden nodig, met als gevolg dat de busaansturing minder vermogen moet leveren en het ruststroomverbruik veel lager is. Er mogen maximaal 20 knooppunten op de bus aangesloten worden bij deze standaard. Figuur 2.5 toont nog een duidelijk verschil met ISO 11898. De buslijnen vertonen zowel bij dominante als bij recessieve toestand een verschilspanning.

24

Figuur 2.4: Opbouw bus signaalniveau’s bij ISO 11898.

Figuur 2.5: Opbouw bus signaalniveau’s bij ISO 11519-2. de “stubs” of dus de verbindingen tussen de knooppunten en de bus zo kort mogelijk te maken. Dit is vooral van belang bij hoge datasnelheden. Bij een snelheid van 1 Mbit/s zouden de lengtes van de stubs niet groter mogen zijn dan 30 cm. De signaalniveau’s

23

Figuur 2.3: Opbouw van een bit in 4 tijdssegmenten. mee een fasebuffersegment maximaal verlengd of ingekort kan worden, noemt men de “synchronisation jump width” (SJW). Er zijn twee gevallen mogelijk. Het kan zijn dat de oscillator van de zender trager loopt dan die van de ontvanger. In dat geval merkt de ontvanger een signaalflank in het propagatiesegment, terwijl hij die normaal verwacht tijdens het synchronisatiesegment. De hersynchronisatie bestaat dan uit het verlengen van het eerste fasebuffersegment. In het andere geval loopt de oscillator van de zender sneller dan die van de ontvanger. De signaalflank komt dan te vroeg (nog voor het synchronisatiesegment). In dit geval voert de ontvanger een hersynchronisatie uit door het tweede fasebuffersegment te verkorten. Elektrische werking De elektrische werking van het CAN-protocol is vastgelegd in ISO 11898 en ISO 11519-2. Deze standaarden definiëren respectievelijk een fysische laag op hoge snelheid en een nog meer fouttolerante versie op lage snelheid. Bij ISO 11898 is de theoretische maximale buslengte bij een snelheid van 1 Mbit/s gelijk aan 40 m. De werkelijke maximale buslengte hangt af van de instelling van de bittiming. Aan snelheden lager dan 1 Mbit/s mag de bus langer gemaakt worden. De maximale buslengte is 1 km bij een snelheid van 50 kbit/s. Het totaal aantal CANknooppunten op de bus bedraagt maximaal 30 stuks. Om het aantal knooppunten op te drijven, kunnen bruggen of repeaters gebruikt worden. Zoals op figuur 2.4 te zien is, bestaat het fysische medium uit een lijn met twee draden die aan beide uiteinden getermineerd wordt met een weerstand van 120 ohm. De toegelaten afwijking bedraagt 10 %. De afsluitweerstanden zijn van belang om reflecties van elektrische signalen op de bus te vermijden. Om dezelfde reden is het ook aan te raden

22

Synchronisatie In het algemeen kan men op vlak van synchronisatie op twee manieren werken, nl. synchrone of asynchrone communicatie. Bij asynchrone systemen wordt data verstuurd onder de vorm van karakters (bv. 8 bit per karakter). Wanneer de zender en ontvanger in rusttoestand verkeren, dan wordt er geen synchronisatie uitgevoerd. De bitsynchronisatie wordt enkel in stand gehouden als data wordt verzonden. Bij dergelijke systemen moet er dus per karakter een synchronisatie uitgevoerd worden en dit bij het begin van het karakter (bv. het startbit bij UART). Bij synchrone systemen wordt de bitsynchronisatie steeds in stand gehouden. De synchronisatie gebeurt bij elk bit. Het CAN-protocol werkt volgens het synchrone principe. Tijdens het ontvangen van een boodschap worden de verschillende klokken van de verschillende CAN-knooppunten permanent gesynchroniseerd. Dit gebeurt in twee stappen. Een eerste “harde” synchronisatie gebeurt bij het begin van een nieuwe boodschap. Ieder knooppunt synchroniseert zich op eenzelfde op de bus gedetecteerde flank en gebruikt deze flank als het begin van een nieuw bit. Tussen twee boodschappen kan de bus relatief lang in rusttoestand blijven, zodat het faseverloop tussen de verschillende knooppunten onbeperkt kan groeien. De harde synchronisatie op de eerste flank van een nieuwe boodschap is dus nodig om de verschillende knooppunten in fase te krijgen. Zoals we zullen bespreken bij de datalinklaag wordt daarvoor een “start-of-frame”-bit gebruikt. Na de eerste (harde) synchronisatie wordt tijdens het ontvangen van een boodschap voortdurend opnieuw gesynchroniseerd op de binnenkomende bitstroom. Deze hersynchronisatie is nodig omdat de klokken van de zender en de ontvangers in fase kunnen verlopen. Ze kan optreden telkens bij een flank tussen twee bits met een verschillend niveau. Het bemonsteringspunt van het binnenkomende signaal wordt daartoe verschoven binnen de bittijd. Bittiming Elk bit is samengesteld uit vier niet overlappende tijdssegmenten. Deze zijn het synchronisatiesegment (Sync seg), het signaalpropagatiesegment (Prop seg), het fasebuffersegment 1 (Phase seg1) en het fasebuffersegment 2 (Phase seg2). Op de grens tussen het eerste en het tweede fasebuffersegment wordt het bit bemonsterd. Dit is ook te zien op figuur 2.3. Bij een harde synchronisatie stelt een ontvanger de interne bittijd zo in dat de flank waarop gesynchroniseerd wordt binnen het synchronisatiesegment valt. Hersynchroniseren gebeurt door het verschuiven van het bemonsteringspunt. De ontvanger kan één van de fasebuffersegmenten over een bepaalde tijd uitrekken of inkorten. De tijdsduur waar-

21

laag naar hoog transitie. Een logische 1 wordt dan voorgesteld door het omgekeerde hiervan. De flank (laag naar hoog of hoog naar laag) die voor elk bit optreedt, bevat de klokinformatie en kan gebruikt worden voor de synchronisatie tussen zender en ontvanger. Het CAN-protocol maakt gebruik van de klassieke, veel eenvoudigere, non-returnto-zero (NRZ) coderingstechniek. Alhoewel deze techniek een kleinere bandbreedte nodig heeft om dezelfde hoeveelheid aan data te transporteren, in vergelijking met de Manchester-codering, bezit een NRZ-gecodeerd signaal onvoldoende klokinformatie. Bij een lange opeenvolging van bits met hetzelfde logische niveau, zal het gecodeerde signaal over lange tijd ook hetzelfde fysische niveau aanhouden. In een dergelijke situatie kunnen de klokken bij de zender en de ontvanger niet gesynchroniseerd worden en bestaat de kans dat na verloop van tijd bits verkeerd gedecodeerd worden. De techniek die bij het CAN-protocol gebruikt wordt om dit synchronisatieprobleem op te lossen, bestaat erin te vermijden dat lange opeenvolgingen van gelijke niveaus kunnen voorkomen. Telkens wanneer er een opeenvolging is van vijf bits van hetzelfde niveau, wordt een extra bit toegevoegd aan de fysische bitstroom. Dit bit is dan tegengesteld aan de vijf voorgaande. Men noemt dit “bit stuffing”. Aan de ontvangstzijde moet dan de omgekeerde bewerking gebeuren. Daar moet men de toegevoegde “stuff bits” terug verwijderen. Op die manier blijft de logische bitstroom transparant en is er minimaal om de vijf bits een flank in de fysische bitstroom waarop de klokken gesynchroniseerd kunnen worden. Bij de basiskenmerken hebben we al vermeld dat CAN een multi-master protocol is met niet-destructieve bitsgewijze arbitrage. De werking hiervan op het niveau van de datalinklaag wordt later uitgelegd. Op fysisch niveau betekent dit soort arbitrage dat bits op het netwerk voorgesteld kunnen worden als “sterke” of “zwakke” signalen. Een sterk signaal kan één of meer zwakke signalen overschrijven. Dit gelijkt op het “wiredOR”-principe, maar dan met negatieve logica. Een andere manier van voorstellen, is het aanwezig of afwezig zijn van energie. Bij een optische uitvoering van de fysische laag kan de aanwezigheid van licht beschouwd worden als een sterk signaal en de afwezigheid als een zwak signaal. In de specificatie van het CAN-protocol spreekt men van dominant en een recessief niveau. De bus bevindt zich in een recessieve toestand als alle knooppunten een recessief niveau uitsturen. Wanneer tenminste één knooppunt een dominant niveau op de bus zet, zal de bus zich in de dominante toestand bevinden.

20

Figuur 2.2: CAN in het OSI-lagenmodel. Taken Volgens de hierboven vermelde ISO-standaard wordt de fysische laag van het CANprotocol onderverdeeld in drie sublagen. Dat zijn de Physical Signalling Sublayer (PLS), de Physical Medium Attachment Sublayer (PMA) en de Medium Independent Interface (MDI). De PLS-sublaag bepaalt de codering en de timing van bits op de fysische laag evenals de synchronisatie. De PMA-sublaag behandelt de functionaliteit van de busaansturing (driver) en de ontvanger. De MDI-sublaag tenslotte heeft te maken met de elektrische en mechanische karakteristieken van de koppeling met het fysische medium (netwerk-topologie en connectoren). Codering Wanneer men bij digitale communicatie een ontvangen signaal wil decoderen, dan moet er een kloksignaal beschikbaar zijn aan de ontvangstzijde dat gesynchroniseerd is ten opzichte van het kloksignaal aan de zendkant. Bij sommige coderingstechnieken, zoals de Manchester-codering, worden data- en klokinformatie in één signaal gecombineerd. De ontvanger kan dan op zijn beurt de klokinformatie uit het ontvangen signaal extraheren en er zijn lokale klok mee synchroniseren. De techniek die men daarvoor gebruikt, bestaat uit het voorstellen van een logisch niveau als een opeenvolging van twee fysische niveau’s binnen eenzelfde bittijd. Een logische 0 kan men bijvoorbeeld voorstellen als een fysische

19

van het CAN-protocol geconfronteerd wordt en soms ook rekening moet houden met de subtiele verschillen in uitvoering van verschillende CAN-bouwstenen. Voor toepassingen in bijvoorbeeld de autoindustrie is een dergelijke aanpak te rechtvaardigen door de grootschaligheid, het gesloten karakter en de nood aan een zo klein mogelijke resource-behoefte. In deze sector kan men zich een “custom” ingebed ontwerp veroorloven. CAN werd ook meer en meer gebruikt in andere sectoren. In de industriële controle bijvoorbeeld valt de eigenschap van het gesloten karakter weg en vaak ook die van de grootschaligheid. Men is tot de vaststelling gekomen dat er “iets” ontbrak boven het ISO-datalinklaag-protocol. Er was nood aan een uniform communicatiemodel en aan netwerkbeheer. Daarnaast moest de interoperabiliteit en de openheid van systemen beter kunnen. Ongeveer gelijktijdig zijn er wereldwijd vanuit verschillende hoeken verschillende initiatieven geweest, die elk vanuit hun achtergrond een voorstel geformuleerd hebben voor de ontbrekende hogere lagen. Het resultaat is dat er meer dan 40 aparte oplossingen bestaan voor dit probleem. De meest populaire daarvan zijn weergegeven in figuur 2.2. De verscheidenheid rechtvaardigt zich voor een groot deel door het verschil in de hoeveelheid resources (kracht van de processor, hoeveelheid ROM en RAM, enz.) die afhankelijk van het toepassingsgebied kan ingezet worden. Het ene protocol voorziet meer en/of zwaardere diensten dan het andere. Ook de flexibiliteit en openheid kunnen verschillen. In dit eindwerk wordt er enkel gewerkt met het CAN-protocol op de onderste twee lagen. Functionaliteit uit de hogere lagen is voor de toepassing die we voor ogen hebben overbodig en zou overigens een onnodige extra last betekend hebben. De protocols uit de applicatielaag bieden mogelijkheden voor complexere toepassingen, maar vallen buiten het bestek van dit eindwerk. In wat volgt, zijn het dan ook vooral de fysische laag en de datalinklaag die verder besproken worden.

2.2.3

Fysische laag

Het CAN-protocol definieert eigenlijk geen fysische laag. Hoewel dit soms als een zwakte van CAN aanzien wordt, leidt het wel tot flexibiliteit. Enkeldraads, twisted-pair of glasvezel zijn mogelijke keuzes voor de fysische laag. Zoals reeds aangehaald in deel 2.2.2 zijn er twee belangrijke standaarden die de fysische laag beschrijven. ISO 11898 is de meest gebruikte. Daarin worden twee logische waarden gedefinieerd die voorgesteld moeten worden door de fysische laag. Naast de implementatie van de logische waarden moet de fysische laag ook in staat zijn om tegelijkertijd zowel een bit te lezen als te schrijven. Dit is in de standaard opgenomen om zo vlug mogelijk op fouten te kunnen reageren.

18

fouten en om defecte knooppunten te herkennen. Wanneer een knooppunt defect is, kan het van het netwerk afgekoppeld worden zodat de normale werking van het netwerk niet gehinderd wordt. • Ware tijdsgedrag (real-time behaviour): De combinatie van het gebruik van korte datapakketten (maximaal 8 bytes) en een deterministisch arbitragemechanisme met prioriteiten zorgt ervoor dat boodschappen met een hoge prioriteit slechts een korte en berekenbare tijd moeten wachten om op het netwerk te komen. Bij de maximale bitrate van 1 Mbit/s bedraagt die tijd voor een boodschap met de hoogste prioriteit ongeveer 125 µs. Dit is heel kort ten opzichte van vergelijkbare communicatieprotocollen. Voor de berekening en verklaring van de waarde van 125 µs verwijzen we naar het einde van het onderdeel “Boodschaptypes” in deel 2.2.4 (pagina 35).

2.2.2

Situering binnen OSI-lagenmodel

Het OSI-lagenmodel voor netwerken en netwerkfunctionaliteiten bestaat uit 7 lagen. Figuur 2.2 situeert het CAN-protocol binnen dit model. De twee onderste lagen, de fysische laag en de datalinklaag, werden door de ISO vastgelegd in twee standaarden. Deze waren voornamelijk gericht op automobieltoepassingen. In beide standaarden is de definitie van de datalinklaag dezelfde, enkel de fysische laag is verschillend. De ISO 11898 standaard legt de uitvoering van de fysische laag vast voor toepassingen met een hoge datasnelheid. De ISO 11519-2 standaard is bedoeld voor implementaties met lage datasnelheden. Beide standaarden maken gebruik van twisted-pair kabel, maar ook andere implementaties zijn toegelaten en mogelijk. Afhankelijk van de eisen van een toepassing kan men implementaties vinden met optische links of draadloze verbindingen. Aangezien ISO 11898 geschikt is voor zowel High- als Low-speed-CAN, wordt ISO 11519-2 niet meer zo vaak gebruikt. De datalinklaag is vastgelegd in het gemeenschappelijke deel van ISO 11519-2 en ISO 11898. Deze standaarden beschrijven het CAN-protocol op een formele manier en in OSI-terminologie. Naar het schijnt zijn dergelijke documenten niet zo vlot leesbaar. De CAN-specificatie 2.0 door Bosch [7] is een meer pragmatische beschrijving en is nog altijd volledig conform met de eigenlijke standaard. Aanvankelijk was er voor de hogere lagen in het OSI-model niks voorzien. Gaandeweg zijn er verschillende protocols ontstaan voor de applicatielaag met de bedoeling het leven van de systeemontwikkelaar te vergemakkelijken. Met behulp van de diensten die aangeboden worden door de datalinklaag is het perfect mogelijk om CAN-communicatie te voorzien binnen applicaties. Het probleem is echter dat de ontwikkelaar met alle details

17

worden. Bovendien is de prioriteit van een boodschap gekoppeld aan het identificatieveld (en dus aan de aard van de informatie). • Informatie-georiënteerde adressering met prioriteiten: In tegenstelling tot de klassieke manier van adresseren, verloopt het routeren van boodschappen op basis van de betekenis of de inhoud van de boodschap. Elke boodschap krijgt in plaats van een bestemmingsadres een identificatieveld mee dat de aard van de informatie aangeeft. Alle knooppunten kunnen op eigen initiatief bepalen of die informatie voor hen nuttig is en ze eventueel binnennemen. Op die manier kan binnen een netwerk zowel punt-tot-punt, broadcast als multicast-transmissie ge¨ımplementeerd worden. Bovendien is de prioriteit van een boodschap gekoppeld aan het identificatieveld (en dus aan de aard van de informatie). • Niet-destructieve bitsgewijze arbitrage: Wanneer op hetzelfde ogenblik meerdere knooppunten ieder een boodschap willen verzenden, dan wordt aan de hand van het identificatieveld van de boodschappen enkel die boodschap met de hoogste prioriteit tot de bus toegelaten. De andere boodschappen moeten wachten tot de bus weer vrij is en opnieuw de arbitragefase doorlopen. De boodschap die de arbitrage wint, merkt niets van de overige boodschappen en ondervindt dus ook geen vertraging als gevolg van het busconflict. • Multi-master: Als gevolg van het arbitragemechanisme, zoals hierboven beschreven, kunnen meerdere knooppunten op eigen initiatief een boodschap beginnen verzenden van zodra zij merken dat de bus vrij is (multi-master werking). In tegenstelling tot bijvoorbeeld protocollen met een centrale arbitrage-meester, die om beurten het recht om te verzenden toekent aan de verschillende knooppunten, is er in het geval van CAN geen extra busbelasting als gevolg van boodschappen die instaan voor de netwerktoegang. De volledige capaciteit kan dus gebruikt worden voor het transporteren van nuttige informatie. • Krachtige foutdetectie en -verwerking: Het protocol is in staat om met een zeer grote zekerheid foutieve boodschappen te detecteren. Het optreden van een fout wordt gesignaleerd aan alle knooppunten en de foute boodschap wordt opnieuw uitgezonden. Door deze aanpak garandeert het protocol dataconsistentie over het hele netwerk. Dit betekent dat een correcte boodschap door alle knooppunten gelijktijdig als correct wordt geaccepteerd, of door alle knooppunten verworpen. Bovendien bezit het protocol intelligentie om tijdelijke fouten te onderscheiden van permanente

16

verwijzen we naar de literatuurlijst en naar het laatste hoofdstuk. Daarin wordt er wat duiding gegeven aan de literatuurlijst, m.a.w. welke artikels of sites geven een simpel overzicht van de materie en welke publicaties of boeken zijn nuttig voor wie meer wil weten over het CAN-protocol en zijn toepassingen. We starten de diepere behandeling van CAN met een overzicht van de basiskenmerken van het protocol. We situeren het vervolgens binnen het OSI-lagenmodel. Daarna bespreken we achtereenvolgens de fysische laag, de datalinklaag en de applicatielaag. Voor de fysische laag hebben we het over de taken van die laag, de codering van het signaal tot bits, de bitsynchronisatie, de bittiming en de elektrische werking. Bij de fysische laag behandelen we eerst de taken en het communicatiemodel van CAN en de toegang tot de bus. Daarna bekijken we de vier boodschaptypes (data frames, remote frames, error frames en overload frames) en de interframe space dat door het protocol als een vijfde type boodschap beschouwd wordt. Als laatste punt van de datalinklaag wordt een sterk punt van CAN bekeken, namelijk de foutafhandeling. Op het einde van dit deel en van het hoofdstuk hebben we het heel summier over de verschillende applicatielaag-protocols. Deze vallen echter buiten het bestek van dit eindwerk.

2.2.1

Basiskenmerken

Vooraleer we de fijnere details en nuances van CAN echt gaan bekijken, gaan we eerst nog even de basiskenmerken van het protocol op een rijtje zetten. • Serieel netwerk in bustopologie: Het protocol transporteert op een seriële manier informatie onder de vorm van boodschappen op een netwerk met een (elektrische) bustopologie. Het aantal knooppunten op het netwerk wordt niet door het protocol begrensd. De hardware die de bus aanstuurt, legt wel een beperking op aan de lengte van de bus en het aantal knooppunten. • Functionele adressering: De adressering in het CAN-protocol is informatiegeoriënteerd en omvat prioriteiten. Bij de klassieke manier van adresseren vinden berichten hun weg doorheen een netwerk op basis van een doeladres. CAN daarentegen gebruikt de inhoud of de betekenis van een bericht. Elke boodschap krijgt in plaats van een doeladres een identificatieveld mee dat de aard van de informatie aangeeft. Alle CAN-knooppunten kunnen op eigen initiatief bepalen of die informatie voor hen nuttig is en ze eventueel binnennemen. Op die manier kan binnen een netwerk zowel punt-tot-punt, broadcast als multicast-transmissie ge¨ımplementeerd

15

Prijs. De kostprijs en de prijs/prestatie-verhouding van CAN is één van de grootste voordelen van het protocol. Door massaproductie en de grote verspreiding van CAN, zijn de hardwarekosten niet veel groter dan die van een gewone seriële lijn. Transmissiemedium. Een vaak voorkomend medium is gewoon een twisted-pair kabel. Een CAN-systeem kan zelfs met slechts één draad werken. Ook optische of radioverbindingen behoren tot de mogelijkheden. Het transmissiemedium kan dus vrij simpel zijn en er is flexibiliteit in keuze. De busstructuur van het protocol vermindert de hoeveelheid kabels door het overbodig maken van de vele punt-tot-punt verbindingen. Foutdetectie en -afhandeling. De enorm krachtige foutdetectie is een kenmerkend punt van het CAN-protocol. Stel dat een CAN-bus systeem gebruikt wordt 24 uur op 24 en 7 dagen op 7 aan een snelheid van 1 Mbit/s en dat de bus de helft van de tijd bezet is. Wanneer om de 0,7 s door uitwendige storingen een bitfout optreedt (dit is een omgeving met een vrij sterke storing), dan zou er slechts één niet-gedetecteerde fout voorkomen om de 1000 jaar. De foutbehandeling en retransmissie van berichten wordt automatisch afgehandeld door de CAN-hardware. Opdat één CAN-knooppunt dat kapotgaat het hele netwerk niet zou verstoren (en alle bandbreedte zou innemen), heeft het protocol een ingebouwde mogelijkheid om knooppunten die zich foutief gedragen van de bus te gooien. In het verleden had CAN een belangrijk nadeel door de beperkte verhouding tussen snelheid en bandbreedte enerzijds en maximale afstand anderzijds. Een maximale snelheid van 1 Mbit/s laat een bandbreedte van 500 kbit toe bij een maximale buslengte van ongeveer 30 meter. De maximale snelheid en bandbreedte nemen af naargelang de buslengte toeneemt. Een goede vuistregel is dat bij een dubbele lengte de snelheid ongeveer halveert. Dit nadeel wordt minder en minder belangrijk omdat veel fabrikanten nu componenten maken met meerdere CAN-controllers on-chip. Enerzijds laat dit toe om het aantal netwerken dat door één knooppunt behandeld wordt (en dus de totale bandbreedte), te verhogen. Anderzijds kunnen dergelijke componenten dienen om bruggen of routers te maken en verschillende segmenten van een CAN-netwerk met elkaar te verbinden. Op die manier kunnen grotere CAN-netwerken gebouwd worden zonder de snelheid te compromitteren.

2.2

Het CAN-protocol onder de loupe

In dit deel zullen we het CAN-protocol wat dieper uitspitten. De behandeling van het protocol is vrij volledig, althans voor wat wij er van moeten weten. Voor meer informatie

14

Toekomstige marktsegmenten Ondanks de leeftijd van het protocol wordt het nog altijd verbeterd en uitgebreid. In 2000 heeft een ISO-werkgroep TTCAN gedefinieerd (time-triggered CAN). Eén van de verbeteringen die door TTCAN aangebracht worden, is de mogelijkheid om een zekere bandbreedte te reserveren voor bepaalde CAN-berichten. Voor meer informatie over TTCAN verwijs ik naar de website van CiA [12]. De toevoegingen van de TTCAN-uitbreiding kunnen de totale levensduur van CAN met nog eens 5 tot 10 jaar verlengen. Op vlak van de applicatielaag kunnen we de goedkeuring verwachten van een uitbreiding voor toepassingen waar de veiligheid vooropstaat. Een voorbeeld is het CANopen-protocol dat reeds gebruikt wordt in de medische wereld voor de communicatie tussen toestellen. Een verdere uitbreiding van dit protocol die nog moet goedgekeurd worden door de EU zou het protocol geschikt moeten maken voor de luchtvaart en de maritieme controle. De dalende prijzen voor CAN controllers en transceiver chips zullen CAN aantrekkelijk maken ook voor prijs-kritische applicaties. We kunnen verwachten dat CAN binnenkort niet enkel terug te vinden is in de industriële wereld, maar ook in embedded netwerktoepassingen in de particuliere sfeer. Men verwacht dat de prijs van een volledig CAN-knooppunt zal evolueren naar 1 euro.

2.1.4

Voordelen

In deze paragraaf zullen we even de belangrijkste voordelen van het CAN-protocol op een rijtje zetten. Rijpe standaard. Het protocol bestaat al sinds 1986 en is dus alle eventuele kinderziektes ontgroeid. De ruime beschikbaarheid van hardware-implementaties zorgen ervoor dat CAN een aantrekkelijke keuze is. Afhankelijk van de applicatie kan men kiezen tussen stand-alone CAN-controllers, microcontrollers met ge¨ıntegreerde CAN-controller of I/Obouwstenen met ge¨ıntegreerde CAN-controller. Deze laatste kunnen, in combinatie met een applicatielaag-protocol, dienen om met weinig moeite complexe controle-applicaties te maken met standaardcomponenten. Real-time. Eén van de belangrijke eigenschappen voor industriële controle is het realtime aspect. Het real-time gedrag van CAN is relatief goed ten opzichte van gelijkaardige netwerken. Afhankelijk van de configuratie en het verkeer op de bus kunnen berichten met een hoge prioriteit binnen de milliseconde verstuurd worden. De toevoeging van TTCAN komt tegemoet aan applicaties met nog hardere real-time eisen.

13

Figuur 2.1: Verkoopscijfers CAN-knooppunten. CAN-knooppunten van de voorbije jaren. De CiA-groep (CAN in Automation) verzamelt en publiceert jaarlijks de verkoopscijfers en -voorspellingen van een twintigtal belangrijke chip-producenten. De cijfers uit figuur 2.1 zijn correct tot en met 2002. Het cijfer voor 2003 is een voorspelling. Ongeveer 80% van de verkoop is bestemd voor toepassingen in de automobielsector. De rest wordt o.a. gebruikt voor embedded netwerken en industriële controlesystemen. De groei in de totale verkoopscijfers is opmerkelijk, in het bijzonder voor het jaar 2001, aangezien dat een mager jaar was voor de halfgeleider-industrie in het algemeen. Desondanks steeg de verkoop van CAN-chips met 70% tot een 200 miljoen stuks. Een conservatieve schatting voor de volgende jaren maakt gewag van een continu groeipercentage van 30%. Dit groeicijfer zou wel eens hoger kunnen uitvallen, aangezien CAN nog niet zo sterk verspreid is in Amerika als in Europa. In 2001 maakte de Europese markt 75% uit van de totale verkoop. De Amerikaanse en Aziatische markt waren goed voor respectievelijk 10% en 15%. In de voorbije jaren zijn de drie grote Amerikaanse autoconstructeurs begonnen met het gebruik van CAN (aanvankelijk enkel in motortoepassingen). Daarenboven lijkt het erop dat ook de Aziatische automobielsector zwaar aan het investeren is in CAN-technologie.

12

zijn hun voorstellen voor de fysische laag (OSI-laag 1) van een CAN-netwerk en voor de ontbrekende applicatielaag (OSI-laag 7). Het originele CAN-protocol specifieerde immers enkel de datalinklaag (OSI-laag 2).

2.1.3

Groei

Traditionele marktsegmenten Hoewel het CAN-protocol oorspronkelijk ontworpen was voor de automobielsector, kwamen de eerste applicaties uit andere marktsegmenten. Vooral in Noord-Europa was CAN reeds in de vroege jaren ’90 al heel populair voor machinecontrole. Het is evenwel zo dat de halfgeleiderfabrikanten die CAN-modules in hun gamma hebben opgenomen, zich vooral gericht hebben op de automobielindustrie. Sinds midden de jaren ’90 hebben Infineon en Motorola reeds grote hoeveelheden CAN-controllers geleverd aan de Europese autoconstructeurs. Sinds de late jaren ’90 bieden ook de Aziatische halfgeleiderfabrikanten CAN-controllers aan. Reeds in 1992 paste Mercedes-Benz CAN-technologie toe in hun duurdere personenwagens. Na Volvo, Saab, Volkswagen en BMW, gebruiken nu ook Renault, Fiat, Peugeot, Audi en Citroen CAN-netwerken in hun wagens. Bijna elke personenwagen die in Europa van de band rolt bevat nu op zijn minst één CAN-knooppunt. Ontwerpen in de toekomst zullen 4 of meer parallelle CAN-netwerken omvatten om de totale bandbreedte te verhogen en zo het aantal CAN-knooppunten op te trekken tot boven de 100. Traditioneel is de automobielsector nog altijd het grootste marktsegment voor CAN. De andere grote markt die van CAN gebruik maakt is die van de industriële controle. De automatiserings- en productiebranche ontdekte de voordelen van het CAN-concept voor meten, sturen en regelen. Door de ontwikkeling van applicatie-laag-protocols zoals CANopen en DeviceNet kan men systemen bouwen met standaardcomponenten op een plug-and-play manier. Typische standaardcomponenten in deze sector zijn verschillende soorten I/O-modules waaronder encoders, aansturingen en hydraulische en pneumatische sensoren en actuatoren. Zo komt het dan men de CAN-bus nu terugvindt als communicatie-ruggegraat in PLC-systemen, robot- en motorsturingen, in gebouwen, liften, in de automatisering van laboratoria, in sensor/actuatorsystemen, enz. Cijfers Het CAN-protocol bestaat nu bijna 20 jaar, maar heeft nog steeds zijn piek niet bereikt en heeft nog steeds een indrukwekkende groei. Figuur 2.1 toont de verkoopscijfers van

11

en noodzakelijk om te voldoen aan de real-time eisen die aan het systeem gesteld werden. Daarnaast moesten de protocolcomponenten door massafabricage heel goedkoop zijn en gemakkelijk in gebruik. Tot slot moest de busopbouw zo eenvoudig mogelijk zijn voor integratie in het chassis. Verschillende busconcepten werden ontwikkeld. Eén van die concepten was het CANprotocol onder impuls van Robert Bosch GmbH. In 1983 werd een interne projectgroep opgericht, onder leiding van Uwe Kiencke, die nu professor is aan de Universiteit van Karlsruhe in Duitsland. Een belangrijke stap werd gezet in 1985 wanneer Intel werd gevraagd om deel te nemen aan de ontwikkeling en promotie van CAN. Vooraleer op dit voorstel in te gaan, werd aan een extern consulent, Prof. Wolfhard Lawrenz van de Fachhochschule Wolfenb¨ uttel in Duitsland, gevraagd om de technische competentie van het protocol te verifiëren. Deze laatste introduceerde de naam “Controller Area Network”. In de herfst van 1985, na het afsluiten van een licentieovereenkomst tussen Bosch en Intel, werd gestart met de gezamenlijk ontwikkeling van een in silicium ge¨ıntegreerde uitvoering van het protocol. Deze samenwerking resulteerde in het midden van 1987 in een eerste werkende chip. Twee jaar daarna, in 1989, introduceerde Intel de eerste commerciële CAN-communicatiebouwsteen, de Intel 82526. Vandaag de dag hebben zowat alle van de voornaamste halfgeleiderproducenten CAN-bouwstenen in productie. Op de SAE-conferentie (Society of Automotive Engineers) in de lente van 1986, werd CAN voor het eerst voorgesteld. In datzelfde jaar werd ook een standaardisatieprocedure in gang gezet. Het duurde echter tot 1994 vooraleer CAN door de ISO (International Standardization Organization) als standaard aanvaard werd. Dit heeft grotendeels te maken met het feit dat rond diezelfde periode, binnen dezelfde ISO-werkgroep voor standaardisatie van communicatiesystemen in de automobielsector, ook een aantal concurrerende protocollen in de maak waren, zoals het Franse VAN en het Amerikaanse J1850 protocol. In het begin van de jaren ’90 werden tevens een aantal gebruikersgroepen opgericht om de verschillende oplossingen te standaardiseren. De groep die uiteindelijk de belangrijkste geworden is, heet CiA (CAN in Automation) en werd opgericht in 1992 door Holger Zeltwanger. Deze overkoepelende organisatie telt nu ongeveer 200 leden. Bijna alle landen van Europa en de Verenigde Staten zijn erin vertegenwoordigd. CiA staat los van enig toepassingsgebied en groepeert naast halfgeleiderproducenten en -leveranciers ook fabrikanten van systemen, gebruikers uit de industriële sector en onderzoekers uit de academische wereld. Het grote succes van CiA is een gevolg van het feit dat haar verschillende interne werkgroepen heel snel en efficiënt tot pragmatische oplossingen kwamen voor de verschillende vragen voortvloeiend uit de toenmalige CAN-standaard. Belangrijke voorbeelden

10

2.1

Algemeen overzicht

In dit algemene overzicht zullen we kort de geschiedenis van het CAN-protocol schetsen. In een eerste puntje bekijken we de redenen waarom CAN een noodzaak werd. Vervolgens hebben we het over het ontstaan en de ontwikkeling van het protocol. Daarna gaan we even dieper in op de evolutie en de groei van CAN. Daarbij kijken we ook even naar de toekomst. Tot slot worden de belangrijkste voordelen van CAN op een rijtje gezet.

2.1.1

Noodzaak van CAN

In de loop van de jaren ’80 en ’90 groeide het gebruik van elektronische systemen binnen de automobielindustrie. Dit had vooral te maken met technische ontwikkelingen voor personenauto’s en vrachtwagens op twee bepaalde gebieden. Enerzijds werden de eisen wat betreft comfort in voertuigen steeds maar groter. Denk bijvoorbeeld aan elektronisch bediende ruiten, stoel- en spiegelverstelling, stoelverwarming, airconditioning en GPSroutebegeleidingssystemen. Anderzijds kwamen ook veiligheidsaspecten steeds maar naar de voorgrond. De daarvoor noodzakelijke systeemuitbreidingen zijn o.a. elektronische centrale vergrendeling, startblokkering, ABS-voorzieningen en economisch en ecologisch motormanagement. Het gevolg van deze groeiende hoeveelheid elektronica in voertuigen is de noodzaak tot communicatie tussen de verschillende intelligente subsystemen (bv. motorcontrole, transmissiecontrole, controle van de vering, etc.). De verschillende units moeten verbonden worden tot een volwaardig gedistribueerd controlesysteem. Volgens de huidige stand van zaken zijn er binnen de auto tot een honderdtal afzonderlijke microcontrollers die hun taken verrichten en onder elkaar gegevens moeten uitwisselen. Het is duidelijk dat het aantal communicatiewegen (de kabelboom) enorm groot is geworden. Zonder een aangepast communicatiesysteem zou dit een extra gewicht betekenen van 100 kilogram.

2.1.2

Ontstaansgeschiedenis

Als gevolg van de nieuwe technische problemen gesteld door de toename van elektronische systemen begon de automobielindustrie te zoeken naar modernere communicatiemethodes. Men kwam terecht bij een bus-systeem dat aan volgende voorwaarden moest voldoen. Het datatransport moest zeer foutbestendig zijn (Hamming-afstand minstens 4) en een transmissiesnelheid hebben variërend tussen 5 kbit/s en 1 Mbit/s (voor luxe- en veiligheidselektronica). Het systeem moest geoptimaliseerd zijn voor de overdracht van kleine hoeveelheden data (0-8 bytes). Dit is gunstig voor sensor/actuator toepassingen

9

Hoofdstuk 2 Het CAN-protocol CAN (Controller Area Network) is een ontwikkeling uit 1986 door de firma Bosch die oorspronkelijk bedoeld was voor gebruik in auto’s, maar die inmiddels ook zeer veel gebruikt wordt in industriële toepassingen. Ook in medische toepassingen en bij liften kan men het CAN-protocol terugvinden. Het is een serieel, real-time communicatieprotocol ontworpen om te werken met korte berichten (tot 8 bytes), om meerdere meesters te ondersteunen (botsingen worden opgelost door prioriteit) en om een hoge graad van betrouwbaarheid te verkrijgen (15-bit CRC voor ieder bericht). Quasi alle Europese automobielfabrikanten werken met CAN, hoewel er uitzonderingen zijn. Zo gebruikt BMW naast CAN ook de MI-bus van Motorola. Recent hebben ook de Amerikaanse en Aziatische automobielindustrie de keuze gemaakt om CAN te gebruiken. We zullen beginnen met een algemeen overzicht van het CAN-protocol, zonder al te diep in te gaan op de technische details. Daarbij bekijken we het ontstaan en de groei van het protocol en de evolutie tot wat het nu is. We overlopen ook even de redenen waarom CAN een succes geworden is. In het tweede deel van dit hoofdstuk zullen we CAN wat meer ontleden. We beginnen met het situeren van het protocol binnen het OSI-lagenmodel. Daarna bekijken we de werking ervan achtereenvolgens op de fysische laag en de datalinklaag. De bovenliggende lagen zijn niet ingevuld door de originele CANspecificatie, maar er zijn wel verschillende interessante uitbreidingen ontworpen die zich op het niveau van de applicatielaag bevinden. Deze protocollen vallen buiten het bestek van dit eindwerk, maar we zullen er toch even naar verwijzen aangezien ze belangrijk zijn voor grotere toepassingen.

8

de belangrijkste componenten, de koppeling met de CAN-bus, de ervaren problemen, de oplossingen hiervoor en tips om problemen te vermijden. De gebruikte microcontroller en CAN-controller worden afzonderlijk nog eens uitgebreider bekeken, vooral i.v.m. de mogelijkheden naar de software toe. Het gebruik van een aangekocht CAN-knooppunt (PCIcan-kaart) wordt uitgelegd. Deze kaart werkte alvast 100% zeker en kon gebruikt worden om de eigen hardware te testen. Tot slot van het derde hoofdstuk wordt de hardware-opstelling van een klein CAN-bus systeem besproken. Dit stuk is een soort praktische samenvatting en aanvulling van het hele derde hoofdstuk. Het vierde hoofdstuk behandelt de software. Er werd een demo-applicatie gemaakt op microcontroller-niveau om de mogelijkheden van de gerealiseerde hardware te tonen. Deze applicatie wordt uitgebreid besproken. Tevens worden twee testprogramma’s vermeld die eventueel nuttig kunnen zijn. Zoals in het hardware-hoofdstuk worden ook hier een aantal mogelijke problemen vermeld samen met de oplossingen, maar dan op het vlak van de software. Het programma op PC-niveau moest zorgen voor de interactiviteit en gebruiksvriendelijkheid van de analyser-applicatie. De analyser-functionaliteit is niet afgewerkt en de grafische “schil” op PC-niveau is bijgevolg ook niet gerealiseerd. De communicatie tussen PC en microcontroller via de seriële poort is wel tot stand gebracht en wordt besproken op het einde van het vierde hoofdstuk. Hoofdstuk 5 vormt het besluit van dit eindwerk. We overlopen nog eens wat allemaal gerealiseerd is en bekijken de resultaten. Er worden een aantal suggesties gedaan voor verbeteringen aan het huidige CAN-knooppunt. Met knooppunt bedoelen we het geheel van hardware en software dat de CAN-communicatie realiseert. Tenslotte geven we nog wat duiding bij de literatuurlijst.

7

Hoofdstuk 1 Inleiding De CAN-bus is een veldbus die in de jaren ’80 onder impuls van de automobielindustrie werd ontwikkeld. Ondertussen is deze bus populair geworden in veel andere sectoren. Onder andere de grote verspreiding van het CAN-protocol maakt het interessant om een CAN-knooppunt ter beschikking te hebben en om via CAN te kunnen communiceren. Het was de bedoeling dat dit eindwerk een basis zou vormen waarop verder werk over CAN kan steunen. Concreet was de oorspronkelijke opdracht een CAN-bord te realiseren waarbij een microcontroller uit de 8051-familie als master zou optreden voor de andere hardware. Het vertrekpunt voor de interface naar de CAN-bus toe was een ontwerp uit Elektuur rond een Philips SJA1000 CAN-controller. Al vlug werd als toepassing gekozen voor een CAN-bus analyser. Hiermee zou dan niet alleen CAN-communicatie kunnen gebeuren, maar ook het testen van het CAN-netwerk. We dachten daarbij o.a. aan het loggen en/of filteren van de boodschappen op de CAN-bus, het verzamelen van statistieken over het bus-verkeer en het zelf genereren van extra CAN-verkeer, bijvoorbeeld om de schaalbaarheid van een CAN-bus-systeem te testen (kan een systeem nog wel meer CAN-knooppunten en meer verkeer aan?). De tekst is ingedeeld in een aantal hoofdstukken. Hoofdstuk één is dit inleidende hoofdstuk. Hoofdstuk twee behandelt het CAN-protocol. Bijna alle op dit niveau nodige informatie over het protocol zou moeten terug te vinden zijn in deze literatuurstudie. Voor de rest kan de uitgebreide literatuurlijst uitkomst bieden. De gerealiseerde hardware en software vormen samen een CAN-knooppunt dat demonstreert wat we met CAN kunnen aanvangen. De bespreking van de hardware en de software gebeurt respectievelijk in het derde en het vierde hoofdstuk. In hoofdstuk drie worden eerst de verschillende aspecten van het hardware-ontwerp van CAN-knooppunt behandeld, met name het ontwerp zelf,

6

4 Software 4.1 Inleiding . . . . . . . . . . . . . . . . . . 4.2 Programma op microcontroller-niveau . . 4.2.1 Inleiding . . . . . . . . . . . . . . 4.2.2 Bijzonderheden van de SAE81C90 4.2.3 Bespreking applicatie . . . . . . . 4.2.4 Testprogramma’s . . . . . . . . . 4.2.5 Resultaten en tips . . . . . . . . . 4.3 Programma op PC-niveau . . . . . . . . 5 Besluit

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en de C8051F120 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

82 82 83 83 88 90 97 98 101 103

Inhoudsopgave 1 Inleiding

6

2 Het CAN-protocol 2.1 Algemeen overzicht . . . . . . . . . . . . 2.1.1 Noodzaak van CAN . . . . . . . . 2.1.2 Ontstaansgeschiedenis . . . . . . 2.1.3 Groei . . . . . . . . . . . . . . . . 2.1.4 Voordelen . . . . . . . . . . . . . 2.2 Het CAN-protocol onder de loupe . . . . 2.2.1 Basiskenmerken . . . . . . . . . . 2.2.2 Situering binnen OSI-lagenmodel 2.2.3 Fysische laag . . . . . . . . . . . 2.2.4 Datalinklaag . . . . . . . . . . . . 2.2.5 Applicatielaag . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

8 9 9 9 11 13 14 15 17 18 25 40

3 Hardware 3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Blokschema . . . . . . . . . . . . . . . . . 3.1.2 Overzicht van dit hoofdstuk . . . . . . . . 3.2 CAN-interface . . . . . . . . . . . . . . . . . . . . 3.2.1 Blokschema . . . . . . . . . . . . . . . . . 3.2.2 Ontwerp . . . . . . . . . . . . . . . . . . . 3.2.3 Koppeling met microcontrollerbordje . . . 3.2.4 Koppeling met de CAN-bus . . . . . . . . 3.2.5 Problemen, oplossingen, tips . . . . . . . . 3.3 CAN-controller SAE81C90 . . . . . . . . . . . . . 3.4 Microcontroller Cygnal C8051F120 . . . . . . . . 3.4.1 Microcontrollerbord Cygnal C8051F120DK 3.5 Kvaser PCIcan-kaart . . . . . . . . . . . . . . . . 3.6 Opstelling CAN-bus-systeem . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

42 42 43 44 45 45 46 54 57 58 64 70 73 75 78

4

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Realisatie van een CAN-bus Analyser ABSTRACT: De CAN-bus is een veldbus die in de jaren ’80 onder impuls van de automobielindustrie werd ontwikkeld. Ondertussen is deze bus populair geworden in veel andere sectoren. Onder andere de grote verspreiding van het CAN-protocol maakt het interessant om een CAN-knooppunt ter beschikking te hebben en om via CAN te kunnen communiceren. Dit eindwerk vormt een eerste stap in de richting om met CAN te werken. Daartoe werd het CAN-protocol zo grondig mogelijk besproken. Bijna alle op dit niveau nodige informatie over het protocol is terug te vinden in de literatuurstudie of in de literatuurlijst. De gerealiseerde hardware en software vormen samen een CAN-knooppunt dat demonstreert wat we met CAN kunnen aanvangen. Het CAN-knooppunt bestaat uit een Cygnal C8051F120DK microcontrollerbord en een CAN-interface-bord dat gebouwd werd rond een Siemens SAE81C90 CAN-controller. De software-kant van het CAN-knooppunt omvat een assembler-applicatie op de microcontroller. In deze tekst werden enerzijds de hardware en de software op zich besproken en werden de (ontwerp)keuzes verklaard. Anderzijds werd er ook aandacht besteed aan algemene principes. Ook door het behandelen van de problemen die ervaren werden tijdens de realisatie van een eerste CAN-toepassing en het geven van de bijhorende oplossingen, werd gepoogd om toekomstig werk rond CAN op het goede spoor te zetten. TREFWOORDEN: CAN-bus, CAN-protocol, veldbus, CAN-controller, microcontroller, digitaal elektronica-ontwerp

Woord vooraf

Een eindwerk is bedoeld om zich een jaar lang te verdiepen in een onderwerp op een manier die niet aan bod komt in het gewone curriculum. Met een eindwerk kun je een pak bijleren en een eigen accent geven aan je opleiding. Ik heb gedurende dit academiejaar dan ook met veel plezier aan dit onderwerp gezwoegd en ik hoop dat mijn werk zijn nut kan hebben voor verdere ondernemingen in verband met CAN. Ik dank mijn promotor Paul Devos om mij dit interessante onderwerp aan te reiken en om het advies en de tips onderweg. Patrick Van Torre en Paul Devos en in het bijzonder Luc Colman bedank ik voor de vele keren dat ze me met raad en daad hebben bijgestaan. Voor het herlezen van deze tekst dank ik mijn promotor en ook mijn ouders. Een woord van dank gaat ook uit naar mijn medestudenten voor de aangename sfeer in het labo en naar de heer Colman voor zijn positief gestoorde aanwezigheid. Dat alles maakte het relativeren van tegenslagen en vertragingen er toch wel gemakkelijker op. Tenslotte bedank ik ook de hogeschool en mijn ouders om me de mogelijkheid te geven na vier jaar licentiaat informatica nog twee jaar bij te studeren in de elektronica. Hans Logie, mei 2004

Academiejaar 2003 - 2004 Departement Industri¨ ele Wetenschappen BME - CTL Schoonmeersstraat 52 - 9000 Gent

Realisatie van een CAN-bus Analyser

Eindwerk voorgedragen tot het behalen van het diploma van INDUSTRIEEL INGENIEUR ELEKTRONICA OPTIE ONTWERPTECHNIEKEN Hans LOGIE Promotor: Prof. dr. ir. Paul DEVOS

[33] Paul Goossens. Elektuur. Seriële poorten onder Windows (met Delphivoorbeeldprogramma)

Recommend Documents