Problem z AVRdude przy małej prędkości taktowania ATmegi.

[Ertew]

Kupiłem procek ATmega169, który posiada sterownik wyświetlacza LCD. Celem jest naprawa uszkodzonego zegarka (z budzikiem, oraz ładnym wyświetlaczem LCD, bez sterownika) poprzez wsadzenie innego procesora (co da także dodatkowe możliwości przyszłej rozbudowy). Jak na zegarek bateryjny przystało, ten także powinien pobierać możliwie mało prądu, jednak z pewnych względów odpada użycie popularnych LCD ze zintegrowanym kontrolerem.
Program piszę w WinAVR z kursu C, więc chciałem użyć dołączonego programatora AVRdude. Programator szeregowy to wtyczka do portu LPT i kilka kabli. W fazie testów układ działa, choć oprogramowanie nie jest jeszcze gotowe.

Procesor chodził na wbudowanym oscylatorze RC 8Mhz. Używając programatora wbudowanego w BascomAVR przestawiłem Fusy procka na kwarc 32Khz i kontakt z nim się urwał . Bascom dogadał się z prockiem po zwiększeniu opóźnienia w opcjach programatora, jednak AVRdude nie mógł się połączyć aż nie nie przywróciłem taktowania z wewnętrznego oscylatora RC.

Po kilku testach stwierdziłem, że lepiej będzie użyć oscylatora RC i dzielnika częstotliwości do taktowania procesora, a czas liczyć Timerem2 taktowanym kwarcem 32Khz (dedykowany dla RTC). Tym razem użyłem możliwości spowolnienia pracy procesora i redukcji zużycia energii poprzez włączenie dzielnika częstotliwości w rejestrze CLKPR. Zaraz po starcie procesor miał wpisać tam wartość 0x80 w celu uaktywnienia dzielnika, a następnie 0x07 w celu wybrania wartości podziału. Niestety znowu straciłem możliwość programowania przy pomocy AVRdude .

Poprzedni przypadek mogę zrozumieć, ale tym razem nie mam pojęcia o co chodzi.
Wyczyszczenie pamięci procesora w programatorze Bascom umożliwiło ponowne zaprogramowanie z AVRdude, niestety tylko jednokrotne, a przed kolejnym należało znowu wyczyścić pamięć w Bascomie, bo inaczej AVRdude nie widział procka .
Przecież w czasie resetu procesor powinien sam załadować do rejestru dzielnika odpowiednią wartość (0x00 dla braku podziału, lub 0x03 przy ustawieniu dzielenia przez 8 w FuseBitach).

Czy umie ktoś to wyjaśnić?

Sensownym rozwiązaniem problemu jest użycie wyższej częstotliwości taktowania (mniejszy dzielnik), wykorzystanie trybów oszczędzania energii oraz wybudzanie procesora przerwaniem Timera2 kilka razy na sekundę.
Czy może zna ktoś lepsze rozwiązanie tego problemu?
Przecież chciałem tylko sprawdzić, na ile mogę obniżyć pobór prądu, wyszło 1mA przy 3V, taktowaniu 63Khz i aktywnym kontrolerze LCD.

[Pikczu]

Witam nie mam pojecia jak w tym programatorze ale w moim avr isp mkII jak również w stk 500 jest możliwość ustawienia częstotliwości tzw ISP frequency ta częstotliwość powinna być 4 razy mniejsza niż kwarc w procku. Może to Cię na kieruje.

[alaris]

Chyba mialem podobny problem, wlasnie z AVRdude.

Może to Cię na kieruje.

Z ciekawosci zajrzalem do dokumentacji avrdude i rzeczywiscie jest cos na ten temat:

Kod: Zaznacz cały

-i delay - For bitbang-type programmers, delay for approximately delay microseconds between each bit state change. If the host system is very fast, or the target runs off a slow clock (like a 32 kHz crystal, or the 128 kHz internal RC oscillator), this
can become necessary to satisfy the requirement that the ISP clock frequency
must not be higher than 1/4 of the CPU clock frequency. (...)

[Pikczu]

To się nazywa praca zespołowa
Pozdrawiam

[Ertew]

Bardzo dziękuje za pomoc w rozwiązaniu podstawowego problemu.

Miałem AVRdude w wersji 4.4 (ta dostępna razem z WinAVR 20055-02-14) i nawet o takiej opcji nie wiedziałem. Po podmianie go na wersję 5.4 i dopisaniu ,,-i 10'' wszystko działa i programuje.


Dalej jednak pozostaje problem związany z dzielnikiem częstotliwości.
Mianowicie podział przez np. 128 może zostać wybrany programowo (po każdym resecie), a w trakcie trwania resetu (i operacji programowania uC poprzez ISP) przywrócony domyślny dzielnik (brak dzielnika).

Nie rozumiem tego zachowania procka .