logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Atmega8 i czestotliwosc generatora wewnetrznego >8MHz

Pi0trek121 28 Gru 2012 23:49 2241 18
  • #1 11709282
    Pi0trek121
    Poziom 23  
    Witam! od jakiegoś czasu jestem w trakcie robienia mojego projektu, jednak po skończeniu całego układu okazało się, ze wewnętrzny generator 8MHz jest za wolny :( na dodanie zewnętrznego generatora jest za późno, bo procesor którego użyłem ma tylko jeden pin wolny i to ADC, a prawdę mówiąc nie podoba mi się zbytnio dawać nowego uC (atmegi 16). Jest jakaś możliwość "podkręcenia" generatora? nie zależy mi na równej częstotliwości, chodzi mi, by było szybciej :) wszystkie funkcje czasowe są wykorzystywane na innym układzie, wiec dana atmega działa jako sterownik: multipleksacja, PWM, ściemnianie itp
  • Pomocny post
    #2 11709340
    szulat
    Poziom 23  
    zapnij pasy i wpisz 255 do OSCCAL :)
  • #3 11709349
    Pi0trek121
    Poziom 23  
    Jeżeli można wiedzieć o ile będzie wiesza częstotliwość? (+/-) i jakie sa szanse na spalenie atmegi, ew. zawieszanie się programu?

    Dodano po 16 [minuty]:

    No i jeszcze kilka pytan.. czy przy wpisaniu 255 wartość zapisuje się w pamięci ulotnej czy nie? tzn chodzi mi czy po ponownym podłączeniu uC do prądu częstotliwość wróci? jeżeli nie jak później kalibrować by było równe 8MHz? Trzeba ręcznie (oscyloskop) czy jest jakiś "reset"?
  • Pomocny post
    #4 11709570
    szulat
    Poziom 23  
    konkretna wartość przyspieszenia zależy od egzemplarza, na pewno nic w ten sposób nie spalisz ale czy każda szybkość gwarantuje pełna stabilność to nie wiem. w razie problemów możesz próbować mniejsze.

    wpisana wartość jest tylko chwilowa, po restarcie wraca normalne ustawienie wynikające z fusebitów.
  • Pomocny post
    #5 11709599
    Konto nie istnieje
    Poziom 1  
  • Pomocny post
    #6 11709825
    piotrva
    VIP Zasłużony dla elektroda
    Otóż fabrycznie procesor jest skalibrowany na częstotliwość bliską 8MHz (i innym częstotliwościom możliwym do wyboru przez fusebity), po każdym resecie procesora wartość zapisana w sekcjach pamięci do których nie mamy dostępu do zapisu jest przepisywana do rejestru OSCCAL. Jeśli w naszym programie A będziemy na początku wpisywali do tego rejestru wartość 255 to będzie on działał z "podwójną" prędkością. Jeśli zaś potem wgramy program B nie zmieniający wartości OSCCAL to będzie on działał z szybkością ustawioną fusebitami, bez żadnego spowalniania/przyspieszania.
  • Pomocny post
    #7 11709832
    BlueDraco
    Specjalista - Mikrokontrolery
    Zacznij od sprawdzenia wersji procesora - co ma po kresce. Jeśli -16, to możesz go pędzić na 16 MHz z zewnętrznego kwarcu z błogosławieństwem producenta. Jeśli nie - popraw oprogramowanie. ;) Jeśli to nie pomoże - zmień procesor na zupełnie inny.
  • Pomocny post
    #8 11709884
    dondu
    Moderator na urlopie...
    Pi0trek121 napisał:
    ... na dodanie zewnętrznego generatora jest za późno, bo procesor którego użyłem ma tylko jeden pin wolny i to ADC, a prawdę mówiąc nie podoba mi się zbytnio dawać nowego uC (atmegi 16).

    Ile przycisków masz podłączonych do mikrokontrolera?
    Jeżeli co najmniej dwa, to zrób klawiaturę na wolnym pinie ADC: http://mikrokontrolery.blogspot.com/2011/03/epp-klawiatura-malo-pinow.html
    i piny kwarcu odzyskasz :-)
  • Pomocny post
    #9 11709932
    Dar.El
    Poziom 41  
    Zmiana OSCCAL na maksa może spowodować problemy przy zapisie do EEPROM i FLASH. Możesz trochę zrobić wstawek asemblerowych w newralgicznych miejscach programu.
  • Pomocny post
    #10 11710080
    BlueDraco
    Specjalista - Mikrokontrolery
    Dobra, dosyć bicia piany, pochwal się programem, bo mam wrażenie, że to tu jest pies pogrzebany. Co Ci się nie wyrabia w czasie i dlaczego?
  • #11 11710355
    Pi0trek121
    Poziom 23  
    Dziękuje wszystkim za odpowiedzi :) jestem zdziwiony, że jest ich aż tyle.

    BlueDraco napisał:
    Zacznij od sprawdzenia wersji procesora - co ma po kresce. Jeśli -16, to możesz go pędzić na 16 MHz z zewnętrznego kwarcu z błogosławieństwem producenta. Jeśli nie - popraw oprogramowanie. :wink: Jeśli to nie pomoże - zmień procesor na zupełnie inny.


    Mój uC to ATMEGA8-16AU

    dondu napisał:
    Ile przycisków masz podłączonych do mikrokontrolera?
    Jeżeli co najmniej dwa, to zrób klawiaturę na wolnym pinie ADC

    co do przycisków mam ich 4, lecz wstawienie zew. oscylatora wiąże się z tym, że musiałbym wykonać druga płytkę, a mam wykorzystaną atmege8 w wersji SMD i prawdę mówiąc nie jest za fajnie takie maleństwo odlutować ;) biorąc po uwagę, że nie mam hotair-a lutowałem ją lutownicą z cieniutkim grotem.


    Dar.El napisał:
    Zmiana OSCCAL na maksa może spowodować problemy przy zapisie do EEPROM i FLASH. Możesz trochę zrobić wstawek asemblerowych w newralgicznych miejscach programu.


    Zmieniłem na 255 i wszystkie problemy które miałem zniknęły :) za co wam szczerze dziękuje :) jak na razie nie ma problemów z programowaniem przez ISP ani zapisu do eeprom

    BlueDraco napisał:
    Dobra, dosyć bicia piany, pochwal się programem, bo mam wrażenie, że to tu jest pies pogrzebany. Co Ci się nie wyrabia w czasie i dlaczego?


    Prawda, część problemu leży po stronie programu, gdyż za dużo funkcji wykonuje w przerwaniach, pierwszy problem jest taki, ze przy ściemnianiu z multipleksacją przy minimalnym wypełnieniu trochę widać jak migają wyświetlacze, drugi problem (bardziej poważny) to funkcje w głównej pętli nieskończonej a mianowicie czasami zdarza się, ze uC zareaguje z opóźnieniem co jest winą zbyt dużej ilości komend w przerwaniu, lecz po zmianie wartości w OSCCAL wszystko działa jak powinno :) i jak na razie nie zauważyłem żadnych skutków ubocznych :P
    Jeszcze raz wszystkim dziękuje i życzę szczęśliwego nowego roku :)
  • #12 11710365
    BlueDraco
    Specjalista - Mikrokontrolery
    Miganie wyświetlaczy - to zła organizacja kodu, a nie problem wydajności. Coś jest źle z tymi przerwaniami i przyspieszenie zegara tu nie pomoże, a tylko zamaskuje problem, ktry ponownie wypłynie przy kolejnej modyfikacji kodu.
  • #13 11710383
    Pi0trek121
    Poziom 23  
    Przy wypełnieniu do ok. 15% wszystko jest ok, problem się pojawia przy niższym wypełnieniu, gdzie wyświetlacz jest dłużej wyłączony... patrząc prosto na wyświetlacz nic nie widać, problem pojawia się przy ruchach głową.
  • #14 11710403
    dondu
    Moderator na urlopie...
    Pi0trek121 napisał:
    Prawda, część problemu leży po stronie programu, gdyż za dużo funkcji wykonuje w przerwaniach, ...

    Skoro jesteś tego świadomy, to zmień sposób pisania programu.
    Może pokazałbyś chociaż te funkcje przerwań?
  • #15 11710439
    Pi0trek121
    Poziom 23  
    Zdaję sobie sprawę z tego, ze nie jestem mistrzem w pisaniu w C, tak więc bardzo proszę bez zbędnej krytyki, za wszelkie podpowiedzi będę wdzięczny :)


    przerwanie multipleksacji wraz z regulacją jasności (jedno z bardziej rozbudowanym przerwaniem)
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #16 11710452
    BlueDraco
    Specjalista - Mikrokontrolery
    Masz źle zrobioną obsługę wyświetlania. Błędnie wyliczone parametry ale też jakiś gruby błąd w realizacji. Częstotliwość odświeżania całości powinna być nie mniejsza niż 120 Hz (tak, wiem, że w książkach piszą 50, 60 albo 80, ale to bzdura - ja zwykle stosuję od 150 do 240). Pomnóż to przez liczbę cyfr wyświetlacza - wyjdzie częstotliwość przerwań. Dalej bez kodu Ci nie pomożemy.

    Ok, kod już widzę. jest parę problemów, opiszę później. Jeśli programowo regulujesz jasność, to musisz mieć odpowiednio częstsze przerwania. Ja bym użył timera do regulacji jasności - start przy zmianie cyfry, w obsłudze przerwania wygaszanie wyświetlacza.
  • #17 11710494
    Pi0trek121
    Poziom 23  
    BlueDraco napisał:
    Częstotliwość odświeżania całości powinna być nie mniejsza niż 120 Hz (tak, wiem, że w książkach piszą 50, 60 albo 80, ale to bzdura - ja zwykle stosuję od 150 do 240)
    ja przeważnie stosuje ok. 200Hz na wyświetlacz co daje 800Hz na całość, ale czy wg. Ciebie te 800 starczy na regulacje jasności przy multipleksacji? na google znalazłem kogoś projekt (multipleksacja z płynnym przejsciem) i zastosował częstotliwość 62kHz gdyż wg. niego było widać nie płynne przejście, resztą u mnie jest podobny problem i przy 62kHz jest dobrze, lecz tak jak pisałem wcześniej problem jest przy małym wypełnieniu, a przy zmniejszeniu preskalera na mniejszy dzielnik (by zwiekszyc te 62kHz) uC się "klinuje" i praktycznie nie wchodzi w pętle główna dlatego szukałem rozwiązania w postaci zwiększenia taktowania.
  • #18 11711351
    tmf
    VIP Zasłużony dla elektroda
    Częstotliwość tu nie odgrywa większej roli. Regulację uzyskuje się przez zmianę śrendiego czasu wyświetlania cyfry. Czyli np, dwa przerwaina timera - overflow - zmiana cyfry, przerwanie compare - wygaszenie wyświetlacza. Regulujesz jasność przerwaniem compare, dla 16-bitowego licznika masz głębię 16-bitową (teoretycznie).
    Tego typu koncepcję masz pokazaną w moich przykładach (stopka). Kod to realizujący nie pochłania więcej niż 1% czasu MCU, a istnieje możliwość dalszej optymalizacji.
  • #19 11711381
    Pi0trek121
    Poziom 23  
    Znalazłem mój błąd... problem był w procedurach - delay-e które były używane do czekania na odebranie danych, muszę je zastąpić jakimś buforem by nie blokował mi "kolejki" :) dziękuje wszystkim za zainteresowanie, temat uważam za zamknięty.
REKLAMA