Fórum témák
» Több friss téma |
Sziasztok!
CAN buszos kommunikációt szeretnék létrehozni PIC18-al. Elolvastam a MicroChip AN713-as ( An introduction to the CAN protocol that discusses the basics and key features), AN228-as ( A CAN Physical Layer Discussion), az AN754-es ( Understanding Microchip's CAN Module Bit Timing) és az AN738-as ( PIC18C CAN Routines in 'C') leírásait. Az lenne a kérdésem, hogy kezelt/használt-e már közületek CAN buszt (mindegy, hogy Standard vagy extended keret), mert a C-ben megírt rutinok jól használhatónak tűnnek, csak azt nem értem, hogy a PIC18FXXXX (értelemszerűen CAN buszos protokollt is használni képes) eszköz adatlapjában több Receive és Transmit buffer is van, azonban a C rutinok csak adott illetve vett üzenetekről szólnak. A másik problémám, hogy az üzeneteknél van Mask-olási és Filter (szűrési) lehetőség is, de egyenlőre nem találom, hogy mi is a különbség a kettő között, mert mind a kettőre azt írja, hogy az azonosítót nézi és nem egyezés esetén nem foglalkozik a csomaggal. Előre is köszönöm a válaszokat! Üdv! AN713 AN228 AN754 AN738
Hali!
Bocsánat a késői válaszért, most is csak véletlen találtam ezt a topicot. Egyszer csináltam egy készüléket pic18f458-cal CAN (nem ECAN!) buszra, szívesen segítek, ha tudok. Kérdéseidre válaszolva dióhéjban: 1. A bufferekben vannak az üzenetek, azért van több, mert ha pl multitaskos rendszert fejlesztesz, teljesen külön tudják összerakni az egyes (vagy együvé tartozó) üzeneteket a folyamatok. Fogadásnál, azért van több h az üzeneteket le tudd már eleve válogatni. 2. ha érkezik egy üzenet, akkor az csak akkor lesz fogadva, ha vmelyik, filter regiszterben megadott cím egyezik az üzenetben címzettként megadottal, de elegendő csak a filterhez tartozó maszk regiszter által kijelölt biteknél. Így megoldható, h a piced ne csak egy bizonyos címmel fogadjon, hanem egy komplett címtartománnyal, vagy akár többel is. Remélem nem érkeztek a válaszok későn, ha nem volt világos, vagy van még kérdésed nyugodtan írj.
Sziasztok!
Ki tudnátok fejteni esetleg bővebben, hogy egy PIC-es rendszerben hogy is megy a multitaszkos vezérlés/kezelés?
Ha jól tudom akkor minden taszk kap egy időegységet ami alatt futhat.
Szerintem egy timer + ugrótábla szükséges hozzá. Ha lejár a timer akkor megszakítás és ha timer megszakítás volt akkor tábla ponter növelése és ugrás a következő taszkra. Ha rosszul gondolom/tudtam akkor javitsatok ki.
Tomee jól gondoltad, tényleg lehet így is csinálni, ezt hívják időosztásos fix időközös rendszernek (vagy vmi hasonlónak). Időosztásosból is létezik több féle, és ezen kívűl van még prioritásos, és abból is több fajta. A multitaszknál nem az a legnagyobb nehézség, h az egyes process-ek h váltják egymást (hogy birtokolják a processzort mint erőforrást), hanem h hogyan osztoznak az erőforrásokon.
Nem szeretnék belemenni a részletekbe mert az nagyon hosszú lenne, erre vannak külön technikák. Sztem a multitaszkot, nem ebben a topicban kéne megvitatni, ha tényleg érdekel akkor sztem hozzunk létre neki egy topicot, bár sajna annyira nem vok otthon ebben a témában, úgyhogy olyan túlsokat nem tok segíteni.
Szia Danix!
Köszönöm a választ, időközben én is rájöttem a megoldásra! Egyébként amit írtál az operációs rendszerről, azt a Microchip azt hiszem úgy hívja a honlapján (persze nem a Microchip találta ezt ki) hogy RTOS (Real Time Operating System), de még nem volt olyan alkalmazásom amihez kellett volna. Sziasztok!
Sziasztok!
CAN buszon szeretnék összekötni néhány 18F458-as PIC-et. A CCS fordítóhoz adott példaprogramot rátöltöttem 2 PIC-re. Az egyiknek elvileg 2 másodpercenként kellene küldenie egy csomagot, amit a másik vesz, és RS232-n keresztül megjelenít. A gyakorlatban azonban csak 3db csomag feladása történik meg, vétel egy se. Ez az első CAN buszom, és nem tudom, hol keressem a hibát. Tudna valaki tanácsot adni? Előre is köszönöm.
hát lehet, hogy írnék bele olyat, hogy ha megnyomsz egy gombot azon ami a soros porton van, akkor küld valamit a portra, hogy az biztos legyen, hogy működik...
Megnézném a buszcímeket, hogy mindenhol jól vannak-e írva.... honnan tudod, hogy 3 megy ki, és hogy nincsen vétel?
A 3 kimenőt onnan tudom, hogy a küldőt rákötöttem a sorosportra, és sikeres küldés esetén kiírja az elküldött adatot. Ez összesen 3x történik meg. A vételt meg abból gondolom hogy nem működik, mert ha a vevő van a sorosportra kötve, akkor a bejelentkező üzenet után semmi mást nem ír ki, pedig sikeres vétel esetén a vett adatnak meg kéne jelennie.
Elküldöm a mintaprogramot. Az egyik pic-be a küldő, a másikból a vevő kódrészlet van kihagyva. A buszcímeket hogy érted? Elvileg az összes csomagot fogadnia kellene. Vagy nem? 
Ajánlom figyelmedbe a mikrovezérlő leírását... egyetlen sikeres küldés sem történt, mindössze annyi, hogy 3 db send buffer van, és ezek megteltek, azért nem megy tovább...
tovább még nem tudom, sosem foglalkoztam még CAN-el, meg C-ben még nem írtam PIC progit, de nézem még mert teccik 
valószínűleg nem történik meg egyetlen sikeres küldés sem...
Azt a makrós részt nem tudom micsoda, ahol a can_kbhit(), meg a can_tbe() van definiálva, de valószínűleg működik, ha az első 3 alkalommal jön cucc... Igazából a can_init() és az abból meghívott dolgokban kéne keresni a problémát, mert úgytűnik, hogy a küldés része jó... ami a főprogramban van jó... igazából én abban sem látok semmi kivetni valót... áttálítja config módba, beállítgatja a kis dolgait, és visszaállítja normál módba.... Elvileg annak a résznek nem is kéne baja legyen, gondolom az a gyári microchipes téma.... esetleg átírhatnád az adót, hogy a két másodperces rész mindenképpen lefusson, és belül legyen még egy if a küldéssel, és 2 másodpercenként kiírhatná a bus-off bit állapotát, vagy a TXERRCNT tartalmát, és akkor lehet, hogy közelebb lennénk a megoldáshoz...
ja valami kép a hardwerről?
bár ennél szerintem olyan nagy baj nem lehet... nem tudom, olvastál-e a can működéséről... én lég régen, de van a bitfolyamban egy arbitrációs mező, ami arra jó, hogy a fonotosabb üzenetek élvezzenek elsőbséget... vannak recesszív, meg domináns bitek, már nem tudom melyik melyik, de asszem a 0 a domináns... elkezdik küldeni a biteket, és figyelik, hogy mi jelenik meg a buszon, ha valaki fontosabb üzenetet akar küldeni, akkor domináns bitek vannak elöl az arbitrációs mezőben, vagyis ha aki véletlenül pont vele egyszerre kez el küldeni és recesszívet küld annak az üzenetét elnyomja... és az tudja ettől, hogy be kell kussolni, és a fontosabb üzenet áttmegy pl "légzsák nyíjjá ki!" fontosabb minthogy "több üzemanyagot kell befecskendezni, mer mittommivan" mivelhogy ezt a buszrendszert igazából autókhoz fejlesztették ki. Szóval ha valami nem jól van bekötve, és folyamatosan el van nyomva az adás, akkor nem megy átt az üzenet... minden egyes alkalommal amikor nem megy átt az üzenet az növeli az error countert... ha az eléri a 255-t akkor feladja, vagy nem tudom, de arra vár, hogy x db valamilyen bitet vegyen, és csak akkor próbálkozik újra... szóval jólenne látni a számláló tartalmát, ezzel csak arra akartam kilukadni. írjál, ha van valami.... remélem nem volt nagyon összevissza amit írtam...
Egyenlőre teszt jelleggel van egy toldott foldott panel. CAN illesztőnek mcp2551-et használok. Könnyen lehet, hogy valamit félre kötöttem, mert az IC adatlapján nincsen ajánlott bekötési rajz. Így kötöttem be:
1. láb: a PIC CANRX lábára 2. láb: GND 3. láb: +5V 4. láb: a PIC CANTX lábára 5. láb: - 6. láb: CANL 7. láb: CANH 8. láb: GND A busz 2 vezetéke közé mindkét végén 1-1 120 Ohmos ellenállást kötöttem. Ha ez így szerinted is jó, akkor legalább a hardverhibát ki lehet zárni (bár azt könnyebb kijavítani) és mélyebben bele kell ásni magam a szoftverbe. Tudsz valami doksit ajánlani a CAN buszról? Okulásként nem ártana valamit olvasnom róla.
Igazából én sem sokat tudok a CAN-ról, csal beleolvastam a doksiba, ahol láttam magyar leírást az a Kónya féle mikrovezérlős könyv, hát ha nagyon akarsz, akkor ki lehet belőle szűrni információkat, azt nem hiszem, hogy a CAN specifikáció elolvasásával többre mennél...
http://zeus.nyf.hu/~elat/can_busz.ppt talán nézd meg ezt, nem tudom ki csinálta, de ugylátom elég lényegretörő. De amit eddig biztosan tudok neked mondani az az, hogy a program küldés részével nincsen baj, beteszi az adatokat a küldő bufferba, és amikor megtelik a 3 buffer, akkor nem tudja már őket hova tenni, és azért telik meg a buffer, mert valamiért nem tudja elküldeni, vagy rosszul van beállítva, vagy vagy valami hardverhiba van... kapcsolási rjazod nincsen?
Ajánlott rajz ugyan valóban nincs, de leírják egy párszor, melyik lábnak mi a funkciója. Ha úgy kötötted be, ahogy írtad is, akkor az 1-es és 4-es lábak fel vannak cserélve, vagyis semmiféle üzenet nem jut ki a buszra, illetve nem érkezik meg onnan, a kontroller felé.
Mégegyszer átnéztem a doksikat, és igazad van. Tényleg felcseréltem.
 Megzavart, hogy az RS232-nél Rx-et Tx-el kötjük össze. Megcseréltem a két lábat, de továbbra is ugyanaz a hejzet. Lehet hogy kipurcant a buszillesztő IC. Majd kipróbálom újakkal is, de azt előbb venni kell. Köszönöm az eddigi segítségeteket.  Majd írok, mi lett.
Tehetnél fel egy képet a kapcsolásról, lehet, gyorsabban menne a dolog. A 2551-est amúgy nem olyan könnyű kinyírni, strapabíró kis darab. Vcc lábán van kondi (100 nF)? A buszvezetékek mindkét oldalon jó polaritással vannak csatlakoztatva? Egyesével is le tudod őket tesztelni: kösd össze a buszt, vedd ki a kontrollereket, csak a 2551-esek maradjanak a panelon, na meg a táp. Ha mindkét transceiver TxD lábát szabadon hagyod, akkor a CANH és CANL vezetékeken a testhez képest 2.5 V körül kell mérned (a kettő közti különbség 0.5 V alatt), az RxD lábaikon pedig logikai "1"-et, azaz 4 V fölött valamit. Ezután felváltva 0-ra kell húzni előbb az egyik, aztán a másik 2551-es TxD vonalát; a buszon mindkét esetben a CANH vonal szintjének legalább 0.5 V-tal a CANL vonal fölött kell lennie, az RxD vonalakon pedig logikai "0", azaz max. 0.8 V kell, hogy legyen. Ha ez kézzel kapcsolgatva így működik, a transceiver-ek üzemképesek, és inkább a progiban lesz valami baj.
Itt a nyák rajza. Kapcsolási rajzot nem csináltam róla, de szerintem elég jól el lehet igazodni rajta. A rajzon még a PIC és a 2551 között fordítva van az összeköttetés. Azóta már átfordítottam, és kondit is raktam a Vcc lábra.
Megmértem amiket írtál. Szabadon hagyva a TxD lábat CANL és CANH is testhez képest 2,53V, RxD lábakon 5,03V. TxD-t 0-ra húzva a helyzet változatlan. A CANL és CANH között mért fesz mindig 0V. A busz bekötését is kimértem: a 2551 lábain mérve CANL-CANL illetve CANH-CANH 0 Ohm, CANL-CANH mindkét variációban 60 Ohm.
Az említett korrekciókat figyelembe véve jónak tűnik a rajz. Talán annyit mondanék, hogy ha legközelebb tervezel ilyet, a CAN vezetékeit a lehető legrövidebbre készítsd a csatlakozás és az interface-chip között (főleg 250 kbps és afölötti sebességnél), és ha nem muszáj, ne keresztezd őket átkötésekkel.
A leírásod alapján mindkét transceiver rossz; esetleg meg lehetne még próbálni ugyanezt a mérést, de nyitott buszon, vagyis külön-külön a két panelt, de sokat már nem várhatunk ettől. Csak azért említettem, mert mindig utálom, ha egyszerre két elem is tönkremegy...
Nyitott busszal megváltozik a helyzet!
 CANH 2,46 V CANL 2,54 V De sajnos csak ennyi változik. TxD akár 0, akár 1 RxD mindig 1, és a CANH és CANL sem változik.  Tehát mehetek a boltba...
Szerintem a programja jó...
Gyári init rutint használ hozzá, és a send bufferbe bekerülnek az adatok amíg van hely.
Megvettem az új IC-ket és ugyanazt mértem mint a régiekkel. A CANL-CANH közötti különbség csak nyitott busz esetén van meg, az RxD pedig mindíg logikai 1. Feszültség értéke a TxD-től függ. Ha lebeg a TxD akkor 4,9V, ha 0-ra húzom akkor 5,02 körül. Átnéztem a panelt is hogy nincs e benne szakadás vagy zárlat, de nem talátam semmi ilyesmit. Mit lehet kezdeni ilyenkor?
MŰKÖDIK!!!
  Nem tudom mi volt a hiba, de az új IC-ket beraktam a panelba, betöltöttem a progikat, és elindult rendben! Köszönöm mindenkinek a segítséget!
Sziasztok!
Kezdőként egy Can illesztést szeretnék csinálni, PC-s játékpedálok can buszon történő kommunikációjára a pc-vel. A hardver fő elemei ugye a kontroller és a can adó-vevő. Az a kérdésem, hogy milyen szempontok alapján válasszak mikrovezérlőt? Nincs semmi tapasztalatom ilyenben, mekkora flash + eeprom stb... szükséges? Ehhez ha adnátok vmi támpontot azt megköszönném. Üdv, dino
Szia.
Ha PIC-el akarod, akkor olyant amiben van HW-CAN, tehát ne külső MCP2515 kelljen mellé. Pl. 18F2480 vagy 18F2580. Ezek rendelkeznek akkora program/RAM memóriával, hogy egy C-ben implementált CAN+kisebb körítés is bőven 40-60%-ba belefér (tapasztalat). Ha CANopen vagy DeviceNet is kell, akkor nagyobbat válassz. Ipari helyen a CAN illesztő IC optoval (2db 1 a TX-re, 1 az RX-re) le van választva a kontrollertől, és egy galvanikusan leválasztott DC5/5 konverterrel van a táp átvive. CAN illesztőnek PCA82C251 javasolt, ezt alkalmazzák szinte minden "gyári" ipari környezetbe is alkalmasnak talált készülékben (tehát nem MCP2551-et). A CAN timing elég szűk, mindenképp KVARC kell a kontrollerre, és abból leosztani a CAN timer-t. Néhány fórum szerint a MicroChip kontrollerek belső PLL-jének jitterje olyan nagy, hogy 1Mbps sebességen nem használható, vagyis ilyenkor ezt ki kell kapcsolni, és egy nagyobb kvarcot kell használni. Általános probléma a microchip kontrollerekkel, hogy a CAN regiszterek bonyolult bitszervezésűek, így egy C-ben írt programnak olyan sok dolga van, hogy képtelen egy 1Mbps kapcsolatot full sávszélességgel kiszolgálni. Ha AVR, akkor AT90CAN32 vagy AT90CAN64 vagy AT90CAN128. Imi.
Szia.
PC oldalra: mindenképp valamilyen szabványos, a nagy gyártók által is alkalmazott technikákat kell alkalmazni az illesztésre. Vagy RS232<->CAN vagy USB<->CAN. Példa USB<->CAN-re: Bővebben: Link Erről van tapasztalatunk, ipari környezetben is extra stabil, linux alatt is jól megy. Példa RS232<->CAN-re: Bővebben: Link És itt a jobboldali. A downloads alatt van manual, ott részletesen leírja, hogy hogyan kell programozni. Ez alapján lehet készíteni egy saját implementációt is akár. Imi.
Én éppen mcp2515-el szívok. Olyan sok regisztere van, hogy elveszek bennük.
Nagy segítség lenne egy demo, vagy valami, ami htpicc18 alatt lefordul. AVR re van rengeteg projekt, de pic-re csak a mikrocsippes maszlagok amik rommádefiniálhatóak. Csak annyit akarok vele, hogy listen módban ráakasztom a buszra és minden forgalmat kiolvas.
Szia.
Én a Microchip féle fordítót használom, de szerintem átültethető htpicc-re. Lásd melléklet. Imi.
Köszönöm, ez brutálisan jó !
Végülis van mcc fordítóm, próbának meg mindegy, hogy miben fordítok. A mainben elég csak a szokásos: -cpu és port init -spi init -MCP2515 init és lehet is garázdálkodni ? |
Bejelentkezés
Hirdetés |
