Sziasztok!
16 bájtot, azaz 128 bitet kellene kiküldenem egy kimeneten egyszuszra. (meghatározott CAN üzenet, csak el kell küldeni, nem kell figyelni semmit) Az órajel 16MHz, a bitek 2 mikrosekundumonként kellene hogy kikerüljenek, vagyis egy bitre 8 ciklusidő áll rendelkezésere.
Ami fontos, a bitek állítása mindig 2us-ként történjen.
Ja, csak asm-ben értek a PIC-hez, de eddig amin agyaltam, azt nem is menne más nyelven, figyelembe véve az utasítások ciklusidejét.
Lehet akár táblából felolvasni, akár 16-szor ugyanazt a ciklust lefuttatni.
Ha esetleg valakinek van ilyen kész rutinja.
A PIC, ami rendelkezésre áll, 16F628 és 16F676. Ez utóbbiból nagyobb mennyiség áll rendelkezésemre, tehát ha ebbe a PIC-be csak ez a rutin fér bele, akkor tudok mellé másikat tenni.
Üdv: Jácint
Megoldás a csatolmányban. Igaz, csak 15 bájt, mert az épp adott üzenet annyiba belefért, de tetszés szerint bővíthető, szűkíthető.
1 bit szélessége pontosan 2us, 16MHz-s quarzzal.
Sziasztok!
Az első siker már megvan.
Üdv: Jácint
0
Hello!
Ezt most CAN buszra is akarod kiküldeni?
Üdv,
KN
0
Hello!
És a CAN fizikai rétegét azt hogyan oldod meg?
Vagy használsz CAN Trasceivert, csak nem használsz CAN controllert?
Ha szabványos akarnál lenni, akkor a 628-ra akasztanál egy ilyet:
http://www.microchip.com/wwwproducts/en/en010406
Arra meg az adott CAN protokollnak megfelelő Transceivert.
Mondjuk egy ilyet:
http://www.microchip.com/wwwproducts/en/MCP256
Így már kész is lenne egy szabályos CAN NODE.
Üdv!
Kaszi
0
Szia!
TJA1040-en keresztül küldeném a CAN buszra.
Tárolós szkóppal megnéztem az üzenetet, a bitsorozat tartalmazza a bitbeszúrásokat is, tehát csak simán ki kellene küldenem.
Üdv: Jácint
0
Így működhet.
0
És a CAN busz "visszahallgatását" miképp oldod meg?
Ugyanis ha a te üzeneted message ID-jánál kisebb értékű ID jelenik meg, akkor ugye az üzenetet le kell állítani.
Nem értem, hogy miért nem használsz egy SJA1000 kontrollert? Az elvégez minden busszal kapcsolatos dolgot és kész.
Kicsit írhatnál bővebben is a dologról, hogy mi a célja az üzenetnek, milyen rendszerbe akarod küldeni, stb.
Akkor biztosan több segítséget kapsz.
Üdv,
KN
0
Szia KN!
Igazad van, az is kellene bele. Egy kijelzőtől kellene lekérdeznem a megnyomott gombokat. Elvileg nem lóg más a CAN buszon, de úgy nézem, még a figyelés is beleférne a programba 16MHz-s kvarcnál.
Üdv: Jácint
0
Szia Jaca!
Most valóban ne haragudj meg a kérdésért, de 100%-ban ismered a CAN buszt?
Ez egy üzenetszórásos hálózat. Nincs hagyományos Master-Slave viszony. Ennek pl az az előnye, hogy abból nincs gond ha menet közben leesik egy node, vagy felcsatlakozik.
Az, hogy ki ad a hálózaton a MSG ID értéke dönti el. Ami a CAN2.0-nál 21 bit hosszú.
A 0 ID a legerősebb.
Azaz, ha a kijelződön megnyomsz egy gombot akkor az kikerül jó eséllyel a hálózatra, aztán veszi a lapot, aki akarja.
Igazából a különböző protokollokkal lehet csak megvalósítani valami M-S viszonyt.
Én a következőt tenném:
Mint itt mondták, kell egy node-ot építeni.
A kontroller elintéz mindent szinte. Sebesség illesztés, időzítések , egyebek.
A PIC-el meg küldesz üzenetet, vagy épp figyeled, ki mit ad.
Készen is lehet ilyen kis modulokat kapni. Egyik fele UART, másik fele meg CAN busz.
Ne ölj abba munkát szoftveresen, amit már régen megcsináltak hardveresen.
Üdv,
KN
0
Szia KN!
Most tanulom a CAN buszt. A működésével tisztában vagyok, és valóban egyszerűbb lenne kiépíteni egy node-ot. Sőt, mégkönnyebb lenne a dolgom, ha lenne egy CAN analizátorom. Viszont azzal, hogy itt beszélgetünk róla, és jött pár gondolat, jelentősen megkönnyítitek a dolgomat. A jelenlegi célom nagyon egyszerű, ha szerencsém van. Ki kell adnom a CAN buszra egy adott kódsort, és utána várni, hogy jön-e adat.
Üdv: Jácint
0
Szia!
Nézd: http://modtronix.com/im1can.html
Szerezz be egy ilyet, vagy hasonlót, csak kontroller legyen rajta.
Üdv,
Nándi
0
Szia Nándi!
Ehhez meg ha jól sejtem, le kell kódolnom az SPI interface-t. Akkor nyernék vele, ha párhuzamos beírású lenne, de akkor meg az eltérő "bájt"szélességek miatt szívnék.
Van most 6 ciklusidőm bitenként, hogy lekezeljem, ha az RX és a TX nem egyforma (tehát ha más eszköz nullát küld a címzésnél). Ez egy ÉS kapu, és egy bemenet lekérdezése.
Üdv: Jácint
0
Szia Jaca!
Nem vagyok assembly mágus, de a 8 Tic bit idő szoftveres port megvalósításához kissé karcsúnak tűnik számomra.
Bájt beolvasása regiszterbe, shiftelés, bit vizsgálat, ugrás, port állítása, ciklus változók kezelése, ciklus elejére ugrás, ...
Egy szóval: szerintem nem fér bele.
Ha ez nem egy "ezer darabor gyártok minimum költségen" projekt, akkor migrálj PIC18-ra.
Ott lesz 64 MHz órajeled külső alkatrész nélkül -> 0.0625us Tic; 32 Tic / bit.
Akár C-ben is megírhatnád...
Üdv, ty
0
Szia ty!
Hát ez "ezer darabor gyártok minimum költségen" projekt.
A 16 MHz elégnek tűnik, azt már megvalósítottam, hogy egy ilyen PIC-kel figyelem az üzenetet, és az egyes biteknél RB0 lesz magas, nullás biteknél RB1 lesz alacsony. A két kimenet közé tettem két ellenállást, a közös ponton mértem.
Üdv: Jácint
0
Az én olvasatomban
indexelt bájt beolvasása
shift ACC b7 - C
shift C - port
nop...
shift ACC b7 - C
shift C - port
nop....
.
.
.
index csökkentés, ha nem 0 vissza
bőven belefér.
0
Szia!
Most értettem meg, hogy mit írtál, de szerencsére a bogarat elültetted a fülembe. A SHIFT nem volt világos, mit akar jelenteni.
Mondjuk én magát az adatregiszter bitjeit tologattam.
loop
RLF candata,F ;MSB a C-be
RLF PORTB,F ;C a PORTB LSB-be
nop...
goto loop
Üdv: Jácint
0
Sziasztok!
Elég az idő, ez két bájt kiírása, még nop is kellett bele. Igaz, az egész PORTB be van áldozva.
EFFECT_1
MOVLW B'10101100' ;küldendő adat
MOVWF candata ;adat a W-be
BCF STATUS,C
MOVLW B'0000111' ;7 ciklus beállítása
MOVWF TIMER4
loop4
MOVF candata,W
MOVWF PORTB ;W a kimenetre
nop
nop
RRF candata,F ;adat eltolása
DECFSZ TIMER4,F ;ciklusszámláló csökkentés
GOTO loop4
MOVF candata,W ; utolsó bit
MOVWF PORTB
nop
nop
MOVLW B'10111000' ;küldendő adat
MOVWF candata ;adat a W-be
BCF STATUS,C
MOVLW B'00000111' ;7 ciklus beállítása
MOVWF TIMER4
loop5
MOVF candata,W
MOVWF PORTB ;W a kimenetre
nop
nop
RRF candata,F ;adat eltolása
DECFSZ TIMER4,F ;ciklusszámláló csökkentés
GOTO loop5
MOVF candata,W
MOVWF PORTB ; utolsó bit
nop
nop
CALL DELAY_ROUTINE
GOTO EFFECT_1
(Bocs, a tabokat kiszedte)
Üdv: Jácint
0
Szerintem csak ciklusokkal fog menni, az időt meg nopokkal kell kiegészíteni.
kb egy pointeres adatbeolvasás az akkuba, utána shiftelés, a C től függő portláb átírás, az ugró utasításnál kompenzáció mert nem egyforma hosszú ha ugrik vagy ha nem. Ha erre nincs idő ( szerintem nem lesz), és szabad a teljes port, akkor a táblából kiolvasott adat kiküldése a portra, késleltetés, az akku shiftelése, újra kiküldés... A 8. után űj érték beolvasás, és kezdődhet elölről. (ekkor a port egyik lába lesz a kimenet, a többi csak járulékos veszteség.
Esetleg a soros port szinkron master módját nézd meg, lehet elég csak azt beállítani, és az adó regiszterbe az adatokat bepumpálni. ( ami esetleg kérdéses lehet, a byte határokon hogyan viselkedik a PIC. ( egyik modernebb PIC-nél a byte határon egy kissé mindíg elcsúszott az idő. bár ott nem a soros portot, hanem mintha a SPI-t használtam volna.)
0
Szia!
Az nekem is eszembe jutott, hogy beírom a PORTB-t, és shiftelem, elviselhető lenne a veszteség. Viszont a 16F676-nál csak 6 bites egy PORT, ott nem tudom, hogy viselkedne a 8 bites shiftelés? Mert a dokuban azt írja, a 6-7 bit olvasva nulla.
Próbáltam egy olyat, hogy
BTFSS adat,0
BCF PORTA,0
BTFSC adat,0
BSF PORTA,0
BTFSS adat,1
BCF PORTA,0
BTFSC adat,1
BSF PORTA,0
De így csúszik az egyes és nulla váltás.
Viszont lehet, egy XORWF PORTA-val lehetne bitet váltani, és a W-t shiftelni. Na, ezen majd reggel tökölök, csak mindig akkor jönnek az ötletek, ha kérdez az ember.
Üdv: Jácint
0