Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Przetaktowanie (Overclocking) AVR

R-MIK 29 Sty 2017 13:35 7101 151
  • #1 29 Sty 2017 13:35
    R-MIK
    Poziom 36  

    Proponuję wymianę doświadczeń związaną z przetaktowaniem AVR'ów.
    Z mojej strony mogę powiedzieć, ze Atmega128 przy 5V działała na 18,4321MHz (+13%), przy 3,3V już nie (126%).
    Atmega2561 działa na 22,1184 z tym, że po 2 tygodniach przestał działać TWI. Na 18,4321 na razie bez problemu.

    <ciach>
    Ograniczanie materiałów tylko do tych w języku polskim jest nie na miejscu w dziedzinie dot. elektroniki.
    Moderator Dondu



    Moderowany przez dondu:

    Temat dotyczy doświadczeń, które nie powinny być stosowane przez konstruktora urządzeń innych niż amatorskie ze względu NA PRACĘ POZA DOPUSZCZALNYMI PRZEZ PRODUCENTÓW PARAMETRAMI MIKROKONTROLERÓW.

    Jest to tym bardziej istotne, że stwierdzanie poprawności pracy mikrokontrolera za pomocą wyrywkowego testu jest kompletnie niemiarodajne.

    WSZELKIE ZAWARTE W NINIEJSZYM TEMACIE PRZYKŁADY OVERCLOCKINGU NALEŻY TRAKTOWAĆ JAKO EKSPERYMENTALNE ZE ŚWIADOMOŚCIĄ, ŻE NIE GWARANTUJĄ POPRAWNEJ PRACY MIKROKONTROLERA.

  • #2 29 Sty 2017 13:48
    Piotrus_999
    Poziom 39  

    Temat omówiony na 1000 sposobów na róznych forach. Zamiast spamować poczytaj.

    http://3.14.by/en/read/arduino-liquid-nitrogen-overclocking

    Jak sobie wrzucisz w googla to zobaczysz że poziom blędów (drobnych nie powodujących zwiechy albo resetu) pamięci i operacji wzrasta w sposób lawinowy w AVR-ach.

  • #4 29 Sty 2017 14:44
    Marek_Skalski
    Poziom 33  

    @R-MIK Opis zawarty w Twojej stopce sugeruje zachowanie minimum poziomu technicznego, merytorycznego i odpowiedzialności. A co mamy? Jakieś bzdury.
    Jaki jest sens zakładania tego tematu? Jak AVR się nie wyrabia, to biorę coś innego: dsPIC33/PIC24, PIC32MX/MZ, STM32, LPC czy inny Kinetis.
    Podajesz jakieś wartości bez opisu warunków brzegowych czy kryteriów oceny stabilności. Teoretycznie zyskałeś 13% prędkości wykonywania programu dla m128, ale nie ma ani słowa o warunkach. Jakie zasilanie, jaki pobór prądu, jaki program był wykonywany, które peryferia były sprawdzane i używane, a które były wyłączone. W jakiej temperaturze prowadziłeś testy i jak długo? Na pewno wiesz, że powyżej 85°C w większości AVR'ów dramatycznie rośnie pobór prądu i pamięć programu ulega szybkiej degradacji. Jak oceniłeś, że uC osiągnął granicę? Wcale nie wykonuje programu, pojawiają się sporadyczne błędy w wynikach obliczeń, pojawiają się błędy w odczycie pamięci, glitche na wyjściach lub jeszcze inne nieprawidłowości?
    Co to jest 13%, kiedy wymiana układu na współczesny pozwala zrealizować ten sam algorytm niższym kosztem i z prędkością kilka razy większą?
    Co to jest Atmega12561? Jeżeli popełniasz błędy w takich miejscach, to jaka jest wiarygodność pozostałych informacji?
    Czy Ty naprawdę sądzisz, że producent wprowadza użytkowników w błąd podając informacje o maksymalnej częstotliwości taktowania w funkcji napięcia zasilania i temperatury? Każdy chciałby mieć w ofercie układy szybkie i/lub energooszczędne. Gdyby AVRy mogły pracować z zegarem 140MHz (jak PIC24), to Atmel/Microchip na pewno by o tym głośno informował, ale tutaj barierą jest archaiczny proces technologiczny. Pozostaje cieszyć się zyskiem rzędu 10% w szczególnych (optymalnych) warunkach.
    Każdy kto projektuje urządzenia elektroniczne, zdaje sobie sprawę z pewnych ograniczeń i odpowiedzialności za ich działanie. Koszt napraw gwarancyjnych jest z wielu względów bardzo wysoki i nikt nie chce go ponosić. To są zawsze zdarzenia, które bardzo źle wpływają na relacje z klientami, zaburzają realizację normalnie biegnących projektów, a do tego wprowadzają duże ryzyko utraty kontraktów w przyszłości.
    Powiedz co zrobisz, jak urządzenie zbudowane na własne potrzeby będzie się "zawieszać" czy działać w sposób niestabilny. Będziesz to tolerował czy jednak zrobisz drugą wersję, która będzie stabilna?
    Mam nadzieję, że ten temat nie ma za zadania zachęcać elektroników do podkręcania taktowania. To jest ślepa uliczka.

  • #5 29 Sty 2017 17:50
    R-MIK
    Poziom 36  

    Marek_Skalski napisał:
    @R-MIK Opis zawarty w Twojej stopce sugeruje zachowanie minimum poziomu technicznego, merytorycznego i odpowiedzialności. A co mamy? Jakieś bzdury.
    Jaki jest sens zakładania tego tematu? Jak AVR się nie wyrabia, to biorę coś innego: dsPIC33/PIC24, PIC32MX/MZ, STM32, LPC czy inny Kinetis.

    A jak taka możliwość nie wchodzi w grę? Czy jak przetaktuje o 2% bo tyle mi zabrakło to nie ma szansy na to aby urządzenie działało?

    Dodano po 1 [minuty]:

    Piotrus_999 napisał:
    Temat omówiony na 1000 sposobów na róznych forach. Zamiast spamować poczytaj.

    http://3.14.by/en/read/arduino-liquid-nitrogen-overclocking

    Jak sobie wrzucisz w googla to zobaczysz że poziom blędów (drobnych nie powodujących zwiechy albo resetu) pamięci i operacji wzrasta w sposób lawinowy w AVR-ach.

    Bardzo cenne informacje, przetłumaczysz?

    Dodano po 1 [minuty]:

    Marek_Skalski napisał:

    Co to jest Atmega12561? Jeżeli popełniasz błędy w takich miejscach, to jaka jest wiarygodność pozostałych informacji?

    Cóż panie profesorze, pan nigdy nie popełnia literówek, prawda?
    Swoją drogą średniointeligentny zorientuje się o jakiego AVR'ka chodzi.

    Aby nie było nieporozumień, nikogo nie zmuszam do czytania tego forum. Mamy (teoretycznie) wolność słowa. Widzę, że niektóre tematy są zarezerwowane dla nielicznych.

    Dodano po 5 [minuty]:

    dondu napisał:
    W jakim celu ta dyskusja ma być?
    Pytanie nie bez przyczyny, bo później dzięki takim tematom powstają mity wśród początkujących.

    Odpowiedź jest prosta, na ile można przetaktować i jakie to niesie ryzyko.

    Moderowany przez dondu:

    Odpowiedź jest równie prosta - ryzyko zależne jest od aplikacji i będzie równe zeru, gdy dotyczy migania diodą oraz równe 100%, gdy dotyczy życia ludzkiego.

    Temat, pomimo że był raportowany warunkowo zostawiam jako ciekawostka na temat doświadczeń, a nie projektowania, które powinno opierać się na parametrach dopuszczanych i gwarantowanych przez producenta.

  • #6 30 Sty 2017 11:21
    R-MIK
    Poziom 36  

    Marek_Skalski napisał:
    [(...) ale nie ma ani słowa o warunkach. Jakie zasilanie, jaki pobór prądu, jaki program był wykonywany, które peryferia były sprawdzane i używane

    Napisałem o zasilaniu 5 i 3V. Pisałem o problemach z TWI. Czy to wegług ciebie ani słowa?

    Dodano po 4 [minuty]:

    Marek_Skalski napisał:

    Każdy kto projektuje urządzenia elektroniczne, zdaje sobie sprawę z pewnych ograniczeń i odpowiedzialności za ich działanie. Koszt napraw gwarancyjnych jest z wielu względów bardzo wysoki i nikt nie chce go ponosić. To są zawsze zdarzenia, które bardzo źle wpływają na relacje z klientami, zaburzają realizację normalnie biegnących projektów, a do tego wprowadzają duże ryzyko utraty kontraktów w przyszłości.

    Czyli sztandarowa konstrukcja firmy CBM (Commodore C64) to amatorszczyzna. W ich konstrukcji procesor był przetaktowany (1,023MHz) zamiast dopuszczonego przez producenta 1MHz.

    Moderowany przez dondu:

    Commodore 64 był oparty o procesor 6510, który mógł być taktowany do 2MHz:

    Przetaktowanie (Overclocking) AVR

    mos_6510_m...v_1982.pdf Download (5 MB)

    Nawet jeśli byłby to procesor 1MHz, a przetaktowany byłby do 1.02MHz, to byłoby to zaledwie 2%.
    Gdyby producent podjął takie ryzyko, zrobiłby to na własną odpowiedzialność. Jak widać nie zrobił tego.

    Jeśli chcesz ryzykować sprzedając urządzenia pracujące poza limitami producenta możesz to oczywiście robić, ale taki temat zostanie z stąd usunięty, by nie tworzyły się mity wśród osób początkujących.

    Jeśli natomiast temat traktujesz jako ciekawostkę, to możemy dalej dyskutować.

  • #7 30 Sty 2017 11:26
    Piotrus_999
    Poziom 39  

    R-MIK napisał:
    Odpowiedź jest prosta, na ile można przetaktować i jakie to niesie ryzyko.


    Zgadza się - jak sobie topisz w azocie dla zabawy to możesz robić co chcesz. Jak robisz dla klienta - nie wolno Ci przekraczać parametrów podanych przez producenta. Wszelkie inne dywagacje są dowodem nieprofesjonalnego podejścia pytającego.

    W branży uC trzeba dobrać odpowiedni sprzet pod zadanie, a nie pod swoje umiejętnosci

    <ciach>

    Moderowany przez dondu:

    3.1.11. Nie wysyłaj wiadomości, które nic nie wnoszą do dyskusj

    i.

    Nie trolluj bo na temat overclockingu dostałeś odpowiedzi w innym wątku zwiazanym z Twoim 1-wire. Nie licz, że odpowiedź się zmieni jak zapytasz jeszcze 50 razy i dostaniesz dyspensę (nikt Ci nie odpowie "tak dodaj te 20%, nikt nie zauważy, a jak nawet to co z tego")

  • #8 30 Sty 2017 11:45
    piotrva
    Moderator Mikrokontrolery

    R-MIK napisał:
    Bardzo cenne informacje, przetłumaczysz?

    Nie widzę sensu tłumaczyć - językiem oficjalnym elektroniki jest angielski i moim zdaniem każdego należy zachęcać do poznania tego języka! Dokumentacji STM32 nie będzie nikt tłumaczył ;)

    R-MIK napisał:
    Odpowiedź jest prosta, na ile można przetaktować i jakie to niesie ryzyko.

    Na to pytanie odpowiedź jest jednoznaczna - nie można przetaktować, bo niesie to ze sobą nieprzewidywalne ryzyko. Ba może być ono zależne od wersji krzemu i wielu innych czynników.
    Tyle w temacie zastosowania układu w urządzeniach komercyjnych.

    W eksperymentach można się pobawić jak się chce - to dosyć ciekawy temat.

    Na pewno co pamiętam to AVR'y żeby chodziły na wyższej częstotliwości należy stopniowo rampować zegar. Wyjść od max dopuszczalnej i potem zwiększać częstotliwość - wtedy można dojść do wyższych częstotliwości niż od razu podając określoną.

  • #9 30 Sty 2017 12:05
    R-MIK
    Poziom 36  

    Piotrus_999 napisał:

    Widzę że slave 1-wire pomimo przechwałek nie chodzi jak trzeba.

    Zdziwię ci bo działa. Przy 18MHz wzorcowo, przy 16 i 14,7 jeszcze nie sprawdzałem, ale prawdopodobnie pojawi się "piczek" przez upływem 2us, czyli przed pobraniem próbki przez mastera (według protokołu, sprawdzę w nocie DS248x kiedy to tak naprawdę robi).

    <ciach>

    Moderowany przez dondu:

    3.1.11. Nie wysyłaj wiadomości, które nic nie wnoszą do dyskusji.

  • #10 30 Sty 2017 12:10
    Piotrus_999
    Poziom 39  

    CMB był przetaktowany dla NTSC i niedotaktowany dla PAL. Podjeli to ryzyko aby nie stosować dodatkowych układów scalonych w układzie wyświetlacza. Ale to trochę inny wyrób.

  • #11 30 Sty 2017 12:13
    dondu
    Moderator Mikrokontrolery Projektowanie

    Jednym z najistotniejszych elementów overclockingu mikrokontrolerów jest jakość sygnału taktującego mikrokontroler. Sporo można podkręcić, używając zewnętrznego generatora o idealnym sygnale prostokątnym.

    Podkręcanie za pomocą zmiany kwarcu nie jest tak skuteczne ze względu na ograniczenia charakterystyki wewnętrznego układu oscylatora, do którego kwarc jest podłączony, nawet przy włączeniu CKOPT.

  • #12 30 Sty 2017 12:28
    tmf
    Moderator Mikrokontrolery Projektowanie

    piotrva napisał:

    Na pewno co pamiętam to AVR'y żeby chodziły na wyższej częstotliwości należy stopniowo rampować zegar. Wyjść od max dopuszczalnej i potem zwiększać częstotliwość - wtedy można dojść do wyższych częstotliwości niż od razu podając określoną.


    To wynikało z błędu w niektórych AVRach, polegającego na tym, że po zmianie częstotliwości taktowania, kilka instrukcji po zmianie mogło być błędnie wykonywanych, stąd producent zalecał jako obejście umieszczenie NOPów po każdej zmianie zegara. Drugim ograniczeniem jest wbudowany oscylator - przy zewnętrznym można wycisnąć więcej.
    Niemniej, tak jak piszesz, temat jest kompletnie bez sensu - brakuje mocy - biorę szybszy procesor. Nawet w AVR mamy procesory do 16, 20 lub 32 MHz. Ciągle mało - biorę ARM. Inna sprawa, że zwykle mało mocy wynika z kompletnie skaszanionego algorytmu lub jego implementacji. Nawet przy tym osławionym slave 1-wire autora - 18 MHz to za mało, ja napisałem slave działający na ATTiny13 , który był taktowany zegarem 1,2MHz i nie tylko działało bezproblemowo, to jeszcze procesor się nudził.

  • #13 30 Sty 2017 12:43
    R-MIK
    Poziom 36  

    tmf napisał:
    slave 1-wire autora - 18 MHz to za mało,

    Na 18 działa, 16 będę sprawdzał.

    No i sprawdziłem. Muszę zmartwić @Piotrus_999, na 16MHz działa. jest co prawda piczek 0,25us przy wysyłaniu zera, ale kolega z pewnością wie, dla którego mastera DS248x i przy jakich ustawieniach stanowi to problem. Co do programowych masterów, to w 99% pobierają próbkę dużo później niż 2us od opadającego zbocza sygnału odczytu więc tam "piczek" 1us nie stanowi kłopotu. Całkowity czas obsługi przerwania to 7,9us więc do 9.5 (może 11 nie pamiętam) jeszcze daleko. To wszystko oznacza, że w praktyce na 14,7456MHz (dziwnie okrągła wartość, którą lubię) slave też zadziała.


    tmf napisał:

    ja napisałem slave działający na ATTiny13 , który był taktowany zegarem 1,2MHz i nie tylko działało bezproblemowo, to jeszcze procesor się nudził.

    Mój slave na tak niską częstotliwość nie zejdzie bez zmian w kodzie. Działa na 4MHz, na 2 lub mniej zadziała ale musiałbym zastosować sztuczkę taką jak w overdrive, przygotować bit do wystawienia na następnym przerwaniu.
    Ponadto o emulacji jakich układów mówimy. Ja mogę emulować kilkadziesiąt układów (wybór zmienną w programie a nie przez #define) takich jak eprom, eeprom (działa DS2431), temometry (działa DS24B20) a nie tylko numer seryjny. No SHA itp szyfrowanie to pewnie odpadnie.

  • #14 30 Sty 2017 13:40
    tmf
    Moderator Mikrokontrolery Projektowanie

    @R-MIK A co ma emulacja urządzenia do realizacji protokołu 1-wire? To są dwie oddzielne sprawy. Nie mieszajmy też SHA. Samo wyliczanie SHA nie jest aż takie kosztowne. Tu problem jest w czymś zupełnie innym - jak zaimplementować tego typu algorytmy, żeby nie dało się odtworzyć klucza przez np. analizę poboru prądu czy zależności czasowych.

  • #15 30 Sty 2017 13:53
    R-MIK
    Poziom 36  

    tmf napisał:
    @R-MIK A co ma emulacja urządzenia do realizacji protokołu 1-wire?

    Przy emulacji czegoś więcej niż numer seryjny, do wykonania dochodzą dodatkowe czynności co ma znaczenie w overdrive bo zajmuje cenny czas procesora. Kolega emulował 1-wire slave overdrive i nie napotkał takiego problemu?
    if (ovedrive ) ....
    if (rodzina==xx)....
    Tego nie ma w emulacji DS1900, prawda?

  • #16 30 Sty 2017 14:06
    tmf
    Moderator Mikrokontrolery Projektowanie

    @R-MIK Jeszcze raz - emulacja urządzenia 1-wire, a emulacja protokołu to są dwie różne sprawy. Jeśli je mieszasz to masz potem jakieś monstrualne funkcje, wykonujące się w nieskończoność. Sytuacja jest prosta - master odpytuje o kolejne bity i tyle. Skąd się biorą ich wartości to już kwestia emulowanego urządzenia, a tu MCU ma całą wieczność na dywagacje.

  • #17 30 Sty 2017 14:26
    jaglarz
    Poziom 23  

    Atmega32 20 MHz z modułęm Ethernet, stabilnie od półtorej roku ;-)

  • #18 30 Sty 2017 14:39
    R-MIK
    Poziom 36  

    jaglarz napisał:
    Atmega32 20 MHz z modułęm Ethernet, stabilnie od półtorej roku ;-)

    Czemu aż 20MHz? Jakieś specjalne wymagania, duże obciążenie? Robiłem na M128 16MHz i ENC28J60 (10Mb) odpowiednik DigiConnectMe i śmiga. Działa zarówno przy 5V, jak i przetaktowany o 100% 3V3. Obsługuje komunikację po UDP i konfiguracje przez WWW i UDP.
    Z jakiego napięcia zasilasz Atmega32?

  • #19 30 Sty 2017 14:57
    jaglarz
    Poziom 23  

    Tylko ciekawość czy da radę. 3,3V, pseudo serwer www.

  • #20 30 Sty 2017 16:11
    R-MIK
    Poziom 36  

    jaglarz napisał:
    Tylko ciekawość czy da radę. 3,3V, pseudo serwer www.

    Dlaczego nie? W necie jest sporo projektów, nawet w BASCOM. Dla AVT zrobiłem dwa albo 3 i dla firmy, jeszcze około 2010 roku, zamiennik DigiconnegtMe. Chodzi tego w kraju około 1000szt. Tam byłem zmuszony do 3V3 bo takie było dostępne ale lepiej dać 5V i stabilizator 3V3 dla ENC28J60. Poziomów nie trzeba konwertować bo ENC akceptuje 5V na wejściach. Z minimalnym zegarem trzeba uważać bo przy 8MHz są jakieś problemy z ENC, więc albo dodatkowy kwarc do AVR albo taktowanie z ENC 12,5MHz.

  • #21 01 Lut 2017 05:55
    R-MIK
    Poziom 36  

    Marek_Skalski napisał:
    (...) i pamięć programu ulega szybkiej degradacji. J

    Jako, ze jestem lamerem, wyjaśnij mi proszę problem degradacji pamięci. Max zegar Atmegi128 to 16MHz przy 5V i 8 przy 3V3. Przetaktowałem megę o 100%, przy 3V3 taktuję 16MHz. Dlaczego pamięć ulegnie szybkiej degradacji?

    Czy to nie jest tak jak z zaklejaniem okienek pamięci eprom? Miałem pamięć w urządzeniu, gwarantowany czas utrzymania danych 10lat. Pamięć zaprogramowania programatorem, który wykonałem w 1993roku (był opis w C&A około 1993, MA i EdW około 1997). Okienko oczywiście nie zaklejone bo prototyp. W 2012 jeszcze działał czy dziś tego nie wiem.

    Dodano po 20 [minuty]:

    R-MIK napisał:
    (...)
    Atmega2561 działa na 22,1184 z tym, że po 2 tygodniach przestał działać TWI. Na 18,4321 na razie bez problemu.

    Sprostowanie.
    Na 16MHz TWI też zaczął szwankować (status $F8). Dokładniejsze badania naprowadziły mnie na problem ze sprzętem (jak to w prototypie, dolutowany pin lutowniczy naderwał ścieżkę). Po poprawce TWI dział dobrze także przy 22MHz.

  • #22 02 Lut 2017 00:37
    Marek_Skalski
    Poziom 33  

    @R-MIK Czytaj, proszę, ze zrozumieniem i bez nerwów. Pamięć NOR-flash jest względnie powolna i jest głównym ogranicznikiem taktowania rdzenia. Dodatkowo wymaga bardzo dużo miejsca na powierzchni układu, a jej skalowanie (zmniejszanie) jest bardzo kosztowne. Wielu producentów stosuje pamięć o szerokości znacznie większej niż szerokość magistrali instrukcji danego procesora. Microchip stosuje pamięć o szerokości 128 bitów w uC z rodziny PIC32MZ, podobnie ST stosuje pamięć o szerokości 256 bitów z dodatkową jednostką nazwaną ART akcelerator. Niestety, AVRy są produkowane w oparciu o dość stare technologie i maksymalnie używają pamięci o szerokości 16 bitów, co przekłada się na dość niską wydajność w dostarczaniu instrukcji dla CPU.
    Degradacja pamięci typu NOR Flash używanej typowo jako pamięć programu w mikrokontrolerach, przyspiesza ze wzrostem temperatury. W zależności od technologii wykonania i zastosowanych opcji, zazwyczaj taka pamięć jest klasyfikowana jako stabilna do +85°C, +105°C, +125°C. To zawsze jest kompromis między maksymalną temperaturą pracy, a wieloma innymi parametrami, np. czas kasowania sektora, minimalne napięcie programowania, gęstość (pojemność) pamięci.
    Podnoszenie częstotliwości taktowania, często w połączeniu z podnoszeniem napięcia powoduje wzrost ilości ciepła wytwarzanego w układzie. Dla półprzewodników, to właśnie ciepło jest zabójcze. Ze wzrostem temperatury struktury, rośnie aktywność elektronów, mniej więcej z 4 potęgą temperatury. Powyżej pewnego poziomu określonego technologią wykonania, w fazie odczytu, nie w fazie programowania, wzrasta ryzyko przeładowania komórek pamięci tworzonych przez studnie ładunkowe. Więcej, sam odczyt jest kłopotliwy, ponieważ podwyższone taktowanie skraca czas każdej fazy w odczycie: ustawienie odpowiedniego potencjału na linii słów (~5V) i wirtualnej masy (~0V), włączenie napięcia buforów odczytu (~5V), włączenie napięcia po stronie źródeł (~1.2V), w końcu efektywne przesunięcie poziomów, które zostaną odczytane przez wzmacniacze i zatrzaśnięcie stanu w rejestrze wyjściowym, czyli z punktu widzenia CPU, pobranie instrukcji. Aby było trudniej, to odczyt komórki pamięci może dać 3 wartości: -, 0, +. Jeżeli jest umowny '-', to przyjmuje się, że bit ma wartość 1 (jest skasowany). Umowny '+', oznacza bit o wartości 0 (zaprogramowany), a umowna wartość '0', oznacza nieprawidłowy odczyt i konieczność podwyższenia zasilania. To właśnie tutaj jest ryzyko przeładowania wartości komórki i uszkodzenie danych.
    W kwestii odporności termicznej, procedurę testowania pamięci zazwyczaj realizuje się według JESD47I (do pobrania ze strony JEDEC). Co jest istotne, testy żywotności pamięci (ilości bezbłędnych kasowań) prowadzi się w temperaturze 25°C, 50% testów, a kolejne 50% w temperaturze >55°C. Najczęściej jest to 85°C, czyli przyjęta granica dla NOR Flash. Testy trwałości zawartości pamięci prowadzi się w temperaturze 125°C. Test jest zaliczony pozytywnie, jeżeli sektory zapisane tylko 1 raz przetrwają 1000h i sektory zapisane 1000x oraz 10000x przetrwają 100h, a sektory zapisane 100000x są zdolne utrzymać zawartość przez zaledwie 10h.
    Podsumowując, zwiększone taktowanie skraca czas dla kontrolera pamięci na właściwe odczytanie jej zawartości. Nieprawidłowy odczyt wymusza stosowanie wyższego napięcia 'czytającego', co samo w sobie już zwiększa ryzyko naruszenia integralności danych. Podwyższenie napięcia zasilania w połączeniu ze zwiększonym taktowaniem oznacza wzrost ilości ciepła generowanego w układzie, co w połączeniu z podwyższoną temperaturą otoczenia może doprowadzić do lawinowego wzrostu aktywności elektronów w strukturze pamięci i utratę jej zawartości. To, że ktoś, gdzieś, zaprogramował układ mikrokontrolera kilka razy, zwiększył taktowanie 2x przy obniżonym zasilaniu w temperaturze 25°C i przez godzinę obserwował miganie diody albo przesyłanie danych przez I2C nie jest żadną gwarancją, że taki układ będzie działał w sposób bezawaryjny w zakresie temperatur i w czasie przewidzianym dla innej aplikacji. Jeżeli producent określa żywotność pamięci na 10k cykli, a trwałość na 20 lat, to nie robi tego ze względu na chęć ukrycia lepszych parametrów, ale ze względu na odpowiedzialność prawną w przypadku niedotrzymania deklarowanych wartości parametrów. Podobnie jak każdy następny podmiot, który tworzy wartość dodaną i jest wiarygodnym partnerem biznesowym.
    Ale mam dobrą wiadomość. Jak wszystko pójdzie dobrze, to za 2-3 lata dotychczasowe pamięci zostaną zastąpione przez pamięci programowalne zawierające tlenek hafnu, co pozwoli zmniejszyć rozmiar technologiczny z 90nm do 22nm, może nawet 16nm, przyspieszyć odczyt 4x i zmniejszyć zużycie energii przynajmniej 10x i koszt produkcji kilka razy. Wtedy inne ograniczenia będą decydowały o maksymalnej częstotliwości taktowania uC. Obawiam się jednak, że AVRy nie dostaną tych nowych pamięci.

  • #23 02 Lut 2017 01:08
    R-MIK
    Poziom 36  

    I ty leży sedno sprawy. Max częstotliwość jest gwarantowana przy max zasilaniu (6 lub 5,5V), max temperaturze itp. Jeśli przekraczamy jeden z tych parametrów, można wyciągnąć więcej. Zgodzę się, że 22MHz dla Atmegi1281 to za dużo przy max zasilaniu i temp struktury. Jeśli więc procek pracuje przy 4,7V (tyle mam realnie, zasilanie z USB, ale należy przyjąć, że może być i 5,1V w/g normy) i temperatura "pokojowa" (max 40 stopni), to na 22MHz będzie działać i działał prawie dwa miesiące, teraz zmniejszyłem do 18MHz bo udało się zoptymalizować kod (problemy z TWI nie były spowodowane częstotliwością taktowania)..

  • #24 02 Lut 2017 01:26
    piotrva
    Moderator Mikrokontrolery

    R-MIK napisał:
    temperatura "pokojowa"

    Niestety nie wiadomo co dzieje się na poziomie struktury krzemowej.

    Ja prowadzę badania i temperaturę mamy w większości badań "pokojową". Ale przez elementy płyną prądu rzędu MA/cm2 (średnice rzędu 100nm) i ich nagrzewanie się jest zauważalne w wynikach (punktowo może być i po 80-100 stopni).

    Swoją drogą co to za projekt?

  • #25 02 Lut 2017 03:09
    R-MIK
    Poziom 36  

    piotrva napisał:

    Swoją drogą co to za projekt?

    1-Wire slave w overdrive. Bez wspomagania sprzętowego 16MHz to ciut za mało aby przebieg był "katalogowy" (pojawia sie nieodpowiedni stan na 0,25us) jakkolwiek większość masterów go akceptuje bo próbkę bierze dużo później. Przy 18,4321 jest wzorcowo a i częstotliwość UART'owa. Małe AVR'y pracują do 20MHz i problemu nie ma, na dużej albo przetaktowanie albo sprzęt (przerzutnik D). Wtedy to do 12 może nawet 10MHz będzie można zejść (14,7456MHz też UART'owy).
    To właśnie ten projekt spowodował moje zainteresowanie Overclocking'em. Pierwotne założenia nie przewidywały overdrive i zapas mocy był duży.

  • #26 02 Lut 2017 13:35
    piotrva
    Moderator Mikrokontrolery

    @R-MIK - zatem mam 2 pytania:
    1. Dlaczego nie weźmiesz procesora AVR, który może działać na 20MHz? Np. Atmega1284 czy 644?
    2. Dlaczego nie porzucić przestarzałych AVRów na korzyść choćby STM32? (ma wejścia tolerujące 5V, pracujące w trybie OD i wiele większą moc obliczeniową) Tu pewnie bawisz się już w ASM, na jakimś ARM zapomnisz o takich problemach.
    (przykład choćby WS2812 - na AVR to gimnastyka w ASM, na ARM - ustawienie kilku peryferiów i zapominasz o problemach ze sterowaniem tych diodek)

  • #27 02 Lut 2017 14:00
    R-MIK
    Poziom 36  

    piotrva napisał:
    @R-MIK - zatem mam 2 pytania:
    1. Dlaczego nie weźmiesz procesora AVR, który może działać na 20MHz? Np. Atmega1284 czy 644?

    PCB już było zrobione jak przyszedł pomysł na overdrive.

    piotrva napisał:

    2. Dlaczego nie porzucić przestarzałych AVRów na korzyść choćby STM32?

    Bo około 6miesięcy będę poznawał go a właściwie kompilator. Były dwa pomysły na projekt z STM (jeden to ethernet drugi z niskim poborem mocy - wcześniej był LPC) ale eth został na AVR, a drugi projekt upadł.

  • #28 02 Lut 2017 14:18
    piotrva
    Moderator Mikrokontrolery

    R-MIK napisał:
    PCB już było zrobione jak przyszedł pomysł na overdrive.

    Nie są pinowo kompatybilne przypadkiem?
    Poza tym cóż - ja pod projekt elektroniki do symulatora lotów robiłem 3 wersje płytek, w tym 2 ze zmianą jednostki centralnej, zanim wybrana okazała się optymalna pod kątem cena/osiągi.

    R-MIK napisał:
    Bo około 6miesięcy będę poznawał go a właściwie kompilator.

    Nie przesadzajmy, jest CubeMX, jest IDE oparte o Eclipse, język C jest ten sam. To kwestia 2-3 tygodni dla osoby, która zrobiła tyle projektów co Ty. Poza tym wiedza ma to do siebie, że raz zdobyta zostaje na zawsze (pomijam demencje itp. ;) ) Ja też miałem długo opory do zmian swego czasu.

  • #29 02 Lut 2017 14:33
    R-MIK
    Poziom 36  

    piotrva napisał:
    R-MIK napisał:
    PCB już było zrobione jak przyszedł pomysł na overdrive.

    Nie są pinowo kompatybilne przypadkiem?

    Nie sprawdzałem, ale jeśli tak to właśnie ustaliłem zrobienie drugiego prototypu więc mogę nawet zmienić typ obudowy.
    Tak jak myślałem, tak ze 20 pinów mniej.

    piotrva napisał:

    Poza tym cóż - ja pod projekt elektroniki do symulatora lotów robiłem 3 wersje płytek,

    Tylko? Zobacz CTAC . Trzy sterowniki (Z80, MC68000, 8051 40MHz, miał być jeszcze na AVR. Dwie wersje karty abonenckiej, dwie sygnałowej.

    piotrva napisał:

    To kwestia 2-3 tygodni dla osoby, która zrobiła tyle projektów co Ty.

    No właśnie, ile mogę zrobić w 3 tygodnie. Jak bedę robił coś bardziej skomplikowanego na ETH, mix typu USB, karty SD to sięgne po STM (mam debuger).

 
Promocja -20%
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
tme