Hűűű, le vagy maradva akkor nagyon. Nincs mester, nincs szolga, nincs olyan aki vezényel. Ez egy demokratikus áramkör, itt minden alkatrész egyenlő. Mindenki ugyan azt csinálja, amit kap tovább küldi.

Az 500ms pont egy kényelmes mintafrissítési frekvencia. Hónapok óta így járnak a panelmérő III prototípusaim, teljesen rendben van és használható a mindennapi mérések során. De ha gondolod teszek majd fel róla videót. Maga az 500ms pedig halál pontos mert muszáj annak lennie a pontos idő és fogyasztás-mérés miatt. A legjobb az 1s-onkénti mérés és kijelzés lenne, de az már tényleg lassú lenne az emberi szemnek, ezért lett 500ms és van egy félmásodperces puffer a szoftverben.

Akkor bekapcsolas utan hogyan inicializalodik? MErt ugye bekapcsolas utan elmeletileg mindenki elkezd beszelni, es nyugodtan tovabbithat hamis/hibas adatot is. Hogyan lesz eldontve a "keringo" adat helyes-e es ki/mi donti el, hogy az inicializas befejezodott?

Na jó, köszönök mindenkinek minden segítséget de most ezt is leírjam már vagy negyedszer? Inkább kérlek olvasd el a korábbi hozzászólásaimat, tényleg többször leírtam már ezt is...

Soros vonal esetén az "1" az üres állapota a vonalnak, azaz ha nincs adás, akkor magas jön ki a kimeneten. Emiatt az optocsatolót általában fordítva szokás bekötni (akkor fogyasszon csak, amikor adás van), tehát a tápra van kötve egy ellenálláson keresztül az optocsatoló diódájának egyik vége, és földre húzza a másik végét a TX, ugyanígy egy ellenállás felhúzza a tápra a másik oldalon az RX-et, és az optocsatoló tranzisztora húzza azt le a földre.

Ha ez egy komoly technikai korlát, végül is elfogadható (bár nekem a II verzió is kicsit lassú, főleg áram figyeléshez). Ha az 1s osztogatod lehetne 250ms, a legtöbb műszer úgyis 3-5Hz-cel frissít. Csak azért erőltetem ezt a témát mert a sebességbe ez is belejátszik (bár ez is simán beleférne szerintem).

Szerintem ez tök szubjektív (és néha helyzetfüggő is), hogy ki milyen értéket visel el/tart jónak. Nekem van automata méréshatárváltós multiméterem, és a halálba tud kergetni, hogy 1-2s, mire megkapom a helyes számot, rendszeresen ki is szoktam rajta kapcsolni (csak minden üzemmódváltásnál visszajön). Nekem még az 500ms is sok, én valószínűleg másodpercenként 3-4-5 frissítést éreznék jónak. Aztán kinek meg a papné, ugye.

Ha csak egy irányba megy körbe "vakon" küldöd az adatokat, hogy fogsz hibákat detektálni, szerintem ez elbonyolítja a hibakezelést.

Ha rossz az adat, el kell dobni. Erre való a checksum.

Van meg mit tanulnom, de ha jol tudom a PIC nem egy multitaszking eszkoz, vagyis egy idoben csak egy dolgot tesz. Ertem en ezalatt, bekapcsolas utan, mivel mindenki egyenlo, es nincs kiindulasi pont, az osszes pic elkezdi mondani a magaet es nem hallgatja, mit kuldott a mogottes(ek). Igy mikor indul be a rendszer?

Ez jó ötlet, köszönöm!

Raadasul aszinkron rendszer, azaz nincs egy kozos pont, mint referencia.

Az áram-figyeléshez ott a vonalkijelzés amit több mint 30FPS-sel jelenít meg. A 250ms-on gondolkodom, végülis megoldható viszonylag egyszerűen, bár AC mérésnél nem annyira előnyös.

Ez garantáltan kijelez új mintát minden 500ms-onként, nincs olyan hogy várni kell 1-2 másodpercet. Méréshatárt nem is tud váltani, de ha tudna (a korábban vázoltak alapján) akkor az elektronikusan váltana méréshatárt és ott is garantáltan 500ms-onként jelezne ki ha vált, ha nem! Ki is próbáltam ezt anno és a gyári multimétereknél tapasztalható "gondolkodás" a méréshatár-váltáskor abszolút nem létezik. Van is róla egy régebbi videóm: Bővebben: Youtube
Mindenféle gondolkodás vagy késleltetés nélkül váltogatja a méréshatárokat.

Amikor mindegyik mérő mért egyet, és az elpropagálódott a kijelzőshöz. Az én hozzászólásaimat se olvastad el végig...

A vonalkijelzés jó is de az nem műszer, hanem "indikátor" .
A hibakezelésnél arra gondoltam amikor a protokollban van hiba, közben meg dőlnének be az adatok, akkor az egész kör elveszik.

Igen, egy időben egy dolgot tesz. Alapesetben az van hogy se nem ad, se nem vesz. A másik állapot amikor ő ad de közben nem kap semmit. Vagy pont fordítva, kap valamit de közben nem kell küldenie. Ezekkel eddig semmi probléma sincs, azt hiszem egy egyértelmű.
A probléma akkor lehet (de nincs!) ha épp ad, és közben érkezik neki valami. Ekkor bemásol egy bájtot az UART kimeneti regiszterébe, majd várna hogy mikor küldte ki az UART modul a bájtot. De még mielőtt kiért volna jön egy megszakítás hogy hékás, kaptunk valamit! Akkor fogja magát és megszakítás-vektorra ugrik, ott szépen letárolja az egész adatcsomagot ami érkezik, mindent bemásol ahova kell stb. Aztán törli a vételi flagbitet és visszalép a megszakításból a főprogramba ahol folytatja a várást. Még mindig arra vár ugyanis hogy kimenjen az első bájt. Na de már ki is ért mert a fogadással egy csomó időnk elment. Úgyhogy fogja és kiküldi a második bájtot, majd a harmadikat stb. Az utána következő PIC csak annyit fog ebből látni hogy kapott egy bájtot aztán nem rögtön utána jött a második bájt hanem csak egy kicsit később. De őt ez nem érdekli.

Kb olyan ez mint mikor levelet írsz de közben csönget a postás hogy leveled jött. Abbahagyod a levélírást, kimész átvenni a postástól az érkezett leveleket majd visszaülsz az asztalhoz és folytatod a levélírást ahol abbahagytad. A levélírást abba lehet hagyni és folytatni később, de a "postást" nem lehet örökké várakoztatni mert ha nem veszed át tőle azonnal a levelet akkor az a levél elveszik és ad egy másik levelet. Kb ez történik a PIC-ben, már ha jól értem az UART modul működését.

A protokollban nincs hiba, amikor csönget a postás (vételi flagbit 1-be áll) akkor azonnal ajtót nyitunk neki és átvesszük tőle a leveleket. Még akkor sincs gond ha vétel pont megszakításban történt, mert beállítom hogy az UART vételi része magas szintű megszakítást okozzon, minden más alacsonyat. Így mindenképp tud figyelni a PIC arra hogy mit kap.

Akkor mond, hogy tudja, ha már kipróbáltad. Ennyi idő alatt ezen már túl lennék...

Mindenki figyelmébe szeretném ajánlani, hogy a problémát logikailag már megoldottuk, csak a kommunikáció sebessége a kérdőjel. Ha az megfelelő (pl 38400baud megy) akkor talán nincs is több kérdés, legalább is szinte biztos, hogy meg tudnám oldani a kommunikációs részt...

Sajnos ez nem ennyire egyszerű. Forrasztgatni vagy bármilyen elektronikai dolgot amit nem fejben vagy számítógépen kell művelni, csak a munkahelyemen tudok mert ott van az összes műszerem, eszközöm és alkatrészem. Oda pedig csak akkor jutok el ha dolgozom. Amióta bedobtam ezt a kérdéskört ide nektek, azóta nem voltam dolgozni. Meg amúgy sem olyan egyszerű, kellene legalább két panelmérőt építenem ráadásul kvarccal úgyhogy a panelmérő II kiesik mert azon nincs kvarc. Szóval akkor már egy (két) új nyákot kell gyártanom, azokhoz alkatrészeket beszereznem, beültetnem, össze kötni őket optón, aztán leprogramozni az egészet és nézni hogy működik-e. Ez sajnos nem megy egyik napról a másikra, bár borzasztóan érdekel a dolog és nagyon kíváncsi vagyok már rá én is!

Pedig en pontosan erre gondolok, mert ez tortenik amikor beindul a rendszer, mert nincs senki aki szinkronizalna, vagy meghatarozna a kezdeti pontot (demokratikus aramkor)

A postás hasonlatomat olvastad?

Olvastam. Mondtam, hogy hianyos a tudasom. Nem gondoltam, hogy egy megszakitassal felfuggesztheto. Ezek szerint neked ugy kell megirnod a FW-t hogy kepes legyen lekezelni kesedelmet (irtal eppen, amikor bejovo adat jon)

Az UART modul (vevő része) röviden úgy működik (ha jól tudom) hogy kap egy start bitet és onnan elkezdi venni a sorban egymás után jövő biteket. Amíg nem jön meg egy teljes bájt, addig nem csinál semmit a PIC. Persze az UART vevő szépen rakosgatja a biteket el magának de a PIC programjának működésére ennek semmilyen hatása nincs. Amikor aztán beérkezik az utolsó bit meg a stop bit akkor a vett bájtot beleteszi egy kitüntetett regiszterbe, és megszakítást generál (már ha beállítottam hogy generáljon). Akkor én (a főprogram) beugrik a megszakításba, ott jó gyorsan átmásolom azt az egy bájtot egy másik regiszterbe, mert közben ha érkezik még egy bájt akkor azt megint beteszi abba a kitüntetett regiszterbe. Ha nem másolnám onnan ki gyorsan a vételi bájtokat, akkor így elvesznének. Ezért kell hogy azonnal reagáljon a vételre a PIC.

A hasonlatomban erre mondtam hogy azonnal ajtót kell nyitni a postásnak és elvenni tőle a levelet amit hozott, mert különben a kis sunyi széttépi a levelet és ad egy másikat helyette. Ő nem túl demokratikus.

Ja hát persze, de azért mégiscsak a hardveres megoldás a legelegánsabb.

Nem is kell azonnal. Van rá minimum 10 bitnyi időd, az 20MHz-es PIC és 38400 bps esetén 1302 utasításnyi. Az rengeteg idő ám, sacc/kb. 100-130 utasításba simán berakható a vevő interrupt rutin.

Na igen. Elméletileg azonnal, de ha utána számolunk akkor kiderül hogy a gyakorlatban ráérünk.

Ráadásul a vevő int rutinja kb mindössze ennyi:
0. Belépek a megszakításba
1. Eltárolom a W-t meg a STATUS-t.
2. Törlöm a vételi flagbitet.
3. Vett bájt (első bájt) bemásolása az "ELOZO_PANELMERO_FESZ" regiszterbe!
4. Érkezett új bájt? Ha nem akkor újra megkérdezzük, ha igen akkor tovább lépünk!
5. Vett bájt (második bájt) bemásolása az "ELOZO_PANELMERO_ARAM" regiszterbe!
6. Érkezett új bájt? Ha nem akkor újra megkérdezzük, ha igen akkor tovább lépünk!
7. Vett bájt (harmadik bájt) bemásolása a "2VEL_ELOZO_PANELMERO_FESZ" regiszterbe!
8. Érkezett új bájt? Ha nem akkor újra megkérdezzük, ha igen akkor tovább lépünk!
9. Vett bájt (negyedik bájt) bemásolása a "2VEL_ELOZO_PANELMERO_ARAM" regiszterbe!
10. Érkezett új bájt? Ha nem akkor újra megkérdezzük, ha igen akkor tovább lépünk!
11. Vett bájt (ötödik bájt) bemásolása a "3MAL_ELOZO_PANELMERO_FESZ" regiszterbe!
12. Érkezett új bájt? Ha nem akkor újra megkérdezzük, ha igen akkor tovább lépünk!
13. Vett bájt (hatodik bájt) bemásolása a "3MAL_ELOZO_PANELMERO_ARAM" regiszterbe!
14. Kilépünk a megszakításból!

Persze a valóságban ennél bonyolultabb mert teljesítményt is küldeni kell meg méréshatárt, ráadásul minden adat két bájtos. Plusz még pár extra bájtot is küldözgetek majd mint például szoftververzió, mert ha az nem egyezik akkor eldobja az egész vételt és hibát ír majd ki. Így nem lesz kompatibilitási probléma, ha esetleg két nem azonos verziójú szoftverű PIC kerül össze.

Na látom nem tudod, hogyan kell ezt csinálni, mert már az elején mondtam, hogy itt nincs idő megvárni az összes bájtot beragadva a megszakításba! Fuss neki mégegyszer! Azt is vedd figyelembe, hogy közben küldened is kell, azt is megszakításban!

A másik, hogy komolyan gondolod, hogy egy opto átvitelének vizsgálatához panelt kell építened, kettőt?
Nem kell hozzá csak egy jó próbapanel, meg egy opto + két PIC esetleg egy MAX232, ha PC-re akarod nyomni a kísérlet eredményét, de egy LED is elég a visszajelzéshez! Tök egyszerű programmal le lehet tesztelni! Ha megy a 40baud, akkor no problem, lehet panelt építeni!
Meg mi az, hogy neked otthon nincs semmi? Ez számomra feldolgozhatatlan!