Zabrakło pamięci w Arduino

[Wrona]

Jako że pisze jedynie proste kody do Arduino myślałem że mnie to nie spotka ....a jednak. Aktualnie mój szkic po kompilacji zajmuje 53% pamięci programu a zmienne globalne używają 59% pamięci dynamicznej. Wszystko śmiga elegancko. Ostatnio zrezygnowałem z wysyłania danych przez WiFi i chciałem zapisywać dane na karcie SD. Jednak samo "inkludowanie" biblioteki SD.h powoduje że szkic zajmuje 64% pamięci programu a zmienne globalne używają 89% pamięci dynamicznej. No i to blokuje cały układ. Zapewne można temu zaradzić zmieniając UNO na MEGA ale kasa mocno mnie ogranicza więc wolałbym to rozwiązanie jako ostateczne. Chciałbym zapytać o możliwość dwóch scenariuszy.

1. Czy można dołożyć jakąś pamięć zewnętrzną? 

2. Czy taki gamoń jak ja może jakoś odchudzić bibliotekę?

Z góry dziękuję za zainteresowanie i pomoc.

[BlackJack]

Jeszcze niczego ci zabrakło, wg. tego co piszesz, a że dodanie obsługi karty SD zamula, no cóż obsługa tej karty jest zasobożerna. Jedyne co ci zostaje to nauka optymalizacji kodu. Jak brakuje ci pamięci to kup sobie ARDUINO EVRY 48KB FLASH i 6KB RAM 20MHz zamiast 16 (ATMEGA4809).

PS. Niestety nie da się podmienić w Arduino UNO ATMegi328 na ATMegę4808, bo nie są kompatybilne pinowo, a szkoda, bo wtedy byłoby bez kłopotu :(.

Co do pytania nr 1. Teoretycznie możliwe przez dodanie FRAMu na SPI lub I2C, ale i tak wymaga pisania specjalnej biblioteki do obsługi tego, a wydajność będzie bardzo mała. W praktyce nikt tego nie robi.

Edytowano Luty 25, 2020 przez BlackJack

[Wrona]

24 minuty temu, BlackJack napisał:

Jeszcze niczego ci zabrakło, wg. tego co piszesz, a że dodanie obsługi karty SD zamula, no cóż obsługa tej karty jest zasobożerna. Jedyne co ci zostaje to nauka optymalizacji kodu. Jak brakuje ci pamięci to kup sobie ARDUINO EVRY 48KB FLASH i 6KB RAM 20MHz zamiast 16 (ATMEGA4809).

Kod zoptymalizowałem na tyle na ile potrafię i już to co stworzyłem przewyższa mój poziom abstrakcji. Gdyby nie zapasowa wersja bez optymalizacji to byłoby pewne że za tydzień nie rozumiałbym własnego kodu. Na tym polu już niewiele zdziałam.  

Z tego jak zrozumiałem twoja wypowiedz, wnioskuj że:

1. Nie ma możliwości dołożenia pamięci do tego co jest w UNO

2. Nie ma szans nic pokombinować z biblioteka SD by nie zajmowała tak dużej ilości pamięci dynamicznej

3. Jedyne co jest dla mnie realne to zmiana płytki

Edytowano Luty 25, 2020 przez Wrona

[marek1707]

Do UNO a także innych AVR-owych Arduinów nie można dołożyć pamięci programu. Te procesory tak mają i koniec - wybierasz tak duży jaki potrzebujesz a gdy pamięć kodu się kończy, kupujesz większy 😞 lub zaczynasz grzebać w programie, ew. opcjach kompilatora. Można dołożyć różne pamięci (RAM, FRAM, FLASH, EEPROM i co tam jeszcze wymyślono) na interfejsach szeregowych - tak jak kartę SD, no ale to zawsze wymaga kolejnych funkcji w programie do obsługi nowego zasobu. Na Twoim miejscu poszukałbym innych bibliotek dla SD. Przecież nie jednemu psu Burek i na pewno coś znajdziesz. Nie jesteś pierwszym, który wszedł na te grabie w Arduino więc szansa na skorzystanie z pracy innych jest spora.

Pierwsze z brzegu trafienie przeglądarki na zapytanie "small SD Arduino library":

http://elm-chan.org/fsw/ff/00index_p.html

https://github.com/greiman/PetitFS

Zopisu wygląda, że ta biblioteka chyba nawet nie rezerwuje statycznie bufora na sektor SD - co zawsze jest sporym obciążeniem "na dzień dobry". Na pewno jest to okupione jakimis innymi ograncizeniami (np. prędkością, możliwością otwarcia tylko jednego pliku na raz itd..), ale dopóki nie zapsiujesz tam próbek głosu tylko z rzadka jakieś wyniki  pomiarów to powinno zadziałać. Co więcej, z tego co czytam we wstępie, PetitFS jest w pewien sposób konfigurowalne więc np. możesz oszczędzić sporo na FLASHu rezygnując z tworzenia i zapisywania do plików a zostawiając sobie tylko odczyt utworzonych (np. na PC) wcześniej. Nie wiemy dokładnie co robisz, ale rozejrzyj się w sieci - to może być prostsze niż kupowanie nowej płytki i migracja projektu na większy procesor. Choc z doświadczenia Ci powiem, że wszystkie niebanalne interfejsy są zasobożerne. Zarówno Ethernet, USB, SD/MMC plus system plików jako moduł - one wszystkie potrzebują po pierwsze RAM, pod drugie RAM i po trzecie RAM, a małe mikrokontrolerki mają go zwykle jak na lekarstwo. I dlatego jak już masz chip z tymi blokami to w środku możesz spokojnie spodziewać się min. 16K RAMu a najpewniej >64K. Mała mega328 zwyczajnie nie jest do tego przeznaczona..

Edytowano Luty 25, 2020 przez marek1707

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Anonim]

.. i nie da się do niej dołączyć równolegle RAMu z interfejsem równoległym na co pozwalają większe wynalazki tej rodziny. Wtedy sprowadza się to jedynie do odpowiedniego ustawienia fusów i rejestrów i Twoja pamięć operacyjna powiększa się o pojemność dodatkowego scalaka.

PetitFS zaproponowane przez Marka to chyba jedyny racjonalny wybór dla małych procków AVR, tak więc nie musisz się już nad tym zastanawiać. Też miałem tego typu dylematy.

Pamiętam, kiedy się pojawiły XMegi jaki był szał przez chwile, obecnie jednak STM32 nic nie przebije ale trzeba pamiętać, że im większe możliwości to więcej problemów do rozwiązania i wiedzy do przyswojenia a to wszystko kosztuje czas a czas to pieniądz więc sam rozważ co Ci się lepiej opłaca. :)

[Wrona]

9 godzin temu, marek1707 napisał:

możesz oszczędzić sporo na FLASHu rezygnując z tworzenia i zapisywania do plików a zostawiając sobie tylko odczyt utworzonych (np. na PC) wcześniej. 

Zapisów będzie dużo i często. Nie będzie natomiast żadnego odczytywania. PetitFS się nie udało wykorzystać. Próbowałem też z SdFat.h ale początkowy entuzjazm zakończył się gdy w pewnym momencie zużycie pamięci dynamicznej przekroczyło 100%. 

Jako że korzystam z tych wszystkich urządzeń bardziej na "czuja" czyli bez pełnej tj. dogłębnej świadomości jak działają na poziomie pamięci, chciałbym dopytać o jedną rzecz. Wykonuje następujące kroki:

1. Inkluduję bibliotekę SdFat.h i mam zajęte 60% pamięci dynamicznej

2. Definiuje       SdFile plik;      i mam zajęte 60% pamięci dynamicznej

3. Definiuje       SdFat sd;        i mam zajęte 89% pamięci dynamicznej oraz komunikat o problemach ze stabilnością 

Co się w tym miejscu wydarzyło? Pytam jedynie z potrzeby wiedzy, natomiast rozglądnę się jeszcze za czymś innym do obsługi SD.

 

[Anonim]

Duża zmienna została utworzona w ramie a ostrzeżenie samo się chyba wyjaśnia - może zabraknąć pamięci podczas pracy. Polecam Ci jednak tego PetitSF jest lekki. Co się stało, że się nie udało wykorzystać? Tam wystarczy jedynie plik konfiguracyjny zmodyfikować.

[Wrona]

1 godzinę temu, atMegaTona napisał:

Co się stało, że się nie udało wykorzystać? Tam wystarczy jedynie plik konfiguracyjny zmodyfikować.

Jestem raczkujący więc nie zrozumiałem jego idei. W swoim dotychczasowym kodzie z wykorzystaniem SD.h w jednym miejscu tworze plik.txt, w innym otwiera się i zapisuje część informacji dotyczących ustawień, w jeszcze innym dopisuje wyniki z czujników, a w innym znów to robi ale z innymi danymi a jeszcze w innym awaryjnie zamyka plik.txt. Zapewne właśnie ta czytelność i łatwość korzystania z SD.h okupiona jest zasobochłonnością. W przypadku PetitSF chyba się pogubiłem bo wszystko się sypnęło. Pewnie spróbuje raz jeszcze. zaczynając od kilku linijek kodu a dopiero potem zaimplementuje to do mojego programu.

[Jarewa]

Dnia 25.02.2020 o 21:33, Wrona napisał:

Kod zoptymalizowałem na tyle na ile potrafię

A pokaz kod....

[Wrona]

@Jarewa Sprawa się rypła gdyż przeanalizowałem cele pomiarów. Priorytetem była wysoka częstotliwość pomiarów i na tym powinienem się skupić. Karta SD a nawet część czujników to "wodotryski". Dlatego przedefiniowałem działanie projektu. Oczywiście wcześniej jednak na innej płytce uruchomiłem funkcje zapisu na karcie  - więc co się nauczyłem to moje. Dzięki za wszystko.

[fast_rabbit]

Dnia 25.02.2020 o 21:20, BlackJack napisał:

Co do pytania nr 1. Teoretycznie możliwe przez dodanie FRAMu na SPI lub I2C, ale i tak wymaga pisania specjalnej biblioteki do obsługi tego, a wydajność będzie bardzo mała. W praktyce nikt tego nie robi.

Dokładając pamięć równoległą do mega2560 trzeba pisać biblioteki? Dostęp do takiej pamięci jest w 2 cyklach to jest mała wydajność?

[marek1707]

Niezły odkop, wątek zdechł miesiąc temu - nie zauważyłeś, czy chęć dodania swoich 3 groszy OT była silniejsza?

A wracając do meritum. Biblioteki? Ano jakieś trzeba, bo przecież Autor chce podłączyć pamięć nieulotną a nie zwykły RAM. O ile interfejs dużej ATmegi rzeczywiście pasuje do zewnętrznej pamięci równoległej, to:

1. Kolega Wrona używa m328,
2. interfejs ten umożlwia bezpośrednie adresowanie tylko małego obszaru (60K) a w praktyce 32K jeśli chcesz mieć duży, ciągły obszar adresowy,
3. zapis musi być uwzględniać gotowość pamięci jakimś bitem RDY/BUSY czytanym z rejestru pamięci lub pinu.

Z powodu (2), chcąc mieć więcej pamięci musisz zrobić stronicowanie najstarszych bitów jakimś innym portem a z (3) i tak nie działa to jak bezproblemowy dostęp do RAMu. Poza tym tak egzotyczne (ilu amatorów tego używa?) podłączenie wymaga mnóstwa drutów, sam scalak pamięci jest wielki a żadna biblioteka organizująca np. system plików nie zadziała wprost. Tak więc tak czy inaczej bez sporego nakładu własnej pracy albo skorzystania z ew. bilioteki obsługującej zewnętrzne pamięci równoległe EEPROM/FLASH raczej się nie obejdzie, nie sądzisz? O wydajności trudno tu dyskutować, bo jest to względne i zależy od sposobu w jaki wyższe warstwy traktują pamięć i od tego czego oczekuje Autor wątku. W każym razie zapis poniżej kilku us/bajt raczej nie wyskoczy a do tego trzeba doliczyć czas kasowania sektorów czy stron.