esp32s3 zabezpieczenie zapisu pamięci USB pendrive

[_LM_]

Mam do wykonania logger parametrów pewnego urządzenia, wymaganie jest między innymi takie aby po włożeniu pamięci pendrive logowanie zaczynało się automatycznie. Logger buduję w oparciu o esp32s3 który ma wsparcie sprzętowe USB msc, aby zapoznać się z komponentem udostępnionym przez espressif korzystam i ich przykładu
https://components.espressif.com/components/espressif/usb_host_msc
https://github.com/espressif/esp-idf/tree/master/examples/peripherals/usb/host/msc
Urządzenie ma być bezobsługowe, czyli użytkownik wkłada pamięć -> esp sprawdza czy istnieje folder ze specyficzną nazwą powiązaną z jego MAC adres, jeśli taki istnieje to tworzy w tym folderze plik z bieżącą datą i czasem oraz zaczyna zapisywanie danych. 
-> jeśli folder nie istnieje to musi go założyć i przejść powyższe kroki, ścieżkę buduję w taki sposób:
 

   uint8_t chipid[6];
   esp_efuse_mac_get_default(chipid);
    char makedir[128];
    sprintf(makedir,"/usb/LOGGER_%02X%02X%02X%02X%02X%02X",chipid[0], chipid[1], chipid[2], chipid[3], chipid[4], chipid[5]);
  bool  directory_exists = stat(makedir, &s)==0;
    
    if (!directory_exists) {
        if (mkdir(makedir, 0775) != 0) {
            ESP_LOGE(TAG, "mkdir failed with errno: %s", strerror(errno));
        }
    }

Następnie plik z oznaczony aktualnym czasem np: 22082024_1444.csv i do niego zapisuje kolejne rekordy danych. 
Sprawa która mnie zastanawia to właśnie ten moment kiedy ktoś podejdzie i wyjmie pendrive z urządzenia, log będzie co sekundę, można liczyć że akurat pendrive zostanie wyjęty pomiędzy kolejnymi zapisami, ale co jeśli trafi akurat w moment dodawania wpisu do pliku? Można w programowy sposób na to zareagować lub muszę wykombinować jakiś mechanizm aby plik został poprawnie zamknięty przed wyjęciem pamięci z gniazda?

[ethanak]

Nie zamkniesz pliku po wyjęciu nośnika, chyba telepatycznie bo przecież nie masz już dostępu do nośnika.

Pytanie: czy na pewno musisz zapisywać logi co sekundę? Załóżmy że zapisujesz paczkę co minutę... jaka to różnica dla gościa co wyjął pena?

[ethanak]

Jeszcze pytanie: ile ma rekord logu i dlaczego tak dużo?

[_LM_]

1 minutę temu, ethanak napisał:

jaka to różnica dla gościa co wyjął pena?

W sumie żadna, czyli robić zapis buforowany, i w najgorszym przypadku przepadnie 60 logów w sumie nic strasznego kiedy logger będzie pracował powiedzmy tydzień.

1 minutę temu, ethanak napisał:

Jeszcze pytanie: ile ma rekord logu i dlaczego tak dużo?

to nie jest określone, bo zależy od tego ile parametrów będzie potrzebnych mogę przyjąć że jeden log nie przekroczy 1024 znaków ASCII 

[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

[ethanak]

A dlaczego musi przepaść? Jeśli log musi być tekstowy a nie binarny i ma ten kilobajt... no to przecież w pamięci zmieścisz 8 kilosekund. Poza tym rekird w pliku może mieć kilobajt, ale założę się że binarna reprezentacja w pamięci zmieści się w 256 bajtach (przy czym obstawiałbym raczej 128 jak nie 64).

[_LM_]

Skąd taka kompresja? Pliki mają być łatwo eksportowane do Excela stąd też narzut formatu 

Edytowano 22 sierpnia przez _LM_

[ethanak]

No to masz csv bo najprostszy. Ale to co masz w ramie to nie musi być to samo co w pliku. Przykład: masz kilka wartości typu on/off. W pliku csv masz na każdą wartość dwa bajty (znak i separator). W ramie masz jeden bit na wartość - czyli x16.

To samo z floatami. W 99.9% przypadków wystarczy float16 (dwa bajty).

A zrobienie csv z binarki żeby zapisać do pliku to raczej zadanie dla początkujacego adepta trudnej sztuki programowania...

[_LM_]

Ok ale dalej nie rozumiem co miałeś na myśli pisząc:
 

2 godziny temu, ethanak napisał:

A dlaczego musi przepaść?

w odniesieniu do tego w jakim momencie pen zostanie wyjęty z gniazda, bo jeśli trafi akurat na moment zapisu? Rozumiem że to trwa milisekundy, jak się posypie jeden wpis to tragedii nie będzie, jeśli zostanie uszkodzony plik to już gorzej

[ethanak]

No ale Ty chcesz, żeby po wyjęciu pena coś tam się jeszcze zrobiło... pane Havranku, to se ne da.

Trzymasz rekordy w pamięci (masz jej w ch...), a usuwasz dopiero jeśli zapis się powiódł. A czy się powiódł to chyba w miarę łatwo sprawdzić?

[_LM_]

Ja chcę aby to co jest zapisywane na pena było pewne. Osoba obsługująca to cudo nie musi a wręcz nie powinna się interesować tym co i jak oraz kiedy może usunąć palca ze slotu. Wyjmuje, wkłada do kompa (tak wiem ch....a robota :P) i importuje z tego pendriva pliki do excela który mu robi ładne wykresiki. Co do oznajmienia operatorowi kiedy może wyjąć(teraz mi to przyszło do głowy), mogę mu to zasygnalizować LEDem na obudowie tak aby ten LED świecił powiedzmy w kolorze zielonym gdy wyjmowanie jest dozwolone a na czerwono kiedy robić tego nie wolno. 

[_LM_]

8 minut temu, ethanak napisał:

Trzymasz rekordy w pamięci (masz jej w ch...), a usuwasz dopiero jeśli zapis się powiódł.

A czyli miałbym te dane wstępnie trzymać w flasch a potem kopiować? Odpada bo "w ch... pamięci" to nie nieskończoność. Rejestracja będzie się odbywała tylko kiedy pen jest w slocie

[ethanak]

Masz 8 MB ramu. Mało?

[_LM_]

Bardzo dużo jak na potrzeby tego urządzenia. Czyli zrobić tak: zapisywać wstępnie do RAM i później całą paczkę wrzucić na pendrive

[ethanak]

Dokładnie tak. Tyle że w ramie zapisujesz dane binarne, a rozpakowujesz na csv dopiero przy zapisie. Poza tym ring buffer jakby zabrakło miejsca.

[_LM_]

No to już zrozumiałem dlaczego pisałeś że te rekordy będą zajmowały o wiele mniej miejsca niż na penie.