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

AVR - Zapis tablicy zmiennych do pamięci Flash z programu

winio42 30 Paź 2016 08:01 3039 20
  • #1 16027048
    winio42
    Poziom 19  
    Szanowni koledzy,
    chciałbym zrobić projekt, w którym mikrokontroler będzie generował pewne określone wartości napięcia analogowego za pomocą DACa (16 bit, podłączony przez SPI). Rozdzielczość czasowa jednego okresu sygnału wynosiłaby 2^12 (czyli 4096) próbek na okres. W sumie, na jeden okres spróbkowanego sygnału potrzeba 8kB pamięci. Mikrokontroler ma mieć możliwość zdalnego (przez Bluetooth, dokładnie moduł HC05 UART-Bluetooth) zmieniania sekwencji generowanego napięcia bez konieczności przeprogramowania. Najłatwiej byłoby oczywiście zapisać wszystko do RAMu, ale to niemożliwe, bo ATMega 328P (taki scalak został wybrany) tyle go nie ma. Czy jest możliwość (i jak to zrobić) aby zapisywać otrzymaną przez UART (BT) sekwencję danych (8kB) do pamięci Flash (ma 32kB) i stamtąd odczytywać ją poprzez pgm_read_byte? Funkcja realizująca zapis do Flasha pobierałaby dane z UARTa do jakiegoś bufora zawartego w RAM (np. 256 bajtów) i zapisywała pełnymi blokami do Flasha.

    Zrobiłem pewne rozeznanie dotyczące projektu i wiem, że:
    *Do komunikacji przez BT mogę użyć HC05 i wypróbowałem go - działa
    *Z pamięci Flash mogę czytać poprzez pgm_read_byte
    *Flash zapisuje się blokami i ma on ograniczoną liczbę operacji zapisu, stąd nie należy tego robić za często
    *Można używać DACa zrobionego z PWM, ale dla mnie ma za mało bitów (albo jest za wolny, bo jedno od drugiego zależy)
    *Wiem że można jakoś zapisywać do Flash, ale nie mogę znaleźć (i zrozumieć) precyzyjnej informacji jak to zrobić (często przewija się słowo bootsector i bootloader, więc coś pewnie jest z nimi na rzeczy)
    *Nie istnieje makro pgm_write_byte

    pozdrawiam i proszę o pomoc!

    PS: Napisałem powyższy post w temacie
    [AVR] - "zmienna flash'owa" - zapis do flasha
    ale administratorzy kazali mi założyć nowy, co niniejszym czynię
  • #2 16027218
    tmf
    VIP Zasłużony dla elektroda
    @winio42 Poczytaj o bootloaderze - przy okazji dowiesz się jak zapisywać FLASH. W skrócie - musisz stworzyć kod umieszczony w specjalnej części pamięci FLASH, który skasuje stronę, a następnie ją zapisze twoimi danymi. Jak to zrobić jest opisane w nocie procesora. W nocie AVR Instruction Set przejrzyj informacje dotyczące instrukcji SPM.
  • #3 16027223
    Konto nie istnieje
    Konto nie istnieje  
  • #4 16027244
    tmf
    VIP Zasłużony dla elektroda
    @Piotrus_999 Przecież autor wyraźnie napisał, że chodzi o 4096 próbek. Skoro MCU ma generować przesłany okres i jak wynika z postu nic więcej, to spokojnie da radę. Problem byłby, gdyby ten wzorzec miał byc często zmieniany, co zarżnie FLASH. W takiej sytuacji trzebaby procka z większą ilością RAM. Lub sprytnego układu typu prosty MCU + pamięć SPI + DAC z SPI. Ale nie ma sensu dywagować, niech autor się ustosunkuje.
  • #5 16027300
    Konto nie istnieje
    Konto nie istnieje  
  • #6 16027301
    winio42
    Poziom 19  
    Już się stosunkuję - potrzeba dokładnie tak jak zauwazył kolega TMF - 4096 próbek po 2 bajty każda. Wzorzec nie będzie często zmieniany (i będzie zmieniane całe 8kB naraz).

    @piotrus Co do ARM to nie mam do nich programatora, nie wiem jak jest ze środowiskiem (w AVR jest darmowe Atmel Studio z symulatorem), ich datasheety nie są dla mnie tak przejrzyste jak te Atmela, a poza tym jest tam bardzo dużo rzeczy wymagających konfiguracji (samo głupie zamryganie diodą to sporo kodu) - można używac bibliotek, które pewnie raz działają, a raz nie, a można pisać bez bibliotek ale to orka w porównaniu z AVR. Zresztą, AVR są dostępne w przyjaźniejszych dla początkującego obudowach, niekoniecznie TQFP 0,5mm...

    @tmf - w sumie dokupienie RAMu obsługiwanego przez SPI nie jest głupie - mógłbym przechowywać wiele wzorców naraz bez konieczności każdorazowego ładowania przez BT. Mógłbyś rzucić na szybko nazwą niedrogiej kości (DIP lub smd 1,27mm, np. SOP)?
  • #7 16027310
    Konto nie istnieje
    Konto nie istnieje  
  • #8 16027335
    winio42
    Poziom 19  
    Piotrus_999 napisał:
    winio42 napisał:
    Już się stosunkuję - potrzeba dokładnie tak jak zauwazył kolega TMF - 4096 próbek po 2 bajty każda. Wzorzec nie będzie często zmieniany (i będzie zmieniane całe 8kB naraz).


    Jaki jest okres? Te próbki ile razy na sekundę mają być wysyłane do DAC-a (nie chodzi o częstotliwość zmiany wzorca)


    To zależy, ale raczej nie większa niż kilka kHz (przy czym samo pasmo DACa musi być większe, bo to nie będą tylko sygnały sinusoidalne, ale np. piła, prostokąt, impuls)
  • #9 16027343
    Konto nie istnieje
    Konto nie istnieje  
  • #10 16027390
    tmf
    VIP Zasłużony dla elektroda
    @winio42 Zanim pójdziemy dalej uściślijmy pewne rzeczy. Chcesz mieć 4096 próbek na okres i generować do kilku kHz (przyjmijmy 10 kHz, ok?). To daje nam konieczność transferu 10000*16bitów*4096 próbek, czyli ok. 81 MB/s. Zdajesz sobie z tego sprawę? Sam DAC przy tym musi mieć pasmo ponad 40 MHz. Zdajesz sobie z tych faktów sprawę? Teraz tak, oczywiście to się da zrobić, tylko potrzebujesz naprawdę dobrego DAC (a co za tym idzie będzie to kosztować), oraz układu, który efektywnie takie ilości danych będzie mógł przesyłać. Zanim będziemy dalej to rozważać napisz, czy rzeczywiście o coś takiego ci chodzi, czy jednak interesuje cię coś prostszego?
    Jeśli to może mieć nie aż tak wyśrubowane parametry, to weź ukłąd typu VS1103b lub VS1053, który ma odpoiwiednią ilość RAM, ma dobre 16-bitowe DACe + wzmacniacze wyjściowe, ma też na pokładzie wydajny procesor DSP i tym generuj przebiegi. Można program napisać wprost na ten procek (IDE i kompilator są za darmo), lub połączyć to z jakimś prostym MCU, np. ATMega. Rozwiązanie proste i tanie.
  • #11 16027412
    Konto nie istnieje
    Poziom 1  
  • #12 16027439
    Konto nie istnieje
    Konto nie istnieje  
  • #13 16027458
    winio42
    Poziom 19  
    Czuję się zaburczany.
    Rozwiązanie, o którym myślałem jak widzę nie ma sensu. Przyznaję - moja wina. Nie do końca przemyślałem sprawę.
    Dziękuję za uświadomienie problemu.
    Aby temat nie został bez żadnej merytorycznej zawartości - powiedzcie proszę, abstrahując od zastosowania, jak w miarę łatwo zapisywać dane do flasha z programu, jeśli macie link do jakiegoś przykładu to poproszę.
  • #14 16027468
    tmf
    VIP Zasłużony dla elektroda
    @Marek_Skalski Marku, trochę kreatywności. Pamięć SPI z prockiem nie musi być łączona przez QSPI, skoro tylko rzadko chcemy wpisywać do niej nowe próbki. QSPI powinno być pomiędzy pamięcią a DACem. Są pamięci, które umożliwiają dynamiczną zmianę interfejsu. Mając taką pamięć, która pracuje jako FIFO/LIFO, wystarczy z MCU zapodać taktowanie i reszta dzieje się automatycznie. Tu jedyne co będzie wymagane to posty procesor, który prześle dane i wygeneruje przebieg. Oczywiście ATMega328 za dużej częstotliwości nie wygeneruje i w sumie pomysł i tak padnie, chyba, że z tych QSPI zrobimy np. 16-bitowy interfejs do DAC. Można też użyć jakiś pamięci FIFO np. z ITD, jednak może być problem z zakupem. Wspomniałem o układach VS1xxx, które przy nieznacznym zmiejszeniu oczekiwań byłyby idealne, można też zastosować np. VS23S010 - mamy pamięć z interfejsem R/W i interfejsem wyjściowym SPI/QSPI/równoległym, dostępną i tanią. Tu MCU ma drugorzędne znaczenie, bo dla parametrów podanych przez autora ledwo super taktowane ARMy wydolą, efekt będzie taki, że wrzucimy ARMa taktowanego 300 MHz, w obudowie BGA208, żeby robił za licznik adresowy do pamięci... Nie wspomnę już o rozwiązaniu typu proste CPLD, w którym zaszyjemy sterownik do pamięci z wypluwaniem danych na interfejs do DAC.
  • #15 16027473
    Konto nie istnieje
    Konto nie istnieje  
  • Pomocny post
    #16 16027480
    tmf
    VIP Zasłużony dla elektroda
    winio42 napisał:
    Czuję się zaburczany.
    Rozwiązanie, o którym myślałem jak widzę nie ma sensu. Przyznaję - moja wina. Nie do końca przemyślałem sprawę.
    Dziękuję za uświadomienie problemu.
    Aby temat nie został bez żadnej merytorycznej zawartości - powiedzcie proszę, abstrahując od zastosowania, jak w miarę łatwo zapisywać dane do flasha z programu, jeśli macie link do jakiegoś przykładu to poproszę.


    Masz kilka rozwiązań, od prostych do relatywnie skomplikowanych. Co do zapisu FLASH - napisałem ci - ściągnij AVR instruction set i zobacz opis instrukcji SPM. Do tego w manualu przejrzyj opis sekcji pamięci FLASH. Zobacz też opis funkcji z nagłówka boot.h z bibilioteki AVRlibc, którą używasz, szczególnie funkcje boot_page_fill, boot_page_erase, boot_page_write.
  • #17 16027492
    Konto nie istnieje
    Konto nie istnieje  
  • #18 16027533
    Konto nie istnieje
    Poziom 1  
  • #19 16028358
    winio42
    Poziom 19  
    To uporządkujmy:
    1) Przede wszystkim chodziło mi o wskazanie kierunku jak można pisać do pamięci Flash z programu, dziękuję koledze tmf za wskazówki
    2) Opisałem do czego jest mi to potrzebne, padło pytanie o liczby, więc odpisałem trochę na szybko i liczby podałem od czapki, co spowodowało ogólny zamęt. Mam wrażenie, że czytając na szybko nie zrozumiałem kolegi piotrusia, przez co wyszły mi bzdury. Chodziło mi o to, że sygnał jaki chcę uzyskać z DACa ma mieć maksymalne pasmo kilkanaście KHz, a nie o to, że chcę przemiatać 4096 próbek kilkanaście tysięcy razy na sekundę - wtedy (nawet mając nieskończoną ilość RAMu w procesorze) na sam transfer po SPI potrzebuję zegara na poziomie Pentium III, a dodatkowo zabawiać się w zagadnienia integralności sygnałowej typu terminacja linii etc. Źle napisałem, przepraszam.
    3) Chcę, aby pasmo mojego sygnału wynosiło, powiedzmy 10kHz, czyli, o ile dobrze rozumiem, potrzebuję wygenerować 20 tysięcy próbek na sekundę. Mając zapisane 4096 w pamięci muszę przemieść ją jakieś 5 razy na sekundę, czyli zegar SPI to jakieś 16(2bity/próbkę)*4096*5= 330kHz, Atmega się wyrobi.
    4) Wielu kolegów, między innymi Marek namawia mnie do użycia STM32, dla przykładu weźmy STM32L4 - rzeczywiście, rdzeń szybki, ma DMA i DAC, ale - jak sam napisałeś - do zabawy z nim należy zaopatrzyć się w płytkę np. Discovery - nie jest to problem, bo mogę (i to akurat dokładnie taką) przytulić za darmo.
    *Chodzi bardziej o fakt używania tych procesorów w gotowych projektach - dla STM32L4 tutaj są jego obudowy: http://www.st.com/en/microcontrollers/stm32l4-series.html?querycriteria=productId=SS1580
    w skrócie - BGA (odpada absolutnie), WLSCP (odpada absolutnie), LQFP (trudna, ale można próbować).
    *Dalej: programator i środowisko - w AVR mam USBASP i darmowe Atmel Studio, z w ARM?
    *Dalej - datasheety i ich przejrzystość (tak piotrusiu, czytałem je)
    *Dalej - biblioteki - w STM32 z tego co pamiętam była STDLib albo te nowe HAL w STMCube - czyli (jak dla mnie) albo programowanie tego jest dużo bardziej abstrakcyjne niż w AVR (HAL) albo jest dużo więcej różnych rejestrów i pierdół do konfiguracji (STDLib lub bez bibliotek).
    5) Co do zaczepek w stylu 'nie lubi ARM bo nie umie czytać datasheetów, pewnie nigdy nie widział ich na oczy a marudzi' - pozostawię bez odpowiedzi. Używałem kiedyś na próbę jakiś STM32 (chyba F103), w środowisku KEIL (tą darmową wersją). Biblioteki STDLib - proszę porównać ile trzeba się nakonfigurować, aby zamigac diodą tu i w AVR. Oprócz tego miewałem różne przygody z programatorem - był wbudowany w Nucleo, przez USB (a czym zaprogramuję goły procesor, bez ewalki?) Z ARMów miałem też ewalkę od Freescale'a (Kinetis KL25Z) - na plus całkiem fajne środowisko (CodeWarrior), było tam tez narzędzie Processor Expert (coś jak HAL w STM32, ułatwia programowanie ale oddala od sprzętu, tj od tego jak kod jest fizycznie realizowany). Pamiętam, że miganie diodą w Kinetisie zajmowało dobrych kilka kB pamięci (a ile w AVR? kilkadziesiąt bajtów?) Programowanie też przez ewalkę, przez USB od razu ze środowiska, w AVR dostawałem plik .hex który wgrywałem bezpośrednio do procesora - używając tych gotowych ewalek z całymi rozbudowanymi środowiskami i bibliotekami czuję się trochę jakbym programował jakieś Arduino - oczywiście, o wiele mocniejsze, ale jednak.
    6) Oczywiście, są rzeczy, dla których nie obejdzie się bez ARMa ze względu na jego szybkość (nawet nie same megaherce, ale też DMA, które pozwala zaoszczędzić sporo taktów zegara), tutaj chyba jednak można się obejść bez ARM i zachować prostotę AVR (zresztą, jesteśmy w temacie AVR, więc nie interesuje mnie ani ARM, ani FPGA ani Raspbery Pi itd.)
  • #20 16028407
    Konto nie istnieje
    Konto nie istnieje  
REKLAMA