To mi się zagwozdka przytrafiła na Atmega168 16Mhz i C...

Robię nowy projekt i podczas zmian potencjometrami działy mi się dziwne rzeczy. Kiedy zacząłem bezpośrednio monitorować ADC szczena mi opadła i nie mam już pomysłu co przeoczyłem. Otóż przy zmianie wartości od 0 do 1023 następuje przeskok z około 445 na 700 gdy zwiększam od 0 do 1023, natomiast gdy zmniejszam od 1023 do 0 to przeskok następuje z około 450 na 195. Zawsze w tych samych miejscach. Wychodzi na to, że gubione jest po drodze 255 jednostek (jakby brak odczytu rejestru) Dzieje się to na każdym kanale który sprawdzałem czyli ADC4 i ADC5. Oczywiście zasilanie, filtracja, itp. jest ok - mam już troszkę doświadczenia w tej kwestii
Żeby nie było, że nie próbowałem to:
1. W bascom napisałem na szybko kontrolę wejść - wszystko działa idealnie(!)
2. Zrobiłem kilka różnych algorytmów odczytu, zarówno nieblokujących pętli jaki i oczekujących na wynik
3. Testowałem też opcję zamiast ADCW -> ADCH*256+ADCL - wynik identyczny (czyli zły)

Zgupłem już
Inicjalizuję tak:

a sprawdzałem tymi funkcjami (oczywiście w danej chwili jedną pozostałe zakomentowane):

Odczyt następował zaraz po pierwszym while(1) więc program główny wyników nie modyfikował.
Dodam tylko, że Timer1 jest jeszcze ustawiony w tryb CTC na przerwania 100us i tu się zastanawiam czy tu właśnie nie ma zgrzytu, chociaż robiłem już w C programy z takimi ustawieniami tyle, że zegar 8Mhz i Attiny44 i nic się nie działo. Nie sprawdzałem tylko przepisywania w przerwaniu od ADC, ale takiego rozwiązania chcę uniknąć.
I co Wy na to?

------------------------ [ Dodano po: 37 minutach ]

Pochodził układ trochę i próg się przesunął -teraz skacze z około 510 na 730, a z powrotem z 530 na 255... Czyżby jednak przerwania przeszkadzały ???

_________________
http://www.sylwekkuna.com

Ja też trzy razy czytałem i zawsze inne dane. Zmień nazwy funkcji chociaż o jotę.
W DS będzie, może coś pisało o błędach pomiaru ADC(ofset, liniowość,...)?

A spróbuj z innym potencjometrem, może to on jest winowajcą.

Potencjometry i wejścia ADC są w pełni sprawne co zaznaczyłem pisząc o teście w bascom. Moim zdaniem przerwania śmiecą i pewnie będę też musiał użyć przerwań od adc do przepisania wyniku... Mówi się trudno. Sprawdzę to później bo teraz piszę z tabletu i nie mam gratów przy sobie. Dziwne jest tylko, że przy tym attiny i identycznym czasie przerwań 10kHz wszystko z ADC jest ok.

_________________
http://www.sylwekkuna.com

Kolego SylwekK moim skromnym zdaniem to jest chyba jakoś tak, że algorytm programu może być walnięty, a dokładnie w tym momencie gdy następuje przeskok, coś musi siedzieć w pamięci programu (jakieś zmienne, rozkazy powrotu do instrukcji?) i dzieje się taka sytuacja, że z jednej strony masz w ADC liczbę 444/445, ale gdzieś z "drugiej" strony władowało się 255/256 i w kolejnym kroku następuje: przeskok + pamięć jest w jakiś dziwny sposób uwalniana i dalej licznik nalicza już dobrze.
Ja bym to obejrzał w trybie pracy krokowej w debugerze w momencie gdy zmienna od ADC przyjmuje wartość 444/445. Assembler zdaje się znasz.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

PROBLEM ROZWIĄZANY

Przysiadłem dziś na świeżo do programu po małej przerwie i znalazłem winowajcę
Powiedziałbym, że to bardzo paskudny i niepozorny robak. Otóż moje przypuszczenia dotyczące przerwań się potwierdziły tylko wcześniej szukałem nie tam gdzie potrzeba. Jakimś cudem pominąłem przy analizie obsługi przerwań linię:

ukrytą w sieci warunków, która co widać jak na dłoni modyfikuje w locie port C, na którym są właśnie wejścia analogowe, a ja go wykorzystuję jeszcze w innych celach.
Po prostu w pewnym momencie zapamiętany jest jego stan (PINC), aby po chwili zaktualizować cały PORT odczytaną tuż wcześniej wartością (mowa o 4-ech starszych bitach).
Teraz muszę tylko wykombinować jak ominąć tą sytuację. Być może właśnie odczyt adc w przerwaniu załatwi sprawę, bo zrobi to za jednym zamachem zaraz po przerwaniach timera. Już pomijam nawet fakt, że chciałem takiego odczytu uniknąć, ale przynajmniej dzięki analizie kodu wiem co było przyczyną, a gdybym od razu zrobił taki odczyt i jeśli okaże się wszystko ok to czułbym niedosyt, że problem niby ominięty, ale przyczyna nadal nieznana, a to jest to sytuacja jak dla mnie niedopuszczalna

------------------------ [ Dodano po: 33 minutach ]

Z ostatniej chwili... odczyt adc w przerwaniach niestety nie pomaga na tą dolegliwość w tym przypadku. Pozostaje pokombinować z innym algorytmem.

_________________
http://www.sylwekkuna.com

W związku powyższym mam pytanie do znawców asemblera (ja niestety bardzo dawno go nie używałem) czy użycie asemblerowych SBI, CBI wpływa TYLKO na konkretny bit portu czy też jakoś wewnętrznie czytany jest cały rejestr, bo tu widzę najprostsze rozwiązanie konfliktu adc i pozostałych bitów portu.
I z tego co kojarzę w tych poleceniach podaje się port i wagę bitu do ustawienia czyli np. 1,2,4,8,itd. czy można też ich sumować, np. wartość 3 (zapalone 1 i 2), 7 (1+2+4)... jeśli od razu ma być kilka zapalonych/zgaszonych, czy się mylę ?

_________________
http://www.sylwekkuna.com

Ta atmega ma rejestr DIDR0, którym możesz wyłączyć funkcje cyfrowe dla pinów używanych przez ADC.

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

@xor, rewelacja! DZIĘKI, leci pomógł.
Trzeba jednak czytać PDF do końca, bo nawet nie przypuszczałem, że jest taka opcja

Dodanie tej linijki rozwiązało całkowicie problem:



I tak to znalezienie przyczyny pozwala jednym szukać tam gdzie inni nawet nie zaglądają
Rada dla potomnych - połowiczne obejście problemu to nie jego rozwiązanie. ZAWSZE należy szukać przyczyny czego jestem namacalnym dowodem


PS. Pytania o SBI i CBI nadal aktualne... mam już pomysły jak to wykorzystać w przyszłości

_________________
http://www.sylwekkuna.com

tylko na jeden bit

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No akurat w tym jest, ale w m8 nie ma. Ale nawet w tym przypadku nie sądzę, żeby babranie się w asemblerze było konieczne. Wystarczy odpowiednio zamaskować przypisanie do portu. Np. ustawiamy piny używane przez ADC jako wyjście w stanie HIGH, wtedy:

albo jak kto woli stan LOW to:


Co do SBI/CBI: ustawiają/kasują tylko i wyłącznie jeden bit na raz.

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Tak, mi się wydawało z tymi pojedynczymi bitami, bo nawet nielogiczne by było gdyby jeszcze jakieś operacje były wykonywane, a to w sumie chyba 2 cykle jak pamiętam.

To maskowanie, bez wyłączenia wewnętrznego nie jestem pewnien czy by zdało egzamin, ale sprawdzę w wolnej chwili, bo teraz muszę kończyć program na wczoraj... Miałem małe opóźnienie w związku z adc

_________________
http://www.sylwekkuna.com

Witam,
Mam problem z moim ADC. Zawsze wszystko działało elegancko, teraz zmieniłem zasilanie referencyjne na 2,5 V ( przedtem 5 V ) Czyta tak wszystko jak przedtem tylko np. jak jestem podłączony na jakimś porcie (obojętnie jakim) to nagle z 1024 impulsów robi się 0. Albo zresetuje mi cały program. Działam na atmega128. Może ktoś ma pomysł dlaczego tak może się dziać. Z góry dzięki za pomoc

Panie, Panie - forum jest po to żeby ZAKŁADAĆ NOWE WĄTKI z NOWYMI pytaniami a nie doklejać się na oślep gdzie popadnie do innego wątku no toż to jest bez sensu - przepraszam

Więc załóż nowy wątek

a tam porządnie opisz problem bo z tego opisu to chyba tylko wróżka ci pomoże

pokaż że jakiś swój kod źródłowy, schemat i jakąś fotkę jak to masz podłączone

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Moim problemem było to że brakowało mi pamięci ram i program się zawieszał. Musiałem zrezygnować z jednego czujnika pod ADC żeby zaoszczędzić trochę miejsca.

P.s następnym razem będę się stosował do Pana zaleceń odnośnie pisania postów:)