Sziasztok!

Ha a megszakítási rész végére beírom: PIR1.RCREG:=0; akkor kilép az IT-ból. Az érdekes, hogy a 18F4550-nel semmi ilyen probléma nem volt, az szépen működik, küld, fogad. A 16F690 a gyenge láncszem.
A RS485Slave_Receive(dat) meghívása után a dat tömbbe kerülnek az adatok, vagyis kellene hogy kerüljenek. A dat egy 7 elemű byte tipusú tömb. A 690-es esetében ebbe nem kerül semmi, azaz minden byte nulla. A RS485Slave_Receive a mikropascalban lévő 485 lib-nek a része. Lehet, hogy ez nem kezeli jól a 690-et?
Most ott járok, hogy a 4550 TX-ét rákötöttem a 690 RX-ére. A 4550 csak küld, a 690 csak fogad. A helyzet tök ugyanaz. Ja és most már 4MHz-es külső oszcillátorral működik. Teljes a tanácstalanság. Van valami ötletetek?

Üdv!

Nem ismerem a 16-os sorozatot, de a pdf alapján a PIR1 regiszterben nincs RCREG nevű bit. RCIF nevű bit van, amely automatikusan törlődik, ha olvasod az RCREG-et.

Tehát amit előzőleg írtunk, akkor az nem igaz, mert ha olvasod az RCREG-et, akkor az IT flag automatikusan törlődik.

Namost te az RCREG nevű a bejövő adatot tartalmazó regisztert kiolvasod az IT-ből ???

A másik, hogy az IE (interrupt enable) bitekkel IT-n belül ne csinálj semmit, azokat ott nem kell sem
engedélyezni, sem tiltani.

Nem ismerem a mikropascal-os lib-et, de ez nem olyan bonyolult, hogy ne tudd magad megírni, ehhez nem kell lib.

Másold ide be a teljes 16F690-es programodat.

Imi.

Szia, előröl kezdem libek nélkül, szerintem azokban lehet a hiba. Úgyhogy elkezdem megírni ezek nélkül. Most egy hét szabin leszek, de utána jelentkezek hogy hol tartok vele. Köszi!

Sziasztok!

Na, újra írtam libek nélkül, a doksi szerint, és láss csodát működik az adatfogadás. Annyira, hogy a külső oscit le is szedtem, belsővel megy most. A küldéssel van bajom, nem megy ki a buszra egyetlen adat sem.
Íme a kód:


A buffer egy byte típusú tömb: cím, adathossz, adat, crc -ezekkel van feltöltve.
Gondolom így kell sorban egymás után kiküldeni a bájtokat, de egy sem megy ki.

Megy ez csak a delay_ms(100) -at ki kell venni.
Így is csak 4 bájtot tudok kiküldeni a 5. utáni
while (TRMT_bit=0) or (TXIF_bit=0) do; -nál megáll.

Van ennek korlátja, hogy hány byte -ot lehet küldeni?

Üdv!

Tudtommal nincs, meg kell várni, míg szabad lesz az adó, aztán mehet.

A buffer-t hol töltöd fel adatokkal ? Mert azt nem látom. Beleteszed a címet, bytecountot, és a végére a CRC-t, de hol vannak az adatok ?

Miért kellett először várni 100 ms-et ?

Mi az a "TXREG := 150" ? Mi az a 150 ?

Szerintem elég a TXIF-et 0-ra figyelni, nem kell a TRMT.

Van ebben ADC ? Ha igen, akkor az nem közös az UART-al ? Ha közös, akkor le van tiltva ?

PORTB.6:=1 mit csinál ? Mert a TX az RB7-en, az RX pedig az RB5-ön van.

Imi.

Szia!

Startbyte=150;
Stopbyte=169;
Megint a MikroPascal-ra kell hivatkoznom, ott így volt a példaprogramban.

A kód amit küldtem az egy eljárás, Send458Data(bycount:byte);
Az adatokat a főprogramban adom meg buffer[0..ByteCount-1]. Betolom az adatokat a buffer-be, mondjuk 2db-ot [0..1], aztán Send45Data(2). A programrész pedig elküldi.
Azt vettem észre, ha a baudrate -et felemelem 9600-ról 19200-ra akkor minden adat átmegy. Nem tudom hol az összefüggés, szerintem 9600-on is bármennyi adatot lehetne küldeni nem?
A PORTB.6-on van a 75176 RE - DE lába, azt állítom át adásra.

Visszatérve a rajzra amit küldtél. Az A-B lábak közé párhuzamosan a 10nF-100 ohm a 120 ohm lezáró helyett raktad be, vagy a stabilitást szolgálja? Egyenlőre ezt még nem raktam be. Viszont már megy a kommunikáció. Ami nem tetszik, hogy kb. 10-ből egyszer nem megy át az adat. Persze a 4550-esben még a mikropascalos lib van, azt is lecserélem. Ja, a mikropascalos lib nem jól számolja a crc-t. Ez volt az alapvető gondom az elején, ezért nem fogadta a 690-es.

Üdv!

9600-on is el kellene mennie az adatoknak, és meg is kellene érkezniük. Egyforma bps-en vannak ? Belső OSC-ról megy vagy kvarc-ról ?

A 120 Ohm helyett van. A lényeg az, hogy a jelváltozást a 10nF átengedi, ebből a szempontból olyan, mint ha ott sem lenne, ugyanakkor DC szempontból szakadás. Tehát működik a lezárás jól, de a 75176 nem fogyaszt sokat. Ha a kondit elhagyod, akkor is jó lesz a lezárás, de a 75176 sokat fog fogyasztani. 120 Ohm helyett 100 Ohm is jó. Van ahol 100 Ohm-ot írnak, van ahol 120-at. A lényeg, hogy a használt kábel hullámimpedanciájával megegyező ellenállással kell lezárni, ez UTP-nél 100 Ohm +/- 15% körül van.

Imi.

Sziasztok!

Szeretnék megvalósítani több, akár 20 pic közötti kommunikációt.
Arra gondoltam, hogy az egyes egységek, egyedi címmel rendelkeznének. Ezt minden egyes egységben a pic tárolná. Lenne egy master.
Az al egységek fele csak kimenetként működne(kijelzők), a másik fele pedig bemenetként. (érzékelők)
Azt találtam ki, hogy rs485-ön beszélgetnének egymással, mivel nagy távolságra lesznek egymástól.
75176b-vel át is tudom alakítani, a pic rc7/RX/dt és rc6/TX/ck lábain megjelenő jeleket.

Az lenne a kérdésem, hogy a vonalon, lehet-e olyan kommunikációt létrehozni, ami azt tenné lehetővé,
hogy a master vezérelné a kijelzőket az érzékelőktől kapott jelek alapján?
Vagyis, hogy csak akkor kommunikáljon, ha muszály, és csak az az egység csinálja amelyiknek szól.
Egy amolyan I2C féleséget tudok így elképzelni. Sokat olvastam a témában, de sajnos még nagy gyakorlatom nincs ezzel kapcsolatban.
Bővebben: Link
Ha nem igazán a megfelelő topikot találtam a kérdésemnek. Ezért elnézést kérek.

Köszi mindenkinek!

Ez a téma kell neked szerintem: Link Itt volt már szó ilyesmiről, ha jól emlékszem.

Kitalálsz egy protokollt, vagy keresel szabványost (pl modbus felcimzed az egységet, küldesz parancskódot, adatot, ha kell vársz a válaszra.
én pl ilyet használok (minden ascii-ban közlekedik)
:, csomaghossz, célcím, parancs, adatok, chsum.
a ":" bevezető csomag kezdet jelölő, máshol nem fordulhat elő, minden szolga hallgat, csak a cimzett válaszol, nyugtáz, ha adott időn belül nincs válasz, akkor baj van... Nálam a "csak kimeneti egységek" is válaszolnak,nyugtázzák a hibamentes átvitelt

Üdv!

Modbus RTU vagy modbus ASCII kell neked.

Vagy CAN.

Imi.

Sziasztok!

Ket PIC kozott szeretnek komunikalni kb 100 meterre egymastol. Van valakinek valami tapasztalata ezzel kapcsolatban? En soros komunikaciora gondoltam ,es jo lenne ha mukodne 4 szalas telefon kabelen, mert azt eleg olcso beszerezni. Van esetleg erre valami otletetek?

Koszonom.

Én inkább UTP kábelt használnék és RS485 vagy CAN-t.

Az atviteli sebesseg nem fontos, az egyik pic csak meri a homersekletet es azt kb percenkent atkuldi a masiknak, probalkoztam radio ado-vevovel, de nem igazan mukodik csak belepakoltam a penzt es sehol semmi, nem szertnek sokat kolteni ra es azert gondoltam a 4 eres telefon kabelre, es egyszeru az UART-hasznalat MikroC-ben.

A 100m nem kevés. Sima UART-on majdnem biztos hogy nem fog menni. Ilyen távolságra már kell a 485.
A rádióssal mi volt a baj? Nem lenne érdemes egy kis energiát még beleölni ha már a pénzt beleölted?

MikroC-t hasznalok pic programozasra, Mplabot is hasznaltam valamikor, de mar elfelejtettem azt is amit tudtam benne. MikcroC-ben van egy fugveny amit lefet hasznalni manchaster kodolasra, de az nekem nem mukodott. UART-on kuldtem ki az adatokat a radio adonak, es a vevot a masik pic UART bemenetere kotottem, egyszer el is indult szepen mukodott, eleg nagy tavolsagra igaz nem ment 100 meterre de kb 50 re talan. A tesztelenel csak egy karaktert kultem at. Mikor valtozot probalok atkuldeni nem mukodik, ha siman osszekotom huzalal az rx-et a tx-el mukodik de radion mar egyaltalan , masik radios modulokat is bevasaroltam napokat dolgoztam rajta de nem megy, kiabrandultam az egeszbol es azert szeretnem kabelen megvalositani az egeszet. Neten olvastam ha alacsony alacsony baud rate-t hasznalok akkor mukodik tobb szaz meterre is: Bővebben: Link . Nekem ugyis megfelel ha azt a valtozot egy percen at kuldozgeti, mert nem fontos a sebesseg. Azt nem tudom hogy ha mukodik ez az egesz mivelhogy a 4 szalas telefon kabel nem csavart, sose dolgoztam meg ilyesmivel

Szerintem az lehet a rádiósnál a probléma, hogy nem manchester kódolást használtál. A vevő csak jelszintváltozást tud felismerni, nem tud jelszintet önmagában, ezért kell hozzá a manchester kódolás, mert annál a jelszintváltozás hordozza az információt. Sőt, az is kellhet, hogy a valós adatod előtt pl. 0xAA-t vigyél át, hogy rá tudjon szinkronizálni a vevő az adóra.

Kábellel végülis ha elég lassan csinálod, akkor szerintem menni fog. Lehet kicsit zavarérzékeny lesz, de átküldheted a mérés eredményét többször is (pl. percenként küldesz új értéket, de amikor küldesz, akkor egymás után átküldöd tízszer ugyanazt), és akkor ami adatból a legtöbbet sikerült fogadni egy ciklusban, valószínűleg az lesz a jó érték. Vagy adhatsz hozzá crc ellenőrzést is.

Koszonom a valaszokat. Holnap megprobalok kabelt vasarolni es max232 ic-ket es remelem mukodni fog az egesz.

Nekem (Aurel modulokkal) egy 0xAA kevés is volt, néha még a 2 is, így 3 0xAA-t kellett kiküldeni az érdemi adás előtt (ha az idő nem kritikus, akár 5 is lehet), bár ezt az idevágó topicban már kiveséztük. Ami biztos hogy el lehet vele szórakozni akár heteket is. A "kiábrándultam belőle" nem jó hozzáállás.
Lehet hogy a telefondróton is elpöszörögnek az adatok, próba cseresznye, bár bevallom én meg sem próbálnám.
Ha már úgyis ott van a 4 ér, akkor van létjogosultsága a 485-nek. Gyorsabb (ami neked most még nem szempont, bár később az lesz), jelentősen megbízhatóbb és költsége sem számottevő (megkockáztatom hogy olcsóbb mint a MAX232).

Egyébként simán. Amikor máskor vettem, az SN75176 olcsóbb volt, mint a MAX232 és utóbbi még igényel néhány kondenzátort is, míg előbbinek elég egy tápszűrő.

Megvettem a kabelt es a maxokat es kiprobaltam, mukodik, igaz meg a kabel fol van tekerve nincs kihuzva de 2000 adatbol egy sem volt hibas , 2400 as baud rate-t hasznalok.

Sziasztok!
Két mikroprocesszor közötti kommunikációt szeretnék megvalósítani, de lehetőség szerint magán a tápvonalon, és ha lehet, akkor multimasteres megoldással.
Azaz össz-vissz két vezeték kelljen az áramkörhöz.
CAN bus nagyon tetszik, de a tápvezeték megakadályozná a miniatűr kivitelezést az áramkörön.
Van valakinek tapasztalata ezen a téren?
Köszönöm előre is!

"PBUS" a varazsszo. Erre keressel ra. Lehetseges egy vonalon kommunikalni, de a tapot kulon kell vinni. Itt talalsz egy erdekes megoldast a tapon valo adatatvitelen.

3 vezeték esetén zavar lehetséges, nem megengedett.
Nem rossz a PBUS sem, de áramgenerátoros üzemmód nagyon lekorlátoz.

Mekkora sebességre van szükség?

Elhanyagolható. Nincs szükség nagy sebességre, sőt:
Percenként egy állapot elküldése elegendő.

Sziasztok, kis segítséget kérnék.
Most próbálkozom először RS232 kommunikációval 2 PIC között. Egy kéziműszer és egy detektor egységről van szó. Csatoltam a kéziműszer kapcsolását, a detektor kapcsolása hasonló, csak nyilván a TX/RX vonalak bekötése fordított (Tx az ellenoldal RX-hez és viszont) Szintillesztőnek MAX232-t használok, amint a rajzon is látható. A programokat CCS C-ben írtam
A gondom a következő: az adó oldalak szépen működnek, ez a szkópon is látszik és még PC-n SIOW programban is szépe és torzításmentesen jönnek a sztringek, de a másik PIC vevőoldalán már gondok vannak. Az RDA megszakítás érzékeli ugyan, ha beérkezik az első karakter, be is olvassa a megadott számú karaktert egy sztrig tömbbe, de amikor kiíratom a sztringet, mindenféle értelmetlen karaktersorozatot ír ki az LCD-re. Tehát úgy tűnik, hogy a bejövő jelek a MAX232 PIC felőli oldalán már torzultan lépnek ki. Próbálkoztam mindenféle trükkel szoftver oldalon, lassítottam az átvitelt 9600 baudról egészen 300-ig, próbáltam különféle beolvasási módokat, megszakítással és anélkül, de semmi sem segített. Ezért is gyanakszom hardware gondra.
Szerintetek okozhatja ezt, hogy a MAX232-n nem 1 uF, vagy nagyobb kondikat használok, hanem csak 100 nF-osakat? Vagy van valami ötletetek, mitől lehet ez a jelenség? Előre is megköszönöm, ha valaki mondana valami megoldást...

A MAX232-nek vannak különböző típusai: van, amelyikhez 1 uF, van amelyikhez 100 nF kell, a megfelelőt használd ! A vétel problémái szerintem inkább szoftveres gond lehet ( ha nincs fizikai sérülésed! ), pl. PK2-vel tudsz soros átvitelt dekódolni a hibakereséshez vagy egy másik max232-vel visszajátszani és egy terminál programmal elemezni ( CCS-t nem használok )!
HP41C kolléga leírt már sok hasznos dolgot a soros port programozásról a fórumban, keress rá!
szerk.: Ha szkóppal rá tudsz nézni, akkor látod, hogy jó-e a jel ( így az 1 µF-os problémát is ki lehet zárni a mérés segítségével! ) !

Nezd meg PC-n valami terminal progival. A CCS-C is telepit ilyet.