Abból kell kiindulni, hogy mennyire engedhető meg hibázás. Illetve, ha egy adat kimarad, vagy rosszul értelmeződik, akkor beragad a hibaállapot, vagy csak valami kisebb tolerálható hibázás történik, de utána helyre áll minden?
Alapvetően ha két csipet összekötsz direktben (esetleg áramkorlátozó ellenállással) UART segítségével, akkor nagyon ritka lesz, hogy hibázzon az átvitel. Persze a körülményeken múlik, hogy mennyira zajos a környezet, mennyire pontosak az órajelek, stb, de ki lehet indulni abból, hogy nem lesz hibázás.
(Én egyébként próbáltam a hibázás valószínűségét becsülni, és nincsenek konkrét számok a neten fellelhetően, meg ugye tényleg az adott elrendezésen múlik. Mérnem sosem sikerült hibát jól összerakott rendszerben, amikor hibázott az UART, akkor mindig kiderült, hogy valami nagyon el volt rontva, például magas órajel mellett olyan korlátozó ellenállás volt beszerelve, aminek jelentős volt az indukciója. Ha egyezik az órajel a két oldalon és szkópon nézve szép az UART jelek formája, akkor nem hibázik.)
Az időzítéseket ki lehet úgy számolni, hogy a vevő biztosan tudjon venni minden adatot. Ennek feltétele, hogy az UART vevő IRQ időben ki legyen szolgálva, és a buffer sose teljen be. Ezeket könnyen lehet becsülni, illetve egy működő rendszeren mérni, és ezáltal biztosra lehet menni.
Az átvitelt sokszor elég egy irányba biztosítani: egy CRC védi egy blokkot, ha a CRC nem stimmel, akkor a vevő eldobja és kész. Nem stimmelő CRC is nagyon ritka lesz, lényegében induláskor az első csomag, ha a vevő éppen egy küldés közepén indul el. A hibát többnyire ha detektáljuk, akkor simán eldobjuk a csomagot, nem jelzünk, mert felesleges és úgyse tudja a másik oldal, hogy mit kezdjen a jelzéssel. Kivétel csak az, ha a hibás működés balesetet vagy óriási kárt okoz, akkor meg kell csinálni a hibaágakat rendesen, de az hirtelen több nagyságrenddel bonyolultabb és drágább lesz.
A protokollt úgy kell megvalósítani, hogy kimaradás vagy hibás csomag esetén a helyes működés vissza tudjon állni, vagy még jobb ha 1 kimaradó vagy hibás csomag nem is okoz észlelhető hibát.
Ha nem kell 100%-ra kitölteni a lehetséges UART sávszélességet, akkor a csomagok közötti határt egyszerűen a szünet tudja jelölni. Ha adott ideig nem jött bájt, akkor töröljük az eddig kapott töredék csomagot (ami szintén csak induláskor fog előfordulni) és tiszta lappal várjuk az újat.
A te esetedben a periódusidő és a csomagméret az MCU-k számára gyerekjáték, tehát simán megbízható lesz minden visszajelzés nélkül az egész rendszer, úgy hogy csak a küldő oldal periódikusan küldi amit kell.

Az UART full duplex (ha mind a két vonalat rendesen összekötöd a két chip között), az adás és a vétel nincs szinkronizálva egymással, nincs olyan, hogy vételen van, mert végig vételen van. Persze létezik half-duplex megoldás, ha csak 1 vonalon akarod összekötni a két csipet, akkor valóban kell valami protokoll, ami alapján eldöntik, hogy éppen ki beszélhet, de ha nincs valami komoly okod ilyennel szivatni magad, akkor inkább csinálj full duplex összeköttetést! (Meg létezik szinkron UART is, azt szintén csak akkor csinálj amikor már nagyon érted mi az és miért jó neked.)

A Mega egyik Uart-ja veszi a 3 JSY energia szenzor adatait(csak 0.5 m),egy másik Uart RS485 vonalán veszi az inverterek napelem adatait(ez pár méter).ezek mind Modbus protokoll.Ebből állapítja meg mennyi a pillanatnyi felesleges napenergia,ami nem kell a helyi fogyasztásnak,amit majd másra elhasználok.Az ESP kb 30 m-re van az RS485 vonalon,itt csak az adatokat és a folyamatot szeretném látni.Mivel a monitorjára grafikonokat lehet rajzolni,ami pár sec is lehet,ezért gondoltam várakoztani a mastert.Az Esp a szenzoraitól 1 wire vonalon kap adatokat amik szintén 30 m-re vannak és jól működik,az RS485 biztosan jó lesz.Köszönöm a hozzászólásokat.

Ejha! Megadod a módját!

A modbus már helyből kérdezz felelek +crc benne protokoll. Nincs kinek mit várakoztatni.

Nos igen,a JSY és a DC szenzorok modbust használnak,de az ESP monitort régebben csináltam és ott az adatok tömbökben vannak kezelve és a Megába is.Ezt nem szeretném komolyabban bolygatni,inkább írok valami egyszerűbb protokollt.Gondolkodtam rajta hogyan lehetne ezeket a tömböket regiszterként címezni mint ahogy a modbus,de nem jutottam sokra,ezért maradtam a réginél amit tudok kezelni,legfeljebb nem olyan szép.

Nem egy ördöngösség... pl ami könnyen emészthető, legyenek csak ASCII(hex) krakterek, kijelölsz egy spéci karaktert, pl ":" ez az adatfolyam bevezetője, utána egy azonosító(vagy regiszterszám parancskód, akármi), utána adathossz, utána adatok, crc. (hasonló mint az intel hex formátum) Vételkor mindent eldobsz, amig a spéci karaktered meg nem jön, ha levetted az összes adatot, ellenőrzöd a crc-t ha jó/nem jó, eldobod vagy visszajelzel oké/rossz/kért adatot küldesz...
A crc helyett lehet valami egyszerű is pl egyszerűen összeadod 2 bájton kapott parancskódot + adatokat.
Ennek a módinak az is előnye hogy terminál progival befigyelve emberi emésztésre is nagyjából alkalmas az asci-hex karakterek miatt. esetleg lezárhatod a sort egy soremelés 0x0a karakterrel, vagy a spéci karakter esetleg lehet a soremelés karakter, akkor a terminál progiban minden parancs új sorban látszik

Igen ilyesmit csinálok, crc-t nem használok,régen egy paritás bit is adott valami biztonságot,de valami kontroll szummát csinálok az egyszerű és jobb.

Jó ötlet, de mégis jobb a már használatban levő protokolokat használni hogy szabványos eszközökkel is lehessen kommunikálni, modbus ascii ami hasonló, vagy omron hostlink

Hello, szerintem túlbonyolítod.
Én egyszerűen beiktattam az áramkőrbe (oda ahol van az inverter „smart meter”-je) egy SDM630 -at (háromfázisról van szó, monofázisra SDM120 ha jól emlékszem).
Az „SDM.h” könyvtárral, 38400 -as sebességgel, 30 m -en kiválóan müködik. Az ESP32 egyik szálja (magja) csak azt csinálja hogy kéri az SDM630 -tól az adatokat (a kapott érték negativ vagy pozitiv előjelű attol függően hogy éppen van felesleg áram vagy sem) és szabályozza a fogyasztót, ami három fűtőszálból áll a puffertartályban.
Ismétlem, kiválóan mükődik.

Végül is ugyanazt csinálom a Megával meg a a szenzorokkal mint Te,csak az SDM helyett JSY-használok amiből 3 db fele annyiba sem kerül és hasonlóra képes.A bonyolítás csak annyi,hogy a régebbi ESP-s monitoromon is szeretném látni a folyamatot.Nekem hibrid inverter is van,nem elég csak a negatív áramot figyelni ennél nincs visszatáplálás,az inverter bemenetét és kimenetét is figyelni kell,a JSY-nak pedig 2 mérőhurokja van.A felesleges energiával nekem is hasonló a célom,csak közvetlen a napelemekről akarom venni.ami tényleg bonyolultabb,de nem terheli az invertereket.Neked mindhárom fázison van inverter,vagy 3 fázisú?

Vagyis, van akksid is ?, az már változtat a helyzeten. de az SDM nem gagyizik és az JSY csak „hasonló”, de nem ugyanaz
Végűl is, nálam annyi a lényeg hogy van pozitiv áram vagy nincs, ha van elfogyasztom és ha nincs akkor annyi

Mit értesz "gagyizás" alatt,úgy tudom a JSY-nak pl.24 bites AD konvertere van és ahogy nézem elég pontosan mér.A két fajta közül egyik sem használható hiteles mérésre,de feltehetőleg mindkettő jó lenne.

Bocsi, de ahogy értettem a fentiekből gondjaid vannak az UART kommuniokációval.
Valójába én a gyakorlati oldalát nézem a dolognak, nem akarom tanulmányozni. Ha müködik rendesen OK, ha nem akkor kuka, mást helyébe.

Szia!

Uart-ot nem sokat készítettem, főleg nem ESP és Arduino-ban, inkább dsPIC/PC (VB.Net), de nekem szerencsére az RX/TX megoldott mindent.
Azonban a soros porton van még pár kábel:

DCD,DTR,DSR,CTS,RTS,RI

Csinálni kell egy null modemet a kábelből, (vagy venni kell) plusz szerelhető d-sub 9 tűs csatlakozók.

Én ebből más célra simán használtam két vonalat, de másképp az igaz. A VB.Net -ben a soros kommunikáció során ezekhez is hozzá lehet férni ha kell, nem csak az RX/TX-hez.

Ha nem is standard módon küldesz/fogadsz adatot, szerintem akkor is ki lehetne egy két rövidke függvénnyel egészíteni az átvitelt. CRC-re elvileg van megoldás, ha még csak szoftveresen is.

Ha crc hiba van, akkor 1-2 vonal magasra húzva visszajelezhetne, így az adatot újraküldi.
Szoftveresen olyat is lehetne, hogy előre megmondja milyen tömböt küld, sor/oszlop és milyen típussal, hány bájt, végén ellenőriz, de ez nem jó ötlet, sok ideig tart.

De még olyat is lehetne, hogy visszaküldi az adatokat és az adó oldalon ellenőriz, ha jó, akkor a másik kábelen jelez, hogy a következő adat az ismétlés lesz-e, vagy már az új.

Mind az adó, mind a fogadó oldalon lehetne kis szubrutin amiben adatokat küld meghatározott mennyiségű byte-al, de csak akkor, ha a megfelelő plusz lábakon a megfelelő értékek jelennek meg. Így az adó vár, míg a vevő dolgozik, vagy ilyesmi.

Sok megoldás lehet ilyenkor szerintem.

Szerintem egy két plusz digitális láb figyeléssel interrupton és néhol némi késleltetéssel megoldható a dolog.

Mindezt ki lehet egészíteni azzal, is hogy az adó oldalon egy szabad vonalon ki lehet adni egy változó szélességű impulzus sorozatot, ami a Vetted? jelzés lenne. A vevő oldalon le lehet ezt is programozni, így ha igen zajos a kommunikáció (mint a rádiós átvitelnél) A vevő majd visszaküld egy ilyen sorozatot, a vettem! jelzéssel. Persze mindegyik oldalon kis várakozással. Ez azért jó, mert ha tüske van a vonalon, az elindíthatja az interrupt lábon a dolgot, de az csak véletlen volt.

Ilyet már csináltam, de ide ez igen sok lenne szerintem. Rádiós átvitelnél ilyen jelsorozatot már programoztam, nem is bonyolult annyira.

Csak mint érdekességnek vetettem fel de kábellel ilyen gond nem nagyon lesz.

Ha jól belegondolsz, akkor mindez nem is olyan sok plusz kód, mert a serial.print() csak akkor indul, ha a lábak megfelelnek stb.

Ok, abbahagyom, tudom hogy ennek sok irodalma van, de lehet agyalni nem?

Köszi,az adatcsere már működik a két eszköz között,most a gondom az ESP32 Uart 1-el van,ha Serial 1-et elindítom elszáll a program.Ez nekem fizikailag ki is van vezetve(9,10),de állítólag belül másra is csatlakozik.A leírás szerint újra kell definiálni,ha átteszem pl 2,15-re működik,de 9,10-re definiálva szintén elszáll.Ha ezt a két lábat nem lehet használni miért van kivezetve?Ez a két láb meg van jelölve RX TX-nek.Az Uart 0 és 2 közvetlenül is működik,de foglaltak.
Még egy kisebb gondom van,ide2.2.2 használok,ha bekapcsolom a könyvtárkezelőt,felteszi a kép bal oldalára,de eltüntetni már nem tudom,kilépés után is visszajön.Hogyan lehet tőle megszabadulni?

Mert a "belső" flash van rajta.
ajánlott olvasmány: https://randomnerdtutorials.com/esp32-pinout-reference-gpios/
Azért van kivezetve hogy flash/rammal bővíthető legyen.
Vannak lábak, amik "boot alatt" meglepetést okoznak

Igen ezeket én is néztem,de mivel ki volt jelölve RX/TX-nek,úgy gondoltam definiáláskor leválasztódik belül,ha pl. nem kell a memória bővítés.Nekem szabad maradt a 0,2,6,7,8,15 ,ebből valószínüleg a 6,7,8 nem lesz jó,de a 2,15 jó lehet RX/TX-nek? Ezeket a lekötött lábakat sima be/ki menetnek sem lehet használni?

RX necces, mert nem tudod a bejövő soros állapotát a boot idején, és ha éppen túloldalról adás van......
Tx-nek jó lehet, de nem mindegy amit meghajtasz az hová húz boot idején...
GPIO 2 (must be floating or LOW during boot)
GPIO 15 (must be HIGH during boot) és outputs PWM signal at boot!!!

Ezt a problémát talán meg lehetne oldani úgy, hogy egy olyan kivezetést ami garantáltan nem mocorog boot idején, ezt használod fel engedélyezésnek egy busz meghajtó felé. Őrajta pedig áthúzod a problémás kivezetéseket. Igaz hogy plusz egy ic, cserébe viszont minden kivezetést ellenőrzésed alatt tudsz tartani, mert csak akkor aktívak a külvilág felé amikor már elindult a rendszered és engedélyezed nekik.

Üdv!
Kezdő vagyok a témában..
Egy Arduino Nano-ra szeretnék feltölteni egy programot de valamiért nem sikerül.
Port probléma vagy mi okozza ezt?
Kipróbáltam gépem elülsö USBről is de ott sem működik.

Szia, próbáld meg a processzor választásnál az "ATmega328P (Old Bootloader)" opciót kiválasztva feltölteni. (Soros port drivere fel van töltve, COM portot kiválasztottad?)

Így már feltöltötte. Köszönöm.

A GPIO 15 jó lehet TX-nek,boot idején HIGH vagy valami PWM jel megy az RS485-re,ha valamelyik éppen ad/vesz ,legfeljebb megzavarja.A GPIO 2- RX-nek használva diódával elválasztva a HIGH nem kerül rá,a LOW nem zavarja ha éppen valaki ad boot idején.A boot után úgyis mindent helyre áll.

Ez jó lehetne,ennyi szabad kivezetésem( 0,2,6,7,8,9,10,11,15 ) van.

Kedves Fórumtársak!

Kéréssel fordulok Felétek. Szeretnék a garázsba szerelni egy laseres "sorompót".
(Nem az autóm nagy, a garázs kicsi.) Találtam egy ilyen arduinóval működtetett sorompót.
A kérdés véleményetek szerint ez működőképes megoldás lehet? Kb. 5 -8 cm-re kell megállnom a faltól, hogy az ajtót is be tudjam csukni.
Valamicskét értek az elektronikához (lelkes 70 éves amatőr vagyok), arduinom van, vettem a modulshpból.
Tisztelettel kérlek ötleteiteket javaslataitokat írjátok meg.
Köszönettel: csibai

https://projecthub.arduino.cc/fanesahadi/laser-security-system-at-h...f2a79e

Felesleges csak ilyenre Arduino-t használni. A lézeres szenzorok egyébként is érzékenyebbek szennyeződésre, beállítás macerás lehet (felfüggesztéstől függően). Én egy retro-reflektív szenzort javaslok. Amire neked kell, kb. a legegyszerűbb is megfelel, csak a hatótáv legyen elég. Ezeknél a szenzoroknál nem kell, hogy a prizma merőleges legyen a szenzorra.

A kimenetére kötsz egy relét, arra pedig olyan jelzőfényt, amilyet akarsz.

Ha csak a távolság a lényeg (ne menj neki semminek) akkor elég lehet az ultrahangos távolságmérő . Van ezen kivűl is még sok ilyen projekt PL EZ , vagy sok más is. Vagy Bakaman javaslata is jó

Kedves Fórumtársak!

Először is nagy köszönet a gyors válaszokért, segítőkészségért!
A helyzet az, hogy kb. 5-8 centiméterre kell a faltól megállnom, hogy az ajtót be tudjam csukni. Több megoldással próbálkoztam, pl. az aljazbetonra csavaroztam deszkát, függesztettem fel pin-pong labdát, stb.
Mindegyik megoldás bizonytalan, így maradt a hagyományos tologatós módszer....
Ez bizony elég macerás, meg nekem már nehéz is.
Az első és hátsó lökhárító kb. egy magasságban van, így egy ilyen fénysorompóval nagyobb biztonsággal tudnék beállni. Próbálta kapunyitókhoz kapható érzékelővel de az vagy nagyon korán riasztott, vagy már koppant a lökhárító.
Azért gondoltam az arduinós megoldásra mert mint írtam van is itthon vagy 3 darab, mert korábban bütyköltem kivezérlés jelzőt, meg ilyesmit. Nyugdíjas lévén szöszmötölök ilyesmivel.
Bakman javaslata biztosan jó lenne, de ahogy néztem elég drága megoldás nekem. 30-40 ezerért láttam ilyen eszközt.
Bocsánat a hosszú fejtegetésért de valószínű nem voltam elég érthető.
Nagy köszönet a javaslataitokért, és várom a további ötleteket.

Szép hétvégét minden Fórumtársnak!
Üdvözlettel: csibai

Itt egy alternatív megoldás (igaz, ehhez nem kell arduino)