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

Bezpieczne przetaktowanie AVR Xmega powyżej 32MHz - ryzyka i limity

mas24 15 Maj 2015 10:38 1386 12
  • #1 14694843
    mas24
    Poziom 16  
    Witam,

    Chciałem się podłączyć do tematu o przetaktowaniu Atmega128, ale został już zamknięty, wiec byłem zmuszony założyć nowy temat.

    Chodzi o możliwości przetaktowania procków AVR Xmega powyżej 32MHz.
    Jakie częstotliwości są bezpieczne, a przy jakich się już sypie?
    Czy zaczyna się wydzielać w procku ciepło, które trzeba odprowadzać?
  • #3 14694914
    mi14chal
    Poziom 28  
    Najlepiej samemu to sprawdzić przy jakich częstotliwościach układ dobrze jeszcze działa.
  • #4 14694943
    Zaquadnik
    Poziom 27  
    A najlepsze jest to, że nigdy nie możesz być pewien czy każdy przetaktowany układ zadziała dobrze. Może być tak, że 20 układów nie wykaże anomalii, a 21 nie wstanie albo posypie się w trakcie działania. Wszystko to przez rozrzuty powstałe przy produkcji struktur krzemowych. Nawet jeśli uda Ci się sprawdzić, że kilka układów pracuje poprawnie przy np. 40 MHz to jest duże prawdopodobieństwo, że trafisz w końcu na układ, który zadziała błędnie lub nie zadziała w ogóle.
  • #5 14695002
    tmf
    VIP Zasłużony dla elektroda
    Tak jak koledzy piszą - jeśli producent daje max 32 MHz to ma jakiś powód, gdyby układ działał np. na 50MHz to producent sam sobie by kagańca nie zakładał. Jeśli jednak chcesz ryzykować - wydaje się, że XMEGi z serii U (z USB) działają poprawnie do 48 MHz. Dlaczego? Bo taki zegar jest potrzebny do poprawnego działania USB i przynajmniej ten podsystem z taką prędkością działa. Nawet wyższe taktowanie idzie na EBI (do 64 MHz), PLL (do 200 MHz) i timery (nawet 128 MHz), więc ze strony tych podsystemów też nie spodziewałbym się kłopotów. Ponieważ wszystko jest na jednym kawałku krzemu, wydaje się, że technologia wykonania powinna umożliwić poprawne działanie reszty z takim taktowaniem (jest to jednak dosyć naciągane). Z pewnością należy obawiać się problemów z FLASH i EEPROM. FLASH w przypadku procków taktowanych szybciej (ARM) ma WSy lub cache, lub dla pełnej prędkości program musi działać z SRAM. Więc tu bym się spodziewał głównych problemów.
  • #6 14695361
    mas24
    Poziom 16  
    Mi nie chodzi o jakieś wielkie podkręcanie, najwyżej do 40MHz, ale jak piszecie: można spróbować, No i procki z literką U obowiązkowo.
  • #7 14695564
    Konto nie istnieje
    Poziom 1  
  • #8 14696036
    mas24
    Poziom 16  
    Dlatego też w innym wątku zadałem pytanie o STM32, lecz to na przyszłość. Chciałbym pobawić się nieco Xmega. Po latach spędzonych w mroku Bascoma z 8bit AVR to już Xmega robi na mnie wrażenie :) Ale mam świadomość, ze jest coś lepszego, i zaczynam zbierać informacje o tym, zadając pytania na Forum.
  • #9 14696307
    tmf
    VIP Zasłużony dla elektroda
    Marek_Skalski napisał:
    Jaki sens podkręcać Xmegę, jeżeli za te same pieniądze możesz mieć ARMa o znacznie wyższej wydajności?
    Taki prosty przykład:
    wydajność Xmega128A1 w CoreMark: 0,44/MHz, max. 14,1@32MHz (wariant optymistyczny)
    wydajność ST32F401VB w CoreMark: 2,16/MHz, min. 181@84MHz (wariant pesymistyczny)
    Zawsze będę wspominał niezbyt sensowny ADC w Xmega, usb tylko w trybie device, brak dedykowanego interfejsu dla kart pamięci.
    To co Xmega może zrobi przy 40MHz, to Cortex M4 prawdopodobnie zrobi przy 8MHz. Oszczędność prądu/czasu.


    Marku, nie chcę po raz kolejny pisać o wyższości jednych rozwiązań nad innymi, ale to co piszesz to tak jakby napisać - po co produkować karabiny, skoro, to co można rozwalić przy pomocy tysiąca karabinów, można zniszczyć jednym działem. Różnica między AVR, ARM , czy PIC wynika wyłącznie z różnic w rdzeniu. A to głównie daje przewagę przy aplikacjach intensywnie korzystających z obliczeń. Ponieważ jednak programowanie MCU polega na maksymalnym stopniu wykorzystania peryferii, nie zawsze szybszy rdzeń oznacza przewagę. A nawet zazwyczaj nie oznacza. Gdyby to przełożenie było takie proste, to już dawno wyginęłoby wszystko co nie ma 64 bitów i co najmniej 4 rdzeni. Podobnie ze wspomnianymi interfejsami - SDIO, czy USB host - czy muszę je mieć jeśli korzystam co najwyżej z USB device, lub USB nie wykorzystuję wcale? Rzeczy, których nie wykorzystuję nie dają mi żadnej przewagi. Teraz spójrzmy na elektrodowe projekty - przez kilka lat mojej bytności tutaj widziałem może kilka, które wymagały czegoś więcej niż ATMega8 :) Nie chodzi o to, żeby na siłę stosować stare rozwiązanie - chodzi o to, żeby nie robić baboli takich jak np. w wątku:
    https://www.elektroda.pl/rtvforum/topic3027211.html
    gdzie autor niby potrzebował hipermocy, a potem okazało się, że procek, który używa to aż nadto w stosunku do potrzeb. Już w pierwszej odpowiedzi pada magiczne - użyj ARM, zamiast analizy problemu, a potem to już tylko licytacja co wyciąga więcej... W efekcie braki umiejętności posługiwania się sprzętem są maskowane użyciem co raz wydajnieszych układów, lecz nie skutkuje to stosowaniem lepszych rozwiązań. Aż dochodzimy do momentu, gdzie te same, głupie, rozwiązania z ATMega8 są przenoszone na jakieś hiper-ARM i okazuje się, że nawet przy 200 MHz jest on zarżnięty. Przejrzyjmy watki o ARM - w ilu autorzy robią transmisję USART testując flagi, stosują delaye do generowania impulsów i inne cuda? W czym ARM we wskazanym wątku będzie lepszy od AVR?
  • #10 14696579
    Konto nie istnieje
    Poziom 1  
  • #11 14696622
    dondu
    Moderator na urlopie...
    Marek_Skalski napisał:
    Dlatego często apeluję o budowanie urządzeń w sposób ewolucyjny.

    Nie możemy się dziwić, że początkujący nie mają wyczucia przez co zawyżają niepotrzebnie swoje wymagania dot. mikrokontrolera. Podejście ewolucyjne ma także swoje plusy i minusy.

    Ja na przykład, gdy robię jakiś projekt, którego efektu końcowego nie mogę określić na początku, bo projekt jest "rozwojowy" śmiało stosuję większy mikrokontroler. Robię to jeszcze śmielej, gdy oprócz tego projekt nie jest urządzeniem seryjnym.

    Ale jeśli projekt jest bardzo konkretny i w dodatku do produkcji seryjnej, to na etapie określania założeń już rozplanowuję jakie wewnętrzne peryferia wykorzystam i dobieram najtańszy możliwy mikrokontroler, który takie peryferia posiada.

    Poza tym na ten wybór wpływa jeszcze wiele innych czynników: http://mikrokontrolery.blogspot.com/2011/04/jaki-mikrokontroler-wybrac-do-projektu.html

    Nie ma więc (przynajmniej dla mnie) jednej jedynie słusznej drogi w doborze mikrokontrolera, bo po prostu założeń i ograniczeń jest zbyt wiele :)
  • #12 14697015
    tmf
    VIP Zasłużony dla elektroda
    @Marek_Skalski Jak widzę Marku, całkowicie się zgadzamy. Trzeba precyzyjnie określić problem, sformułować wymagania, a potem pod to dobrać odpowiedni MCU.
    Kolega @mas24 w innym wątku już zdradził co chce tobić - ponieważ będzie potrzebował dobrego DAC i ADC + układów analogowych w związku z przetwarzaniem muzyki, w zależności od tego co znaczy "przetwarzanie muzyki" zaproponowałbym mu zupełnie inne rozwiązanie - DSP lub specjalizowane koprocesory muzysczne (np. coś z VLSI, jakieś VSxxxx). Żaden MCU nie ma na tyle dobrego DAC, ani ADC, ani potrzebnych torów analogowych, żeby móc konkurować ze specjalizowanymi rozwiązaniami.
  • #13 14697341
    mas24
    Poziom 16  
    Ja tego procka nie potrzebuję do konkretnych zastosowań, ale po to, by się nauczyć go programować, dlatego płyta ewaluacyjna by się przydała. Interesuje mnie generowanie dźwięku, ale nie musi być to jedyne wykorzystanie takiego procka. Po co ludzie używają Arduino czy Discovery, czy Raspbery Pi? Żeby poznać dany procek, napisać na niego kilka programów, nauczyć się, doświadczyć.
REKLAMA