Üdv.

CAT5 FTP merevérpáras árnyékolt. A toldásoknál az árnyékoló huzalt toldjuk, az alufóliát kivágjuk. A tápot is ezen visszük 24VDC, a panelen az 5V-ot egy LT1676 készíti. Ez még 8V-ból is képes 5-öt készíteni. A kialakítás csillagpontos, a kötések egy a telefontechnikában (régebben) használatos telefonos rendezőben vannak, így a gerinc "sorosítva" van, a tápot meg mindenki a csillagpontból kapja.

Imi.

A Texas Instruments ISO1050 szigetelt transciever-ét szeretném kipróbálni a közeljövőben, ami galvanikus elválasztást biztosít a kommunikáló egységek között. Ilyennel találkoztál már?

Üdv.

Még nem, de ami galvanikusan leválasztott, az csak jó lehet. Ebben az esetben 3 vezeték kell a kommunikációhoz:

- CAN_L
- CAN_H
- CAN_GND (ez a "terepi" oldali "GND2")

Arra vigyázz, hogy ugye kell egy galvanikus DC/DC konverter is, amelyek közül sajnos nem mindegyik stabilizált kimenetű, meg kell fogni valami low-drop stab. kockával! Nálam egy TRACO TSM 0505S volt a DC/DC konverter, és egy L4941BDT-vel fogtam meg.

Imi.

Én a CAN BUS oldalon ugyanúgy közös tápegységben gondolkodom, mint ahogy te is használod. Csak a "digitális" oldal nem erről menne, hanem készülékenként külön-külön (és a többitől független) tápegység lesz, amire egyébként is szükség van a készülék többi részének működtetéséhez. DC-DC konverter nem lesz, 220-ból, trafóval megy mindegyik tápegység.

Valahol majd rendszerszinten egy pontban összejönnek a földek...

Sziasztok!
Én jelenleg is folyamatosan CAN busszal dolgozom, egy eléggé nagy vezérléstechnikai projektben arra fejlesztek mérő-, kijelző- és vezérlő modulokat, csak a maximális elégedettség hangján tudok beszélni róla. Amit Jym leírt, az minden pontosan úgy van, amint azt leírta. Én PIC18F4680 MCU-kat használok 20 MHz-es kvarccal minden modulban, normál, kicsit jobb minőségű UTP patch kábel gerinccel (a hajlékonysága miatt könnyebben szerelhető). RJ-45 8/8 csatlakozókat használok, szabványos bekötéssel, a 12VDC táp is ezen megy a modulokhoz, a gerinc van a moduloknál megszakítva, itt lehet a lezárót (120ohm) is rátenni. PCA82C251 CAN transceivert használok én is, rendkívül strapabíró és megbízható, kipróbáltan működik -25 és +90 C fok között. A sw-ről: CCS C-ben programozom a driver könyvtárban van 18-as MCU-hoz kétféle ragyogóan használható driver is a nagyobbikkal a CANOpen is megvalósítható, bár én nem használom ezt a konfigurációt, nekem a 29 bit cím és 8 byte adat egyenlőre bőven elegendő. 90 m távolságban a fentiekben vázolt modulokkal 3-4 msec válaszidőket mérek folyamatosan valós adatáramlás közben, úgy, hogy jelenleg 9 db modul van ráakasztva a gerincre ezen a hosszon.
Elsőre ennyi jutott az eszembe
Üdv: Jossz

Hellosztok. Egy kis problémám akadt az uart kommunikációval vettem egy mcp2200 -őt megépítettem a demoboard másolatát a max232 chip et lehagyva. az usb gond nélkül működik, a soros kapcsolat is jó (pickit2 ővel teszteltem oda vissza), megírtam a pic16f627a ra a programot az adatlap szerint (adatot szeretnék küldeni picről) pickit2-ő logikai analizátora szerint van is adat (pontosabban volt, mert manapság kifagy az analizátor valamiért). De amikor összekötöm akár a pickit2 -ővel akár az mcp2200 -ával sehol sincsen jelem hogy történne valami is... a programot úgy írtam meg hogy minden elküldött bájt után villan 1et egy LED, na most ez villog folyamatosan. sok mindenhol utánanéztem cserélgettem a Tx Rx lábakat is hátha elnéztem valamit, minden GND-t összekötöttem de sehol semmi nem értem. van valakinek valami elképzelése hogy mi lehet a probléma?
(300 baud on próbálom mert csak 4MHz em van én a jelszintre gyanakszom vagy a programra ... jah és ASM ben programozom a PIC em)

Az MCP2200-nél az volt a tapasztalatom, hogy nem szabad engedélyezni, hogy villantson a led-del (a LED toggle ezzel szemben kifogástalan működést adott). Ha 5V-os tápfeszültségről járatod, akkor jelszinttel nem lesz probléma. Ha az RX/TX lábát összekötöd, akkor Hyperterminállal is tesztelheted, hogy visszajön-e az USB virtuális porton kiküldött karakter.

A PIC16-ot is tesztelheted a PICkit2 UART tool-jával (max 38400 bit/s-ig, ennyit tud fogadni a PICkit2). A kötés meg egyértelmű: a PIC16 TX a kimenet, ez menjen az MCP2200 RX bemenetére és viszont. Ezen kívül még a földjük is legyen összekötve...

a MCP2200 nél nálam mind1 hogy villog e vagy nem a LED visszajött a jel így is úgy is. a PICkit2-ő UART tool ja sem reagál a kommunkiációra pedig ott tökkéletes a jelillesztés amint hazaérek bemásolom nektek a programot hátha ott vétettem hibát...

íme a kódom van benne pár fölös dolog és javarészt pédaprogramból való...

Üdv mindenkinek!

Egy 18F2550 és egy 18F2431 között szeretnék kommunikálni spi-n keresztül. A 2550 a master, bizonyos időközönként küld egy bájtot a másiknak, ami működik is. Ezután várnék vissza egy bájtot, de ha beállítom a masterben az spi megszakítást, akkor a saját maga által küldött adat is megszakítást okoz. Ezt hogy lehet elkerülni? A porgramot C18-ban írom.

Közben rájöttem hogy a PIR1 regiszter SSPIF bitjét írás esetén is nekem kell törölnöm

Nagyobb mennyiségű adatátvitelnél (pl. ~30 kbyte szöveg vágolapra másolásánál és a HyperTerminal Szerkesztés/Beillesztés a távoli állomásra menüpontjára kattintva) jött elő a probléma. Meg az "éles" alkalmazásnál...

Azt mondja az adatlap, hogy:

Te meg ezt írod:
MOVLW B'11000010'
MOVWF TRISB ;RB7 & RB6 are inputs.

Lehet, hogy rosszul gondolom, de a "have to set" szerintem azt jelenti, hogy a TRISB,2 bitet is 1-be kell állítani, még ha logikátlannak is tűnik.

Utóirat: Hogy ne legyen annyira egyszerű az élet, van egy Errata is ezzel kapcsolatban, ami szerint nem egészen úgy működik az áramkör, mint ahogy az adatlap írja. Kár, hogy nem értem...

A cimét letárolhatod a belső EEPROM-ba. Programozáskor beállatod. Később sorosan is leküldheted egy portján. Ha van a Picben I2C akkor azt ajánlanám. Szintén megadhatod EEPOPM-ban a címét amit induláskor kiolvas onnan.

Köszönöm szépen a segítséget, most már minden működik... de 1 hiba fölött elsiklottunk...
51. sortól az 56. ig

a LEDING az rutin nak indult csak lefelejtettem a RETLW 0 parancsot... így el sem jutott addig hogy egyáltalán jelet küldjön köszönöm a segítséget mindenkinek

Megakadtam az RS485 kommunikációval !
Egy PIC csak ad LTC485 -ön keresztül.
Ezt tesztelem PC-n RS232-RS485 átalakítón keresztül.
Ilyet eddig sokat csináltam és minden gond nélkül működött.

A másik PIC csak venné az előbbi bájtjait, szintén LTC485-ön és LCD- kiírná, de nem veszi.

Viszont, a HEXIN converter DATA+ és DATA- hozzákötöm, akkor tökéletes.
A PC-n még tesztelő program sem fut, csak a konverter be van dugva a soros portra.

Az egyértelműség miatt, mellékelek egy skiccet.

Ha valakinek van ötlete, megköszönném.

(Záróellenálásokkal és felhúzókkal már próbálkoztam.)

Üdv MGy

Üdv!

Úgy érted, hogy ha a HEXIN konvertert bedugod a PC-be, akkor a PIC1 már jól vesz ? Ha igen, akkor vagy valami lezáró nem jó, vagy felhúzó nem jó.

Imi.

Kösz ! Nyertél !
Egy rossz rajz szerint fordítva volt a felhúzó és lehúzó ellenállás bekötve.
Átkötöttem a B és +5 valamint az A és Gnd közzé és minden működik.
Eddig mindig valamilyen konvertert használtam és az én áramköreimről lemaradhattak a felhúzó ellenállások.

Üdv MGy

Sziasztok!

Megakadtam 2 PIC 485-ös kommunikációjában.

Az egyik 16F690 a másik 16F877. A 877 a master a 690 slave. Egyenlőre csak egy adatot szeretnék küldeni a masternek, de nem sikerül. Mikropascalban a példaprogramot másoltam ki, módosítottam. A master interrupt részébe beleírtam, hogy mikor vesz valamit, egy kis időre gyújtson ki egy ledet. A led fel is villan egy pillanatra, de a dat[4] byte mindig 0 értéket ad vissza, ami azt jelenti, hogy nem vett semmit. SN75176 használok az illesztéshez. A busz eleje vége 120R -mal lezárva. A 690 HS oszcillátort használ, a 877 külső 20 MHz kvarcot. lehet hogy ez a baj?

Köszi! T.

Üdv!

A 10k fel-le húzók is megvannak ?

A 690 HS forrása is kvarc nem ? Biztosan egyforma bps-en megy a két eszköz ? Debugger-ed van ? Belelátsz a kontrollerbe működés közbe ?

Imi.

Szia!
Bocsi, nem kértem értesítést, és csak most látom a választ. Szóval a 16f877- et kicserélte 16F4550, ezzel nincs semmi gond, küld, fogad. A 16F690-nel van bajom. Ha lehet a belső oscillátort használnám helyhiány miatt. A 16F690 most küld, de a fogadással azóta is bajom van. A mikropascal-ban lévő kapcsolás alapján kötöttem be a SN75176-ot, azóta rájöttem, hogy az nem jó. Az 56 ohmokat levettem a buszról és a vel lehúzó ellenállásokat is. A 4550-en sincs, az működik rendesen. Hová milyen fel-, lehúzókat rakjak, mert ahány rajzot néztem annyi változat volt.

Köszi! T.

Hol volt 56 ohm? elég durva lezárás lenne.
A belső oszcillátorok lehetnek pontatlanok, emiatt a baudrate jelentősen elmászhat, próbáld meg kvarccal jó lesz-e

Szia!

A MikroPascal helpjében szereplő kapcsolást építettem meg, mellékelem. Csak nekem az LTC485 helyett SN75176 van. A MikroPascal-ban van egy USART terminál nevezetű tools, ezzel monitorozom az adatokat a buszon. Az ábrán látható a fel és lehúzó ellenállások 4,7K. Ezeket már lecseréltem 10K-ra. A helyzet, hogy nem jó adatok jöttek a buszon addig, amíg a ezeket el nem távolítottam. Szóval most nincs egyetlen ellenállás sem a körben, csak a busz elején és végén a 120ohm. Ha 16F690 ad, azt a másik pic jól veszi, bár azon van külső oscillátor. A másik irányba nem működik ha a 4550 -es ad. A 16F690 nem fogadja az adatokat. Usart terminálon jól látszanak az adatok mindkét esetben. Megpróbálom külső oscival.

A melléklet lemaradt

Szia, kipróbáltam kvarccal, a helyzet változatlan. Amire menet közben rájöttem. A main részben egy ledet villogtatok. Ez működik is, amíg a PIE1.RCIE := 0. Ahogy a megszakítást bekapcsolom a PIC "lefagy". Azaz a main programrész nem villogtatja a ledet. Mintha az interrupt részben megállna az egész. Ha az interrupt részbe rakom a led kigyújtását, a led kigyullad.

procedure interrupt();
begin
RS485Slave_Receive(dat);
PORTC.1:=1;
end;

Ha a main részbe rakok egy PORTC.1:=0, akkor is égve marad a led, mintha ide nem is kerülne vissza a vezérlés. Lehet hogy a led kigyújtás is interruptot okoz?

Próbáltam hogy az interrupt részben letiltom a megszakítást, de hiába:

procedure interrupt();
begin
PIE1.RCIE :=0;

RS485Slave_Receive(dat);
PORTC.1:=1;
PIE1.RCIE :=1;
end;

Valami ötletetek van?

Hali!
Ami a megszakítást okozza, jelzőbit, azt kellene szoftveresen visszabillenteni, mert különben megszakítási rutinból vissza sem tér, megint megszakítást végez a PIC

Az RS485Slave_receive függvény kiolvassa az RCREG regisztert? Megszakítási rutin alatt hardverből tiltva vannak a megszakítások, így az azokat engedélyező biteket ott nem ajánlatos piszkálni.

Üdv!

Ilyenre gondoltam:

Imi.

Üdv!

A 10k helyett jó a 4.7k. Viszont a soros 56 Ohm-ok nem tudom, hogy hogyan viselkednek, amit eddig láttam, azok párhuzamos 100 vagy 120 Ohm-ok voltak a kábel 2 fizikai végén. Jó még az RC tag is (100 Ohm - 10 nF), így DC szempontból nem terheli a buszt, a lezárás viszont jól működik, mert a 10 nF átengedi az éleket.

Imi.

Üdv!

Az van, amit foxi63 is írt: bejön egy IT, a hozzá tartozó flag-et nem törlöd, ezért az IT-ből kilépve, azonnal újból IT-t okoz, és ez megy a végtelenségig. Tehát a főprogramodra nem ugrik rá a vezérlés, mert szerencsétlen állandóan IT-t hajt végre.

Imi.