CAN USB kijelző modul, datalogger BOSCH Invented For Life Pályázat
Készítette:
Zubán Gergely Márton BME – VIK III. évf.
Konzulens:
Piroska László
Robert Bosch kft. (GS-TC/ENG1-Bp)
Csorba Kristóf
BME – AUT
1
1. Tartalom CAN USB KIJELZŐ MODUL, DATALOGGER .......................................................................................................... 1 1.
TARTALOM ............................................................................................................................................... 2
2.
BEVEZETÉS ............................................................................................................................................... 3
3.
ÁLTALÁNOS ISMERTETÉS .......................................................................................................................... 4
4.
A RENDSZER FELÉPÍTÉSE DIÓHÉJBAN........................................................................................................ 5
5.
A HARDVER .............................................................................................................................................. 6 5.1.
0. VERZIÓ ..................................................................................................................................................6
5.1.1.
Tápegység .........................................................................................................................................6
5.1.2.
CAN meghajtó áramkör ....................................................................................................................7
5.1.3.
CAN vezérlő áramkör ........................................................................................................................7
5.1.4.
Layout ...............................................................................................................................................8
5.2.
VÉGLEGES KAPCSOLÁS ..................................................................................................................................9
5.3.
KIVITELEZÉS .............................................................................................................................................11
6.
A SZOFTVER ........................................................................................................................................... 12 6.1.
BOOTLOAD ..............................................................................................................................................12
6.2.
CAN VEZÉRLŐ ..........................................................................................................................................13
6.3.
PIC18F4550 ..........................................................................................................................................15
6.4.
USB – CAN C# .......................................................................................................................................16
7.
TOVÁBBFEJLESZTÉSI LEHETŐSÉGEK ........................................................................................................ 18
8.
GAZDASÁGOSSÁG .................................................................................................................................. 19 8.1.
MÉRET ...................................................................................................................................................19
8.2.
KÖLTSÉGEK ..............................................................................................................................................19
8.3.
FEJLESZTÉS ..............................................................................................................................................20
9.
ÖSSZEGZÉS ............................................................................................................................................. 21
10.
HIVATKOZÁSOK ...................................................................................................................................... 22
11.
MELLÉKLETEK ......................................................................................................................................... 23
11.1.
FÉNYKÉP A HARDVERRŐL ............................................................................................................................23
11.2.
KÉPERNYŐMENTÉS A SZOFTVERRŐL ..............................................................................................................24
11.3.
AZ ESZKÖZ MŰKÖDÉS KÖZBEN .....................................................................................................................25
11.4.
GYÁRTÁSI KÖLTSÉG SZÁMÍTÁSA ....................................................................................................................26
11.5.
CAN TESZTÁBRÁK .....................................................................................................................................27
11.6.
LOG FILE..................................................................................................................................................28
2
2. Bevezetés
Eredeti témakiírásom szerint Piroska László és Csorba Kristóf segítségével „CAN kijelző modul” készítésével foglalkoztam, ami egy jármű CAN üzeneteibe kódolt információ egyszerű és paraméterezhető megjelenítési felületéül szolgál. Sok számunkra érdekes jelet forgalmaz a busz, melyek több esetben közvetlenül, könnyen értelmezhetők. Amint kicsit beszélgettünk a lehetőségektől körvonalazódott bennem, hogy a szó szerinti témától el lehet térni, ha az „életre tervezés” a cél. Manapság, akinek egy ilyen modulra szüksége lehet, annak rendelkezésére áll laptop, netbook, esetleg PDA, melyek könnyű kezelhetőséget
és
nagyon
magas
rugalmasságot
biztosítanak
a
beépített
hardver
sokoldalúságának és a divatos magas szintű programnyelveknek köszönhetően (JAVA, C#, stb.). Ilyen eszközökre nyugodtan alapozhatunk, ráadásul saját alkalmazásunk legtöbbször az erőforrások töredékét használja csak ki, így más funkciót is betölthetnek akár egy fejlesztőközpontban, akár egy szerelő műhelyben. A fent leírtak alapján úgy döntöttem, hogy a kijelző modul szerepét egy laptopra ruházom, a CAN laptophoz való illesztését pedig egy elterjedt, korszerű szabvánnyal (USB) végzem el. Ha a buszon közlekedő adatokat már látja számítógépünk, korlátlannak tekinthető memóriájának és nagy műveleti sebességének köszönhetően azokat nem csak megjeleníteni, naplózni, hanem azonnal feldolgozni, statisztikákat készíteni és beavatkozni is képes. Ez a megoldás sok szempontból kedvező, rengeteg a dolgozat elkészítése alatt kiaknázott és kiaknázatlan lehetőséget tartogat, mindenképp életre termett.
3
3. Általános ismertetés
A feladat az volt, hogy egy jármű CAN kommunikációban forgalmazott üzenetei közül minél több hasznos információt kinyerjünk. Hozzáférhetünk például olyan üzenetekhez melyek a műszerfalon láthatók, és láthatunk olyan üzeneteket is, melyek az autó különböző egységeinek belső változóit hordozzák. Ezeket az információkat helyben láthatóvá, értelmezhetővé tevő CAN interface készítése volt tehát a feladat. Az elkészített rendszer alkalmas a busz monitorozására, a buszon közlekedő adatok feldolgozására, szűrésére. Lehetőség van az összes beérkező üzenet figyelésére, naplózására, illetve rendelkezésre áll egy grafikus felület, mely az adatokat könnyen értelmezhető formában, paraméterezhetően jeleníti meg. Olyan hardver összeállítást terveztem, mellyel a kitűzött feladatok korszerűen, jól skálázhatóan és kis méretben megoldhatók. A fejlesztéshez mindenképp egy eszközpárra volt szükségem, hogy a kommunikációval kapcsolatos feladatokat könnyebben megoldhassam, tesztelhessem, a tervezés így két lépcsőben történt. A 0. verzió mérőpontokkal, ledekkel rendelkezik, melyek könnyítik a fejlesztést. Második lépcsőként ezen összeállítás letisztult, elsődlegesen a funkcionalitást szem előtt tartó mása készült el. A szoftverkomponenseket is bővítettem, átírtam, így a végleges rendszer már képes a CAN üzenetek fogadásán, szűrésén túl bootload üzemmódban magán szoftvert frissíteni USB –n keresztül. Az elkészült eszközök otthoni gyártásúak, ezért méretük nem összemérhető egy felületszerelt, többrétegű technológiát alkalmazóval, viszont struktúrájuk így jól követhető, ami fejlesztéshez ideális.
4
4. A rendszer felépítése dióhéjban
Az eszköz alapja egy olyan mikrokontroller
(1)
,
mellyel könnyű USB szabványú kapcsolatot létrehozni. A mikrovezérlő egyrészről a számítógéppel – a rajta futó programmal; másrészről egy CAN vezérlő áramkörrel kommunikál (1. árba). A CAN vezérlő
Notebook Windows – C#
áramkör alatt a buszhoz történő illesztést biztosító IC
USB
látható.
PIC µC 18F4550 SPI
A számítógépre készített szoftver az érkezett üzeneteket visszafejti, azokat egy műszerfalhoz hasonló
ablakban
fordulatszám,
jeleníti
vízhőmérséklet,
meg sebesség
(sebesség, fokozat,
CAN Controller MCP 2515 RX
TX
CAN Transceiver MCP 2551
gázpedál-állás); illetve lehetőség van az üzenetek CAN BUS naplózására is. A szoftver a kapott értékeket egyszerű grafikonon is képes ábrázolni, látványos eredményt kapunk a laborautóval történő teszteléskor. 1. árba: felépítés
5
5. A hardver 5.1.
0. verzió
5.1.1. Tápegység
Az eszközt úgy terveztem, hogy mind az USB által szolgáltatott 5V –ról, mind a gépjárművekben elérhető 12V tápfeszültségről használható legyen (2. ábra). Alapvetően, ha az utóbbi rendelkezésre áll, akkor erről működik, feltéve, hogy a Schottky diódák előtt a Stabilizátor IC kimenetén magasabb feszültség áll be, mint amit az USB felől kapunk. A stabilizátor IC kimenetét célszerű lett volna egy hasonló diódával megemelni. A mikrokontroller felé jelzés megy a rendelkezésre álló külső forrásokról, így akár az le is kapcsolódhatna az USB +5V vonaláról. Az ábrán még a feszültség stabilizátor által megkövetelt kapacitásokat láthatjuk, illetve. mindkét forrás jelző ledet kapott.
2. ábra: tápegység kapcsolás
6
5.1.2. CAN meghajtó áramkör
A kapcsolásban az MCP 2551
(2)
CAN
meghajtó áramkör szerepel, mellyel könnyen és gyorsan lehet a busz jelszintjeihez illeszteni áramkörünket.
A
CAN
meghajtó
csupán
tápfeszültséget kap, hozzá van kötve a 3. ábra: 2551 CAN meghajtó
vezérlőhöz és a CAN –hez.
5.1.3. CAN vezérlő áramkör
A CAN üzenetek fogadása nem a mikrokontrollerben történik, hanem egy külön – erre a célra fejlesztett célhardverben, a Microchip MCP 2515 CAN (3) kontrollerben. Ezen egység és az imént említett MCP 2551 azért szerepel a Microchip palettáján, hogy az olyan mikrokontrollereikhez is egyszerű legyen CAN csatlakozást biztosítani, melyekben nincs hardveres CAN támogatás. Integrált CAN perifériájú családjuk is igen széles választékú, de egyelőre USB és CAN egységet is tartalmazó eszközük nincs, így esett a választás erre a megoldásra. Az MCP 2515 alapvetően SPI buszon kommunikál a mikrokontrollerrel. A vezérlő fogadó és küldő regiszterei rendelkeznek jelző, ill. trigger lábakkal, melyek használata opcionális, független I/O portként is konfigurálhatók.
7
5.1.4. Layout
A mikrokontroller SPI –on kapcsolódik az MCP 2515 vezérlőhöz. Ezen kívül terveztem az eszközre két nyomógombot (bootload, reset) és pár ledet, melyek visszajelzést szolgáltatnak a rendszer állapotáról. A mikrokontroller környékén nem látunk semmi szokványostól eltérő megoldást, a kialakult nyák-terv lejjebb látható (4. ábra). A kapcsolás így sem bonyolult, de párjának létrehozásakor még egyszerűsítettem, amin csak lehetett.
4. ábra: 0. verzió layout
8
5.2.
Végleges kapcsolás
Az áttervezés célja az volt, hogy a végleges verzió mentes legyen minden olyan felesleges hardvertől, mely a fejlesztés során csak kényelmi funkciót látott el. Az alapvető struktúra megmaradt, csak a lehető legegyszerűbben, legkevesebb alkatrész felhasználásával terveztem át az eszközt. Az egyszerűsítésnek áldozatul estek a visszajelző ledek, a bonyolultabb tápegység rész, a CAN vezérlő küldő puffereinek vezérlő jelei.
5. ábra: végleges kapcsolási rajz
Az integrált alkatrészek együtt maximum 335 mA –t vehetnek fel adatlapjuk alapján, a kapcsolás használatakor pedig ezt az értéket meg sem közelítették. Az USB-ről felvehető 500 mA áramot tehát a rendszer semmiképp sem haladja meg, ezért nem indokolt külső forrás
9
használata, az USB táplálás elégséges. A CAN vezérlő a regiszter vezérlőszálak nélkül is teljes értékű kommunikációra képes, itt is csak egy kényelmi funkciótól estünk el.
A végleges terv az alábbi layout rajzon látható:
6. ábra: végleges layout
10
5.3.
Kivitelezés
A kapcsolási rajzok tervezéséhez és a layout generálásához a DipTrace (4) programcsomagot használtam, mely non-profit célra 250 pin korlátozással freeware. Amint az a fényképeken és layout terveken látszik, az otthoni gyártás miatt furatszerelt alkatrészeket és egy vezetékezési réteget használok. A TOP oldalon csak átkötések vannak. Mivel nem kell nagy áramokkal számolnunk a vezetékezést 25 mil –nek választottam, készítéskor figyeltem, hogy ne történjen alámaródás. Ahol elvékonyodást tapasztaltam a vezetéket befuttattam ónnal. A vezetékezés általános szabályait betartottam, az SPI és a CAN RX, TX vonalakat sebességkritikusságuk miatt rövidre terveztem. Az integrált áramköri elemeket foglalatba helyeztem, így cseréjük fejlesztés alatt egyszerű. A végleges verzió kapott egy plexi fedőlapot, mely a kezelhetőséget hivatott megkönnyíteni. Nagyságrendileg 30% méretcsökkenéshez vezetett ez az egyszerűsítés.
7. ábra: az11 eszköz felülről
6. A szoftver
A szoftver felépítésének megértéséhez az 1. ábrát kell szemünk előtt látni. Egyrészt fut egy szoftver a mikrokontrollerben, mely a buszhoz történő kapcsolódást és az adatok USB továbbítását végzi, másrészt a számítógépen fut az a program, mely az érkezett adatokat feldolgozza.
A fejezetben
sorra
veszem
a
rendszer
elemeit, az
alacsony
szintű
mikrokontrollerben futó programkomponensektől a laptopon futó C# programig.
6.1.
Bootload
A Microchip sok szabadon felhasználható példaprogramot, függvénykönyvtárat készít termékeihez, melyek nagyon megkönnyítik a tervezést. Ezek közül az USB Framework PIC18 (5) segített a fejlesztésben. A 18F4550 USB kommunikációban slave –ként képes részt venni, de a programozó célja és az alkalmazási terület szerint választhat a keretprogram által támogatott „Generic USB Device”, „USB Human Interface Device”, „Mass Storage Device” illetve „Communication Device Class” módok közül. A CDC módban üzemelő soros port szimulálást választottam, mert a számítógép oldaláról ez kezelhető a legegyszerűbben. A framework tartalmaz gyári összeállításokhoz használt bootloadert. A bootload tulajdonképp egy szolgáltatás, ami arra jó, hogy processzorunk szoftverét az USB-n keresztül frissíteni tudjuk. Első használat előtt a processzorunkba egy bootload programot égetjük be a programozóval, majd ennek a már mikroprocesszorban futó kis alkalmazásnak köszönhetően létre tud jönni egy USB kapcsolat a számítógép és a mikroprocesszor közt. Ez a kapcsolat arra elég, hogy a 12
processzorunkba a bootloader alá saját programot töltsünk. A bootloader a felhasználói program betöltése után is megmarad, és egy bizonyos gomb indításkor - újraindításkor való nyomva tartásával elérhető. Tulajdonképp a µC minden egyes induláskor ezt indítja, és ő adja át a vezérlést a gomb állapotától függően a felhasználói programnak, vagy tartja magát bootload módban, amikor a felhasználó újraprogramozhatja. Meggyorsítja a munkát, illetve otthoni szoftverfrissítés lehetőségét kínálja ez az opció. Ezen bootloader verzió USB HID üzemmódban kapcsolódik a számítógéphez, ami azért nagyon kedvező, mert így a fejlett operációs rendszerek külön driver nélkül is támogatják. A felhasználói programot más linker fájllal kell fordítani, hogy a bootloader mellé kerülhessen.
6.2.
CAN vezérlő
Az MCP 2515
(3)
CAN vezérlő sokkal többet kínál, mint amennyit egy átlagos CAN -re
kapcsolódó beágyazott eszköz elvárna, egy egyszerű monitorozásnál pedig rendkívül kevés szolgáltatását használjuk ki. A vezérlőt SPI buszon keresztül kell felprogramozni, az alábbi üzemmódok közül választhatunk: 1.
Configuration mode. A felkonfiguráláskor kiválasztandó mód
2.
Normal mode. Üzemszerű működés.
3.
Sleep mode. Alvó állapot.
4.
Listen-only mode. Csak hallgató állapot.
5.
Loopback mode. Belső, virtuális átvitel – „visszacsatolt” 13
A vezérlőt a fent specifikált kritériumok alapján látszólag használhatnám két módban is, a „normál”, és a „csak hallgató” módban, de utóbbiban a hibás kereteket is elküldi a mikroprocesszor felé, melyekre most nincs szükség. Ebben a módban például akkor érdemes üzemeltetni, ha különböző buad-rate –en kommunikáló rendszerekben is univerzálisan működő eszközt szeretnénk készíteni. Ekkor magától addig állítja a baud-rate –et, amíg főként értelmezhető kereteket nem kap, ez az automatikus baud-rate felismerés legegyszerűbb módja.
Normál mód: az a mód, amiben egy ipari alkalmazásban, üzemszerűen használható az eszköz. Ebben a módban kell szót ejteni arról, hogy milyen szolgáltatásokkal rendelkezik a vezérlő. A beérkezett üzeneteket két pufferben képes eltárolni, melyek közül az egyik a másik tartalék puffere is tud lenni. A kontroller képes az üzeneteket maszkolni, szűrni, ez alapján a különböző pufferekbe betölteni és jelezni a mikrokontroller felé. (2 elfogadási maszk és 5 elfogadási szűrő) Így el tudjuk érni, hogy egy adott címtartományból nézze meg az összes üzenetet, vagy csak a számára érdekesekre figyeljen, a többi üzenetet hagyja figyelmen kívül. Az elküldendő adatot 3 Tx pufferbe tölthetjük, melyekből jelzésre adja ki a kívánt üzenetet. Ha nem kívánjuk használni a Tx pufferek hardveresen triggerelt kiadásának lehetőségét, vagy az Rx pufferek tele jelzését, akkor ezeket természetesen szoftverből is megtehetjük, ill. a RTS (Request To Send) / BF (Buffer Full) pinek digitális be / kimenetként is felkonfigurálhatók.
14
6.3.
PIC18F4550 (1)
A PIC mikrokontroller kiválasztásakor az is fontos szempont volt, hogy a típus szoftvertámogatása igen jó. Rendelkezésre áll fejlett C fordító, függvénykönyvtárak, és mintaprogramok. A szoftver alapvetően az alábbi folyamatábrán láthatóan üzemel:
reset BTN2 reset
1
INITSYS
0
main
Bootload
USB TASKS
CAN PROCESS
8. ábra: a mikrokontroller szoftvere
Az INITSYS felel azért, hogy a PIC minden perifériája a szükséges definiált állapotba kerüljön: Portok, SPI, USB, Timerek, stb. Ezen beállítások befejezése után a gép belép a main ciklusba, mely váltogatva hajtja végre a számítógép felé kötelező USB –s feladatokat, illetve az MCP2515 által vett üzenetek feldolgozását. A CAN PROCESS figyeli, hogy érkezett-e új üzenet, ha érkezik, akkor azt előfeldolgozza, majd elmenti a USB TASKS által továbbított USB küldő pufferbe. A beolvasási folyamat után jelzi a CAN kontrollernek, hogy az adott fogadó pufferbe érkezhet új adat. A küldő pufferből az adat az emulált soros porton érkezik meg a számítógéphez, ott egy C# –ban írt program dolgozza fel azt. Az eszköz jelenleg egy összes csomagot továbbító üzemmódban fut, a felhasználási környezet biztonságkritikussága miatt nem szólhat a CAN forgalomba.(11.5. fejezet) 15
6.4.
USB – CAN C#
Az egész beágyazott rendszer nem sokat érne magában, ha a jeleket, amiket szolgáltat nem tudjuk felhasználóbarát felületen megjeleníteni, vagy épp nem tudjuk naplózni. Az eszköz működésének bemutatásához nagyon kedvező lehetőséget biztosít a BME –n és a Bosch –nál is rendelkezésre álló laborautó, melyet a Bosch mérnökei az automataváltó-vezérlések teszteléséhez – fejlesztéséhez készítettek. Ezen laborautó által generált CAN üzeneteket jelenítem meg programomban egy autó műszerfalához hasonló módon. A CAN üzenetek visszafejtésében segített a BME MIT dokumentációja
(6)
, ill. nekem is sikerült néhányat
értelmezni – a laborautó kimeneti paramétereinek változtatása alapján. Visszafejtett CAN üzenetek: ADDR
D0
D1
0x280
D2
D3
Fordul a ts zá m l ow
Fordul a ts zá m hi gh
D4 D5 D6
D7
1926 rpm: 0x1e18 6085 rpm: 0x5f14 0x380
0x5a 0
Hűtővíz
Gá zpedá l
Pi l l a ngós zel ep
-48°C: 0x00
0%: 0x00
0%: 0x00
143°C: 0xfe
100%: 0xff
100%: 0xff
Sebes s ég 0kmh: 0x00 306kmh: 0xff
0x440
Sebes s égvá l tó 1-4: 0x1-0x4 N: 0x0 R: 0x7 1. táblázat CAN mátrix
16
A számítógépes program két szálon fut, az egyik szál felel a soros port kezelésért, és az üzenetek egy dinamikus struktúrában való tárolásáért; a másik szál pedig a grafikus felület dupla pufferelt kirajzolásáért, a mutatók, kijelzők, mért eredmények kijelzésért felel. A dupla pufferelés a gyakori frissítés miatti vibrálás elkerülésének érdekében került implementálásra, tulajdonképpen a beépített kirajzoló függvényt felüldefiniálva. A thread biztonság érdekében SortedList típusú osztályban tárolok, amit egyszerre több folyamat is olvashat és egy írhat. A grafikus felületen megjelenő objektumok (váltó, mutatók) egyszerűen példányosíthatók, százalékos bemenetet szolgáltatva nekik a következő kirajzoláskor az annak megfelelő értéket mutatják. (11.2. fejezet) A műszerfalat szimbolizáló grafikára rákattintva egy olyan ablak nyílik meg, melyben a vett adatok grafikonon ábrázolhatók. Választhatunk, hogy melyik adatokat szeretnénk látni, a folyamatos rajzolást megállíthatjuk, az aktuális képet lementhetjük. A grafikonkezelő függvénykönyvtár a ZedGraph (6) munkáját dicséri, mely LGPL alatt felhasználható. A főprogramban egy gombbal választhatunk, hogy szeretnénk-e az érkező üzeneteket naplózni. A naplózás a program mellé egy text fájlba történik, így a naplózott adatokat számítógéppel utólag is könnyű kiértékelni. (11.6. fejezet) Az elkészült eszköz egy általános interface, így ahol CAN technológiát alkalmaznak, ott könnyen kezelhető, gyorsan fejleszthető megoldást nyújt, legyen szó akár egy kaputelefonról, vagy egy kamionról.
17
7. Továbbfejlesztési lehetőségek
A hardver összeállítás lehetővé teszi több további funkció implementálását. Elsősorban az emulált soros kommunikáció USB HID módra cserélésére gondoltam, ami driver függetlenséget ad. A hardver továbbá alkalmas CAN üzenetek továbbítására is, ezért például OBD II szabványú hibakód kiolvasás is készíthető. Említésre méltó, hogy a mai okostelefonok és palmtopok is rendelkeznek a feldolgozáshoz szükséges erőforrással. Ezen eszközökre is ugyanolyan egyszerűen fejleszthetőek alkalmazások, mint nagyobb testvéreikre, hordozhatóságuk még kedvezőbb, így mindenképp megfontolandó a feldolgozó szoftver átvitele, mely C# .NET keretrendszerben jól támogatott. Minden hardverelem beszerezhető felületszerelt tokozásban, így könnyen gyártásba vihető a termék. Felületszerelt technológiával az alábbi méretekkel számolhatunk (65x20 mm):
9. ábra: SM alkatrészeket használó terv
A csatlakozókat az összehasonlíthatóság kedvéért hagytam meg, természetesen ez már akár OBD csatlakozóba is integrálható méret, egy rágógumi csomaggal egyenlő nagyságú.
18
8. Gazdaságosság
A tervezés első lépéseként azt a választást kellett meghoznom, hogy interfacet készítsek, vagy inkább egy olyan összeállítást, mely önmagában működőképes – idegen szóval stand-alone. Úgy gondolom érdemes sorra venni, hogy milyen előnyökkel és hátránnyal jár a kijelző modult és egyéb beavatkozó perifériákat alkalmazó eszközök helyett a tárgyalt megoldás választása.
8.1.
Méret
A továbbfejlesztési lehetőségeknél leírtak szerint az eszköz egyszerűen gyártható akár csatlakozóba szerelve is. Valójában egy laptop nagyságával kell számolnunk, mely esetleg kényelmetlenséget okozhat. Ideális egy olyan összeállítás, mely PDA–t, vagy tablet-pc–t használ, ekkor már hasonló méretnél járunk, mint egy integrált kijelzőt tartalmazó konkurens. Mobilitását nehéz így összemérni, de a konstrukciók mindenképp adottak, sajnos nincs akkora rugalmasság, mintha magunk választanánk kijelző és gombok köré akár műszerfalba építhető dobozolást.
8.2.
Költségek
Számításaim szerint az általam megépített eszköz gyártási költsége csatlakozókkal, dobozolással, a jelenlegi kivitelben: 4830 Ft, SMD kivitelben: 4710 Ft. (11.4. fejezet) Ezeken a költségeken felül egy kijelzőt és beavatkozó szerveket is használó összeállítás gyártásakor felmerül a kijelző árán kívül a sokkal erősebb kontroller, ill. a nyomó-, vagy 19
érintőgombok költsége. Nem szeretnék spekulálásba bocsátkozni, de ezen költségek az én tervem árának sokszorosát teszik ki. A közgazdaságtan egy meglévő laptopot egy új projekt szempontjából tipikusan elsüllyedt költségnek kezel, ami annyit tesz, hogy a projekt gazdaságosságának, várakozásainak számolásakor nem vesz figyelembe. Ezen gondolkodásmód is oda vezet, hogy ha van már meglévő számítógépünk, akkor mindenképp ez a megoldás az ésszerű.
8.3.
Fejlesztés
Ha belegondolunk, hogy milyen lépések kellenek ahhoz, hogy egy szép grafikus kijelzőn adatokat és felhasználói kéréseket valós időben dolgozzunk fel, rájöhetünk, hogy itt már nem elég egy egyszerű 8 bites mikrokontroller, a funkcionalitás nem csak erősebb hardvert kíván, hanem akár egy real-time operációs rendszer működtetését is megkövetelheti. Ilyen rendszerekben a bővítés nehézkes lehet, hosszú fejlesztői munkát kíván. Az általam létrehozott USB –s interface belső működése az alapszolgáltatást adja – adatokat lehet küldeni, fogadni vele. Ennél többre nincs is szükség, mert minden másról a hoszt számítógép gondoskodik. A PC fejlett operációs rendszert futtat, melyhez könnyen, gyorsan fejleszthető
programozási
nyelvek
és
keretrendszerek
társulnak.
implementálásához elég egy új objektumot illeszteni meglévő rendszerünkbe.
20
Egy
új
funkció
9. Összegzés
Az USB CAN interface elkészítése közben elsődlegesen a pályázat és a Bosch „invented for life” mottóját tartottam szem előtt, mely a tárgyalt eredményre vezetett. A dolgozatban dokumentáltam a tervezés fontos lépéseit, a felmerült kérdéseket, lehetőségeket és a megvalósítás menetét. A tervek alapján az eszközöket otthoni módszerekkel legyártottam, majd az elkészült eszközök hardverének viselkedését mértem. A hardvert a szoftverrel együtt alapos tesztelésnek vetettem alá. A kiírást és a kitűzött feladatokat teljesítettem: az eszköz alkalmas az üzenetek paraméterezhető grafikus megjelenítésére, naplózására, bootload üzemmódra. Az elkészült szoftver könnyen kezelhető, látványos és moduláris – egyszerűen bővíthető. A fejlesztés .NET keretrendszerben történt, mely lehetővé teszi a mérőprogram átvitelét PDA –ra vagy okostelefonra. A prototípus hordozható méretű, alacsony költségű, így könnyen elérhető megoldást nyújt terepi teszteléshez, szereléshez. A fejlesztési lehetőségek közt megjelölt SMD kivitelben már egy nagyon kompakt és sokoldalú eszközt kapunk, amely széles körű alkalmazhatóságot tesz lehetővé.
21
10. Hivatkozások
[1]. Microchip Technology Inc. 18F4550. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010300.
[2]. Microchip Technology Inc. MCP 2551. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010405.
[3]. Microchip Technology Inc. MCP 2515. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010406.
[4]. Novarm. DipTrace. http://www.diptrace.com.
[5]. Microchip Technology Inc. Full Speed USB framework. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en021940.
[6]. Scherer Balázs. AKH 05b CAN visszafejtés. [Dokumentum] Budapest: BME-MIT, 2008. [7]. ZedGraph. .Net graph tool wiki. http://www.zedgraph.org.
22
11. Mellékletek 11.1.
Fénykép a hardverről
0. verzió
végleges hardver 10. ábra
11. ábra: az eszköz alulról
23
11.2.
Képernyőmentés a szoftverről
12. ábra: az adatokat fogadó program három grafikonnal
13. ábra: sebességet és fordulatszámot ábrázoló grafikon
24
11.3.
Az eszköz működés közben
14. ábra: a mérési elrendezés
15. ábra: valós és virtuális mutatók
16. ábra: az eszköz működés közben
25
11.4.
Gyártási költség számítása
A számításkor kiskereskedelemben elérhető árakkal tudtam csak számolni, természetesen nagy tétel esetén a megjelölteknél sokkal kedvezőbb ajánlatokra lehet számítani.
Tétel DIP kivitel 18F4550 PIC DIP 950 MCP 2515 DIP 480 MCP 2550 DIP 230 Nyáklemez 1 oldal 56cm2 500 USB Csatlakozó DIP 50 USB kábel 320 Műszerdoboz 300 Összeszerelési költség 2000 Szum: 4830 Ft
SMD kivitel szállító QFN 970 ChipCAD kft TSSOP 530 ChipCAD kft SOIC 270 ChipCAD kft 2 oldal 21cm2 310 I+K elektronikai bt SMD 30 Lomex kft 320 Lomex kft 280 Lomex kft 2000 4710 Ft
2. táblázat: árkalkuláció
26
11.5.
CAN tesztábrák
Az eszköz jelenleg passzív módban működik, a CAN üzenetküldés hardver közeli szinten le van tiltva, így az eszköz csatlakoztatása nem befolyásolhatja a busz jelalakját. A 17. ábra az eszköz csatlakoztatása nélküli jelalakot, a 18. ábra pedig a csatlakoztatás elenyésző hatását mutatja.
17. ábra: az interface csatlakoztatása nélkül
18. ábra: interface csatlakoztatásával
27
11.6.
Log file
Az üzenetek az alábbi formátumban kerülnek naplózásra, a táblázatban bekereteztem azokat az adatokat, melyeket a program felhasznál. address D0 5A0 80 5C0 2 1AC 0 320 0 440 8 540 B0 100 72 280 0 288 80 1A8 7D 4A0 D2 101 A7 320 48 440 8 540 C0 280 0
D1 EF 0 0 0 54 0 A AA A2 50 6A D 0 54 0 C6
D2 4A 80 0 0 25 FF D1 40 11 0 D2 D9 80 25 FF 40
D3 B8 0 0 0 FE 0 0 3B 6A 0 6A 0 C9 FE 0 3B
D4 EE 0 0 0 7F FF 0 AA 4E 0 D2 0 6A 7F FF C6
D5 EE 0 0 0 80 0 0 74 6D 0 6A 0 0 80 0 AB
D6 C 0 0 0 D8 0 1 24 FE 0 D2 0 70 E0 0 24
D7 30 0 0 0 2 50 0 6A 24 0 6A 0 0 2 5F 78
L 8 8 8 8 8 8 8 8 8 3 8 8 8 8 8 8
Date 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009. 2009.
07. 07. 07. 07. 07. 07. 07. 07. 07. 07. 07. 07. 07. 07. 07. 07.
27. 27. 27. 27. 27. 27. 27. 27. 27. 27. 27. 27. 27. 27. 27. 27.
Time 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:500 17:41:06:515 17:41:06:515 17:41:06:515 17:41:06:515
3. táblázat: részlet a log fájlból
Érdekességképp: fél óra tesztelés alatt kb. 70MB adatot mentett el a szoftver.
28
