[AT90S2313] AT90S2313 Bascom: Błędny odczyt RC5, adres 255 i kod 127, jak poprawić?

Stawiam pierwsze kroki z mikrokontrolerami i mam małe pytanko.

RC5 odbieram w przerwaniu i wszystko prawie działa tylko co któryś raz, a czasami kilka razy pod rząd ( w sumie to wychodzi ok 50% przypadków ), mam odczyt adresu 255 i kod 127.
Jak celuję pilotem gdzieś w ścianę, to taki odczyt jest o wiele częściej, więc chodzi prawdopodobnie o to, że sygnał dociera zakłócony. Przy celowaniu w odbiornik powinno już chyba być ok, a nie jest.

Jako odbiornik mam TSOP 1136 podłączony prawie jak w nocie katalogowej.
Tzn:
zasilanie z 5V przez 100 ohm
między VCC a GND 4,7 uF
OUT do VCC podciągnięty przez 5.6 kohm


Co może być przyczyną? Czy tak ma być?

No w końcu ktoś początkujący kto zajrzał do noty PDF i chyba prawidłowo zrobił zasilanie i odkłócanie sprzętowe (rezystor 100R plus kondek). Tylko jedno pytanie dla sprostowania - mam nadzieję, że ten kondensator 4,7uF dałeś nie do VCC przed rezystorem 100R a za nim - czyli bezpośrednio do nóżki zasilania odbiornika TSOP ????? - jeśli odwrotnie to popraw to ok?
Bo na prawdę - jest to jeden z podstawowych sposobów pozbycia się sporej ilości zakłóceń.

Mam też dla ciebie niedobrą wiadomość, bo ja osobiście już nigdy nie korzystam z odbiorników TSOP - one przynajmniej wg moich wielu wielu porównań są dużo gorsze pod względem filtrowania pozostałych zakłóceń niż odbiorniki seroo TFMSxxxx - więc na jakąś tam przyszłoś szczerze polecam kupowanie tej serii TFMS poważnie

kolejna rzecz - to masz MEGA BABOLA w kodzie. Wywal ty żesz to wyświetlanie na LCD z procedury obsługi przerwania. I nigdy ale to nigdy nie wciskaj wyświetlania czegokolwiek na LCD do procedur obsługi jakichkolwiek przerwań bo sam sobie robisz masakrę ..... poczytaj sobie o zastosowaniu flag - a nawet na tym forum jest wiele razy prezentowany także mój kod obsługi IR w przerwaniu z użyciem flagi właśnie puszukaj troszkę tego

Po kolejne - po co zaremowałeś If Address <> 255 then ????

w takim przypadku sam się prosisz o błędne odczyty - po to się go robi żeby w kolejny już programowy sposób odfiltrować innego rodzaju zakłócenia - m.inn pochodzące z odbić.

W zasadzie to powinieneś wiedzieć jaki Adres wysyła twój pilot - bo adres nigdy się nie zmienia w danym pilocie i ten warunek powinien byc taki dla pilota TV gdzie adres jest równy ZERO

If Address = 0 then

wtedy eliminujesz całą kolejną serię zakłóceń - można powiedzieć, że te sposoby to jest już jakby filtrowanie fyfrowe zakłóceń rozumiesz?

.... i poczytaj sobie o zastosowaniu flag w przerwaniach oraz dlaczego kod przerwań musi być bardzo krótki i b.szybko się wykonywać - bo inaczej długo nie zaczniesz dobrze programować procków ok?

Kondensator jest oczywiście przy nóżkach TSOP.
Wiem już że w przerwaniu powinno być tylko co niezbędne, a obsługę lcd w przerwaniu zrobiłem na szybkiego, żeby zliczać przerwania podczas prób (nie byłem pewien czy program nie zawieszał się w przerwaniu, ale przyczyna pozornej zwiechy była inna ).

Mój pilot wysyła adres 1, ale dla kontroli co się dzieje i nauki chcę mieć pokazane na wyświetlaczu wszystko co odbiera.
Teraz mam tak:
Odebrany adres na wyświetlaczu jest zawsze "1" a kod co któryś raz "255".
Z mojego rozumowania w tej chwili ( a może być lekko " zakrzywione " bo szwagier miał urodziny i bez alkoholu się nie obeszło ), powodem mogło by być to, że jeśli przerwanie wystąpi w momencie między wyświetleniem na lcd prawidłowego adresu, a wyświetleniem kodu... i w tym przerwaniu wystąpi błąd wynikający z odbić czy innych przyczyn to w zmiennych będzie "255". Tylko na mój chłopski rozum co jakiś czas adres też powinien pojawiać się jako "255" w momencie kiedy przerwanie wystąpiło by po:...a na adres 255 nie mogę jakoś trafić.

Za ok pół godz szwagier ma podejść ze swoim pilotem od DVD Philipsa i zobaczę czy na jego pilocie będzie ta sama sytuacja bo przestaję wierzyć swojemu pilotowi.

No teraz wprowadziłeś flagi w przerwaniu, brawo .... w takim przypadku nigdy nie powinien ci się pojawić Command = 255 bo przecież masz warunek:



więc flaga Odb jest tylko ustawiana wtedy gdy Command <> 255

Tak dla porządku jak już tak działasz ładnie z flagą Odb czy Przer to powinieneś je wyzerować przed wejsciem do pętli głównej a nie ustawić a masz



tuż przed pętlą Do Loop i choćby z tego powodu przy starcie procka może w pierwszym przebiegu pętli a przed odbiorem IR nastąpić wejście w tego If'a i wyświetlenie wartości Command=255

mirek36 ale ta flaga odb jest zerowana w pierwszym przebiegu pętli.
Jest tylko po to żeby wyświetlić początkowy tekst na wyświetlaczu z adresem i kodem = 0.

A mi się wydaje że pomimo warunku jeśli 2-gie przerwanie wystąpi na początku pętli ( getrc5 odczyta błędy kod ), a flaga "odb" będzie ustawiona z poprzedniego przerwania to może wystąpić w/w sytuacja. Ale dlaczego tylko kod jest 255 a adres nigdy?

Co o tym myślisz?

Spróbuj zastosować kondensator 100µF. Swego czasu gdy bawiłem się RC5 to pięknie to działało . Oczywiście kod popraw.

Ni hula. Tzn 100uF nic nie zmienia.
Wiem że jestem upierdliwy i wiem że do "normalnego działania " pilota nie jest to potrzebne, chciał bym tylko żeby ktoś potwierdził lub obalił mój tok rozumowania co do w/w sytuacji, a właściwie czy dobrze próbuję rozumować i jeśli dobrze to czemu adres jest poprawny zawsze?

No to dlatego ja bym to przerwanie napisał na twoim miejscu tak:



tyle że sam widzisz, że koniecznie przed wejściem w pętlę główną trzeba na początku ustawić Odb na ZERO a nie na JEDEN jak masz wyżej w tym kodzie (wspominałem już wyżej o tym)

Spróbuj się domyśleć co ci da ten dodatkowy warunek w przerwaniu

Tak oczywiście działa dobrze.
Ten warunek nie pozwoli na ponowny odczyt rc5 jeśli nie wyświetlą się odczytane wartości z poprzedniego odczytu i "odb" nie zostanie wyzerowany.

Ale uprę się ( mam nadzieję że się nie obrazisz ) że ustawienie "odb" przed pętlą nic nie zmienia i dalej nie rozumiem dlaczego we wcześniejszej wersji tylko kod był czasami błędny, ale może jestem za bardzo dociekliwy.

Wielkie dzięki za pomoc i poświęcony czas.

Żbik napisał:

Ale uprę się ( mam nadzieję że się nie obrazisz ) że ustawienie "odb" przed pętlą nic nie zmienia i dalej nie rozumiem dlaczego we wcześniejszej wersji tylko kod był czasami błędny, ale może jestem za bardzo dociekliwy.

Wielkie dzięki za pomoc i poświęcony czas.

Ależ dlaczego miałbym się obrażać ? wręcz przeciwnie to po prostu zażarta dyskusja i chęć dojścia do ostatecznej "prawdy" przez cieie ... tylko pogratulować takiego uporu

Ja jednak powiem jeszcze raz, że jeśli ustawiasz Odb przed pętlą główną a nie naciśniesz żadnego klawisza na pilocie - to czyż nie wyświetlą ci się niepotrzebnie jakieś dziwne wartości Command i Address za pierwszym razem przy wejściu programu w tę pętlę główną???

No zobacz - masz ustawiony Odb
(nie naciskasz w ogóle pilota)
program wchodzi pierwszy raz w pętlę główną
natrafia na warunek If Odb = 1 Then i jest on spełniony PRAWDA? pomimo to, że nie wcisnąłeś żadnego klawisza pilota - a tylko w takiej sytuacji powinien się wykonać kod zawarty w tym warunku.

oczywiście dalej już wszystko idzie dobrze - bo Odb w pod koniec tego warunku jest resetowane. Czy dostrzegasz ten niuans ?

A to dlaczego we wcześniejszej wersji pokazywał ci się dziwny kod 255 było spowodowane właśnie tym, że przerwanie RC5 występowało np po wystąpieniu rozkazu CLS. Więc pętla główna była już w tym warunku, tymczasem nadleciała jakaś błędna ramka i polecenie Getrc5 ustawiło np Command na 255. Jednak flaga Odb nie została ustawiona ponieważ nie spełnił się warunek ten w przerwaniu. To co z tego - skoro przerwanie idąc dalej kończy się, a program główny wraca do realizacji kolejnego rozkazu po CLS .... dochodzi do wyświetlenia Address i Command no i Command wyświetla się jako 255. Poza tym do takiej sytuacji dochodziło ci chyba tylko wtedy jeśli dłuższy czas trzymałeś wciśnięty klawisz pilota.

Oczywiście masz rację.
Ale błędny odczyt, czyli inny niż "0" podczas pierwszego przebiegu, pojawi się tylko wtedy gdy po resecie uC, TSOP coś odbierze w ciągu części ms, w czasie gdy porty i przerwania będą już skonfigurowane a przed , czy na samym początku pętli. Według mnie można taki przypadek pominąć.

Co do 255 to dlaczego jeśli przerwanie wystąpiło po CLS adres był prawidłowy?
Jest możliwe że getrc5 odbierze w połowie błędną ramkę?

I nie występowało to tylko przy długim "trzymaniu" pilota ale też przy pojedyńczych naciśnięciach, po to zrobiłem licznik przerwań, żeby mieć pewność że nacisnąłem przycisk pilota tylko raz.

To, że ramka może być uszkodzona to nie dziwne. Zobacz zresztą taki efekt.

Wystarczy że zrobisz układ, który już normalnie działa z tymi wszystkimi poprawnymi warunkami itp i spróbuj strzelać pilotem a to w ścianę a to przez jakąś przeszkodę jednocześnie ruszając ręką - zobaczysz że czasem wskoczą ci inne - tzn różne kody - pomimo to, że cały czas trzymasz wciśnięty ten sam jeden klawisz. Ja robiłem takie próby na własny użytek i to sporo bo transmisja w podczerwieni to mój konik - okazuje się, że procedury w Bascomie choć rzadko pozwolą jednak raz na jakiś czas przedostać się innej wartości Command. Natomiast Address w takich przypadkach chyba albo prawie nigdy mi się nie zmieniał.

Dlatego jak zacząłem programować w C - i sam zacząłem robić sobie procedury obsługi kodów najróżniejszych pilotów i standardów to z uporem podobny do twojego - zaparłem się tak - żeby zrobić jak najlepsze filtry błędnych ramek w swoich procedurach. I nie chwaląc się ale udało mi się uzyskać zdecydowanie lepsze parametry jeśli chodzi o to że u mnie w zasadzie albo nie pojawi się żaden kod albo tylko prawidłowy! i to obojętnie dla jakiego standardu kodowania - nie tylko RC5. Poza tym - moje procedurki działają bardziej płynnie - i co najważniejsze bez NAJMNIEJSZYCH opóźnień

No to wychodzi na to, że winnym całego zamieszania jest trochę niedopracowany getrc5.

Jak skończę lekturę "Mikrokontrolery dla początkujących", przerobię jeszcze coś o Bascomie już dla troszkę bardziej obeznanych, to wtedy przyjdzie czas na C
Jak na razie to "za wysokie progi, na moje nogi"...

Jeszcze raz dzięki i
Pozdrawiam.

Żbik napisał:

No to wychodzi na to, że winnym całego zamieszania jest trochę niedopracowany getrc5.
.

No nie, jednak z takim stwierdzeniem to bym się nie zgodził absolutnie. To, że czasem przy zakłóceniach szczególnie przy niewprawnie napisanym kodzie w Bascomie - pojawią się jakieś błędy raz na milion - to nie oznacza, że Bascom jest Be .... ja uważam, że Bascom ma bardzo fajnie dopracowane wszystkie swoje procedury. Są łatwe w użyciu i jak mówię jak się dobrze napisze program co sam widzisz - to nie masz żadnych błędów. Więc nie za szybko z tak pohopnymi wnioskami proszę

Bascoma jak najbardziej doceniam, bo pozwala takiemu amatorowi jak np. ja, po miesiącu nauki zrobić coś pożytecznego. Dodałem parę linijek kodu i mam sterowanie jasnością i wł/wył diody. Zmienię tego AT na Attiny2313 i mam już 4 pwm do wykorzystania.
Po prostu luksus.

A getrc5.. przydało by się że jak nie odczyta poprawnie kodu, to i adres zwracał by błędny. Choć można to wykorzystać, jeśli program ma reagować na danego pilota bez odczytu wciśniętego guzika ( wtedy częściej odczyt jest ok. ).

I u mnie kod 255 przy poprawnym adresie był tak na oko co 5 może 10 raz, a nie co milionowy, ale to może ten TSOP. Następnym razem kupię TFMS.

Pzdr.

Żbik napisał:

I u mnie kod 255 przy poprawnym adresie był tak na oko co 5 może 10 raz, a nie co milionowy, ale to może ten TSOP. Następnym razem kupię TFMS.

No to wtedy poczujesz różnicę tak jak przy zmianie opon letnich na zimowe - zapewniam. A jeśli się u ciebie działo to co 5 czy 10 raz - przy celowaniu wprost na odbiornik - to znaczy że działo się jeszcze coś nienormalnego . Tak mi się wydaje. Bo ja nie potwierdziłbym u siebie takich sytuacji . Musiałem się sporo starać, żeby złapać jakiś dziwny command czy adres nawet przy odbiciach i przeszkodach gdy jeszcze działałem w Bascomie ale na pewno nie tak często.

No ale najważniejsze że dzięki Bascomowi można bez większych stresów zacząć to fajne hobby , później, kiedyś w miarę potrzeb na pewno sam sięgniesz jeszcze po jakiś język programowania - tak to już bywa.