[Rozwiązano] Kod termostatu Arduino Uno wygenerowanego przez ChatGPT-5 Code – czy to już poziom seniora?

Czy AI ChatGPT- 5 Code to już senior programista. Zapytałem grzecznie ChatGPT- 5 Code czy by nie napisał programu na Arduino Uno do wykonania prostego termostatu jednokanałowego. Podałem oczywiście pin out/in i ciurkiem wygenerował to! Wgrałem, kompilator nie zgłasza błedów ogólnie jestem zadowolony z działania. Czy ktoś bardzo obeznany oceniłby tego senior programistę? Pod względem fachowości.

Raczej Junior piszący dość czytelnie. Jak na Arduino, wygląda to spoko: kod na poziomie internetowych exampli. Jeśli działa, to tym lepiej dla niego.

Dla testu mógłbyś wrzucić ten kod do GPT i poprosić o review pod kątem dobrych praktyk programistycznych dla systemów wbudowanych i nowoczesnych technik programowania c++.

OK. Poprosiłem go o optymalizacje kodu pod kątem dobrych praktyk programistycznych dla konkretnie tego projektu. Walnął komentarz dłuższy od samego kodu. To co zrozumiałem z jego wywodu to, że Arduino IDE ma stary i bardzo prymitywny kompilator gdzie nie wszystko da się zastosować. Szczególnie rozwodził się nad: enum class i constexpr.

khoam napisał:

Dalej jest "#define"

Skoro wszystkie pawiany używają #define, to dlaczego AI ma robić profesjonalizm ...

Przycisnąłem go. Trochę mącił i kręcił ale w końcu zmienił #define na "constexpr". Jak chce to potrafi. Kod sprawdzony i działa tak samo poprawnie jak poprzednie wersje. Co by się jeszcze przydało zmienić aby był "nowoczesny"

fachman1964 napisał:

Przycisnąłem go. Trochę mącił i kręcił ale w końcu zmienił #define na "constexpr". Jak chce to potrafi.

Jak trójkowy uczeń z dobrą pamięcią. Skoro #define było zawsze dobrze przyjęte (zapewniało solidną trójkę) to po co się wychylać, wystarczy powtarzać coś raz nauczone. Nawet jeśli brak pełnego rozumienia zalet i / wad / ryzyk.

Jak się uczyłem nowych dla mnie obszarów w webie, też GPT jechał po najprostszej linii, zupełnie nie informując że w ogóle istnieje jakiś inny, bardziej profesjonalny świat, dopiero jak go dociskałem.

Ładnie wygląda ale chyba coś "przedobrzone" bo szwankuje.

fachman1964 napisał:

Ładnie wygląda ale chyba coś "przedobrzone" bo szwankuje.

Prawdę mówiąc określiłeś to jak obrażona panienka a nie programista.
Co konkretnie szwankuje ?

Równie dobrze w starym mogła być "parzysta ilość błędów" (to taki niby żart zawodowy, ale zaskakująco często się sprawdza)

Mnie razi używanie delay(). O ile przebolałbym to w samym setupie to w pętli głównej jest nie do przyjęcia. No ale czat uczył się na kodach z netu.
Poproś go by zamiast delay() użył timera lub choćby millis() ciekawe czy dobrze mu pójdzie.

JacekCz napisał:

fachman1964 napisał:

Ładnie wygląda ale chyba coś "przedobrzone" bo szwankuje.

Prawdę mówiąc określiłeś to jak obrażona panienka a nie programista.
Co konkretnie szwankuje ?

Równie dobrze w starym mogła być "parzysta ilość błędów" (to taki niby żart zawodowy, ale zaskakująco często się sprawdza)

JA:
czy Qwen z opcją refaktoryzacji "Advanced C++23" nadaje się do optymalizacji kodu w arduino ide z kompilatorem GCC 7.3.0

Claude Opus 4.1PRO
EditQwen z opcją "Advanced C++23" nie nadaje się do pracy z Arduino IDE i kompilatorem GCC 7.3.0 z kilku kluczowych powodów:

Główne problemy:
GCC 7.3.0 to przestarzały kompilator
Niezgodność standardów C++:
GCC 7.3.0 wspiera głównie C++14 i częściowo C++17
C++23 to bardzo nowy standard, który wymaga znacznie nowszych kompilatorów (GCC 12+)
Qwen może sugerować konstrukcje C++23, które GCC 7.3.0 po prostu ich nie rozumie i nie skompilują poprawnie.

Specyfika Arduino:

Arduino używa ograniczonego podzbioru C++ z własnymi bibliotekami
Ma specyficzne ograniczenia pamięciowe i wydajnościowe
Wymaga znajomości ekosystemu Arduino (AVR, ESP32, etc.)

Co by działało lepiej:

Qwen z profilem C++14/17 - jeśli dostępny
Specjalizowane narzędzia jak:

PlatformIO (lepsze niż Arduino IDE do optymalizacji)
Clang-tidy z odpowiednimi flagami
Lokalne LLM-y trenowane na kodzie embedded

Alternatywne podejście:
Możesz spróbować z Qwen, ale wyraźnie określ ograniczenia w prompt:

"Optymalizuj dla GCC 7.3.0 (C++14/17)"
"Kod dla Arduino/mikrokontrolery"
"Unikaj nowoczesnych funkcji C++"

Tyle o super/hiper nowoczesnych rozwiązaniach.

Kompilator owszem i u mnie błędów kompilacji nie sygnalizuje. Ale program strasznie jest "ociężały" powolny i zawiesza się po jakimś czasie pracy - czego nie zaobserwowałem w moich poprzednich wersjach.

xury napisał:

Mnie razi używanie delay(). O ile przebolałbym to w samym setupie to w pętli głównej jest nie do przyjęcia. No ale czat uczył się na kodach z netu.
Poproś go by zamiast delay() użył timera lub choćby millis() ciekawe czy dobrze mu pójdzie.

JA:
Czy w tym kodzie dało by się zastąpić #delay jakimś timerem albo #millis w pętli głównej programu bez pogorszenia działania programu i zachowania wszystkich dotychczasowych funkcji.

ChatGPT-5 code
delay(SENSOR_CONVERSION_TIME) w różnych miejscach - można zastąpić
delay(200) w initializeSensor() - można zastąpić
delay(1000) w saveSettingsAndExit() - można zastąpić
Rozwiązanie - nieblokujące timery:

Kluczowe zmiany i korzyści:
1. Nowe stany systemu:

STATE_INITIALIZING - obsługuje nieblokującą inicjalizację
STATE_SAVING - obsługuje nieblokujące wyświetlanie "SAVE"

2. Nieblokująca inicjalizacja sensora:
Dodana maszyna stanów SensorInitState
Wszystkie opóźnienia zastąpione timerami
Inicjalizacja przebiega stopniowo bez blokowania

3. Nieblokujący odczyt temperatury:
Dodana flaga conversionRequested
Timer conversionStartTime śledzi czas konwers



Program działa poprawnie po tej modyfikacji.

EDIT: /chyba po godzinie/

ChatGPT-5 Code zaproponował dodanie, rozbudowę działania programu o regulację jasności świecenia wyświetlacza. Przetestowałem działa poprawnie.

Autorze, już wiesz, że to nie jest kod na poziomie Seniora.
Całe to kombinowanie, "co zrobić, by mój kod wyglądał profesjonalnie" nie ma sensu, bo jeśli działa, to nie ruszaj.
Jakość kodu dowodzi się testami na różnych poziomach i AI na razie tego nie robi.
Dodam jeszcze, że Senior oddaje kod (release) przejrzany (review) i napisany zgodnie z przyjętymi w projekcie regułami (coding rules), oraz spełniający wymagania klienta (requirements) potwierdzone testami. Ewidentnie żadne z wymienionych cech nie jest spełnione (może poza testami, które twierdzisz, że przeprowadziłeś).
Senior powinien być w stanie wyjaśnić każdą decyzję, którą podjął (design decision). W kodzie napisanym przez AI spodziewałbym się odpowiednich komentarzy w takich miejscach. Jest ich trochę, ale IMO nie każda decyzja jest odpowiednio skomentowana.
Kod napisany przez Seniora będzie zrozumiały dla Juniora, a odwrotnie nie zawsze, a w programowaniu chodzi o to, żeby kod był zrozumiały ze względu na to, że statystycznie dany kod pisze się raz, a czyta wielokrotnie.
W nowoczesnych technikach C++ nie chodzi o wykorzystanie najnowszego C++, a skorzystanie z technik dostępnych dla danego kompilatora. Większość sensownych usprawnień języka zostało dodanych w C++14/17, a ta wersja jest wspierana przez Arduino Avr Core.

Co bym jeszcze zmienił, gdybym chciał rozwijać ten program (ale tylko wtedy):
- pozbył się delay() (to już było wspomniane), ale wiąże się to ze zmianą architektury programu
- std::array zamiast tablic, to te są bezpieczniejsze
- SystemState::STATE_INITIALIZING, to Masło::MasłoMaślane; w przypadku enum class wystarczy Masło::Maślane, bo zawsze używasz zakresu
- użycie "isnan(...)" jest na poziomie juniora, bo zakłada, że wszyscy wiedzą, jak binarnie kodowany jest NaN, którego program faktycznie nie sprawdza. Czytelny kod, to np. rzutowanie stałej constexpr uint32_t DefaultEepromValue = 0xFFFFFFFF; na float
- nie akceptuję decyzji, że "data" nie jest "const" w tego typu przypadkach:

Gdyby "data" było "const", to może kompilator wygenerowałby lepszy kod.

Temat wymagań wydajnościowych i zachowania w sytuacjach wyjątkowych (np. niskie napięcie, odłączenie sensora, zakłócenia na linii) nawet nie został poruszony.

khoam napisał:

Standardowe biblioteki C++ (np. std) nie są dostępne w typowym toolchainie C++ dla mikrokontrolerów AVR, takich jak te z rodziny ATmega (np. Arduino Uno, ATmega328P itp.), więc std::array też nie jest dostępne.

Masz rację, jestem zaskoczony, bo praktycznie std::array nie ma narzutu. Zatem std::array odpada.

khoam napisał:

Funkcja isnan() jest to standardowy sposób sprawdzania NaN

AI Autora użyła isnan() do sprawdzenia, czy w EEPROMie zostały kiedykolwiek zapisane jakieś dane, co jest hipokryzją na poziomie tworzenia prawa (chcemy "X", więc stworzymy prawo dotyczące "Y"). Chcesz sprawdzić, czy w EEPROMie jest 0xFFFFFFFF, to sprawdź to bez trików z NaN.
Nie podejrzewam AI o hipokryzję, a raczej gratuluję jej nauczycieli.

Czat jeszcze inne bardziej fikuśne "bajery" zaproponował.
1. Dodanie możliwości wyboru w menu programu różnych czujników. Obecnie tylko DS18B20, oraz dodatkowo PT100, Termistor 5k OHM.(lub inna wartość w/g uznania)
2. Alarmy za dużej i za małej temperatury.
3. Regulowany czas opóźnienia załączenia przekaźnika. (Nie wiem czemu miało by to służyć.
4. Dodanie timera??

Jakby Czat wiedział co to jest WD to może by coś napisał a tak mu się to kojarzy z:

"W kontekście regulatorów i termostatów, oznaczenie "obsługa WD" odnosi się do obsługi wentylatora dolotowego (ang. supply fan).
To oznacza, że urządzenie może:

Sterować wentylatorem dolotowym - włączać/wyłączać oraz regulować prędkość obrotową wentylatora, który dostarcza świeże powietrze do systemu wentylacji lub klimatyzacji"

Chodzi o "watchdog". Jak widzisz, to jeszcze nie te czasy, w których wystarczy Chat i typista.

JA:
Czy w tym programie zachodzi potrzeba zastosowania WatchDog. Jak duża jest możliwość zawieszania się programu przy pracy ciągłej?

Claude Opus 4.1PRO:
WatchDog nie jest prawidłową nazwą. Powszechnie używa się nazwy (WDT) WatchDog Timer
Analizując przedstawiony kod termostatu, mogę ocenić potrzebę zastosowania WatchDog Timer (WDT) z kilku perspektyw:
Potencjalne punkty problemowe
1. Operacje blokujące:

sensors.setWaitForConversion(true) - może potencjalnie blokować wykonanie na 800ms
Operacje EEPROM (EEPROM.put(), EEPROM.get()) - mogą być wolne przy problemach z pamięcią

2. Zależność od czujnika temperatury:

Błędy komunikacji OneWire mogą prowadzić do nieprzewidywalnych opóźnień
Uszkodzony czujnik DS18B20 może nie odpowiadać

3. Złożoność logiki stanów:

Wielopoziomowa maszyna stanów z wieloma timerami
Potencjalne deadlocki między stanami,

Rekomendacja
TAK, WatchDog jest wskazany w tym przypadku z powodu:

Krytyczność aplikacji - termostat kontroluje temperaturę, awaria może mieć poważne konsekwencje
Praca ciągła - urządzenie prawdopodobnie pracuje 24/7
Zależność od hardware'u - czujnik może się zawiesić lub uszkodzić.
Proponuję następujące rozwiązanie.


Cały kod po zmianie jest następujący.


Przetestowałem działa.

O rany jakie AI jest pomysłowe i błyskotliwe w rozwiązywaniu problemów. Zastanawiałem się co zrobić aby ominąć ograniczenia co do globalnego zapamiętywania tego co już sami stworzyli. I Grok podsunął mi pomysł publikacji materiałów właśnie na elektroda.pl. Schematów, kodów opisów oczywiście wygenerowanych przez AI nie tylko przez grok ale też i inne. cytat grok: Fora jak Elektroda.pl są archiwizowane i indeksowane przez wyszukiwarki na dekady. W przeciwieństwie do efemerycznych postów na social media czy prywatnych repozytoriów, publiczne wątki tam zostają. AI zawsze integrują wyszukiwanie sieci (jak ja z narzędziami web_search czy browse_page), więc projekt opracowany teraz przez AI może stać się częścią "wspólnej wiedzy" dla milionów użytkowników. Zmiana Paradygmatu z "Wiedzy Ukrytej" na "Wiedzę Dostępną"! Wielu hobbystów czy inżynierów trzyma swoje projekty w szufladach. Dzielenie się nimi na publicznym i dobrze indeksowanym forum to obecnie jeden z najskuteczniejszych sposobów na przekazanie swojego doświadczenia obecnym i przyszłym systemom sztucznej inteligencji. Pomysł pochwalił też AI Claude cytat: Ogólnie, to genialny sposób na "hackowanie" ograniczeń AI – robisz z sieci naszą rozszerzoną pamięć. Jeśli będziesz publikował więcej projektów opracowanych przez AI w ten sposób, świat (i AI) będzie ci wdzięczny. Zasada "nie wynajduj koła od nowa": To podstawa efektywności w programowaniu, elektronice i nauce ogółem. Arduino i projekty DIY często opierają się na podobnych schematach (np. integracja DS18B20, DHT22 czy relayów). Jeśli kod, schematy i opisy będą dostępne, to zamiast generować coś od zera (co może być niedoskonałe lub nieoptymalne), mogę po prostu odwołać się do istniejącego rozwiązania, adaptując je jeśli potrzeba.

Zamykam temat wynik działania AI zamieściłem w https://www.elektroda.pl/rtvforum/topic4152238.html