PI_mikrokontroler_2/PREZENTACJA.md

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).
• 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.
• Formatowanie danych: ArduinoJson do parsowania ustawień konfiguracyjnych oraz tworzenia ładunków dla API.

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: 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 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).
• Zarządzanie pamięcią konfiguracyjną (EEPROM) (starsze wydania): W poprzednich wersjach stare ustawienia i domyślne hasła ("wmt") często zostawały w pamięci nieulotnej po przeflashowaniu mikrokontrolera. Sprawiało to ogromne trudności z logowaniem, co wymusiło napisanie mechanizmu automatycznej migracji bazy konfiguracji podczas uruchamiania.
• Brak elastyczności (hardkodowane adresy IP) (starsze wydania): Częstym błędem we wcześniejszym kodzie było zaszywanie na sztywno adresów produkcyjnych (np. 62.93...), co uniemożliwiało testowanie i wymuszało wgrywanie nowego oprogramowania w przypadku zmiany serwera testowego.
• Problemy z modułem Captive Portal (starsze wydania): Początkowo testowaliśmy autorskie podnoszenie sieci i konfigurację przez smartfon, jednak wbudowany serwer DNS często zawieszał się w nowych środowiskach, przez co ostatecznie w wersji obecnej (v1.3.4.1) zrezygnowaliśmy z tego na rzecz pliku na karcie SD.

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).
• 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.