Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Podkęcanie/ tuning ATMEGA c.d.

06 Wrz 2006 19:04 3129 24
  • Poziom 26  
    Witam
    Mój ATMEGA8 śmiga na kwarcu 24 MHz :D i działa stabilnie. Program może nie wymagajcy, ale pracuje w nim zapis i odczyt z zewnętrznej pamięci EEPROM 256kb (TWI) - 100kHz, na bitrate 32, i wyświetlanie na LCD 2x24 4-ro bitowo dynamicznego tekstu (taki który sie przewija po LCD).

    Czy można dać szybszy kwarc ?? ;D Pytam tak z ciekawości :).

    A tak apropos.....TWI.
    Bo na 1MHz to bitrate wynosi 10 (coś ok. 20 kilka kHz), na 8 MHz - 32 (100kHz) a na 24MHz ;| ile?? Bo w manualu jest napisane, że TWI może chodzić do 400kHz.
    Jak to obliczyć z tego cudownego wzorku??:
    Code:

    SCLFreq = (F_CPU) / (16 + 2*(TWBR) * 4^(TWPS))


    Aha...i dodam to, iż faktem jest, że cały układ uC pracuje na oddzielnym zasilaczu komputerowym, stąd dobre źródło prądu stawia czoła wymaganiom uC :).
  • Specjalista techniki cyfrowej
    Kubbaz napisał:
    POPRAWKA:

    Założyłem teraz kwarc 32MHz i uC działa szybciej ;|.
    Czy to normalne i czy to w ogóle działa??


    Nienormalne :P
    Niekoniecznie wszystko musi pracować poprawnie, np. peryferia lub podawany już kiedyś na elce przykład instrukcji LPM (albo ld, nie pamiętam) z postinkrementacją wsklaźnika (lpm r0, Z+).

    Jeżeli jesteś pewien, że na kwarcu 24MHz działało z zegarem 24MHz, a na 32MHz działa szybciej, to znaczy że faktycznie tak jest.
    Ale... Może być i tak, że oba kwarce są overtonowe (nominalna częstotliwość na trzecim overtonie), było by to całkiem możliwe przy kwarcu 32MHz, ale 24MHz częściej pracują na drganiach podstawowych.
    Gdyby oba były overtonowe, to zamiast 24MHz miałbyś 8MHz, a zamiast 32MHz było by 10.667MHz.
    Zobacz, czy proc się bardzo grzeje, podobno tak jest przy podkręcaniu.
    Napisz też jak sprawdziłeś, że działa szybciej.
  • Poziom 26  
    shg napisał:
    Nienormalne


    Też tak sądzę :D.

    shg napisał:
    Jeżeli jesteś pewien, że na kwarcu 24MHz działało z zegarem 24MHz


    Tego nawet najstarsi górale nie są pewni - nie mam oscyloslopu.

    shg napisał:
    Zobacz, czy procesor się bardzo grzeje, podobno tak jest przy podkręcaniu.


    Nie, uC mże chodzić cału dzień i jest taki jak nie pracuje - temperatura pokojowa.

    shg napisał:
    Napisz też jak sprawdziłeś, że działa szybciej.


    Nie wiem czy to jest odpowiedni sprawdzian dla tego parametru .... pewnie nie, bo być może niedostatecznie obciąża pracę uC .... ale cóź spróbować zawsze można.

    shg napisał:
    Napisz też jak sprawdziłeś, że działa szybciej.


    Otóż napisałem funkcje , która wyświetla tekst w płynącej linijce na wyświetlaczu LCD - dość popularny bajer w sklepowych wirtynach, ta z kolei wykorzystuje inną funkcję do wyświetlania pojedyńczych znaków na LCD i funkcję opóźnienia czasowego pare innych funkcji. Do tego uC zapisuje i odczytuje literki z zewnętrznego EEPROM i wyświetla ja na dolnej lini LCD.

    Otóż jeśli mam w bibliotece z opóźnieniami zdefiniowane F_CPU na 8MHz i mam włożony kwarc 8MHz, jest wszystko wporządku - działa poprawnie, jeśli wyjmę kwarc z podstawki - wszystko sie zwiesza i nic nie działa, jeśli ponownie włoże kwarc ale szybszy np. 24Mhz to wszystko działa z powrotem tylko że dużo dużo szybiej - czyli tekst sie szybciej przewija, i szybiej sie wszystko dzieje. Jeśli w bibliotece z opóniewniami zdefiniuje F_CPU na 24Mhz - tekst pzrewija sięz taką prędkościa jak na starym kwarcu :).
  • Poziom 21  
    Świetnie :D Z ciekawości - mierzyłeś pobór prądu przy podkręconym procku?
    Fajnie, że zrobiłeś taki research. Mam algorytm aproksymacji pozycji słońca, który w "normalnych" warunkach liczy się 8h. Aż sprawdzę, czy uzyskam 4-ro krotne przyspieszenie :D
    Znalazłeś górną granicę F_CPU dla m8?
  • Poziom 26  
    migod napisał:
    Z ciekawości - mierzyłeś pobór prądu przy podkręconym procku?

    Wiesz, że nie .... ale jutro z rana to uczynie :).

    migod napisał:
    Znalazłeś górną granicę F_CPU dla m8?


    Jak na razie to nie, bo po kupnie kwarcu 16HMz (jakieś 2 tygodnie temu), sądzilem że to maximum, ale dwa tni temu kupilem 20 i 24 MHz - akurat takie, bo o takich czytałem na elektrodzie. Ponieważ uC działał coraz szybciej i poprawnie, przechodząc koło sklepu elektronicznego pomyślałem sobie że warto kupić kwarc nieco większy - 26 albo 28 MHz, ale ponieważ nie mieli takich a mieli 32MHz, to dla jaj wziąłem 32MHz, ale okazało się że działa :].... szkoda że nie kupiłem odrazu 50MHz :D.

    Tak apropos.....jaki program napisać aby maxymalnie zmulić uC i sprawdzić jego prędkość przy obciążeiu ??

    Researchu ciąg dalszy .....:). Wszystko opisze na forum....
  • Poziom 21  
    Kubbaz napisał:
    Tak apropos.....jaki program napisać aby maxymalnie zmulić uC i sprawdzić jego prędkość przy obciążeiu ??


    najlepiej, aby to był jakiś w miarę prosty alg. obliczeniowy, ale taki, który wykorzystuje "duże" tablice danych, ale oprócz tego na wyjściu produkuje jakiś wynik, który jest się w stanie zweryfikować alternatywną metodą (np. na PC). Wtedy ma się względną pewność co do osiągów i stabilności obliczeń na podkręconym procesorze.

    Moja propozycja - umieścić w pamięci procesora powiedzmy 512 bajtów jakiś losowych danych. Jako program realizowany na nim zaimplementować (czyt. znaleźć gotowca w google :-) ) obliczanie CRC8 lub CRC16 z tych 512 bajtów, następnie otrzymany wynik "dokleić" do pierwotnych 512b (lub podmienić 8/16 bitów początkowych danych w/g ustalonej reguły) i operację powtórzyć. Na koniec, po iluś tam tysiącach iteracji niech wyśle dane na out (po rs232, na wyświetlacz, cokolwiek). Dla porównania zrealizować to samo na PC i skonfrontować wyniki.

    Oczywiście wtedy przetestowana zostanie wyłącznie jednostka arytmetyczna. Poprawność działania "peryferiów" (ADC, SPI, TWI, UsART) nadal będzie niewiadomą.
  • Poziom 26  
    Witam

    Niestety, ale muszę zdementować ostatnie próby z kwarcem 32MHz, potwierdzając to poniższymi wynikami pomiaru poboru prądu układu uC i LCD.

    Podkęcanie/ tuning ATMEGA c.d.

    Podkęcanie/ tuning ATMEGA c.d.

    Jak nie trudno zauważyć, największy pobór prądu - 40mA - wystąpił podczas pracy uC na kwarcu 24MHz, co jest zgodne z notą aplikacyjną (nie oficjalną) producenta.

    Wszelkie uwagi i komentarze mile widziane.
  • Poziom 21  
    to pomęczmy go trochę.. ;-)

    Code:

    unsigned char data[256];

    unsigned crc_16(char c)
    {
            unsigned CRC;

            int i,j;
            for(i=0;i!=8;c>>=1,i++) {
                    j=(c^CRC)&1;
                    CRC>>=1;
                    if(j) CRC^=0xa001;
            }
            return CRC;
    }

    unsigned long crc_16_compute(unsigned char* buf, int len)
    {
            int i;
            unsigned long c;
            for(i = 0; i < len; i++) {
                    c = (crc_16(buf[i]) & 0xFF) ^ (c >> 8);
            }
            return c;
    }

    int main(int argc, char** argv) {
            long i;
            unsigned long c;

            for(i = 0; i < 65535L; i++) {
                    c = crc_16_compute(data, 256);
                    data[i%255] = c & 0xffL;
            }
            printf("%x\n", c);
    }

    "Dziwny" ten punkt przegięcia przy 24MHz. Czy dla wyższych F_CPU faktycznie jest szybciej?
  • Poziom 26  
    migod napisał:
    to pomęczmy go trochę..

    ok, zobaczymy :). - a co oblicza ten program ? bo u mnie wynikie, na PC jest ciągle "d6" ;|.

    Faktycznie - praca procesora PC podczas wykonywania siępowyższego kodu wzrosła do 100 % :D.

    migod napisał:
    Czy dla wyższych F_CPU faktycznie jest szybciej?


    Wyższe, tzn. jakie masz na myśli ??

    Dodano po 28 [minuty]:

    chciałem zmierzyć czas w jakim PC wykonuje te obliczenia, żeby mieć porównanie do uC, ale wynikiem jest 0 w czasie 1s ;| - nienormalne ....

    kod:
    Code:
    #include <stdio.h>
    
    #include <conio.h>
    #include <time.h>

    unsigned char data[256];

    unsigned crc_16(char c)
    {
            unsigned CRC;

            int i,j;
            for(i=0;i!=8;c>>=1,i++) {
                    j=(c^CRC)&1;
                    CRC>>=1;
                    if(j) CRC^=0xa001;
            }
            return CRC;
    }

    unsigned long crc_16_compute(unsigned char* buf, int len)
    {
            int i;
            unsigned long c;
            for(i = 0; i < len; i++) {
                    c = (crc_16(buf[i]) & 0xFF) ^ (c >> 8);
            }
            return c;
    }

    int main(int argc, char** argv)
    {
            long i;
            unsigned long c;
           
            clock_t poczatek,koniec;
            float czas;
           
           i = 0;
           c = 0;
           poczatek = 0;
           koniec = 0;
           czas = 0;

            poczatek = clock();
            for(i = 0; i < 65535L; i++) {
                    c = crc_16_compute(data, 256);
                    data[i%255] = c & 0xffL;
            }
            koniec=clock();
            czas=(koniec-poczatek)/CLK_TCK;
           
            printf("%x\n", c);
            printf("%f\n", czas);
            getch ();
    }


    Sprawdź u siebie ile pokazuje.
  • Poziom 21  
    to d6 ( u mnie FD ) to wynik iteracyjnego obliczania sumy CRC16 w/g reguł opisanych w kodzie. Podałeś źródła dla C/C++ ale na platformę Windows. Ja mam Linux i muszę to przeportować, aby się kompilowały.

    Różnica w wartości checksum-y u Ciebie i u mnie wynika zapewne ze sposobu obsługi słowa maszynowego przez obie platformy (Lin / Win).
    To mi nasuma myśl, że podobnie może być z m8.. :|

    Ten kod jest na tyle "prosty", żeby bez zmian ruszył na ATmega8 (może bufor danych trzeba będzie zmniejszyć i %255 w kodzie również).

    Porównywać można wynik CRC obliczony na PC i ten obliczony na m8. To uwiarygodni, że algorytm wykonuje się poprawnie mimo podkręcenia procka. Co do czasówek - to wiadomo - nie ma skali porównania PC-ta do m8 :)

    PS. odnośnie tego F_CPU - skoro zużycie energii ma peak przy F_CPU=24MHz, to może dla wyższych cz. kwarcu (Q) m8 po prostu nie pracuje z F_CPU = Q, tylko z mniejszą. Przy innych procesorach zwykle zauważa się prawidłowość, że im wyższe F_CPU tym więcej energii potrzeba dostarczyć i tym więcej jej one wypromieniowują. Stąd moje przypuszczenie, że choć Q = 32MHz, to efektywne F_CPU < 24MHz i o to próbowałem Cię zapytać :-)
  • Poziom 26  
    migod napisał:
    odnośnie tego F_CPU - skoro zużycie energii ma peak przy F_CPU=24MHz, to może dla wyższych cz. kwarcu (Q) m8 po prostu nie pracuje z F_CPU = Q, tylko z mniejszą. Przy innych procesorach zwykle zauważa się prawidłowość, że im wyższe F_CPU tym więcej energii potrzeba dostarczyć i tym więcej jej one wypromieniowują. Stąd moje przypuszczenie, że choć Q = 32MHz, to efektywne F_CPU < 24MHz


    Dokładnie do tego samego wniosu doszedłem :) . Z wykresu nawet możnaby odczytać, że przy kwarcu 32MHz F_CPU wynosi ok. 10MHz, bo pobór prądu (24mA) jest taki sam jak przy 10MHz.
  • Poziom 21  
    jeszcze jedno - ekperymentowałeś z ATmega8 (nie L), i przy zasilaniu.. 5 V DC w temp. pokojowej?
  • Poziom 26  
    migod napisał:
    jeszcze jedno - ekperymentowałeś z ATmega8 (nie L), i przy zasilaniu.. 5 V DC w temp. pokojowej?


    Tak. Był to dokładnie egzemplarz ATMEL ATMEGA8 DIP28, zasilanie 5VDC (pobierane z oddzielnego zasilacza komputerowego), no i wssystko działo się w pokoju- temperatura pokojowa :).

    Po lekkich przeróbkach kosmetycznych twojego programu (pod mój układ uC i LCD) i po skompilowaniu w WinAVR i sflashowaniu do ATMEGA8 na kwarcu 24MHz program wykonywał się 2min 7s, po czym LCD wyświetlił lirerę 'W' czyli wg kodu ASCII liczbę 87, dodam, że na moim PC (AMD Athlon 1700+ - 1478MHz, program się wykonał w ok. 3 sekundy).

    Na kwarcu 12MHz (ale przy definicji F_CPU na 24000000) czas był dokładnie dwa razy dłuższy - 4 min 14 sekund.

    Na kwarcu 12MHz z definicją F_CPU na 12000000 czas był identyczny jak w próbie opisanej powyżej z tym, że n LCD pojawił się jakiś chiński znaczek, czyli wartość obliczona przez program była inna jak w poprzednich próbach.

    A jak z czasem wykonywania tego programu u Ciebie ??

    Przy tym doświadczeniu można zauważyć, że częstotliwości pracy procesorów nie rosną liniowo, bo wg poniższych obliczeń:

    127 sekund : 3 sekundu = 42 razy szybciej na PC niż uC, teraz:
    24MHz x 42 = 1008 MHz, a to wcale nie jest nawet w przybliżeniu równe częstotliwości procesora PC.

    Swoją drogą co ten program oblicza ?? Bo CRC kojarzy mi się z błędem odczytu danych z płyty CD :D.
  • Poziom 21  
    Czyli dostajemy inną wartość (0x57).

    Ok, posiedzę trochę nad tym kodem tak, aby wyeliminować efekt różnych interpretacji kodu maszynowego na PC i m8.

    CRC to suma kontrolna, skojarzenia masz dobre. Pozwala wychwycić drobną zmianę w danych (względnie błędu powstałego na etapie odczytu/zapisu danych), która w efekcie odpowiada innej sumie kontrolnej. Znając dane wejściowe i obliczoną sumę CRC8/16/32 można później (poprzez ponowne obliczenie wartości sumy) ustalić, czy dane nie uległy przekłamaniu.

    W przypadku mojego programu - oblicza on CRC z poprzednich wartości CRC. Jeśli na którymś etapie obliczeń coś pójdzie "nie tak", końcowa wartość CRC z bardzo dużym prawdopodobieństwem będzie miała inną wartość niż ta wyliczona w "stabilnym" środowisku.

    Bufor (na początku pusty) wygląda z czasem jakoś tak:
    CRC1, CRC2, CRC3, .. , CRC128,
    przy czym CRCn jest wyliczana na podstawie całego bufora (255 bajtów), czyli f(CRC1, ..., CRCn-1).

    Można oczywiście kazać procesorowi wykonać dowolne inne obliczenie, które powtórzymy na PC-cie. Ważne jednak, aby był to algorytm iteracyjny a jednocześnie nie wymagający "danych z zewnątrz" (nie testujemy UsART-a, tylko procesorek). Czyli optymalnie, aby dane do obliczeń procesor generował sobie sam, a równocześnie, aby każdy etap obliczenia był dostatecznie wyrafinowany obliczeniowo (więc raczej odpada obliczanie wartości ciągu typu An+1 = An + C). Stąd pomysł na użycie CRC, bo tutaj małe "potknięcie" ma kolosalne znaczenie i łatwo to wychwycić.

    U mnie, na 2-procesorowej maszynie program wykonuje się ~50sek. Ale to nie jest miarodajne z uwagi na priorytetyzację procesów użytkownika w tym systemie.

    PS. Zauważyłem drobny błąd w kodzie, który wcześniej podesłałem (brałem tylko ostatnie 8 bitów CRC zamiast pełnych 16-tu). Poprawię i podeślę update. Odezwę się jutro.

    Dodano po 1 [godziny] 2 [minuty]:

    poprawiony kod w załączniku. Obliczenia zabierają ~3 sek. Wartość wynikowa: 0x110c
  • Specjalista techniki cyfrowej
    Czyli tak jak pisałem. Kwarc 32MHz to kwarc overtonowy.
    Podstawowe drgania ma na 32/3MHz, co zresztą zgadza się z wynikami eksperymentu.
    Układ generatora w ATmega przystosowany jest w zasadzie wyłącznie do przacy z kwarcami pracującymi na drganiach podstawowych i bez modyfikacji na takich będą się kwarce wzbudzały.
    Żeby uruchomić go na trzecim overtonie (32MHz) trzeba by dodać jakiś obwód rezonansowy.
    Ale wątpię, żeby ATmega działała aż z taką częstotliwością.
    Kwarc 24MHz masz na drganiach podstawowych, czyli tu jest wszystko OK - układ się jeszcze wyrabia. Tylko jakieś testy pracy peryferiów i rdzenia należało by dla pewności wykonać. To CRC może być niezłe, bo dość "męczące" dla CPU.
    Przydało by się jeszcze trochę operacji na wskaźnikach, żeby sprawdzić instrukcję ładowania danych z pamięci (programu i danych) z postinkrementacją.
  • VIP Zasłużony dla elektroda
    32 przez 3 czyli troche mniej niż 11...
  • Poziom 21  
    Czyli 24MHz to maksimum, czy też może kwestia poszukania odpowiednik kwarców o wyższych f?
    PS. (wiem trochę wariactwo) :)
  • Poziom 41  
    Witam
    Można kupić od razu gotowy generator albo zrobić syntezę częstotliwości (są gotowe scalaki) do takich eksperymentów.
  • Specjalista techniki cyfrowej
    migod napisał:
    Czyli 24MHz to maksimum, czy też może kwestia poszukania odpowiednik kwarców o wyższych f?
    PS. (wiem trochę wariactwo) :)

    W zasadzie kwarce 27MHz i więcej są kwarcami overtonowymi. Kiedyś w ogole nie produkowano kwarców z drganiami podstawowymi o takich częstotliwościach, tylko overtony. Przyczyną były wymiary rezonatora.
    Obecnie technika poszła trochę do przodu i można dostać kwarce na drganiach podstawowych nawet do 150MHz.

    Ale... Większoś >=27MHz wciąż produkowana jest jako overtonowe ze względu na to że przystosowana jest do tego większość ukłądów, w których takie kwarce mają pracować.

    Pytać w sklepie, jak sprzedawca nie wie, czy drgania podstawowe, czy overton, to znaczy że overton :P
  • Poziom 21  
    Dar.El napisał:
    Witam
    Można kupić od razu gotowy generator albo zrobić syntezę częstotliwości (są gotowe scalaki) do takich eksperymentów.


    można prosić o jakiś konkretny przykład (producent, oznaczenie)? Domyślam się, że to może być sprzęt wykorzystywany w skanerach częstotliwości radiowych, gdzie w grę wchodzi płynny przestrój cz. ?

    shg dzięki za hint, teraz wiadomo o co pytać w sklepie :)

    Kubbaz jeśli jesteś zainteresowany dalszym eksperymentowaniem, a były problemy z dotarciem do takich kwarców - daj znać, zapytam w zaprzyjaźnionym sklepie. Podoba mi się pomysł wyciągnięcia 24MIPS a może więcej z tego maleństwa ;)

    Ja ze swej strony mogę prowadzić testy, ale na wersji m8L, a te oficjalnie pracują z kwarcami do 8MHz, więc prawdopodobnie mniejszy margines na "żyłowanie" osiągów..

    PS. Niestety nie wiem jak zaimplementować ten sam algorytm na PC i na m8 tak, aby wykorzystywał EEPROM lub żeby to "zaemulować". Macie jakieś pomysły?. Postinkrementacja + wskaźniki są naturalnie do osiągnięcia, wystarczyłoby chyba odrobinę zmodyfikować wcześniej zamieszczony kod.
  • Poziom 41  
    Generatory można kupić prawie w każdym sklepie a scalaki do syntezy już trudniej ale nie są one do skanerów tylko właśnie do procesorów. Można coś takiego znaleźć w starych płytach głównych PC lub też w nowszych. Można też zastosować scalaki do syntezy częstotliwości w nadajnikach. Najprościej jednak jest kupić parę generatorów w obudowie DIP14 i wkładać je w podstawkę.
  • VIP Zasłużony dla elektroda
    AD9851 dostępny jako sampel z Analoga