Setare PIC sa treaca semnalele prin el ca si cum nu ar fi

[Vizitator beamrider]

Pot seta un PIC sa-si copieze cumva automat 5-6 intrari la 5-6 iesiri (un fel de scurt intre in si out)?

 

Am niste pulsuri de 1-2 ms care se repeta la 20 ms si care in mod normal comanda direct servomecanisme.

 

Vreau sa intercalez un PIC intre generatorul de semnale (un receptor de telecomanda) si servomecanisme in asa fel incit citeodata, functie de niste conditii, receptorul sa fie cel care comanda direct servomecanismele altadata acestea sa fie comandate din PIC si semnalele de la generator sa fie ignorate oprindu-se pe intrarile PIC-ului.

 

Nu este o problema daca PIC-ul intirzie iesire chiar si cu 100 ms fata de intrare insa out-ul trebuie sa fie identic cu in-ul ca forma si durata deoarece o eroare de 1/180 ms in lungimea pulsurilor inseamna deviatie de 1 grad a servomecanismului, acceptabila dar la limita. Citirea intrarilor cu 180 kHz urmata de scrierea iesirilor cu aceeasi frecventa ar rezolva problema insa un asemenea ritm de lucru incarca prea mult procesorul care mai are si altceva de facut. Ar mai fi si solutia cu intreruperi daca exista 5-6 pini de intrerupere disponibili insa amindoua solutiile mi se par complicate.

 

Ar mai exista varianta adaugarii linga PIC a unui multiplexor comandat de acesta care sa aiba la o intrare cele 5-6 semnale de la generator si la cealalta 5-6 semnale de la PWM-urile PIC-ului iar iesiriea sa fie conectata la grupul de 5-6 servomecanisme. Totusi, nu sunt sigur ca se justifica un asemenea circuit suplimentar.

[sofian]

Saluteu zic ca mai bine faci un multiplexor cu un PLD (xc9536)

[10vid]

Nu e o idee buna trecerea prin PIC a semnalelor, pentru ca e greu de evitat jitter-ul cauzat de software (mici variatii ale perioadelor, cauzate de nesincronizarea ceasului intern (si a instructiunilor) cu fronturile semnalele venite de la receptor).

 

Cea mai simpla metoda e probabil cea intalnita in calculatorul XZ Spectrum, unde ULA (unul din cele doua procesoare, celalalt fiind Z80), avea prioritate mai mare la adresarea memoriei, pentru ca se ocupa si cu trasarea pe ecran. Astfel, busul lui Z80 era legat la memorie prin niste rezistente, iar busul ULA pe direct. Cand ULA nu dorea acces la memorie, isi pastra iesirile high-Z, lasand pe Z80 sa adreseze. Cand ULA dorea acces, semnalul cu impedanta mai joasa evident castiga, adica cel al ULA, indiferent ce trimitea Z80, se oprea la intrarea in rezistente.

 

O alta metoda, mai eleganta ar fi folosirea unui latch tri-state 74HC373. Semnalele de la receptor intra pe intrarile latch-ului. PIC-ul controleaza iesirile latch-ului la pinul OE (output enable) al latch-ului.

Initial iesirile PIC-ului sunt high-Z iar ale latch-ului "strong". Cand PIC-ul doreste el sa trimita semnale, intai trimite 1 pe pinul OE, facand iesirile latch-ului transparente (high-Z), dupa care iesirile PIC-ului iau valori "strong".

Important e ca momentul de tranzitie sa fie high-Z la ambele cipuri, nicidecum "strong" la ambele cipuri.

[masterpic77]

Din cate am inteles de la "beamrider" se vrea ca doar forma semnalului de iesire sa fie indentica cu cea de la intrare iar deviatia maxima a pulsului de iesire de +/- 1/180ms = 5.55us ceea ce este se poate face si cu un PIC lucrand la 4MHz ; la 5.55us nu cred ca se pune problema de jitter. Lucrand cu PIC-ul la 4MHz (1us tact intern) eroarea maxima de citire a unui puls este de 2us ; desigur urcand frcventa la 40MHz eroarea scade de 10 ori...

[costi002]

sa fie vorba de un fail safe pentru barcute/avioane?

[10vid]

Lucrand cu PIC-ul la 4MHz (1us tact intern) eroarea maxima de citire a unui puls este de 2us ; desigur urcand frcventa la 40MHz eroarea scade de 10 ori...

La 4Mhz incertitudinea e de 4us, ca nu doar citeste, mai trebuie sa si scrie si sa sara inapoi in bucla.Iar daca mai are de facut si alte operatii, metoda pica complet.

[Vizitator beamrider]

PIC-ul acesta este necesar pentru un autopilot.

 

Exista un montaj foarte simplu (nu pe 5-6 canale) de asemenea autopilot cu PIC care se gaseste la adresa:

 

http://rcpilot.sourceforge.net/modules/rcap/index.php

 

Proiectul este open source si toata arhiva cu:

 

- schema electronica (vezi fisierul: rcap.zip\circuit\ap-ckt.jpg din rcap.zip dat mai jos)

- program pseudocod (rcap.zip\doc\Pseudo.doc)

- program scris in Basic (rcap.zip\src\main.bas)

 

se afla aici:

 

http://rcpilot.sourceforge.net/downloads/rcap.zip

 

Cineva care se pricepe la PIC-uri si la Basic-ul in care este scris programul ar putea spune cum implementeaza de fapt autorul trecerea semnalului de la receptor prin PIC catre iesire spre servomecanism. Atit in pseudocod cit si in codul Basic exista o subrutina numita "PassThru:" care tocmai de asta se ocupa.

[picolo]

Cea mai simpla metoda e probabil cea intalnita in calculatorul XZ Spectrum, unde ULA (unul din cele doua procesoare, celalalt fiind Z80)...

Tu esti constient ca acesta aberatie si continuarea pot sa fie chiar citite si crezute?Fara se vrei, ai dat dreptate lui sofian. Un PLD trebuie. (se numea altfel la XZ Spectrum. ghici cum)

[masterpic77]

"La 4Mhz incertitudinea e de 4us, ca nu doar citeste, mai trebuie sa si scrie si sa sara inapoi in bucla.Iar daca mai are de facut si alte operatii, metoda pica complet."PIC-ul trebuie numai sa citeasca in cazul de fata : "Am niste pulsuri de 1-2 ms care se repeta la 20 ms ...Nu este o problema daca PIC-ul intirzie iesire chiar si cu 100 ms fata de intrare " deci nu este nevoie ca in momentul in care ai "1" pe intrare sa pui "1" pe iesire si sa te intorci in bucla ; poti citi tot pulsul de 1-2 ms cu timer sau captura sau intrerupere pe edge , etc , dupa care poti sa generezi acelasi puls pe iesire;avantajul este ca scapi de "incertitudine" iar aceasta este fixa ( 2us salt in intrerupere + 1us start/stop timer =3us) si pe rising edge-ul semnalului de intrare si pe falling edge .

[cirip]

Salut,Merge cu PIC de rupe. Am facut asa ceva acum cativa ani cu un PIC12F683 si nu numai sa treaca semnalele de servo prin el. Am luat semnalul serial analogic scos de receptor, l-am facut digital cu comparatorul din pic, l-am despachetat, filtrat digital, protectie la erori si alte nazdravanii. Nu are nicio problema picul sa faca toate astea rulat cu oscilatorul intern de 4MHz. Initial il fugaream la 8, dar am constatat ca merge si la 4. Ca sa ai precizie tre sa folosesti input capture de la timer si o sa ai rezolutia de 1us/0.5us rulat la 4/8MHz. Asta inseamna minim 1000 de pasi pe cursa completa. Nu are servoul asa o rezolutie. Practic am constatat ca 128 de pasi sunt arhisuficienti. Daca servoul are cursa de 90 de grade, folosind 128 de pasi ai mai putin de 1 grad/pas.Chestia e ca, daca nu le ai cu programarea, tre' sa gasesti pe cineva sa-ti scrie si sa-ti testeze programul. Eu l-am facut in asamblare. Aici s-ar putea sa fie un spil. Nu stiu daca in BASIC ar merge. Depinde cat e de optimizat compilatorul. Si inca ceva: am folosit intreruperi la greu. Nu merge cu poling.Nu am timp sa te ajut, dar am intervenit ca sa-ti spun ca un pic poate sa faca fata cu brio la ce vrei tu. Bafta!Cirip

[Vizitator beamrider]

Merge cu PIC de rupe.

Multumesc pentru informatii si incurajari.

[Vizitator beamrider]

Exista in BASIC instructiunea PULSEIN,

a se vedea: http://www.picaxe.com/BASIC-Commands/Di ... ut/pulsin/

care citeste lungimea unui puls pe un pin de intrare cu rezolutie de microsecunde.

 

Este eviden ca pentru un singur canal de telecomanda o asemenea comanda este suficienta pentru a citi pulsurile de pe intrarea procesorului si in colaborare cu PULSEOUT a le transfera la iesire.

 

Totusi, nu imi este clar daca pot folosi PULSEIN pentru transferul mai multor canale spre iesirea PIC-ului.

 

Pot avea exprimari de genul:

 

pulsin C.3,1,w1

pulsin C.3,2,w2

pulsin C.3,3,w3

pulsin C.3,4,w4

 

mai ales in conditiile cind nu stiu care din cele 4 pulsuri vine primul?

[costi002]

poti sa dai u exemplu clar, cam ce ar trebui sa faca montajul tau?pe partea de RC eu am reusit fara probleme 2 chestii care mi se par apropiate de ale tale:1 . monitorizare semnal se iesea de pe un canal al receptorului, cel ce comanda motorul de ex.: atat timp cat exista semnal valid receptionat de receptor, scoate la fiecare iesire a receptorului cate un puls cu durata variabila. cand receptorul nu mai are semnal, pe iesirea canalelor vei avea 1 sau 0 logic. in acel moment, pic-ul incepe sa genereze semnale, prestabilite. caz concret: merge barca pe apa, pierde semnal, pic-ul vede si da comanda stop motor, sau carma stanga sa mearga in cerc, sau motor inapoi , sau ce vrei tu. 2. decodare semnal serial primit de la receptor. pic-ul identifica semnalele si comanda un motor cu pwm prin punte H, deci cu revers, comanda 2 cuve si lumini.Toate astea cu doar 8 MHZ.Deci se poate, numai spune concret ce vei sa faca cand e semnal bun si cand nu mai exista semnal receptionat.Trebuie sa ai in vedere faptul ca la iesirile receptorului semnalele nu apar toate odata ci pe rand. Intre 2 canale ai cam 1.5 ms, intre 2 trenuri de semnal ai cam 20ms, timp suficient sa procesez iinformatia

[Vizitator beamrider]

Caz concret simplificat:

 

Navomodel dotat cu receptor avind doua canale, unul destinat servomecanismului care actioneaza cirma, celalalt pentru comanda turatie motor.

 

Atita vreme cit emitatorul este pornit, si asta chiar in conditiile cind eu nu dau nici o comanda, microcontrollerul de pe barca trebuie sa fie transparent ca si cum nu ar exista. Eu, de pe mal, controlez barca.

 

In momentul cind am inchis emitatorul, procesorul PIC seteaza cirma pe pozitia drept inainte si motorul in starea turat la maxim, adica navomodelul porneste cu toata viteza, tangent la curba pe care mergea inainte de disparitia semnalului radio.

 

Cind pornesc din nou emisia de la statie, microcontrollerul trebuie sa devina iar transparent ca la inceput.

 

Acesta este doar un exemplu.

 

Ceea ce ma intereseaza in mod deosebit, pentru moment, este nu ce se va petrece cu barca dupa pierderea semnalului si cum va actiona microcontrolerul ci cum fac ca acest PIC sa fie transparent la cit mai multe canale (semnale) ce vin de la receptor, atita vreme cit emitatorul este pornit.

[cirip]

In momentul cind am inchis emitatorul, procesorul PIC seteaza cirma pe pozitia drept inainte si motorul in starea turat la maxim, adica navomodelul porneste cu toata viteza, tangent la curba pe care mergea inainte de disparitia semnalului radio.

O fi bine asa? Si daca modelul e orientat in sensul indepartarii de mal?

 

Ceea ce ma intereseaza in mod deosebit, pentru moment, este nu ce se va petrece cu barca dupa pierderea semnalului si cum va actiona microcontrolerul ci cum fac ca acest PIC sa fie transparent la cit mai multe canale (semnale) ce vin de la receptor, atita vreme cit emitatorul este pornit.

Cred ca ceea ce doresti se cheama "failsafe". Am avut asa ceva facut, care mi-a adus avionasul la sol in cercuri largi. Imi sarisera bateriile din emitator Am postat povestea pe frumul de modelism.

E posibil sa gasesti gata facut. Da o cautare cu ceva de genul "RC failsafe". Chestia e ca e multa munca la realizare si nu sunt convins ca se poate in basic. Ar trebui sa pornesti simultan mai multe rutine de masura. In asembler asta se face prin alocare de intreruperi si folosirea resurselor hardware de genul capture/compare.

 

In orice caz, bafta!

Cirip