Skocz do zawartości

STM32F7 Zbyt mała szybkość zapisu danych z czujników I2C na kartę SD


radek04

Pomocna odpowiedź

W tym kontekście, bawiąc się kartą SD po SPI (tylko odczyt jak dotąd) zastanawiałem się nad koncepcją "niekończącego się zapisu". Chodzi o to, żeby nie zatrzymywać i finalizować zapisu, czy to instrukcją stopu, czy bez podawania ilości bloków do odczytu przed rozpoczęciem zapisu. Celem takiego działania, ma być to, że karta będzie cały czas oczekiwać danych, tylko w przerwach między wypełnianiem bufora z czujników będzie czekać (zegar będzie stał), żeby ilość odebranych przez kartę danych do zapisu była równa jednostce usuwania (która może wynosić kilka czy kilkadziesiąt MiB dla kart HC i XC). System plików musi być wyrównany z tą jednostką, ale jest narzędzie do formatowania, które to robi. Podczas odczytu karta może oczekiwać aż zegar ruszy, więc spodziewam się, że przy zapisie będzie podobnie. Ale to jeszcze wymaga przetestowania.

Małe karty, zwykłe SD, nie HC i XC, mają tą jednostkę zapisaną w rejestrze CSD w wersji 1.0, gdzie przyjmuje ona wartość maksymalnie 128 bloków po 512 B, więc bez kombinacji jak wyżej może być tutaj lepiej, mając jakąś uczciwą kartę.

Edytowano przez matsobdev
  • Pomogłeś! 1
Link do komentarza
Share on other sites

Znów moje kombinacje bez systemu plików (ale trochę więcej danych), ale też sama specyfikacja SD zapewnia osiągi w odniesieniu do jednostki alokacji AU. Np. karta 4 GB SDHC Kingstona (to pewnie była klasa 6, nie pamiętam, bo jest bez obudowy). Dorobiłem się zapisu po SPI i zakładając to (co inni sprawdzili też), żeby nie kończyć zapisu, tylko rozpocząć i potem podawać cały czas i zakończyć już po zakończeniu zbioru danych. Można wielkość tej jednostki sprawdzić poleceniem ACMD13, ale tutaj wychodzi, że jest to 2 MiB. Suche liczby to zapis gigabajta, czy całej karty (razem ze wszystkim, zakończeniem zapisu itd.) z prędkością 3,52 MiB/s, przy taktowaniu SPI 31,25 MHz. A teraz wykres z czasami zapisu (w ms) poszczególnych bloków (po 512 B). Pierwsze dwa (wycięte z wykresu) bardzo wolne:  ok 170 i 60 ms. Następnie jak niżej:

1790848355_Beztytuu.thumb.png.4604a24b33069d57fe2b5c401e594fcc.png

Co 4096 bloków (na oko z wykresu i faktycznie z tabeli) przytrzyma trochę, jak pewnie RAM karty się zapełni i musi zapisać do matrycy flash. Ok 138 us, czyli 3,62 MiB/s na zapis bloku. Np. gdyby dane z czujników przychodziły w tempie X MiB/s, to trzeba coś zrobić z ok 3 * X ms danych. Jakiś bufor. Takie podejście wymaga sprofilowania karty. Trzeba by też pamiętać, żeby mieć taki zapas szybkości zapisu, żeby szybciej móc opróżnić bufor(y) niż będzie się je zapełniać. Szybszy/szerszy interfejs pomoże, ale nie zmniejszy okresów zajętości karty (więcej kółek tylko będzie się robić oczekując określonego bajtu odzewu). Możliwe, że celowe zamykanie tych 2 MiB wcześniej niż wynika ze zbioru danych, a tym samym karta będzie w stanie zajętym wtedy kiedy i tak nie będzie się z nią nic robiło. Znając charakterystykę karty, można też nie oczekiwać zajętości karty po zapisie bloku, tylko iść dalej i przed zapisem następnego odczytać już pewnie tylko jeden bajt 0xFF zamiast wielu.

PS. To tylko na podstawie jednej karty, więc może nie mieć znaczenia nawet, ale można się bawić.

PS2. Nie uwzględnia to sposobu działania gotowego interfejsu. Trzeba samemu coś zrobić.

Link do komentarza
Share on other sites

Nie bardzo rozumiem jaki jest cel grzebania w szczegółach implementacji karty sd. Używając SPI i przesyłając jeden bit na raz z częstotliwością 31.25 MHz i tak nie ma szans uzyskać nawet pełnych 4MB/s. 

Wydaje mi się że należałoby zacząć od zmiany interfejsu używanego do komunikacji z kartą. Nie wiem którego STM32F7 używasz, ale większość obsługuje interfejs MMC, może nie uzyskasz HS400, ale powinno działać dużo lepiej niż SPI

Link do komentarza
Share on other sites

Nie używam też żadnego z STMów, choć to temat o nim, ale ogólne rzeczy dotyczące karty SD będą niezależne od kontrolera. Świadomość jak działa karta, to w sumie połowa sukcesu. A może to się przydać, żeby chociażby nie robić dużego nalotu karty (zmieniając jeden bit można efektywnie dołożyć 2/4/16/64 MiB przebiegu) jednocześnie nie dusząc wydajności zapisu. Zgadzam się, SPI ma swoje granice (MHz = Mb/s sygnałowo), ale nawet te mogą bym nie do osiągnięcia, jak nieumiejętnie się wykorzystuje potencjał karty, zważywszy na to, że kilka megabajtów buforu może być nieosiągalne. Oczywiście 4 bity to 4 razy więcej danych na sekundę, a tym samym na odpowiedniej karcie SD to i 40 MiB/s zapisu sekwencyjnego nie jest problemem nawet przy 3,3 V. Konstruktywna krytyka też jest w cenie.

PS. HS400 pewnie nie osiągnę, bo specyfikacja SD o nim milczy.

Edytowano przez matsobdev
  • Lubię! 1
Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

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

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.