Aktualizacja prezentacji - usunięcie informacji o Captive Portal

PREZENTACJA.md

@@ -6,13 +6,13 @@ W mojej części aplikacji (firmware mikrokontrolera) wykorzystane zostały nast
 * **Ś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).
+  * 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:** 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.
+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.
@@ -22,7 +22,7 @@ Podczas realizacji tej części systemu napotkałem i musiałem rozwiązać szer
 * **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.
+* **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).