Két, illetve több Pic-et szeretnék összekötni azzal a céllal, hogy ezek egymás között kommunikáljanak (egy alapbeállítás után egymásnak számokat küldenek és a számokkal különböző műveleteket végezne, majd azokat továbbküldik egy újabb Pic-nek, vagy egy PC-nek soros porton, vagy USB-n amely a keletkezett adatokat feldolgozza.

Nagyon sok információm hiányzik a probléma megoldásához.

Mi a véleményetek a megoldásról.
Képes a Pic I/O porton másik Pic-nek az I/O portjára adatokat küldeni?
Gondolom mondjuk 8 I/O porton egy 8 bites számot át lehet küldeni egy másik PIC bemenetére?

Lehet, hogy nem jól közelítem meg a problémát mert kevés a tudásom.

A témában bármilyen hozzászólás érdekelne.

Kösz!

Persze lehetséges. Én még nem küldtem adatokat ugyan át két PIC között. A legegyszerűbb a párhuzamos adatátvitel, de ehhez 8 bites szám átvitelénél 8 port kell. Aztán ott vannak a soros átviteli szabványos portok I2C, SPI,USART. Nem emlékszem hogy láttam volna valaha két PIC közötti kommunikációra példát. Ha találok valamit akkor jelentkezem.

Ha egyszerűen akarod megoldani akkor mindenféle képpen egy RS232höz hasonló USART kommunikációt csinálnék. Ez bekajál két I/O portot...
Ha meg soksok PIC-et akarsz összekötni és jobban preferálod a sínszerű elrendezést akkor a barátod az I²C busz...

Hello. Bocs hogy beleszólok a témádba,de nem akartam ujat nyitni. Olyan kellene nekem hogy egy PIC 16F84-el betűket kiiratni egy 16 szegmenses kijelzővel. Hogy lehet azt megoldani? Vmi 74164-es dekódert vagymit kell hozzá használni. Hogy lehet ezt megvalósitani. A programot meg tudom hozzá irni, nekem csak a PIC köré irt áramkör kellene. Köszi

Jól gondolom?:
Ha a soros megoldást választom akkor az rx tx lábakon megy az adat,
Ha I2C buszt választok akkor az I2C vezérel és az I/O portokon mennek az adatok.

A soros kommunikációt inkább meghagynám a hardver és a PC közti adatátvitelre.

Bbatka által említett párhuzamos átvitelnél lehet egyszerre 8 bitnél többet is mozgatni? Mondjuk 2 port egyszerre?

Szóval. A nagyobb PIC-ecnek (pl. 16F877) van hardveres I2C buszuk. De egy pár soros programmal bármelyik I/O ból lehet I2C buszt csinálni.
Az I2C nél tökmindegy mekkora adatot viszel át. És majdnem hogy végtelen eszközt tudsz csatlakozni. Pl I2C busz alapon működik a Dallas Semi hmérő chipje. 1 szál drót van (+GND) és arra az egy szál drótra fel tudsz fűzni alap esetben 65535 darab hőmérő IC-t. Szóval 65535 hőmérő végpontos van, és ez a PIC-ből egyetlen egy I/O portot foglal el! Ez a lényegeaz i2c-nek. Hogy mennyi adatot viszel át, az rád van bízva. Persze egyszerre csak 1 bájtot (8bitet) tudsz átvinni. de korlátlan byte mennyiséget...
Amit bbatka említett, az is egy jó megoldás, csak sok i/o-t kajál meg a pic értékes lábaiból

Üdv. Topi.

Mint már a többiek emlitették többiek is emlitették több lehetőségedis van.
Legfőbb kérdés, hogy mennyi adatot illetve milyen gyorsan akarod küldözgetni?
Mit szeretnél még az áramkörhöz kapcsolni?
Ha több eszközt is akarsz egy buszra felfűzni és a legkevesebb I/O lábat akarsz elhasználni akkor I2C vagy SPI busz a nyerő megoldás.
Ezzel rakatív gyorsan tudsz adatokat küldeni. Általában HW is implementálva van szinte minden picben.
Az I2C-n még multimaster környezetet is kialakíthatsz ahol egy buszt több master is használhat, de természetesen nem egy időben.
Másik megoldás a párhuzamos adatátvitel, de ne feledd, hogy kell a 8 adatvezeték + a vezérlő jelek számára is egy pár I/O el fog menni.
Ide akár Lcd-t, párhuzamos SRAM-t, meg egy csomó mindent fel lehet aggatni.
De szerintem a árhuzamos adatátvitelhez kéne egy master ami az egész kommunikációt felügyeli. Címzi a perifériákat, adatot küld és fogad.
De a master-hez csatlakozhatna akár a pc is usb vagy soros porton.

Az i2c télleg a legjobb megoldás. De emellett ott van még a soros átvitel is, és egy picnek nem csak egy soros portja van, vagyis hardveres lehet hogy télleg egy van, de szoftveres úton is lehet soros portot létrehozni. Hogy neked melyik a jobb, az attól függ mire akarod használni.
Ha többpontos hőmérőt akarsz, akkor i2c. Ha picek közti komm a lényeg, akkor szinte mindegy, bár a szoftveres com porttól a hardveres i2c gyorsabb.

Tehát, ha I2C buszon összekötök mondjuk 5 db pic-et és úgy alakítom ki a nyákot, hogy minden picnek 1 portját (8 bit) felhasználva csinálok egy 8 bites buszt (úgy képzelem mindenki mindenkivel össze van kötve), akkor az I2C busszal meg lehet szólítani bármelyik pic-et (egyszerre csak egyet), hogy küldjön 8x 1 bitet az adatbuszra és meg tudom mondani, hogy az adatokat melyik pic fogadja?

Elvileg valahogy így gondolom:

Hát azt nem tudod megmondani, hogy kinek küldöd. Csak azt tudod csinálni hogy az adat elé teszel egy címző bytot / kódsorozatot. És minden egyes buszra felfűzött cucc megnézi, hogy neki szól?? nem jó akkor nem csinál semmit.
Pl a dallasos cucc is úgy működik, hogy a pic végigszólongatja az összeset, mivel nincs is más lehetősége, hisz 1 dróton van mindenki...

Úgy néz ki magam is rájöttem, hogy ez hülyeség mert pont az a lényeg, hogy az egész két vezetéken megy és az adatok az SDA vezetéken mennek.

Kicsit átgondolom, hogyan tudnám jobban érthetővé tenni a problémámat.

Szerintem használj I2C buszt.
Lehetőleg HW megvalósítással mert azzal nagyon egyszerű.
Így minimum 128 picet vagy egyéb 7bites címmel rendelkező eszközt tudsz felrakni, de ha a címzést kibővíted 10 bitesre, akkor 1024 db 10 bittel rendelkező eszköz is címezhető.
Szinte majdnem az összes I2C eszköz támogatja a 400KHz buszfrekvenciát. Némelyik még az 1-2 sőt még a több MHz-t is.

Én erre régebben a következő megoldást láttam:

Start(10101010)Cím(00000011)Adat(110101100)

Ha start jel érkezik a buszon akkor a PIC figyeli a következő 8 bitet. ha az ő címét tartalmazza akkor a következő 8 bitre is figyel, ellenkező esetben figyelmen kívül hagyja... így akár 16 vagy 32 bites címzést is használhatsz illetve nem csak 1 bájtot küldhetsz egyszerre...

Ha szerencsém van akkor még megvan a kód...

Ez azt jelenti, hogy a Startjel utáni 8 bites címmel megadhatom, hogy melyik Pic-nek küldöm az adatokat? A Startjel után ezekszerint minden Pic sasol a következő 8 bitre.

A Pic-eknek egyébként van fejlesztés közben elérhető azonosítójuk, vagy nekem kell megadnom Pic-enként egyet-egyet?

Igen jól értetted! a Start jel után minden PIC figyeli a címet. ha nem az övé a cím akkor is figyelnie kell, hogy megjött e az adatbit, csak nem törődik vele... Azért kell mindig figyelnie az adatbitekre is mert ha esetleg az adat megeggyezik a start jellel akkor ugye a PIC elkezd várni a következő 8bitre... feleslegesen... és felborul a rendszer. Ezért fontos,h fixen rögzített legyen,h hány bites a címzés és hány bites az adat... de persze ezzel is lehet variálni.

Amúgy a PIC "hálózati" címet neked kell beállítanod. ha egy fix rendszerről van szó, ahol minden elemből csak 1 van és nem bővíthető, akkor a címeket fixen is rögzítheted a PICbe. de ha több azonos feladatú cucc kerül a sínre akkor célszerűbb DIP kapcsolókkal megadni a PIC kódját...

Ha csak pár db I2C eszközt akarsz használni (127), akkor elég neked a 8 bites cím és a pic csak akkor fogja a megszakítási rutint végrehajtani, ha az ő címe került ki a buszra és a többi pic figyelembe sem veszi a küldőt adatokat. Persze csak akkor, ha megszakításban csinálod.
Szerintem így egyszerűbb és nem kell figyelgetni a byte-okat.

7 bites a cím
amúgy valóban egyszerűbb... Az én módszeremet csakis akkor érdemes használni, ha nagyon sok elemet akarsz rákötni... Bár az én módszerem nem is igazán I2C-t sokkal inkább egy standard soros kommunikációt igényel

Mindenkinek köszönöm a segítséget. Sokkal közelebb kerültem a megoldáshoz. Most megpróbálok valamit összehozni. Közben biztos lesznek új problémák.

Üdv: JB

Otthon találtam pár hasznos doksit az I2Cről...
Este feldobom ide is...

Ha megtennéd, szerintem sokunknak hasznára válhat.

itt a talált anyag...

remélem segítettem...

Tapasztaltak véleményét várom arról, hogy PIC és PC közti kommunikáció kialakításában melyik az egyszerűbb és melyik a jobb megoldás - az USB vagy a Soros port?

Nekem őszinténszólva a Soros porti kommunikáció egy kissé bonyolultnak tűnik. Itt is kaptam segítséget, de nem igazán akar összejönni (PIC18f452)

Az is fontos szempont lenne, hogy a PC-n melyikre könnyebb egyszerű felhasználói programot írni, mondjuk Visual C++ vagy C# nyelven.

Érdekelne konkrét esettel kapcsolatos tapasztalat.

Előre is kösz a hozzászólásokat!

Sorosport. Sokkal egyszerűbb ! Ez tény. Mindkét oldalon. Ha már csak abból indulunk ki, hogy PC oldalon egy valamire való USB cuccnak van driver-je...

helósztok, lenne egy kérdésem: ugye vannak ezek a különböző hibaértékek a komunikáció során amik a kvarctól és a bps től függnek. ha pl ott van hogy +4% akkor ez gondolom mit jelent, időközönként hibásan veszi az adatot, de milyen időközönként? mi van ha pl 10 bájtos csomagokat küldök a pic usartjának és akkor az interruptol és veszi a 10bájtot, ilyenkor mi van? ugyanúgy hibázik, vagy csak a folyamatos átvitelnél van ez??
thx!

?? tudjátok az adalapokon van az usart résznél ilyen táblázat, kvarc bps hiba

valaki írta hogy a dallas hőmérők i2c-t használnak, ami csak egy vezetéken kommunikál...
na ez hülyeség.
i2c: 2 vezeték: órajel és adat (plussz táp és föld)
dalsemis cuccok jó nagy része pedig 1-wire kommunikációt használ, ami teljesen más mint az i2c.
Itt csak adatvezeték van, nincs szükség órajel vezetékre, és pl. elég sok eszköznek külön tápvezeték sem kell, csak adat+GND, mert parazita eszközként az adatbuszrólc csípnek le maguknak energiát.

Szerintem ott azt akarják mondani, hogy pl.: BRGH=1 és 3.6864MHz, 9600 Baud esetében a pic tényleg ennyivel küldi az adatot. De 4 MHz esetében 0.16%-al fog eltérni a 9600 Baudtól.
Én úgy tudom, hogy 10% maximális eltérés esetén még éppen, hogy mükődik a komunikáció.
Minden byte küldését Start byte-al kezd és szerintem ezzel szinkronizál a USART. (tőbb mint valószínű)
Szerintem 4% hiba az még símán elmegy.

remélem, mert én is így gondolkodtam, 20bájtos csomagokat fogok küldözgetni picnek pcből.

Üdv mindenkinek!

Arra szeretnék választ kapni, hogy soros komunikációnál az adatlapban megvan adva mindenféle érték. (BRGH, SPBRG és a proci órajel)
És van HIGH meg LOW mód.
HIGH és LOW módban mekkora hiba százalékkal megy a komunikáció?
Én kinéztem magamnak (pic18F452) BRGH=1, SPBRG=0, órajel=40MHz-t, ezzel 2500 Kbaud érhető el ami kb 2.5MHz. Vajon ilyen nagy frekin mükődik e még a sorosport? (Van még odébb ennél is nagyobb sebbeség is megadva)

Egy grafikus lcd kijelzőt szeretnék ezen keresztül mükődtetni és adott esetben akár (ha egyszer elkészül) ez lenne egy digit szkóp kijelzője is + sok más feladatot is megjelenítene.

2500 Kbaud-ot nem fogja bírni semilyen PC-s sorosport....
ftdi csippel asszem megoldható 3Mbaudig, de csak valamilyen különleges szabvány szerinti dupla vezetékes módszerrel működik a 3Mbaud, 1Mbaud az müxik ftdivel...