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

ATMEGA32 - oszacowanie kondensatora do podtrzymania zasilania przy zapisie EEPROM

arturromarr 24 Lis 2016 19:44 1443 16
  • #1 16083675
    arturromarr
    Poziom 17  
    Witam,
    Chcę zrobić podtrzymanie zasilania przy wyłączeniu na czas zapisu danych do pamięci trwałej EEPROM.
    Muszę chociaż wstępnie oszacować jaki kondensator będzie potrzebny na wejściu zasilania.
    Nie mogę w dokumentacji znaleźć jaki jest prąd pobierany podczas zapisu danych i ile trwa ten zapis.
    Procesor z wyłączonymi peryferiami (wyłączę wszystko po wykryciu braku zasilania) przy zasilaniu 3V ma pobierać około 11mA, ale przy zapisie pewnie sporo więcej. Czy te wartości zależą od kwarcu, czy można przyjąć jakieś wartości szacunkowe?
    Można gdzieś ustalić średni prąd i czas przy zapisie do EEPROM?
    Potrzebuję zdążyć zapisać 500 bajtów (i jeszcze będzie zapisanie czasu i daty do zegarka PCF8563).

    Proszę o jakieś wskazówki.
  • #2 16083882
    dondu
    Moderator na urlopie...
    Faktycznie w dokumentacji nie ma chyba na ten temat informacji.
    Na czas zapisu do EEPROM usypiaj mikrokontroler do trybu IDLE lub ADC Noise Reduction.

    arturromarr napisał:
    Procesor z wyłączonymi peryferiami (wyłączę wszystko po wykryciu braku zasilania) przy zasilaniu 3V ma pobierać około 11mA, ...

    Skąd te dane?

    Czasy zapisu są w dokumentacji w rozdziale o EPROM.
  • #3 16084268
    krisRaba
    Poziom 31  
    Najłatwiej, jeśli masz np. oscyloskop, to zrobić kilka powtórzeń takiego "awaryjnego zrzutu" danych, ze wszystkim co wtedy chcesz mieć zrobione (żeby uwzględnić wszystkie instrukcje do wykonania) i monitorując GPIO (przestawiane na początku i końcu procedury) zmierzyć czas empirycznie (no a prąd to jakoś oszacować średni na podstawie miernika). Kilka razy, żeby sprawdzić powtarzalność. Ewentualnie przy braku oscyloskopu można odpalać timer i wyciągać wynik...
    W ramach eksperymentu możesz przygotować taką procedurę wyzwalaną przerwaniem (bo finalnie pewnie jakiś komparator powiadomi MCU, że zniknęło zasilanie z wejścia układu), tyle że napięcia nie ściągać. I testować :) Bo w DS jest jakaś wzmianka, że przy zapisie do EEPROM można sprawdzać flagę gotowości (polling) albo odczekać czas tWLRH (punkt 8 na str.285), albo na str.20 w tabelce, że programowanie EEPROM trwa średnio 8.5ms. Ale lepiej sprawdzić czas całości...
    http://www.atmel.com/Images/doc2503.pdf

    A już najlepiej najlepiej ;), to mieć narzędzie, które monitoruje dokładnie prąd w czasie i jest w stanie podać sumaryczne zużycie energii podczas takiego zrzutu :D SiLabs ma taki wynalazek na StarterKicie do modułów BLE ;) Przydatna rzecz.

    Albo zastosować nowość od Microchipa, czyli EEMEM :D Ciekawy wynalazek, choć chwilowo mają małe pojemności. Ale do Twoich zastosowań by wystarczyło. To EEPROM+RAM na I2C. Dopóki jest zasilanie działa jak zwykły RAM, więc bez ograniczeń zapisów, a jak traci zasilanie, to robi automatycznie zrzut do EEPROM, tak jak Ty chcesz to robić ;) Choć wiadomo, to dodatkowy klocek i koszt w BOM...
  • #4 16084537
    BlueDraco
    Specjalista - Mikrokontrolery
    500 bajtów - to zdecydowanie za dużo. Przemyśl ten algorytm. Przecież te dane nie zmieniają się wszytskie równie często i niespodziewanie.
  • Pomocny post
    #5 16084572
    michalko12
    Specjalista - Mikrokontrolery
    BlueDraco napisał:
    500 bajtów - to zdecydowanie za dużo. Przemyśl ten algorytm. Przecież te dane nie zmieniają się wszytskie równie często i niespodziewanie.

    Ja się nie zmieniają to wystarczy użyć odpowiedniej funkcji eeprom_update_block().
    krisRaba napisał:
    Albo zastosować nowość od Microchipa, czyli EEMEM :D Ciekawy wynalazek, choć chwilowo mają małe pojemności.

    EERAM. Równie dobrze można wykorzystać FRAM, najlepiej na SPI.
  • #6 16084662
    arturromarr
    Poziom 17  
    Dziękuję za odzew.
    krisRaba napisał:
    programowanie EEPROM trwa średnio 8.5ms

    To mi wychodzi w moim przypadku ponad 4s!! . Czy to jest czas uwzględniający jakiś minimalny kod obsługujący zapis (pętla ze sprawdzeniem zmiany), czy w praktyce wyjdzie jeszcze więcej?
    krisRaba napisał:
    Albo zastosować nowość od Microchipa, czyli EEMEM

    Fajna sprawa bo o taką funkcjonalność mi chodzi, tylko, że mam gotową płytkę i miałem nadzieję, że da się zrobić coś w jej ramach.
    BlueDraco napisał:
    500 bajtów - to zdecydowanie za dużo. Przemyśl ten algorytm

    Typowa sytuacja, czyli pracujemy na jakimś zbiorze danych i chcemy by nie ulatywały po wyłączeniu. Obecnie w prowizorycznym programie zapisuję je właśnie na bieżąco w przypadku wykrycia zmiany takiego rejestru co oczywiście w dalszej przyszłości zabije EEPROM.
    Idealnie było by pracować tylko na RAM-ie i zapisać do EEPROM tylko przy wyłączeniu. W tym układzie też najlepiej sprawdzać czy coś się zmieniło, ale itak trzeba założyć najgorszy przypadek zmiany wszystkich rejestrów bo układ może pracować długo bez wyłączenia.
    michalko12 napisał:
    EERAM. Równie dobrze można wykorzystać FRAM, najlepiej na SPI

    Jeśli nic się nie da zrobić w tym rozwiązaniu które mam i będę musiał przerabiać płytkę to co jest lepsze (wygodniejsze, tańsze, dostępniejsze) EERAM czy FRAM? Znalazłem jakieś EERAM-y ale są tylko na I2C (SPI było by chyba szybsze) i nic nie piszą o pojemności Cvcap. Teoretycznie jakbym miał dokładać większy kondensator to mogę dać go na głównym zasilaniu i zapisywać przez te 4s do jego EEPROM-u.
    Czy czas zapisu w FRAM-ie jest na tyle szybki, że mieście się w czasie przesyłania danych do układu i można go pominąć, czy trzeba go uwzględnić?
  • #7 16084685
    krisRaba
    Poziom 31  
    michalko12 napisał:
    EERAM. Równie dobrze można wykorzystać FRAM, najlepiej na SPI.

    Fakt, machnąłem się :D
  • #9 16084704
    krisRaba
    Poziom 31  
    W sumie dlatego pisałem, żeby to po prostu zmierzyć dla całej procedury, bo pewnie gdybyś robił zapis blokowy, to nie będzie to czas odpowiadający wielokrotności zapisu pojedynczego.
  • #10 16084722
    arturromarr
    Poziom 17  
    dondu napisał:
    Pokaż jak to robisz.

    Jak mam pokazać, to jest już duży program (zajmuje prawie całą pamięć 32-tki) w całej swojej objętości zmienia te rejestry a w głównej pętli sprawdza kolejny rejestr czy nastąpiła w nim zmiana zmiana i jeśli tak to zapisuje do EEPROM-u. Nie zmienia się na raz cały pakiet danch więc zapis jest rozłożony w czasie i gdyby nie żywotności EEPROM-u to było by dobrze. Jednak gdybym miał zapisywać w najgorszym przypadku wszystko przy wyłączeniu to z tych ponad 8ms przy 500 danych robi się sporo czasu.
    dondu napisał:
    Odpowiedz na moje pytanie z pierwszego postu

    Prąd źle odczytałem z wykresu dla poboru peryferiów a nie bez peryferiów, Jest gdzieś podany prąd taki "jałowy" bez obsłużonych peryferiów?
  • #11 16084728
    dondu
    Moderator na urlopie...
    arturromarr napisał:
    Jak mam pokazać, to jest już duży program (zajmuje prawie całą pamięć 32-tki) w całej swojej objętości zmienia te rejestry a w głównej pętli sprawdza kolejny rejestr czy nastąpiła w nim zmiana zmiana i jeśli tak to zapisuje do EEPROM-u.

    Pytałem o konkretny jego fragment. Skoro zajmuje Ci to 4s to znaczy, że masz błędny algorytm, bo nie sądzę, by był to jakiś niemożliwy do obejścia problem.


    arturromarr napisał:
    Prąd źle odczytałem z wykresu dla poboru peryferiów a nie bez peryferiów, Jest gdzieś podany prąd taki "jałowy" bez obsłużonych peryferiów?

    To właśnie te wykresy dla różnych przypadków. Inaczej niż na wykresach nie da się tego przedstawić.
  • #12 16084744
    michalko12
    Specjalista - Mikrokontrolery
    arturromarr napisał:
    Czy czas zapisu w FRAM-ie jest na tyle szybki, że mieście się w czasie przesyłania danych do układu i można go pominąć, czy trzeba go uwzględnić?
    Działa jak RAM, więc nie ma żadnego oczekiwania. Po drugie nie ma limitu operacji kasowanie/zapis.
  • #13 16084755
    arturromarr
    Poziom 17  
    dondu napisał:
    Pytałem o konkretny jego fragment. Skoro zajmuje Ci to 4s to znaczy, że masz błędny algorytm, bo nie sądzę, by był to jakiś niemożliwy do obejścia problem.

    Nic mi tyle jeszcze nie zajmuję, bo robię to obecnie na bieżąco przy zmianach, ale teoretycznie jeśli czas zapisu EEPRO to ponad 8ms to zapis wszystkich 500 danych po zaniku zasilania zajmie ponad 4s tak?
  • #14 16087908
    Janusz_kk
    Poziom 38  
    To dołóż diodę schotkiego i super capa na zasilaniu samego procka, 0,5 - 1F da ci dość dużo czasu na zapis.

    Janusz
  • #15 16096795
    arturromarr
    Poziom 17  
    Dziękuję wszystkim za podpowiedzi.
    Zdecydowałem, że przy takiej liczbie danych najlepiej będzie dorobić pamięć FRAM do układu.

    Pozdrawiam.
  • #16 16097199
    tmf
    VIP Zasłużony dla elektroda
    arturromarr napisał:
    Dziękuję wszystkim za podpowiedzi.
    Zdecydowałem, że przy takiej liczbie danych najlepiej będzie dorobić pamięć FRAM do układu.

    Pozdrawiam.


    Nie ma jak sobie wziąć starego trupa i potem próbować go reanimować:) ATMega32 to historia, weź sobie np. ATMega328 i tam po pierwsze całkowity czas zapisu to już tylko 3,4 ms, w dodatku można go rozdzielić na kasowanie i zapis i wtedy zapis to już tylko 1,8ms/komókę. Czyli masz 900 ms na zapis 500 bajtów, ale... jeśli masz potrzebę zapisu takiej liczby danych to raczej algorytm jest kiepski i zapewne część danych jest niezmienna, czyli nie zajdzie potrzeba ich zapisu. Poza tym 900 ms to już można spokojnie takie podtrzymanie zrobić. Albo... użyć AVR XMEGA, gdzie EEPROM jest zapisywany w blokach po 32 bajty, więc zapis 500 zajmie tylko 28 ms. Albo... zapisywać do FLASH - zapis odbywa się stronami i też nawet w ATMega zajmie to kilkadziesiąt ms. Ponieważ zapisujesz tylko przy awarii zasilania, to limit min. 10k zapisów (w rzeczywistości wielokrotnie więcej) nie jest żadnym ograniczeniem.
  • #17 16114286
    arturromarr
    Poziom 17  
    Cóż, projekt zaczynał się od czegoś małego i z czasem się rozrósł. Czeka mnie przesiadka na lepszy model bo kończy mi się już flash. Zastanawiam się nad ATMEGA644. Jak dobrze zrozumiałem dokumentację to podobna architektura do ATMEGA64 w obudowie 44 pinowej? Mam zamiar się zabrać za XMEGI ale podchodzę jak do jeża bo pewnie jest więcej różnic a przy takim długim programie łatwiej było by mi podmienić teraz na tego 644.
    arturromarr napisał:
    Czyli masz 900 ms na zapis 500 bajtów, ale... jeśli masz potrzebę zapisu takiej liczby danych to raczej algorytm jest kiepski i zapewne część danych jest niezmienna, czyli nie zajdzie potrzeba ich zapisu

    Czemu to takie dziwne że jak mam pewną ilość danych na których program pracuje to muszę założyć że wszystkie się zmienią i nie jest to wina algorytmu. nie chcę zapisywać zmian w trakcie wykonywaniu programu bo to go spowolni, najwydajniej pracować na RAM-ie i zrobić jego "zrzut" po zaniku zasilania skoro mam wykrywanie tego stanu.
    Podłączyłem FRAM-a, działa super, dzięki za podpowiedź. Trochę się namęczyłem zanim załapałem z dokumentacji, że przed każdym zapisem trzeba uaktywnić zapis, bo trochę niejasno to opisali na przebiegach a człowiek się spieszy i nie czyta :).
REKLAMA