Zapis daty z ADC do karty SD + DMA [STM32F767zi]

Question

Zapis daty z ADC do karty SD + DMA [STM32F767zi]

Chef_C 10 Mar 2019 17:34 495 6

#1 10 Mar 2019 17:34

Chef_C Chef_C

Level 4

#1 10 Mar 2019 17:34

Cześć, mam pytanie jak najlepiej podejść do tematu

Jak na razie, udało się podłączyć dwa potencjometry na dwóch kanałach ADC przez DMA i na bieżąco odczytywać dane z potencjometrów w programie STMStudio, wykorzystując bibliotekę HAL.

przetwarzanie ADC jest ustawione na Scan Conversion Mode, Continous Conversion Mode a DMA ustawione na Circular Mode.

Ostatecznie chciałbym zapisywać odczyt danych z potencjometrów do karty SD i później odczytać dane z karty SD na laptopie

Aktualny kod na inicjalizację ADC i DMA :

Code: c
Log in, to see the code

zdefiniowanie tablicy dla dwóch kanałów ADC i transmisja DMA w main() :

Code: c
Log in, to see the code

Jak na razie są dwa potencjometry, jednak dojdzie jeszcze kilka innych czujników do przetwarzania ADC, więc kanałów również będzie więcej. W jaki sposób można skierować strumień tych danych do karty SD?

Pozdrawiam

[30.03.2021, darmowy webinar] Nowoczesna diagnostyka maszyn, monitorowanie i przewidywanie awarii. Zarejestruj się

LChucki · Answer 1 · 2019-03-10T18:28:14+01:00

Chef_C wrote:
W jaki sposób można skierować strumień tych danych do karty SD?

Aby skierować strumień musisz mieć system, zainstaluj Linuxa i kieruj strumieniami jak chcesz.

Skoro chcesz zapisywać na kartę SD i równocześnie robić inne rzeczy, użyj RTOS, tak będzie łatwiej.

Dane do zapisu musisz buforować, bo "zajeździsz" kartę SD. Zapamiętuj więc dane w RAM, NvRAM, FRAM i co np 10 minut, zapisuj na kartę.

norbis15 · Answer 2 · 2019-03-14T09:02:17+01:00

Zrobiłem urządzenie bazujące na stm32f1 zbierające dane z wielu czujników (cyfrowych i ADC) i zapisujących te dane na karcie SD. I obyło się bez systemu operacyjnego.
Wejdź sobie na stronę: http://elm-chan.org/fsw/ff/00index_e.html pobierz biblioteki FF13a, dodaj do projektu, skonfiguruj timer, i obsługę SPI i zostaje tylko przetwarzanie danych a czujników do karty.

LChucki wrote:

Dane do zapisu musisz buforować, bo "zajeździsz" kartę SD.

Co dokładniej masz na myśli? Ja u siebie zapisuje próbki co minutę, czy jest to za często? Czy ilość danych ma znaczenie?

LChucki · Answer 3 · 2019-03-14T09:14:54+01:00

norbis15 wrote:

LChucki wrote:

Dane do zapisu musisz buforować, bo "zajeździsz" kartę SD.

Co dokładniej masz na myśli? Ja u siebie zapisuje próbki co minutę, czy jest to za często? Czy ilość danych ma znaczenie?

FAT, którego pewnie używasz, nie nadaje się do częstych zapisów. BAM siedzi w pierwszych sektorach i każdy zapis zmniejsza liczbę żyć FLASH. Wystarczy poużywać karty SD w wideorejestratorze aby wiedzieć o czym piszę.

Freddie Chopin · Answer 4 · 2019-03-14T10:11:55+01:00

LChucki wrote:
Wystarczy poużywać karty SD w wideorejestratorze aby wiedzieć o czym piszę.

Wystarczy też trochę doczytać, żeby nie rozpowiadać takich "prawd i mitów" (nawiązanie do innego tematu jest oczywiście celowe).

Po pierwsze w ogólnej ogólności błędem jest założenie, że skoro w FAT tablice alokacji znajdują się w początkowych sektorach to częsty zapis danych na kartę może ją uszkodzić. Jest to błąd ponieważ adres którym operuje karta a FIZYCZNY adres pod który zostaną zapisane dane to dwie kompletnie odmienne sprawy. Karta pamięci SD ma swoje własne "FTL" które realizuje algorytmy wear levelingu, więc częste zapisy pod ten sam adres są jej kompletnie obojętne.

Po drugie w sformułowaniu tym jest ziarnko prawdy, ale tylko ziarnko. Najmniejsza jednostka która możne zostać zapisana na karcie to 512 bajtów, systemy plików mogą to nawet jeszcze bardziej zwiększyć. Z tego względu na przykład 512 zapisów po jednym bajcie do pliku w teorii jest 512 razy gorsze niż jeden zapis 512 bajtów na raz. Niemniej jednak większość bibliotek systemów plików realizuje buforowanie zapisu i wykonuje zapis tylko gdy jest to konieczne lub gdy użytkownik zażąda tego wprost (zwykle funkcją typu "synchronize").

Po trzecie wszystko co napisałem powyżej odnosi się do "porządnych" i oryginalnych kart produkowanych przez kogoś innego niż "Firma Krzak Sp. z o.o.". Specyfikacja SD w zasadzie nie wymaga wear levelingu, więc jak ktoś się ucieszył że kupił na aliexpress karty "kingstoone" albo "samssung" po 2 centy za sztukę to oczywiście nawet patrzenie na taką kartę ja "zajeździ", a co dopiero zapis pod ten sam adres.

Po czwarte wszystko co napisałem powyżej odnosi się do kart pamięci oraz np. pendrive'ów - nie odnosi się natomiast do czipów pamięci, bo tam adres używany w komendach jest adresem fizycznym.

LChucki · Answer 5 · 2019-03-14T11:04:56+01:00

Freddie Chopin wrote:
Po czwarte wszystko co napisałem powyżej odnosi się do kart pamięci oraz np. pendrive'ów

PenDrive tak, karty, zależy jakie.

Freddie Chopin wrote:
Po trzecie wszystko co napisałem powyżej odnosi się do "porządnych" i oryginalnych kart

I tu leży sedno sprawy. Karta marnej jakości padnie bardzo szybko, nawet zanim osiągnie 20..30% deklarowanych cykli zapisu.

Kto używa drogich kart w tanich konstrukcjach na AVR, Arduino?
Dlatego warto buforować dane do zapisu.
Ciekawe jest to, że problemu częstych zapisów na PenDrive nie spotkałem, bez względu na cenę pena.

Freddie Chopin · Answer 6 · 2019-03-14T11:39:28+01:00

LChucki wrote:
PenDrive tak, karty, zależy jakie.

No to napisz dla jakich "nie", zamiast powtarzać miejskie legendy.

LChucki wrote:
I tu leży sedno sprawy. Karta marnej jakości padnie bardzo szybko, nawet zanim osiągnie 20..30% deklarowanych cykli zapisu.

To nie chodzi o używanie "drogich" vs "tanich" kart. Tu chodzi o używanie "normalnych" kart i czegoś co śmiało można nazwać "podróbką" lub "chińskim badziewiem". Nikt nie sugeruje, że wear leveling jest używany tylko w kartach które są "industrial grade" i kosztują >200 zł za sztukę.

Poza najtańszym i oszukanym badziewiem nie spełniającym żadnych standardów jakieś mapowanie adresów fizycznych na wirtualne (FTL) i jakiś wear leveling po prostu MUSZĄ być, bo inaczej one by po prostu nie działały. Mam tu na biurku ze 3 zupełnie typowe karty (nic specjalnie wyszukanego, ale kupione normalnie w sklepie, a nie za 2 centy i z darmową przesyłką od "majfrendów") i w każdej z nich tzw. AU (zapewne Allocation Unit, choć skrót nie jest nigdzie w dokumentacji rozwinięty) ma rozmiar 4 MB. A może być jeszcze większy! To jest REALNY rozmiar najmniejszej jednostki na karcie którą można skasować. Jeśli by nie było żadnego FTL i żadnego wear levelingu, to kartę załatwiłbyś z minutę a modyfikacja czegokolwiek trwałaby z 10x dłużej niż trwa faktycznie.

Nie wierzysz mi, poszukaj w google - znajdziesz dokładnie takie samo info, że wszystkie "normalne" karty mają wear leveling i tylko jak kupiłeś podrobiony złom to go być może nie ma. Tyle że szybkie popsucie podrobionego złomu jest bardziej niż pewne i nie trzeba do tego żadnego systemu plików zapisującego tablicę alokacji na samym początku obszaru.

Quote:
Kto używa drogich kart w tanich konstrukcjach na AVR, Arduino?

Nic mnie nie interesuje jak ktoś kupuje podróbki i potem marudzi że mu nie działa. Jego wybór - jego problem. Pewne rzeczy muszą kosztować. Jeśli w PL kartę o jakiejś tam pojemności da się kupić za X zł, to znaczy że cokolwiek kupionego w Chinach tańszego niż powiedzmy X/2 pewnie jest badziewiem, a tańszego niż X/4 to już nawet szkoda na to czasu. A pewnie zaraz by się tu ktoś znalazł, kto kupił karty za X/10 i jest super zadowolony ze swojej przedsiębiorczości.

Zwłaszcza że mówimy o kartach które kosztują np. 20 zł za bardzo porządne produkty (SanDisk) o ogromnej pojemności (32 GB), więc o czym tu w ogóle rozmawiać i gdzie jest sens tu oszczędzać?