Vagy az úgy jobb hogy bemegy a jel az egyib pic rx tx lábra és a pic amit használok rendelkezik még egy rx tx lábbal azzal tovább küldi a jelet a másik picknek??

Ahhoz, hogy több UART kapcsolatot tudj elosztani/összegyűjteni, minimum három UART kell egy kontrollerbe, különben nem lesz semmilyen elosztás/összegyűjtés. Egy "bejövő" és másik kettő, amin egy-egy eszköz csücsül.

Akkor veszett ügy.
Az volt a cél hogy egy soros bemenettel pcröl tudjam vezérelni 3 picet egyszere ennyi. De akkor csak egyet fogok.....
szerk:
Vagy amit mondtam hogy sorba kötöm öket mert a picnek van 2db soros lába.
Az egyik meg kapja az adatot de nem az övé tovább küldi és igy tovább. Rossz elképzelés ez ?

Lehet csak én értek félre valamit ...
Kétirányú kapcsolat lenne a PIC-ek és a PC között, vagy csak a PC küld adatokat?
Ha csak a PC küld, akkor miért ne lehetne a PIC Rx bemeneteket lepárhuzamosítani?

Még 1 ötletet felvetnék
Próbáld ki,hogy a PC-től ki az első pic RX-re(címzéssel)ha nem neki szól akkor továbbküldi a kövi pic RX-ére,stb...Így végül is soros kommunikációt valósítanál meg ,és lenne másik címzés a PC-felé,amit csak továbbküldenek...Ez így szerintem megoldható ,Ehhez elég 1 uartot használni.

Minden további nélkül megoldható. Az USB/TTL serial átalakító TX kimenetét közvetlenül összekötheted a 3 (vagy akár több) PIC RX bemenetével. A PIC-ek TX kimenetére rákötöd a soros diódákat, a diódák másik felét összeközösíted, rákötöd a felhúzóellenállást, és bekötöd az USB/TTLserial RX bemenetére.

Ha ttl uartod van, nem kellene gondot jelentsen. Nyitott kollektoros kötéssel bármikor közösíteni tudod a jeleiket. A tx jel kimenetéről ellenállás osztóval meghajtasz egy npn bázist, a kollektora a kimenet, + táp felé felhúzó ellenállás. Azokat a jeleket közösítheted, közös vezetéken szállíthatod. A szállított jelről a bemeneten ugyan úgy ellenállás osztóval npn bázist hajtasz meg, a nyitott kollektor felhúzó ellenállással a bemeneti jel rx-hez. A szerver felől csak egy tx van, és sok rx-hez kötöd be. A kliensek felől sok tx van, és csak egy rx-hez kötöd be. A kétoldali tranzisztoros "bohóckodás"-nak részint lesz egy olyan előnye, hogy a földhurok kevésbé fogja kinyírni a pic-eket, mert jellemzőbben a kimeneti tranzisztor fog megsülni, ha túl sokat fészkelődtél a műszálas pulcsiban - már ha érzékeny az a tranzisztor egyáltalán. Feteket azért ne használj, mert azok viszont érzékenyek, még a teljesítmény fetek is. Az ellenállás osztó is azért kell a bázisra, hogy ha szétkötögetsz dolgokat, legalább egy ellenállás a bázison föld felé mindenképpen legyen. Ha kicsi sebességgel is elég a meghajtás, még egy kondenzátort is rakhatsz bázis-emitterrel párhuzamosan "villámvédelem"-nek.

Egyébként nemc sak rs232 létezik, feltalálták már az rs485-öt is. Ott is végül ttl uart-od lesz, és cak annyi a trükk, hogy sosem beszél mindegyik állomás egyszerre, azért lehet közösíteni a jeleiket. Felkotrod wikin a fizikai interface-t, használod a 485-ös meghajtókat (vannak max ic-k), akkor ugyan azt kapod szabványosabb formában, mint amiről fentebb a barkács leírást adtam. Az egyik olcsóbb, a másik szabványosabb, dönts kedved szerint.

Ha messzire vinnéd a jelet, a földhurok tényleg gáz tud lenni. Mindig az nyírja ki a max ic-ket is. A sima tranzisztorok kicsit teherbíróbbak.

Azért mert az van otthon + az op amp valami kiegészítés nélkül visszakapcsolgatna és nekem nem kell, hogy az akkukat ha hemerültek kapcsolgassa az opamp ki-be-ki-be amm már megoldottam köszi a segítséget

BASIC-et nem ismerem, de lehet csak egy apró bakit követtél el.. Esetleg írásnál nem a megfelelő byte-ot küldöd ki..

Egy PC soros portról lehet több pic -et vezérelni. Több megoldás is létezik...
- RS232 / RS485 konverterrel - azt hiszem szükségtelenül bonyolult ide.
- A PC adási vonala szintillesztőn keresztül elmegy minden PIC vételi vonalára, a PIC -ek adási vonala is szintillesztőn keresztül összesíthetők a PC vételi vonalára. A szintillesztőn van a lényeg:
Ahhoz hogy esetlegesen kikapcsolt PIC ne zavarja a többi egység adatforgalmát optocsatolós szintillesztőket ajánlok. A PC adási vonala az optocsatolók sorba kapcsolt LED -jeit hajtja meg egy áramkorlátozó ellenálláson keresztül. Az egyes PIC -et Rx lába az optocsatoló kimenetére vannak kötve és egy ellenálláson keresztül a Vcc -re vannak húzva. A PIC -ek Tx kivezetései egy-egy ellenálláson keresztül egy-egy optocsatoló LED -jeit hajtják meg. Ezen optocsatolók tranzisztorai párhuzamosan vannak kötve és egy közös lehúzó ellenállásra dolgoznak. A Tranzisztorok közös kollektora egy modem vezérlő jelre (pl. RTS) illetve a közöt ellenállás egy másik modem vezérlő jelre (pl. DTR) megy. A közös emitter a PC Rx vonala. A PC -s program +9 .. 12 V -ot kapcsol az RTS -re, -9 .. 12V -ot a DTR -re. Ezen kívül csak arra kell vigyázni, hogy egyszerre csak egy PIC adjon.

Ezt természetesen elgondolkottam feljebbirtamés kérdeztem is hogy lehetségese de nem lesz lassú??

Ezt megtudnád rajzolni mire gondolsz???

Elolvastam de most gondoltam jobban belle hogy nagyon nem lényeges hogy a pic komunikáljon a pcvel....... Elég ha a Pc küldi csak a jelet és kész. akkor közösithetöek a lábak??

RX lábak közösíthetőek minden további nélkül, ezekre köthetsz rá egy TX-et. Ha ezzel kezded, egy oldalnyi maszatolást meg lehetett volna spórólni.

Hát "maszatolás" is lehet de nekem mondjuk tanulás.
Mindegy rx közösitve tx et nem lényeg bekötni akkor nem???

Értelmezhetetlen a kéréds.

RX lábakat közösitem akkor de tx lábakat nem kell bekötni mert adatokat nem fogad jól gondolom?

RX lábakat mindenféle trükk nélkül össze lehet kötni. Ha a kontrollerek TX lábára nincs szükséged, akkor azokat hagyd szabadon. Az összekötött RX lábakra egy TX ráköthető.

Ami egyéb alkatrészek nélkül nem megy, az a TX lábak összekötése.

Rendben köszönöm

Be sem kell kötni őket. Ekkor az összes PIC Tx lába bekötetlen.

Még annyi lenne de ennek semmi köze a pc nek és ez másik RX-Tx modulon lenne.

Van két pic össze van kötve rendesen komunikálnak. Egyik pic küldneki xy értéket a másik pic lekérdezi MSGEQ7 értékeit (beolvassa) és vissza küldi a mért értékeket. Ezt végre lehet hajtani 1ms idötartamonként??

MSGEQ7 lekérdezés végző pic nek az éppeni folyamatát nemfogja meg "fagyaztani"???
Vagy interupot használjak a lekérdezésnél(MSGEQ7-s)?

Köszi!

Logikailag volt hibás a történet. Most, hogy vissza kaptam a normális internet elérésem, könnyű volt rátalálni az AN734-es App Notes-ra. Ebben részletesebben le van írva és van hozzá C forrás is. Onnan könnyű volt átültetni.
Amúgy rajta lógtam a vonalon szkóppal és logikai analizátorrál, jót küldetm ki, csak a feldolgozás volt eltévedve kissé.

Megszakítással nem lesz az...Bár a Pic-ektől is függ,hogy mennyire akasztja meg,a soros kommunikáció a pic egyéb dolgait(mert ugyebár van pár dolog,amit nem jó ha megzavarnak).
Bár annyira nem vágom,hogy mit is szeretnél,de ha csak a PC-vel lekérdezni a Pic-eket,akkor van még 1 ötletem .
Kiválasztod azt a Pic-et,ami a legkevesebb dolgot csinálja,és azt teszed a lánc végére. A többi Pic-en beállítod a loopback-et. Így az összes Pic az utolsónak küldi az adatot,ami így elpuffereli,és amikor jön a lekérdezés a PC-től,akkor az utolsó Pic kiküldi az Összes Pic adatát.Vagyis az utolsó Pic kivételével az összes Pic küld folyamatosan,és az utolsó csak tárol,és küld.Így talán bonyolultnak tűnik,de megoldható
Ha a távolság növelése a cél,akkor még jó lenne a BlackNet is,bár így 1 Pic-nek 2 uart-ját kellene használni.

Ui: (Kriszrap) az USB-TTL az fogjuk rá,hogy ua. mintha csak 232-3232-es szintillesztő lenne az össz Pic-en,de a feltevésed csak akkor jó,ha relatív rövid a Pic-ek közötti távolság.A szintillesztés lényege pont a távolság növelése lenne sztem.

Mekkor adatmennyiség, milyen sebességgel? Ebből könnyen ki lehetne számolni, hogy 1 ms alatt mennyi adat megy át.
Ha 9600 Baud a sebesség, akkor körülbelül 1, azaz egy bájt fér ekkora időszeletbe.

No akkor megoldódott. Én is sokat szívtam nem rég 32MX-esetében az I2C-vel, ez a PIC mindig a sebességével lep meg..

8 bit összesen MSGEQ7 kérdéses hogy mennyit kell várni a Feldolgozásra.
9600 sebesség lenne.

Úgy nem lenne egyszerűbb és a fő folyamatot nem akadályozza.
Megy szépen az idömultiplex és belerakom a uart figyelést van e adat vagy nincs.
ha van akkor elindított egy interrupot amibe az alprogramba benne van a MSEQ7 lekérdezés és uart elküldése így nem akadályoz a fő folyamatokat.
És i annyira nem kell számolgatni. Így is lehetne??

Annyi a kérdésem soft uart vagy hadweres érdemes használni mikroC be?
Hadweresnél több az eljárás mint a softosba...

A hadweres uart -ot könnyebb kezelni (főleg a vételt). A PIC uart -ja kellő belső órajel esetén akár 300kbit/s -el is tud működni, akkor egy byte 33.3us alatt átküldhető.

Hogy érted??
Másik ha az egyik szoftverest használ a másik hadweres uartot használ az nem okoz problémát???

SW uart: A vételnek mindig figyelnie kell a vonalon történő jelváltásokat, még akkor is, ha más teendői akadnának. Ezért változásfigyeléses megszakítással kellene kezelni a vonalat. Ha egy lefutó élet talál, fel kell indítania egy időzítőt (előbb 1.5 bitidőre, majd 1.0 bitidőre) hogy az adatbiteket beolvassa. Ezután még egy bitet (a stop bitet) kell beolvasnia és ellenőriznie. Ha minden jól ment, az adat feldolgozható. Ha hiba volt, újra lefutó élet kell várnia.
HW uart: Beállítod a vételi sebességet, formátumot, a megszakítás kérést, engedélyezed a vételt. Várod a megszakítást, ha megjött kiolvasod a status regisztert, megnézed van-e hiba. Ha nincs hiba, kiolvasod a RCREG -et és átadod az adatot. Akkor is ki kell olvasni az RCREG -et, ha volt hiba. Egyes hibák törlésére elég a kiolvasás, másokéhoz le kell tiltani az uart -ot és újra engedélyezni kell.

Ha a sebesség, a formátum azonos, nem okoz problémát hogy az egyik fél a hw, a másik fél (gondosan megírt) sw uart -ot használ.