Microcontrolere - Interconectare!

[78ATI]

Buna! Doresc sa conectez doua microcontrolere, printr-un port I/O. Doresc ca pe acest fir comunicarea sau schimbul de date sa se faca in ambele directii prin schimbarea repetata sa directiei porturilor I -> O, O > I: Intrebare:*** Ce se va intampla in cazul unei eventuale "nesincronizari" intre cele 2 Controlere, cand ambele controlere au portul setat ca si Output ? *** Daca pot aparea probleme in functionarea unui microcontroler din acest motiv, cum se poate evita acest lucru?

[Zerro]

in asemenea cazuri de comunicatii se aplica principiul de master si slave .... ai un pic master si unul sau mai multe pic-uri slave ... masterul face toata sincronizarea si astefel scapi de bataia de cap cu conflictele de comunicatie in multimaster, nu zic ca nu se poate multimaster ci ca e destul de dificil de tratat sincronizarea si conflictele in asfel de moduri de comunicatie...Toate cele bune!

[78ATI]

Sincronizarea in cazul meu nu este un lucru absolut necesar. Doresc ca cele doua Controlere sa functioneze oarecum independent astfel:PIC-A trimite comanda PIC-B -> PIC -A trece pe receptiePIC-B trimite comanda PIC-A -> PIC -B trece pe receptieTeama mea, este: in cazul in care cele doua PIC sunt in acelasi timp pe SEND, deci pot avea starile: 0-0, 1-0, 0-1, 1-1, acest lucru poate duce la defectarea (arderea) celor doua porturi? sau pur si simplu programul nu va mai functiona...fiind o erroare de sincronizare, insa din punct de vedere electric Controlerele vor fi absolut in stare de functionare?

[d2134]

Teama ta e intemeiata. Se pot arde porturile.Daca in loc de un simplu "fir" pui o rezistenta de 4k7 nu se mai ard.

[78ATI]

@d2134, sa inteleg ca punand o rezistenta, nu va mai exista pericolul distrugerii porturilor?Functionarea va ramane aceiasi sau "transmisia" va avea de suferit?Va mulumesc, pentru informatii!

[Vizitator]

Implementeaza ceva similar cu protocolul ethernet: cand canalul de comunicatie e liber, fiecare vorbeste cand vrea, daca sunt mai multi care vorbesc simultan (coliziuni) atunci fiecare asteapta o durata de timp aleatoare dupa care incearca iar sa vorbeasca, numai daca este liber canalul de comunicatie.Practic e mult mai simplu sa folosesti protocoale de tip master-slave, adica nimeni in afara de master nu vorbeste neintrebat.Bafta!

[d2134]

Impedanta de intrare a porturilor e foarte mare, fiind in tehnologie MOS, deci o rezistenta de 4k7 sau chiar 10k nu mai conteaza.

[edy_wheazel]

Pt. a preintampina arderea porturilor (daca sunt amandoua pe send) eu a-si face in felul urmator: a-si folosi un pin de la un alt port pt. control, adica inainte sa trimit date pe port verific starea pinului respectiv, daca (de exemplu) este in stare high atunci nu trimit pt. ca este ocupat, celalalt port imi trimite date, daca e low totul e OK si pot trimitea date.

[lucicop]

Poate sunt offtopic, dar de ce ai vrea sa comunici folosind un I/O ? De ce nu folosesti un bus tip CAN sau macar I2C, care in plus poate fi extins in functie de necesitati ?

[XAN77]

faci asa : sa zicem ca in protocolu tau de comunicatie nu ai impulsuri de "1"mai mari de 10 ms sa zicem, , ca daca e vreo comunicare nu trec 10 ms si sa fie un "1" stabil pe magistrala. Fiecare controler cand vrea sa transmita ceva are pinu ca intrare evident si verifica daca este "1" pe magistrala, si daca da verifica daca sta stabil timp de 10 ms, daca da atunci poate "vorbi" el, magistrala fiind libera . Celalalt verifica daca are ceva de primit in permanenta si va primi, in urma a ceea ce primeste daca are ceva de trimis, va verifica prin acelasi procedeu daca e libera magistrala, deci nu vor avea cum sa se intersecteze .

[lucicop]

Exista posibilitatea ca ambele sa emita in acelasi timp, daca doua dispozitive decid simultan ca e libera "magistrala". Si atunci s-a terminat distractia

[Abram Burel]

Daca exista resurse (adica PIC-urile stiu diverse comunicatii si sunt disponibile) atunci lucicop are dreptate: utilizati ce au gandit altii, nu reinventati roata.Daca exista limitari (de regula de cost), atunci rezistenta aia e suficienta pentru 2 PIC-uri pe aceeasi placa sau macar in aceeasi cutie.Daca sunt mai departate si cu atat mai mult daca mediul e "zgomotos", trebuie reevaluata solutia (si se ajunge probabil la prima varianta)

[78ATI]

Poate sunt offtopic, dar de ce ai vrea sa comunici folosind un I/O ? De ce nu folosesti un bus tip CAN sau macar I2C, care in plus poate fi extins in functie de necesitati ?

Trebuie sa cominic in acest mod deoarece am doar un singur port liber! daca aveam doua...parca alta era distractia!Am sa protejej I/O cu rezistori de 4.7Km si voi avea grija sa nu se intample errori in sincronizare.Sa vedem ce va iesii!

[edy_wheazel]

Este cam riscant, si din punctul de vedere al protectiei si al sincronizarii. Dar se poate rezova, din pacate nu am lucrat cu PIC-uri dar la Atmel a-si face cam asa: foloseste o linie din port pt. control (initial), dupa care il folosesti ca si magistrala de date. Adica iei de exemplu P1.0 care ii legat de P1.0 al celui de-al doilea uC. Scrii codul in felul urmator: pinul respectiv are o stare prestabilita (low), pt. stand-by, daca are aceasta stare il treci ca si magistrala de date, poate sa primeasca date. Daca amandoua sunt in high atunci nu se comunica, unul dintre ele trebuie sa treaca pe receptie. Pt. Atmel cred ca a-si putea sa ma fortez sa scriu un cod, nu e mare lucru, dar PIC-urile nu ma pasioneaza.

[d2134]

Pt. Atmel cred ca a-si putea sa ma fortez sa scriu un cod, nu e mare lucru, dar PIC-urile nu ma pasioneaza.

Dar sa-ti dai cu parerea te pasioneaza?Vezi ca este un forum pentru Atmel: http://www.elforum.info/viewforum.php?f=37