Power On Reset pe RS422/485

[Abram Burel]

Am o instalatie cu 1 master si 8 slave conectati pe un bus RS422/485 (comunicatie doar de la master la slave), fiecare modul din cele 9 cu PIC12F629.Alimentarea este de la 12V (de la o sursa in comutatie de pe 220V) printr-un stabilizator "tipic" cu LM2931AZ-5.0, deci cu un condensator de 100uF pe iesire, pentru fiecare modul.Comunicatia (cu SN65176) merge brici.Problema naibii este ca PIC-urile nu au circuit de POR pe MCLR. Rezultatul este destul de neplacut. Trebuie destul de multe tertipuri pentru a face toti "sclavi" sa asculte de "stapan".Am citit AN607, am facut un prototip de "sclav" cu POR extern (10K + 10uF pe MCLR), dar inca nu sunt convins ca aplicand solutia asta la toti sclavi se rezolva situatia.E clar ca de vina e slew rate-ul combinat dat de sursa in comutatie si stabilizatorul de pe placa.Intrebarile ar fi:- ar ajunge un POR extern de genul celui mentionat?- ar fi mai bun altul (o dioda de descarcare "de urgenta" a condensatorului?)?- ar fi mai bine sa alimentez lantul de controlere (master si slave) dintr-o sursa separata mai "sigura" (eventual una "traditionala" cu traf) - as avea sarme suficiente pentru tele-alimentare (cablu UTP, distanta sub 10m)?-ar fi mai sigur un reset controlat de master - sa zicem la 1s dupa ce el a pornit, "propagat" pe una din perechile disponibile (am 2) - si dus la toti "sclavii"?Mentionez ca concluzia e certa: problema e POR-ul dependent de... power (ca fapt divers, pentru a face sa mearga instalatia trebuie aplicat un reset compus din 2-3 intreruperi scurte ale alimentarii cu 220V, si pe unul din "sclavi" un "reset" prin scutrcircuitarea" alimentarii ).

[Cristiano]

Poate mi-a scapat ceva, dar ce legatura este intre POR si comunicatia seriala ? De ce trebuie intrerupta alimentarea pentru comunicatia master-slave ? Nu e mai simplu cu un protocol ?

[Abram Burel]

Probabil ca am scris prea multe Toata descrierea e asa pentru... intelegerea contextului.Problema pe scurt este: la power on, sclavii nu fac resetul cum trebuie si o iau razna (evidemt, ca urmare nu mai comunica)

[sofian]

cum a zis si cristiano ce treaba are resetul cu comunicatia ?ce spui tu ar insemna ca oriunde as pune picul ar avea probleme cu resetul ?deci problema ta este de la comunicatie.apropo PIC16F629 are BOR

[Cristiano]

Probabil ca am scris prea multe Toata descrierea e asa pentru... intelegerea contextului.Problema pe scurt este: la power on, sclavii nu fac resetul cum trebuie si o iau razna (evidemt, ca urmare nu mai comunica)

Dupa cate imi dau seama, nu prea cred ca problema are de-a face cu reset-ul. Daca ai POR si BOR activate iar tensiunea (5V) e stabila (n-ar fi rau sa o verifici cu osciloscopul), atunci PIC-ul functioneaza cum trebuie. Banuiesc ca mai trebuie lucrat la software (asigura-te ca oscilatorul e calibrat - detalii in foaia de catalog, ca rutina de receptie trateaza toate situatiile posibile - zgomote, octeti incomplet transmisi, etc).

[Abram Burel]

Daca ar fi probleme de comunicatie, atunci s-ar intampla te miri cand ca lucrurile sa nu mearga sau sa nu mearga deloc. El insa merge impecabil, dar totul e sa... porneasca (odata pornit, nimic nu-l mai opreste ).Activat e doar PWRTE (GP3/MCLR e folosit ca intrare digitala, deci circuitul de reset e tras la Vdd intern).O sa revin cand ii dau de cap. Nu e probabil o situatie de prea mare interes in aplicatiile "domestice", dar invatamintele pot fi utile.

[Vizitator spider_ktx]

incearca cu un condensator de 100nF imediat dupa condensatorul de 100uF am avut si eu o problema cu sursa in comutatie...

[Abram Burel]

Asta a fost prima idee, dar n-a fost de ajuns.Cateva rezultate preliminare:0. PWRT era activat de la inceput -> nu e de ajuns1. Am activat MCLR si l-am tras la Vdd cu 10K -> niciun efect1a. Un reset aplicat pe MCLR aduce montajul la viata (de unde sa deduce ca este o problema de POR )2. Am activat si BOD -> niciun efect3. Am pus 10uF din MCLR la masa si s-a potolit

[Abram Burel]

E posibil sa aiba si Cristiano dreptate cu problema de comunicatie.Aparent acum lucrurile stau bine, dar...Daca opresc masterul si il repornesc s-a rupt filmul.Daca opresc un slave si il repornesc e OK.E drept ca receptia e cat se poate de ideala (un bit bang la nivel de biti din octet si o secventa de 5 octeti de date cu un start si un checksum tratata la modul "daca-i primesc bine, altfel...???"Sap acum sa gasesc locurile de unde sa "capturez" erorile. Ma multumesc si cu un "warm restart", numai sa gasesc de unde sa-l generez

[Vizitator]

Eu am impresia ca nu ai filtrari pe alimentare si/sau nu iti porneste oscilatorul.Pune decuplari de 10-100 nF si 10-100 uF pe alimentare.

[Abram Burel]

Sunt filtrari de toate.O rezolutie pre... finala: POR decalat (si eventual nereusit) in functie de sursele folosite pentru alimentarea fiecarui master, combinat cu tratarea defectuoasa a receptiei la nivel pachet de octeti.Deci unele surse (fiecare modul, 1 master sau 8 slaves era alimentat separat) porneau bine si POR se facea corespunzator. Altele porneau mai tarziu si/sau aveau un slew rate mai prost. Asta nu stiu exact.Daca nu porneau (POR defectuos) asta era. E vorba de sclavi ca masterul pornea mereu.Daca pornea, dar rata inceputul transmisiei, putea sa o ia razna. Interesant e ca efectul trebuia sa fie vizibil (e vorba de un sistem de lumini pentru firme luminoase), dar nu se vedea nimic :( (de unde concluzia initiala cu POR defectuos).Dupa modificari (circuit de reset extern, tratarea erorilor prin droparea pachetului) testele de laborator (cu fel de fel de surse si simulare pe tot felul de erori de comunicatie), lucrurile par sa se fi rezolvat.Dar proba adevarata va fi pe... teren. Tare-s curios.Pana atunci, multumiri lui Cristiano care mi-a adus aminte ca o comunicatie poate suferi si de erori