Dostosowanie opisu do wersji v1.3.4.1 (ArduinoThread)

PREZENTACJA.md

@@ -1,10 +1,10 @@
-# Prezentacja Projektu: Moduł Mikrokontrolera ESP32 (Akwizycja Danych z ADXL345)
+# Prezentacja Projektu: Moduł Mikrokontrolera ESP32 (Akwizycja Danych z ADXL345) - Wersja v1.3.4.1
 
 ## 1. Technologia
 W mojej części aplikacji (firmware mikrokontrolera) wykorzystane zostały następujące technologie i narzędzia:
 * **Sprzęt:** Płytka rozwojowa Freenove ESP32-S3 WROOM, zewnętrzny czujnik przyspieszenia/drgań ADXL345 (komunikacja przez szynę SPI), karta SD do lokalnego przechowywania danych.
 * **Środowisko i Język:** PlatformIO (C++ dla środowiska Arduino).
-* **System operacyjny czasu rzeczywistego (RTOS):** FreeRTOS wbudowany w ESP32 – wykorzystany do wielowątkowości i podziału zadań pomiędzy rdzenie (Core 0 i Core 1).
+* **Zarządzanie czasem i zadaniami:** Wykorzystanie biblioteki `ArduinoThread` do "pseudo-wielowątkowości" i cyklicznego wywoływania zadań (np. testów WiFi, sprawdzania trybu offline, pomiarów i uploadu) w głównej pętli `loop()` mikrokontrolera.
 * **Komunikacja Sieciowa i API:** 
   * Wi-Fi (konfiguracja sieci wczytywana bezpośrednio z pliku `wifi.txt` zapisanego na karcie SD).
   * Klient HTTP (REST API) implementujący uwierzytelnianie (Basic Auth) i przesyłanie plików.
@@ -13,18 +13,19 @@ W mojej części aplikacji (firmware mikrokontrolera) wykorzystane zostały nast
 ## 2. Prezentacja działania
 Moduł stanowi serce układu akwizycji pomiarowej. Poniżej główne założenia jego działania:
 1. **Tryb Konfiguracji:** Podczas uruchamiania, urządzenie wczytuje poświadczenia docelowej sieci Wi-Fi bezpośrednio z pliku konfiguracyjnego `wifi.txt` umieszczonego na karcie SD. Pozwala to na szybką zmianę sieci bez konieczności rekonfiguracji przez webowy interfejs.
-2. **Zbieranie danych z czujnika:** Na głównym rdzeniu działa precyzyjna pętla (Task), która ze zdefiniowaną częstotliwością odpytuje czujnik ADXL345 przez szynę SPI, gromadząc surowe dane na temat drgań.
-3. **Zapis na nośnik nielotny:** Zebrane pakiety danych są zrzucane w zoptymalizowany sposób (zapobiegając blokowaniu odczytów) do binarnych plików z rozszerzeniem `.wmt` na kartę pamięci SD.
-4. **Zarządzanie Uploadem w tle:** Niezależne zadanie we FreeRTOS (`UploadManager` na Core 0) monitoruje kartę SD. Jeśli znajdzie zamknięte i gotowe pliki, nawiązuje autoryzowane połączenie z zewnętrznym serwerem FastAPI i sekwencyjnie wysyła te pliki. Jeśli wystąpi błąd (np. brak sieci), pliki pozostają bezpieczne na karcie SD i proces powtarza się później.
+2. **Zbieranie danych z czujnika:** W głównej pętli (poprzez `ArduinoThread`) ze zdefiniowaną częstotliwością odpytywany jest czujnik ADXL345 przez szynę SPI, a surowe dane na temat drgań są gromadzone.
+3. **Zapis na nośnik nielotny:** Zebrane pakiety danych są zrzucane w zoptymalizowany sposób do binarnych plików z rozszerzeniem `.wmt` na kartę pamięci SD.
+4. **Zarządzanie Uploadem:** Dodatkowy obiekt typu `Thread` wewnątrz głównej pętli regularnie monitoruje kartę SD. Jeśli znajdzie zamknięte pliki `.wmt`, tymczasowo blokuje pętlę na czas wysyłania (aby zapobiec utracie pakietów), i nawiązuje połączenie z serwerem FastAPI w celu zrzucenia zebranych logów. Jeśli wystąpi błąd (np. brak sieci), pliki pozostają bezpieczne na karcie SD i proces powtarza się w kolejnym cyklu.
 
 ## 3. Problemy
 Podczas realizacji tej części systemu napotkałem i musiałem rozwiązać szereg problemów:
-* **Kolidowanie czasu rzeczywistego z operacjami dyskowymi:** Zapis plików na kartę SD bywa blokujący i powodował "wypadanie" próbek ze strumienia danych z akcelerometru. Rozwiązaniem było dokładne rozdzielenie wątków, zastosowanie buforów i unikanie przerw dzięki FreeRTOS.
-* **Watchdog Timeouts (WDT):** Ciężkie i przedłużające się operacje sieciowe lub plikowe powodowały restart mikrokontrolera ze strony sprzętowego watchdoga. Wymagało to strojenia czasów pętli we FreeRTOS oraz dodawania instrukcji yield/delay uwalniających zasoby.
+* **Kolidowanie czasu rzeczywistego z operacjami sieciowymi:** Wysyłanie plików na serwer oraz zapis na SD jest operacją czasochłonną. W tej wersji, opartej na `ArduinoThread`, długotrwały upload blokuje główną pętlę, co wymusza przerwanie zbierania kolejnych próbek z akcelerometru na czas przesyłu danych z karty.
+* **Watchdog Timeouts (WDT):** Długie operacje sieciowe wykonywane w jednym i tym samym głównym wątku często powodowały wyzwolenie sprzętowego Watchdoga i reset mikrokontrolera. Rozwiązaniem było odpowiednie dozowanie czasu, przerywanie operacji oraz dodawanie instrukcji "karmiących" (feed) systemowego watchdoga wewnątrz pętli wysyłającej pliki.
 * **Autoryzacja (401 Unauthorized) z serwerem i bezpieczeństwo API:** Skonfigurowanie płynnego logowania i autoryzacji sprzętu, tak aby backend poprawnie weryfikował zgłaszający się po WiFi mikrokontroler przed odbiorem plików pomiarowych.
 * **Problemy z odczytem konfiguracji z karty SD:** Konieczność zapewnienia poprawnego i niezawodnego odczytu oraz parsowania pliku `wifi.txt` w początkowej fazie rozruchu mikrokontrolera (zanim wystartują główne wątki sieciowe).
 
 ## 4. Do zrobienia
 * **Implementacja pełnego szyfrowania (HTTPS/SSL):** Zabezpieczenie ruchu do REST API z wykorzystaniem zaufanych lub wbudowanych certyfikatów na ESP32 (obecnie wymaga to odpowiednich optymalizacji pamięci).
-* **Testy stresowe (długodystansowe):** Uruchomienie układu w warunkach symulujących środowisko docelowe bez przerwy przez klika tygodni, by zbadać zachowanie alokacji pamięci masowej na karcie SD w przypadku pełnego zapełnienia.
+* **Przejście na architekturę wielowątkową (FreeRTOS):** Ponieważ `ArduinoThread` blokuje główną pętlę pomiarową na czas uploadu, najpilniejszym krokiem do zrobienia będzie wyciągnięcie UploadManagera do osobnego, niezależnego Taska przypiętego do Core 0 mikrokontrolera ESP32 (rdzenia odpowiedzialnego za obsługę Wi-Fi).
+* **Testy stresowe (długodystansowe):** Uruchomienie układu w warunkach symulujących środowisko docelowe bez przerwy przez klika tygodni, by zbadać stabilność alokacji pamięci przy odczycie dużych wolumenów i upewnić się o niezawodności struktury katalogów na karcie SD.
 * **Dokładna synchronizacja czasu (RTC / NTP):** Integracja dokładnego mechanizmu czasu z siecią tak, by tworzone na karcie SD pliki miały zawsze poprawny i bardzo precyzyjny stempel czasowy, niezależnie od tego czy mikrokontroler miał pełny restet z odłączeniem baterii.