Prezentacja Projektu: Moduł Mikrokontrolera ESP32 (Akwizycja Danych z ADXL345)

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).
Komunikacja Sieciowa i API:
- Wi-Fi oraz Captive Portal (do początkowej konfiguracji urządzenia przez użytkownika w trybie Access Point).
- 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.

Moduł stanowi serce układu akwizycji pomiarowej. Poniżej główne założenia jego działania:

Tryb Konfiguracji: Po pierwszym uruchomieniu, urządzenie podnosi własną sieć Wi-Fi z tzw. Captive Portalem. Użytkownik może wpisać tam poświadczenia docelowej sieci Wi-Fi oraz hasło, by mikrokontroler zintegrował się z otoczeniem sieciowym.
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ń.
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.
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.

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.
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.
Niestabilność modułu Captive Portal: Kłopoty z poprawnym serwowaniem strony konfiguracyjnej przez wbudowany serwer DNS, które blokowały uruchomienie modułu w nowych sieciach.

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