Instutionen för Systemteknik
Department of Electrical Engineering
Examensarbete
Modulariserbar operatörspanel baserad på ett
CAN-buss gränssnitt
Examensarbete utfört i datorteknik vid Tekniska högskolan vid Linköpings universitet
av
Linus Isberg Martinsson LiTH-ISY-EX-ET--15/0430--SE
Linköping 2015
Department of Electrical Engineering Linköpings tekniska högskola Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden, Sweden 581 83 Linköping
Modulariserbar operatörspanel baserad på ett
CAN-buss gränssnitt
Examensarbete utfört i datorteknik
vid Tekniska högskolan vid Linköpings universitet
av
Linus Isberg Martinsson LiTH-ISY-EX-ET--15/0430--SE
Handledare: Mattias Engström Examinator: Kent Palmqvist
Sammanfattning
För att styra utrustningen i olika fordon inom industrin används olika typer av strömbrytare som sitter monterade på en operatörspanel. Från dessa går det of-ta individuella signalkablar fram till enheterna som ska styras. Ett alternativ för att att slippa den störa mängden kablar detta kan leda till är att istället koppla strömbrytarna till en mikrokontroller, denna vidarebefodrar sedan signalerna via en CAN-buss till en ECU som styr alla enheter från en central position i fordo-net.
Under detta examensarbete, som har utförts hos Syncore Technologies AB, har därför en operatörspanelsplattform, både hård- och mjukvara, utvecklats för att uppnå en minimal NRE-kostnad för varje ny kundkonfiguration som inkluderar olika bestyckningar av strömbrytare samt beteenden för dessa.
Abstract
To control the equipment in different industrial vehicles various types of switches are used which are mounted on a operator panel. Individual signal cables are often connected from these switches to their respective equipment they are controlling. An alternative to avoid the large amount of cables this can lead to is to inste-ad connect the switches to a microkontroller which in turn forwards the signals through a CAN-bus to a ECU which controls all units from a central position in the veichle.
During this bachelor thesis, which has been performed at Syncore Technologies, a software and hardware platform for a operator panel has because of this been developed. This platform has a goal to minimize NRE-cost for every new customer configuration which involves different setups of switches and various behaviours of these.
Lista över förkortningar
Förkortning Betydelse Beskrivning
ACK Acknowledgement En bekräftelse på att ett meddelande kommit fram
ADC Analog Digital Converter Omvandlare från analoga till digitala signaler CAN Controller Area Network Seriellt busssystem inriktat mot
fordonsindustrin
CRC Cyclic Redundancy Check Metod för att beräkna kontrollsummor för filer DAC Digital Analog Converter Omvlandlare från digitala till analoga signaler DCE Data Communications
Equipment
DLC Data Length Code Specificerar hur många bytes som skickas i ett CAN-meddelande
DTE Data Terminal Equipment Terminal som konverterar användarinforma-tion till signaler och tvärtom
ECU Electronic Control Unit Ett inbyggtsystem som styr ett eller flera funktionsområden i ett fordon
EOF End Of Frame Bit som indikerar slutet av ett meddelande ESD ElectroStatic Discharge En plötslig elektrisk urladdning mellan två
GPIO General Purpose
In-put/Output Programmerbar in/utgång hos en integreradkrets HTTP HyperText Transfer
Pro-tocol Kommunikationsprotokoll för att överförawebbsidor på Internet IC Integrated Circuit Elektronisk krets där alla komponenter tillver-kas tillsammans istället för att de tillvertillver-kas var för sig och ansluts till varandra
IDE Integrated Development
Enviroment Ett program som innehåller en textredigerare,kompilator och debugger IFS InterFrame Space Tiden det tar för en mikrokontroller att flytta
ett mottaget meddelande till en buffer I/O Input/Output Insignal/Utsignal
IP Internet Protocol Kommunikationsprotokoll för överföring av in-formation över Internet
LED Light Emitting Diode Ljusdiod MAC-adress Media Access Control
ad-dress Hårdvaruadress för en enhet, tilldelas avtillverkaren i fabrik MCU MicroController Unit Liten dator i en enda integrerad krets.
Inne-håller en processor, minne och programmerba-ra in- och utgångar
NRE-kostnad Non-Recurring
Engineering cost Engångskostnad för utvecklingen av en nyprodukt OSI-modellen Open Systems
Intercon-nection model En konceptuell modell fördatorkommunikation i sju lager PCB Printed Circuit Board Kretskort
PWM Pulse Width Modulation Metod för att skapa varierbara spänningar ge-nom att slå av och på signalen med hög fre-kvens
RISC Reduced Instruction Set
Computing Processorarkitektur som använder en mindre,men mer optimerad, mängd instruktioner
RTR Remote Transmission
Re-quest Bit i ett CAN-meddelande som indikerar omett svar från mottagaren förväntas eller inte SOF Start Of Frame Bit som indikerar början av ett meddelande SPI Serial Peripheral Interface Buss för synkron seriekommunikation som
an-vänds i mikrokontroller SRAM Static Random Access
Memory Snabb typ av läs- och skrivbart minne. An-vänds bland annat som cacheminne i mikro-processorer
SRR Substitute Remote
Re-quest Substitut för RTR i ett förlängt CAN-meddelande STM STMicroelectronics En av Europas största halvledartillverkare SWD Serial Wire Debug Ett två stifts alternativ till JTAG
UART Universal Asynchronous
Receiver/Transmitter Mikrochip som översätter pararell datatill seriell USB Universial Serial Bus Standard för snabb seriell databuss
Innehåll
1 Inledning 1
1.1 Företagsbeskrivning . . . 1
1.2 Bakgrund och syfte . . . 1
1.3 Mål . . . 2 1.4 Metod . . . 2 1.4.1 Konstruktion av hårdvaruplattform . . . 2 1.4.2 Mjukvaruutveckling . . . 3 2 Seriell kommunikation 5 2.1 OSI-modellen . . . 5 2.1.1 Fysiska lagret . . . 6 2.1.2 Datalänkslagret . . . 6 2.1.3 Nätverkslagret . . . 7 2.1.4 Transportlagret . . . 7 2.1.5 Sessionslagret . . . 8 2.1.6 Presentationslagret . . . 8 2.1.7 Applikationslagret . . . 8 2.2 RS-232 . . . 9 2.3 UART . . . 9 2.4 CAN . . . 10
2.4.1 Uppbyggnaden av ett CAN meddelande . . . 12
2.4.2 CAN-bussen . . . 13 3 Hårdvara 15 3.1 Mikrokontroller . . . 15 3.1.1 Val av mikrokontroller . . . 15 3.1.2 STM32F042x . . . 16 3.1.3 STM32F100xx . . . 17 3.1.4 STM32F103C6 . . . 18 3.2 Kringutrustning . . . 18
INNEHÅLL INNEHÅLL
4 Utförande och Implementation 19
4.1 Hårdvaruutveckling . . . 19 4.1.1 Altium Designer 14 . . . 19 4.1.2 Schemaritning . . . 20 4.1.3 Kretskortslayout . . . 22 4.2 Mjukvaruutveckling . . . 23 4.2.1 Keil µVision 5 . . . 23 4.2.2 CAN protokollstack . . . 23 4.2.3 Programflöde . . . 24 4.3 Problem . . . 29 5 Resultat 31 5.1 Slutsats . . . 31 5.2 Diskussion . . . 33 5.3 Vidareutveckling . . . 33 Referenser 35 xiv
Figurer
2.1 De olika lagrena i OSI-modellen[1] . . . 6
2.2 Översikt över de olika lagerna som CAN standarden innefattar[2] . . 11
2.3 CAN meddelande med standard 11-bitars identifierare[2] . . . 12
2.4 CAN meddelande med förlängd 29-bitars identifierare[2] . . . 13
2.5 Den inverterade logiken hos en CAN-buss[2] . . . 14
2.6 Meddelandeprioritet på CAN-buss[2] . . . 14
4.1 CAN-tranceiver . . . 21
4.2 Färdiga kretskortslayouten . . . 23
4.3 Flödesschema över mainloopen . . . 25
4.4 Flödesschema över systemavbrotten . . . 27
4.5 Flödesschema över eventroutern . . . 28
5.1 Framsidan av det färdiga kretskortet . . . 32
5.2 Baksidan av det färdiga kretskortet . . . 32
Ekvationer
4.1 Effektförlust i form av värme . . . 20Kapitel 1
Inledning
I detta kapitel ges en introduktion till innehållet i rapporten.
1.1
Företagsbeskrivning
Arbetet denna rapport beskriver är utfört på Syncore Technologies AB, benämns fortlöpande som Syncore eller företaget, ute i Mjärdevi Science Park som ligger i anslutning till Linköpings Universitet. Syncore är ett företag med omkring 25 anställda och specialiserar sig på utveckling av inbyggda system.
1.2
Bakgrund och syfte
I fordon inom industrin sitter det många strömbrytare som styr allt från vindrute-torkare till att justera höjden på gafflarna i en gaffeltruck. Dessa sitter monterade på en så kallad operatörspanel och från denna går det ofta signalkablar för varje individuell strömbrytare fram till de enheter som ska styras. Detta leder till en stor mängd kablar som alla går åt olika håll i fordonet.
Ett alternativ till detta är att koppla dessa strömbrytare till en mikrokontroller som tolkar signalerna och skickar vidare meddelanden via en CAN-buss till en ECU som istället styr reläerna från en mer central position i fordonet.
1.3. MÅL 1. Inledning
Många företag har sin specifika förarmiljöer som deras anställda är vana vid och vill behålla. För att lätt kunna anpassa en ny plattform efter detta krävs det att denna är generell och enkelt omkonfigurerbar för varje företags egna önskemål.
Syftet bakom projektet är att utforma ett en generell och omkonfigurerbar platt-form för en operatörspanel. Denna plattplatt-form ska kommunicera med omvärlden via en CAN-buss.
1.3
Mål
Målet med detta projekt är att utvärdera möjligheten att skapa en plattform för en operatörspanel som minimerar NRE-kostnaden vid varje ny kundkonfigu-ration.
Utöver detta ska olika CAN-standarder studeras för att undersöka om och hur en homogen protokollstruktur kan implementeras för att kunna skicka meddelanden över olika standarder.
1.4
Metod
Projektet delas upp i två stycken delfaser vilka beskrivs nedan, arbetet kommer växla fram och tillbaka mellan dessa två vid behov.
1.4.1 Konstruktion av hårdvaruplattform
Inledningsvis kommer en kravbild på plattformen specificeras och utefter denna väljs en microkontroller ut. Altium Designer 14 används därefter för att rita upp ett kretschema och efter färdigställandet av schemat även utforma kretskortets layout. Så långt som det går kommer ytmonterade komponenter att användas som väljs ut efter Syncores standarder. Vid leverans av det färdiga kretskortet kommer alla komponenter att handlödas fast.
1.4. METOD 1. Inledning
1.4.2 Mjukvaruutveckling
Utvecklingen av mjukvaran kommer att fokusera på att utforma en arkitektur i programspråket C som enkelt är modifierbar för att enkelt kunna ändra beteendet hos strömbrytarna för varje individuellt projekt.
Kapitel 2
Seriell kommunikation
Under detta kapitel kommer den teori som ligger till grund för detta arbete att förklaras. Läsaren ska vid behov kunna få nödvändig bakgrundsinformation häri-från.
Inom telekommunikationen och datorvetenskapen innebär seriell kommunikation processen att skicka data bitvis i en sekvens genom någon kommunikations kanal. Alternativet till detta är parallell kommunikation vilket innebär att ett flertal bitar skickas på samma gång över flera kanaler. Fördelen med att skicka seriellt är bland annat ett färre antal kablar, vilket minimerar det fysiska utrymmet kabeln tar upp. Detta frigjorda utrymme kan istället användas för att isolera mot yttre störningar och dessutom minska tillverkningskostnaderna.
Två begrepp som förekommer inom seriellkommunikation är DTE, Data Terminal Equipment, och DCE, Data Communications Equipment. Dessa termer används för att indikera stiftkonfigurationen på kontakterna på en enhet och riktningen av signalerna på dessa stift. En dator är en DTE enhet, medans de flesta andra enheter, såsom modem är en DCE enhet.[3]
2.1
OSI-modellen
OSI-modellen är uppdelad i sju lager, var och en av dessa lager beskriver olika aspekter i ett datornätverk. Med start i det nedersta lagret kommer alla att be-skrivas kort nedan.[1]
2.1. OSI-MODELLEN 2. Seriell kommunikation
Figur 2.1: De olika lagrena i OSI-modellen[1]
2.1.1 Fysiska lagret
Det nedersta lagret i OSI-modellen beskriver de fysiska egenskaperna i ett nätverk, till exempel vilka kablar som används för att koppla ihop enheter, vilka typer av kontakter som används och hur långa kablarna får vara. Utöver detta så specificerar det fysiska lagret även de elektriska egenskaperna av signalerna som används för att överföra data genom kablarna mellan två noder i ett nätverk. Här definieras inte signalernas mening utan detta sker i de ovanliggande lagrena.
Ett exempel på en enhet i det fysiska lagret är en repeater. En repeater används för att vidarebefordra signaler om man överskrider den maximala kabellängden som tillåts eller när man vill distribuera en signal från en kabel till en eller flera andra kablar.[1]
2.1.2 Datalänkslagret
Datalänkslagret är det nedersta lagret där bitarna som överförs i nätverket är till-delad någon mening. Ett datalänksprotokoll adresserar saker som storleken på varje datapaket som skickas, olika sätt att specificera en mottagare för paketen så att de når sitt avsedda mål samt metoder för att garantera att inte flera noder försöker
2.1. OSI-MODELLEN 2. Seriell kommunikation
prata över nätverket samtidigt. Dessutom tillhandahåller datalänkslagret grund-läggande feldetektering och korrigering för att försäkra att den data som skickas är den data som tas emot. Om ett okorrigerbart fel uppstår måste datalänkspro-tokollet specificera ett sätt att avsändaren blir informerad om felet så att paketet kan skickas igen.
I detta lagret har varje enhet i nätverket en fysisk adress som kallas MAC-adress, detta är hårdvaruadressen till enheten som tilldelats den vid tillverkning.[1]
2.1.3 Nätverkslagret
Det tredje lagret har till uppgift att dirigera alla meddelanden på nätverket från en enhet till en annan. En viktig funktion i nätverkslagret är logisk adressering, som tidigare nämnts har varje enhet på nätverket en fysisk adress, MAC-adress. Denna går inte att ändra på. Men för att använda en annan metod att referera till de olika enheterna i nätverket används logiska adresser. En logisk adress ger en dator i nätverket en plats där den kan nås, en adress som kan tilldelas vid konfiguration av nätverket. Ett populärt protokoll i nätverkslagret är IP, detta, såsom alla andra protokoll i det tredje lagret, måste översätta de logiska adresserna till MAC-adresser.
Routing är en annan viktig funktion i nätverkslagret, vilket innebär att hitta en lämplig väg genom nätverket. Detta används då en dator vill skicka ett paket till en dator i ett annat nätverk. Då används en router som vidarebefordrar paketet till destinationsnätverket. Routrar måste kunna ansluta till nätverk som använder sig av olika datalänksprotokoll.[1]
2.1.4 Transportlagret
Huvudsyftet med transportlagret är att se till att datapaketen förflyttar sig över nätverket med tillförlitlighet och utan fel. Detta åstadkoms genom att etablera en anslutning mellan enheter på nätverket, bekräfta mottagandet av paket och skicka om paket som inte tagits emot eller som är korrupt när de kommit fram. I många fall så delar transportlagret upp stora meddelanden i små paket som effektivt kan skickas över nätverket. Vid mottagande sätts dessa paket ihop igen till det ursprungliga meddelandet.[1]
2.1. OSI-MODELLEN 2. Seriell kommunikation
2.1.5 Sessionslagret
Sessionslagret etablerar sessioner, instanser av kommunikation och datautbyte, mel-lan noder i nätverket. För att kunna överföra data över nätverket måste först en session etableras. Sessionslagret ser till att dessa skapas och upprätthålls på ett bra sätt.[1]
2.1.6 Presentationslagret
Det sjätte och näst sista lagret är ansvarig för att konvertera datan som skickas över nätverket från en typ till en annan. Till exempel kan informationen komprimeras så att ett mindre antal bytes krävs för att representera datan när den sänds, vid mottagandet så packar transportlagret upp den igen. En annan uppgift för presen-tationslagret är att vid behov kryptera datan hos avsändaren och sedan dekryptera igen hos mottagaren.[1]
2.1.7 Applikationslagret
OSI-modellens översta lager, applikationslagret, hanterar olika tekniker som pro-gram använder för att kommunicera med nätverket. Namnet på detta lager är lite missledande då inte applikationerna i sig (till exempel Google Chrome och Spo-tify) är en del av lagret utan istället de tekniker och protokoll som används av programmen för att interagera med nätverken på olika sätt. Ett av de mest använ-da protokollen i applikationslagret är HTTP som är grunden för hela World Wide Web.[1]
2.2. RS-232 2. Seriell kommunikation
2.2
RS-232
RS-232 standarden är en samling av andra anslutningsstandarder mellan olika typer av utrustning. Första upplagan kom redan 1962 och utvecklades då för att koppla ihop fjärrskriftsmaskiner, en elektrisk skrivmaskin som användes för att kommuni-cera skrivna meddelanden från en punkt till en annan med modem. Sedan 1962 har tre nya revisioner publicerats, den senaste är EIA232F som introducerades 1997. Standarden bytte då namn från RS232 till EIA232.[4]
Standarden beskriver bland annat de elektriska signalegenskaperna såsom spän-ningsnivåer, signaleringshastigheten, timingen och stigningshastigheten på signa-lerna och hur kontaktdonen som används ska se ut samt vad stiften i dessa används till.
Då RS232 utvecklades för mer än 50 år sedan har många förenklade versioner sprungit fram för applikationer som inte gick att föreställa sig på 60-talet. Idag så liknar i princip alla seriella gränssnitt EIA232 i hur deras spänningsnivåer, protokoll och kontaktdon ser ut. Då inte branschen inte kunde enades om en specifik förenklad standard så finns idag många gränssnitt som är skapade för att vara kompatibelt med en EIA232 kontakt men är inte kompatibla med varandra.
EIA232 definierar spänningsnivåerna som motsvarar logisk nolla till mellan +3 och +15 V samt logisk etta till intervallet -3 och -15 V, detta i relation till jord, spänningar mellan -3 och +3 V är alltså ingen giltig signal.[4]
2.3
UART
En UART, Universal Asynchronous Receiver/Transmitter, är en krets som översät-ter data mellan parallell och seriell form. Benämningen universell kommer av att kretsen kan omkonfigureras för olika dataformat och överföringshastigheter. Oftast är en UART en del av en, eller en egen, IC-krets som används för seriell kommuni-kation över en dator eller en extern enhets serieport. Det är även vanligt att UARTs är inbyggda i mikrokontroller. En variant av UART som kan kommunicera synkront är USART, Universal Synchronous/Asynchronous Receiver/Transmitter.[5] En UART tar in bytes av data och placerar dessa i ett skiftregister och vid över-föringen skiftas en bit i taget ut på ledningen. När mottagaren sedan tar emot de enskilda bitarna placeras de i ett annat skiftregister som skiftar inåt istället för ut. På detta sätt byggs de ursprungliga bytesen upp igen.
2.4. CAN 2. Seriell kommunikation
Oftast sker varken generering eller mottagande av de externa signalerna direkt hos UARTen utan en separat gränssnittsenhet används för att konvertera de logiska nivåerna som UARTen använder till de externa signalnivåerna som kan se ut på många olika sätt. Ett vanligt exempel på standard för signalnivåer som används är tidigare nämnda RS-232.[5]
2.4
CAN
Controller Area Network (CAN), eller CAN-buss, är en seriell kommunikations buss som utvecklades av Robert Bosch. CAN, som är definierad inom Internationella standardiseringsorganisationen (ISO), utvecklades ursprungligen mot fordonsindu-strin med tanken att ersätta den dåvarande komplexa kabelhärvan med en betydligt enklare tvåkabelsbuss. Specifikationen kräver hög tolerans för elektriska störning-ar och förmågan att utföra självdiagnostik och repstörning-arera eventuella datafel. Dessa egenskaper har lett till att CAN blivit populär inom en stor mängd olika branscher, bland annat inom flygindustrin och marinen.[2]
CAN kommunikations protokollet, ISO-11898: 2003, beskriver hur informationen förflyttas mellan enheter på ett nätverk i enlighet med OSI modellens uppdelning i olika lager.
2.4. CAN 2. Seriell kommunikation
Figur 2.2: Översikt över de olika lagerna som CAN standarden innefattar[2] I figur 2.2 upprättar applikationslagret en anslutning till ett högnivå protokoll som till exempel det tillverkaroberoende CANopen, detta är ett av de protokoll som kommer undersökas närmare senare i rapporten.
CAN-protkollet är ett såkallat CSMA/CD+AMP protokoll, vilket står för "Carrier-sense, multiple-access with collision detection and arbitration on message priority". CSMA betyder att varje nod i nätverket måste vänta en fördefinierad tid, under vilken den är inaktiv, innan den skickar ett meddelande. CD+AMP betyder att meddelandekollisioner löses automatiskt genom att det meddelande med högst pri-oritet får företräde på bussen. Detta sker genom att varje nod i nätverket hela tiden ligger och lyssnar av bussen, även om de samtidigt själva sänder på den. Om en nod skickar ut en logisk etta och samtidigt läser av en logisk nolla på bussen betyder detta att någon annan skickar samtidigt med högre prioritet, noden väljer då att avbryta sin sändning försöker sedan skicka igen efter den tidigare nämnda fördefinierade perioden.[2]
2.4. CAN 2. Seriell kommunikation
2.4.1 Uppbyggnaden av ett CAN meddelande
Standard meddelande
Figur 2.3: CAN meddelande med standard 11-bitars identifierare[2] • SOF - Indikerar början av ett meddelande, används för att synkronisera
no-derna på bussen efter att den varit i vila
• 11-bitars identifierare - Bestämmer prioriteten på meddelandet, desto lägre identifierare, desto högre prioritet
• RTR - Säger om sändaren vill ha information från en annan nod eller inte. En logisk nolla betyder nej, logisk etta ja.
• IDE - En logisk nolla indikerar att en standard 11-bits identifierare utan förlängning används
• r0 - Reserverad för framtiden
• DLC - Specificerar hur många byte data som skickas i meddelandet, 0 till 8 • Data - Eventuell meddelandedata, upp till 64 bitar
• CRC - Innehåller kontrollsumman, antal bitar data överförda, för meddelan-dedatan. Används för feldetektering
• ACK - Vid mottagande ändrar varje nod som tagit emot ett korrekt medde-lande denna logiska etta till en nolla för att indikera att ett felfritt meddemedde-lande har mottagits. Om en nod detekterat ett fel lämnas denna bit oförändrad och sändaren skickar sedan om hela meddelandet.
• EOF - Indikerar slutet på ett meddelande.
• IFS - Sju bitar som berättar hur länge CAN-kontrollern behöver för att för-12
2.4. CAN 2. Seriell kommunikation
flytta det mottagna meddelandet till meddelandebuffern Förlängt meddelande
Figur 2.4: CAN meddelande med förlängd 29-bitars identifierare[2] Det förlängda CAN-meddelandet som visas i figur 2.4 innehåller alla delar som det vanliga utöver dessa tillägg:
• SRR - Tar över RTR-bitens plats i ett standard meddelande
• IDE - En logisk etta på denna plats indikerar att identifieraren innehåller 18 extra bitar.
• r1 - En extra bit som är reserverad för framtiden
2.4.2 CAN-bussen
En grundläggande egenskap i CAN standarden är de motsatta logiska tillstånden mellan bussen, sändaren och mottagaren. Vanligtvis är en logisk hög nivå associerad med en etta och en logisk låg nivå med en nolla, men på en CAN-buss är det inverterat.[2]
2.4. CAN 2. Seriell kommunikation
Figur 2.5: Den inverterade logiken hos en CAN-buss[2]
Om två noder försöker skicka ett meddelande över bussen samtidigt ges tillträde till det meddelande med lägsta identifierare. En fördel med CAN är att meddelanden varken förstörs eller blir korrupta då flera noder sänder samtidigt, detta fungerar som tidigare nämnt genom att alla noder konstant avlyssnar bussen och skiljer det som skrivits till bussen från det som avläses innebär det att ett meddelande med högre prioritet sänds samtidigt.[2]
Figur 2.6: Meddelandeprioritet på CAN-buss[2]
I boken Embedded Networking with CAN and CANopen[6] finns vidare information om både CAN i sig samt ett av de mest använda CAN protokollen för inbyggda system, CANopen.
Kapitel 3
Hårdvara
I kapitlet nedan ges en översikt på hårdvaran som använts i projektet.
3.1
Mikrokontroller
Under denna sektion kommer de olika mikrokontrollers som använts under pro-jektets gång beskrivas. Alla de nedan beskrivna mikrokontroller är vid samma kapselstorlek direkt pinkompatibla med varandra.
3.1.1 Val av mikrokontroller
Innan sökandet av en mikrokontroller specificerades de krav som projektet ställde på den, dessa kvar listas nedan.
• CAN-interface • Lågt inköpspris
• Minst 24 GPIO-pinnar, fyra per strömbrytare
Flertalet tillverkare har mikrokontrollers som överensstämmer med kravspecifika-tionen. Diskussioner fördes därför med några av de anställda på Syncore om
vil-3.1. MIKROKONTROLLER 3. Hårdvara
ken tillverkare de föredrog och STM kom ut som vinnare. Då en tillverkare valts, filtrerades kravställningen ut hos återförsäljaren Digi-Key[7]. Ur filtreringen kom en lång lista med mikrokontrollers där de flesta endast såldes i paket om minst 1500 enheter, STM32F042K6T6 och STM32F042C6T6 var de billigaste kontroller-na som inte hade det kravet. Enda skillkontroller-naden på dessa två mikrokontrollerkontroller-na var antal I/O-pinnar, K6 hade 26 och C6 38, för att ha lite större marginal valdes STM32F042C6T6.
3.1.2 STM32F042x
STM32F042x familjen av mikrokontrollerna använder sig av ARM® Cortex®-M0 32-bit RISC arkitektur som arbetar i 48 MHz[8]. Inbyggt finns upp till 32 kB flashminne, 6 kB SRAM och en lång lista med kringutrustning. Gemensamt för alla medlemmar i denna familj är följande:
• En I2C
• En SPI och en I2S • Två USART
• En full hastighets USB • Ett CAN-interface
• En 12-bitars ADC • Fyra 16-bitars timers • En 32-bitars timer • En PWM timer
Alla i STM32F042x familjen klarar av att arbeta i temperaturer från -40 till +85 °C, vissa ända upp till +105 °C, med en spänningskälla som kan ligga mellan 2.0 och 3.6 V.
Dessa mikrokontroller finns i sju olika kapslar med 20 till 48 pinnar. Beroende på vilken kapsel som valts tillkommer viss kringsutrustning. Nedan kommer den kapseln som valts för detta projekt beskrivas.
3.1. MIKROKONTROLLER 3. Hårdvara
STM32F042C
STM32F042C är den enda i familjen som kommer i en kapsel med 48 pinnar, utöver detta är det enda som skiljer den från de övriga i familjen att den har ett extra SPI-interface. Detta innebär att den får betydligt fler pinnar över till GPIOs än de andra familjemedlemmarna, då detta projekt använder sig av flertalet strömbrytare som kräver upp till fyra pinnar vardera var detta faktum en avgörande faktor i valet av mikrokontroller.
3.1.3 STM32F100xx
Till skillnad från STM32F042x familjen så bygger STM32F100xx på ARM Cortex™-M3 32-bit RISC arkitektur arbetandes i 24 MHz[9]. Här finns upp till 128 kB flash-minne och maximalt 8 kB SRAM inbyggt. Övriga skillnader från tidigare nämnda familj listas nedan:
• En I2C • En USART
• Två 12-bitars DACar
• Två 16-bitars timers • Saknar CAN-interface
Arbetstemperaturen och den önskade spänningsnivån för dessa mikrokontroller är densamma som för STM32F042x familjen.
Där F042x kontrollerna slutade på kapslar med 48 pinnar börjar STM32F100x och finns med ända upp till 100 pinnar.
STM32F100RB
Denna mikrokontroller fanns inbyggt i det utvecklingskit, STM32VLDISCOVERY [10], som användes under projektets början då den slutgiltiga hårdvaruplatformen inte var färdigställd.
Förutom att inte något CAN-interface fanns i denna familj så var det från projektets synvinkel ingen skillnad på STM32F100RB och STM32F042C.
3.2. KRINGUTRUSTNING 3. Hårdvara
3.1.4 STM32F103C6
I projektets slutskede behövdes en extra mikrokontroller tas in av skäl som för-klaras senare i rapporten. Ur projektets synvinkel är STM32F103C6 identisk med STM32F042C6.
3.2
Kringutrustning
I denna sektion kommer kringutrustningen som använts i projektet att beskri-vas.
3.2.1 Kongsberg Automotive SKIM modul
SKIM, Smart KAn Interface Module[11], är en flexibel I/O-modul mellan externa enheter och ett CAN (J1939) nätverk från Kongsberg Automotive.
De enskilda I/O-portarna kan konfigureras som bland annat analoga eller digitala insignaler eller en pulsbreddsmodulerad utsignal med hjälp av ett Windowsbaserat verktyg.
Modulen är kompakt och IP-67 certifierad för att fungera i tuffa mijöer.
Kapitel 4
Utförande och
Implementation
Nedan kommer de olika delarna som byggt upp arbetsgången i projektet att be-skrivas.
4.1
Hårdvaruutveckling
I denna sektion kommer utvecklingen av hårdvaruplattformen att diskuteras.
4.1.1 Altium Designer 14
Hela hårdvaruutvecklingen skedde i Altium Desginer 14[12] som kombinerar hela utvecklingsprocessen i ett designverktyg som är enkelt att använda men svårt att bemästra.
4.1. HÅRDVARUUTVECKLING 4. Utförande och Implementation
4.1.2 Schemaritning
Under denna sektion kommer kretsschemat att bestyckas upp i olika delar och beskrivas var för sig.
Mikrokontroller
Processen påbörjades med att granska databladet för den utvalda mikrokontrollern[8] efter eventuella kringkomponenter som krävdes. I enlighet med detta datablad fil-treras inspänningen från eventuella spikar med hjälp av ett antal avkopplingskon-densatorer, storleken på dessa kondensatorer specificerades i databladet.
Strömförsörjning
För att driva de olika delarna på kretskortet behövdes två olika spänningar, +12 V och +3.3 V. +12 V erhålls direkt från den inkommande spänningskällan och behövs endast filtreras från spikar, men för att få +3.3 V krävs en spänningsregu-lator.
På grund av bristande kompetens inom området och begränsat med tid togs be-slutet att plocka hela strömförsörjningsdelen från ett gammalt projekt.
Två olika alternativ diskuterades, en linjär och en switchad spänningsregulator. Bå-da alternativen har fördelar och nackdelar. En linjär spänningsregulator är enklare och kräver mindre komponenter, men har sämre verkningsgrad än en switchad lösning och är beroende av vilken inspänning som tillförs. Switchade spänningsre-gulatorer är mer komplicerade att konstruera, men ger en stabilare utspänning som är oberoende på vilken spänning som matas in i regulatorn.
I spänningsregulatorn kopplades mikrokontrollern och CAN-tranceivern in och des-sa drog 120 mA respektive 100 mA, detta skulle med en linjär spänningsregulator leda till en effektförlust i form av värme som illustreras av ekvationen nedan. Skulle en högre inspänning användas skulle effektförlusten bli ännu större.
(12 − 3.3) ∗ (0.120 + 0.100) = 1.914W (4.1)
4.1. HÅRDVARUUTVECKLING 4. Utförande och Implementation
För att leda bort 1.9 W värme skulle en kylfläns behöva monteras på spänningsre-gulatron, för att slippa detta togs beslutet att använda en switchad lösning. CAN
Ut från microkontrollerns CAN-kontroller går signaler till en CAN-transceiver, mo-dellen som valts är en SN65HVD230D från Texas Instruments, denna verkar som ett gränssnitt mellan bussen och MCUn.
Kring transceivern krävdes det en del kringutrustning som syns i figuren 4.1 nedan. Alla beteckningar som nämns är hämtade därifrån.
Närmast CAN-tranceivern, U3, sitter ett motstånd, R21, som används för att ju-stera stigningshastigheten på de utgående signalerna. Bredvid finns ett till termi-neringsmotstånd, R3, som ska sitta i ändarna av CAN-bussen. Termineringsmot-ståndet är kopplat till en bygel, J1, så att det vid behov kan kopplas ur eller in. D18 och D19 används som ESD-skydd för CAN-bussen. L2 är till för att däm-pa asymmetriska störningar som kan uppstå på bussen. Slutligen är C8, C9 och C10 avkopplingskondensatorer som används för att filtera bort AC-spänning och spänningspikar hos matningspänningen och på bussen.
Figur 4.1: CAN-tranceiver
Strömbrytare
En undersökning om vilka strömbrytare som var mest populära ute på marknaden utfördes bland några av företagets kunder. Resultatet från denna undersökning
4.1. HÅRDVARUUTVECKLING 4. Utförande och Implementation
visade att V-serien: Contura II och III från Carling Technologies[13] var bland de mest använda av de utfrågade företagen.
Dessa strömbrytare finns i ett antal olika utföranden. Nedan är en lista på olika egenskaper som kan antas, dessa kan kombineras hur som helst.
• En eller tvåpoliga brytare • Två eller tre lägen
• En, två eller helt utan lysdioder. Dessa är antingen beroende eller oberoende vilket läge strömbrytaren är i
• Med eller utan återfjärdring
Gemensamt för alla dessa konfigurationer är att de har samma fysiska mått och stiftplacering. Detta innebär att endast en design krävs om den utgår från kon-figurationen med tre lägen och två oberoende lysdioder. Sedan kan den faktiska konfigurationen som används specificeras i mjukvaran. Detta utnyttjades dock inte i detta arbete utan individuella scheman skapades för varje typ av strömbryta-re.
4.1.3 Kretskortslayout
Efter färdigställandet av kretsschemat som granskats och godkänts av en mer erfa-ren utvecklare på företaget påbörjades nästa steg i utvecklingen, kretskortslayou-ten.
Då huvuddelen av kretskortet upptas utav de sex strömbrytarna utgick designen från dem. Avståndet mellan brytarna bestämdes så att det skulle få plats kompo-nenter emellan dem i ett försök att minimera den totala kretskortsytan. I figur 4.2 nedan syns det hur spänningsregleringen, inringat i grönt, och CAN-tranceivern, inringat i svart, är placerade emellan strömbrytarna.
I övre högra hörnet på kortet finns mikrokontrollern med tillhörande komponen-ter och en bygel som kan användas för att välja vilken kod som ska laddas då kontrollern går igång. Under dessa finns två stiftlister för UART och SWD samt plattformens huvudkontakt. Dessa används för debuggning av mjukvaran respekti-ve programmera MCUn. Huvudkontakten ansluter systemet till CAN-bussen samt ger tillgång till yttre spänningsmatning.
4.2. MJUKVARUUTVECKLING 4. Utförande och Implementation
I figur 4.2 nedan finns en helhetsbild över den slutliga kretskortsdesignen.
Figur 4.2: Färdiga kretskortslayouten
4.2
Mjukvaruutveckling
4.2.1 Keil µVision 5
Programmet som beskrivs i kommande stycken är skrivet i utvecklingsmiljön Keil µVision 5[14] som är en komplett IDE för inbyggda system. Koden är skriven i programmeringsspråket C.
4.2.2 CAN protokollstack
Ett av målen med projektet var att undersöka möjligheterna att implementera en gemensam protokollstack för olika CAN-standarder på MCUn. Under arbe-tets gång studerades ett antal alternativ för att använda CANopen, bland annat CANFestival[15], CANopenNode [16] samt att skriva en egen stack. Att skriva en egen stack skulle ta flera månaders arbetstid och därför uteslöts detta alterna-tiv.
Det alternativ som utreddes djupast var CANFestival. Försök gjordes för att modi-fiera de exempel som fanns att tillgå för att fungera på mikrokontrollern som valts ut. Detta drog dock ut på tiden och ett beslut togs att avbryta dessa försök och istället bara använda de inbyggda funktioner som finns i STM32F0 seriens bibliotek för att skicka CAN-meddelanden.
4.2. MJUKVARUUTVECKLING 4. Utförande och Implementation
4.2.3 Programflöde
Som tidigare nämnts skedde utvecklingen av mjukvaran i det första skedet på ett utvecklingskort från STM som byggde på STM32F100RB. Detta användes inled-ningsvis för att skapa en grundläggande förståelse för hur programmeringen av deras mikrokontrollers gick till då ingen tidigare erfarenhet av detta fanns. Utveck-lingskortet användes även för att kunna påbörja mjukvaruutvecklingen innan dess att hårdvaran färdigställts och på så sätt effektivisera projektets arbete.
Initialt var tanken att mjukvaruarkitekturen skulle bygga på att varje strömbry-tare skickade en avbrottssignal till mikrokontrollern varje gång de bytte läge, men efter ett antal iterationer var det klart att detta inte var ett effektivt sätt att lösa problemet på. Istället designades en helt ny arkitektur som förklaras nedan. Vid uppstart sker först en initiering av all kringutrustning systemet kommer an-vända sig av, till exempel CAN, USART, de GPIO-pinnar som strömbrytarna är kopplade till och två timers inställda på 1 kHz respektive 1 Hz. Efter initieringen övergår programmet till main-loopen som snurrar tills dess att systemet stängs av. Loopen har två uppgifter, att se om någon av strömbrytarna har bytt läge och i så fall generera ett event som skickas till funktionen EventRouter som beskrvis längre ner, samt att se om någon av LEDarna ska ändra läge. En översikt över dessa processer kan ses i figur 4.3.
Med en frekvens på 1 kHz eller 1000 gånger i sekunden sker ett avbrott i main-loopen för att läsa av de pinnar strömbrytarna är kopplade till och se om någon av dessa har bytt läge. Om detta har skett signaleras detta till funktionen som körs i main-loopen genom en vektor av flaggor.
4.2. MJUKVARUUTVECKLING 4. Utförande och Implementation
4.2. MJUKVARUUTVECKLING 4. Utförande och Implementation
Utöver detta visas i figur 4.4 även hur avbrottet vid mottagande av CAN-meddelanden ser ut. Vid ett inkommande meddelande filtreras förangivna meddelande identifi-erare ut medan resten ignoreras. Om en identifiidentifi-erare filtrerats ut kommer detta meddelande att generera ett event som skickas till den tidigare nämnda EventRou-tern.
4.2. MJUKVARUUTVECKLING 4. Utförande och Implementation
4.2. MJUKVARUUTVECKLING 4. Utförande och Implementation
I figur 4.5 beskrivs den funktionen EventRouter som har till uppgift att faktiskt utföra det som ska ske då en strömbrytare byter läge eller ett CAN-meddelande ankommit. Denna funktion består av en stor switch-sats som ser vad som genererat eventet och utför specifika uppgifter för just det fallet. Till sist finns en 1 Hz timer som endast läser av en vektor med flaggor som anger om en ljusdiod ska blinka eller inte, är flaggan satt inverterar funktionen diodens läge till ON eller OFF, men tändandet och släckandet av dessa sker i funktionen som körs i main-loopen.
Figur 4.5: Flödesschema över eventroutern
4.3. PROBLEM 4. Utförande och Implementation
4.3
Problem
Det största problem som uppstått, under arbetets gång, kom efter monteringen av alla komponenter var klar och mikrokontrollern skulle programmeras. Programmet som har hand om att programmera enheterna[17] fick kontakt med MCUn och kun-de ikun-dentifiera kun-denna men inte skicka över kokun-den. Efter nästan en veckas felsökning av både kretskortet och inställningar i mjukvaran togs beslutet att försöka byta ut mikrokontrollern och löda dit en ny, likadan. Även under detta moment uppstod problem, första försöket att löda dit den nya MCUn gick snett och ledde till att den också blev obrukbar. En ny beställning vart tvungen att göras då endast två stycken köptes in initialt. Den modell som användes från början, STM32F042C6, gick inte att få tag på med kort varsel och istället beställdes STM32F103C6 som tidigare nämndes i kapitel 3.1.3. När denna anlände utfördes ett nytt försök att byta mikrokontroller och detta gav ett positivt resultat, allting fungerade direkt och det kunde konstateras att den gamla kontrollern var trasig.
Kapitel 5
Resultat
Här i rapportens avslutande kapitel kommer projektets resultat att summeras och diskuteras. Även problem som uppstått under projektets gång och fortsatt utveck-lingsarbet kommer tas upp.
5.1
Slutsats
Målet med detta projekt var att utveckla en modulariserbar operatörspanel med fokus på att minimera NRE-kostnaden för varje ny kundkonfiguration, samt under-söka möjligheten för en gemensam protokollstruktur för olika CAN-standarder. På grund av projektets begränsade tidsram fick undersökningen dock strykas. För att utvecklingstiden av en ny konfiguration ska bli så kort som möjligt har antalet filer som behöver modifieras minimerats, om inte en ny typ av strömbry-tare introduceras är det endast funktionen EventRouter som behöver ändras. Här specificeras det önskade beteendet då någon brytare byter läge eller systemet tar emot ett CAN-meddelande. Vid implementation av en ny typ av brytare läggs ett nytt fall till i funktionen CreateSwitchEvent switchsats, denna funktion beskriver vilka event varje enskild typ av brytare genererar.
I figur 5.1 och 5.2 nedan syns det färdiga kretskortet. Hålet i mitten där en sjätte strömbrytare borde sitta är där på grund av en av brytarna som levererades var feltillverkad och det fanns ingen tid att byta ut den. Ett försök gjordes för att tillmötesgå denna feltillverkning men det visade sig när kretskortet kom att
för-5.1. SLUTSATS 5. Resultat
skjutningen av stiften blivit spegelvänd, strömbrytaren passar men måste monteras på baksidan.
Figur 5.1: Framsidan av det färdiga kretskortet
Figur 5.2: Baksidan av det färdiga kretskortet
5.2. DISKUSSION 5. Resultat
5.2
Diskussion
Spannet på detta examensarbete har inkluderat allt från kravspecifikation på hård-varan till en färdig design, utveckling av tillhörande mjukvara och slutligen en färdig prototyp som motsvarar alla förväntningar.
Detta breda spann har gjort projektet väldigt utmanande, men samtidigt mycket roligt. Kunskaper inom många områden har behövts införskaffas under arbetets gång då jag varken utvecklat ett kretskort eller lött ytmonterade komponenter tidigare. Mycket tid gick i början av projektet åt till saker som i slutändan aldrig blev implementerat, som till exempel att integrera en färdig protokollstack för CAN på mikrokontrollern, detta är dock något som fortsatt skulle kunna undersökas för vidareutveckling av plattformen i framtiden. Vid reflektion är detta tid som istället kunde ha lagts på att förbättra designen av hårdvaran.
5.3
Vidareutveckling
För att utöka modulariseringen av plattformen kan som tidigare nämnts en ge-mensam layout för alla olika strömbrytare, från serien som använts i detta projekt (Contura II och III från Carling Technologies), användas och istället konfigurera mjukvaran för de specifika brytarna som monteras.
En annan del i projektet som bör optimeras är kretskortslayouten. Hade det funnits mer tid eller mer förkunskaper inom området innan, hade denna aspekt av platt-formen kunnat bli bättre. I efterhand upptäcktes en färdig ram för sex stycken strömbrytare av den sort som använts här och formfaktorn på kretskortet skulle kunnat utvecklas för att passa denna ram.
Till sist så skulle en protokollstack för olika CAN-standarder kunna implementeras för att kunna tillhandahålla bland annat diagnostik av systemet för att indikera om något fel inträffat, då detta inte är implementerat i den prototyp som finns idag.
Referenser
[1] D. Lowe, “Layers in the OSI Model of a Computer Network - For Dummies,” 2013.
[2] S. Corrigan, “Introduction to the controller area network (CAN),” Application Report, Texas Instruments, no. August 2002, pp. 1–15, 2002.
[3] Intea, “Introduction to Serial Communication,” 2002. [4] C. E. Strangio, “The RS232 standard,” 2006.
[5] F. Durda, “Serial and UART Tutorial,” 1996.
[6] O. Pfeiffer, A. Ayre, and C. Keydel, Embedded Networking with CAN and CANopen. Copperhill Media, 2008.
[7] Digi-Key Corporation, “DigiKey Electronics - Electronic Components Distri-butor,” 2014.
[8] STMicroelectronics, “STM32F042x family microcontrollers,” 2014. [9] STMicroelectronics, “STM32F100xx family microcontrollers,” 2012.
[10] STMicroelectronics, “STM32VLDISCOVERY Discovery kit for STM32F100 Value Line - with STM32F100RB MCU - STMicroelectronics,” 2014.
[11] Kongsberg Automotive, “Skim Modules | Kongsberg Automotive,” 2014. [12] Altium Limited, “Altium Designer Overview - PCB Design Tool,” 2014. [13] Carling Technologies, “Carling Technologies,” 2012.
REFERENSER REFERENSER
[14] ARM Ltd and ARM Germany GmbH, “Keil µVision IDE,” 2013. [15] CanFestival - http://sourceforge.net/projects/canfestival/, 2003. [16] CANopenNode - http://sourceforge.net/projects/canopennode/, 2012. [17] STMicroelectronics, “STSW-LINK004 STM32 ST-LINK utility -
STMicroe-lectronics,” 2014.
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upp-hovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garan-tera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/
In English
The publishers will keep this document online on the Internet - or its possible repla-cement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent per-mission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/
Avdelning, Institution Division, Department Datum Date Sprk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport
URL för elektronisk version
ISBN
ISRN
Serietitel och serienummer Title of series, numbering
ISSN
Linköping Studies in Science and Technology Thesis No. LiTH-ISY-EX-ET--15/0430--SE
Titel Title Frfattare Author Sammanfattning Abstract Nyckelord Keywords
För att styra utrustningen i olika fordon inom industrin används olika ty-per av strömbrytare som sitter monterade på en oty-peratörspanel. Från dessa går det ofta individuella signalkablar fram till enheterna som ska styras. Ett alternativ för att att slippa den störa mängden kablar detta kan leda till är att istället koppla strömbrytarna till en mikrokontroller, denna vidarebefodrar sedan signalerna via en CAN-buss till en ECU som styr alla enheter från en central position i fordonet.
Under detta examensarbete, som har utförts hos Syncore Technologies AB, har därför en operatörspanelsplattform, både hård- och mjukvara, utvecklats för att uppnå en minimal NRE-kostnad för varje ny kundkonfiguration som inkluderar olika bestyckningar av strömbrytare samt beteenden för dessa.
To control the equipment in different industrial vehicles various types of switches are used which are mounted on a operator panel. Individual signal cables are often connected from these switches to their respective equipment they are controlling. An alternative to avoid the large amount of cables this can lead to is to instead connect the switches to a microkontroller which in turn forwards the signals through a CAN-bus to a ECU which controls all units from a central position in the veichle.
During this bachelor thesis, which has been performed at Syncore Technolo-gies, a software and hardware platform for a operator panel has because of this been developed. This platform has a goal to minimize NRE-cost for every new customer configuration which involves different setups of switches and various behaviours of these.
ISY,
Dept. of Electrical Engineering 581 83 Linköping 2015-05-05 -LiU-Tek-Lic–2015:2015 -http://XXX 2015-05-05
A modular operator panel based on a CAN-bus interface
Modulariserbar operatörspanel baserad på ett CAN-buss gränssnitt Linus Isberg Martinsson
× ×
