cirip Postat Septembrie 24, 2011 Partajează Postat Septembrie 24, 2011 @francezu Ai dreptate. Nu am fost atent. Link spre comentariu
pegas Postat Septembrie 24, 2011 Autor Partajează Postat Septembrie 24, 2011 @10vid: eu zic ca nu se pacaleste... verifica0mi codul cu atentie@francezu: corect, dar... de unde sa citeasca alt front decat cel de start? programul acum numai asta face. si il resetez inainte de masuratori.@Liviu M: stiu acel site, l-am studiat destul de mult, insa nu am vrut sa iau codul de acolo si nu am inteles acea masina de stari descrisa de autor...si de aia am vrut sa imi scriu propriul cod.oricum,am sa mai revin, pentru ca e ceva dubios... e normal ca facand "1-0", STATUS sa arate "xxxxxxx1"? ce imi scapa? Link spre comentariu
Liviu M Postat Septembrie 24, 2011 Partajează Postat Septembrie 24, 2011 Eu nu prea am habar de assembler, asa ca intrebarea e probabil aiurea.Carry (bitul 0 din STATUS) e facut 0 automat la operatia "1-0"? Ca daca nu, carry poate ramane 1 de la operatiile de shiftare (poate trebuie sa-l faci 0 de mana dupa shift). Link spre comentariu
10vid Postat Septembrie 24, 2011 Partajează Postat Septembrie 24, 2011 @pegas, ai dreptate, n-am fost atent la valoarea delay-ului ala, am crezut ca e mult mai scurt si se merge cu pasi foarte marunti intre citiri, ca sa se vada cand se termina un bit. Acum vad ca delay-ul are exact 889us, adica jumatate din durata alocata unui bit. Totul pare OK. Ramane bineinteles problema cu sincronizarea. Si asta pentru ca desi valoarea delay-ului e exacta, trebuie luata in considerare si durata executiei celor cateva instructiuni ce au loc intre doua citiri (overhead). Deci delay-ul efectiv e putin mai mare. Daca citirea pica foarte aproape in spatele unei schimbari de nivel, pe parcursul trenului de impulsuri e posibil ca un "vagon" sa fie sarit. Cel mai bine cu a spus Liviu M, cu intreruperi de schimbare de nivel, sau cu un loop foarte strans la bitii de start pentru detectarea frontului. @Liviu M, orice instructiune care modifica un bit de stare, scrie intotdeauna in acel bit, indiferent de rezultatul operatiei. Daca sa zicem bitul C a fost 0, si o instructiune add a facut 1+2, va scrie si ea 0 in C. Deci se scrie intotdeauna in acei biti, nu se "lasa". De aceea nu are importanta ce a fost mai in spatele ultimei instructiuni ce modifica acel bit. Link spre comentariu
Liviu M Postat Septembrie 24, 2011 Partajează Postat Septembrie 24, 2011 @Liviu M, orice instructiune care modifica un bit de stare, scrie intotdeauna in acel bitMultumesc de lamurire. M-am uitat putin prin helpul de la mpasm inainte sa postez, da' nu am reusit sa ma prind cum e. Link spre comentariu
francezu Postat Septembrie 24, 2011 Partajează Postat Septembrie 24, 2011 @francezu: corect, dar... de unde sa citeasca alt front decat cel de start? programul acum numai asta face. si il resetez inainte de masuratori.Exemplu: ceva iti obtureaza calea dintre led-ul IR de la telecomanda si receptor. Restabilirea caii optice poate sa survina in mijlocul unei transmisii, si nu intr-o pauza chiar inainte de bitii de start. De aici totul este desincronizat, daca nu iei in considerare bitii de start, ci doar ii numeri, si posibil sa fie "trecuti" ca biti din adresa/comanda. Din cate am vazut codul tau asteapta o tranzitie un timp nedefinit; daca ai prins sfarsitul unei transmisii ( nu toti bitii din cuvant), atunci la urmatoarea transmisie vei deplasa in registru si bitii de start ( total gresit).Precum exemplul de mai sus, pot fi multe alte cauze pentru care receptia se va desincroniza; bitii de start nu au fost implementati degeaba. Link spre comentariu
25L91N11 Postat Septembrie 24, 2011 Partajează Postat Septembrie 24, 2011 Salut, vezi mai jos un alt proiect asemanator cu cel in discutie. Poate ca nu este ce vrei tu insa este posibil sa te ajute explicatiile. Google translate: http://translate.googleusercontent.com/ ... MAtWJR7AiQ http://www.ucontrol.com.ar/forosmf/proy ... y-control/ Succes. Link spre comentariu
XAN77 Postat Septembrie 25, 2011 Partajează Postat Septembrie 25, 2011 am decodat si eu dupa informatiile de pe sb-projects atat RC5 cat si jvc, nec, sony chiar si x-sat pentru un prieten. Metoda mea era cam aiuristica dar functiona corect odata sincronizata perfect. Detectam startul si apoi cu un delay "plonjam" direct in mijlocul primului bit (a doua jumatate adica, unde e bitul propriu-zis), dupa care cu delayuri de 1770 ajungeam mereu in mijlocul urmatorului bit. Ce vreau eu e sa-ti propun o metoda de a verifica ca controlerul tau face ceea ce te astepti tu, asa cum am verificat eu la vremea respectiva ca sincronizam bine citirile. Modifica in soft si la fiecare citire a bitilor utili scoate un puls pe un pin auxiliar din controler. Conecteaza la placa audio pe LineIN semnalul respecitv pe un canal si pe celalalt canal (doar e stereo) semnalul de iesire din TSOP. Vei inregistra cu ce soft crezi tu ca e potrivit si vei vedea exact cum arata codul si unde anume faci tu citirile. Nu e ceva complicat, iti ia 2 minute sa faci conexiunile pentru experiment. Poti lega printr-un potentiometru stereo pentru coborarea semnalului, eu personal am pus direct, regland din mixerul windowsului, nu s-a inecat placa audio. Eu de exemplu am descoperit atunci ca aveam aiurea primul delay, cel cu care saream peste bitii de start+cei 6 ce privesc aparatul vizat; ulterior citirea facandu-se mereu aiurea. Numerele alea 889, 1778 etc nu sunt prea precise, telecomenzile nu prea le respecta. LE am gasit in PC un save de la telecomanda cu cod x-sat capturat din programul audacity. Asta ca sa-ti faci idee cum se captureaza prin placa de sunet. Duratele pulsurilor le afli foarte usor din softul respectiv, are atat o rigla cat si indicarea separata a portiunii selectate. Link spre comentariu
Postări Recomandate
Creează un cont sau autentifică-te pentru a adăuga comentariu
Trebuie să fi un membru pentru a putea lăsa un comentariu.
Creează un cont
Înregistrează-te pentru un nou cont în comunitatea nostră. Este simplu!
Înregistrează un nou contAutentificare
Ai deja un cont? Autentifică-te aici.
Autentifică-te acum