On 15/11/2021 19:57, Grzegorz Niemirowski wrote:
>> Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR.
>> Miliony programistów Arduino raczej by go znalazły.
> Oczywiście nie mówię o bugach w AVR. Chodzi o to, że urządzenie nie
> składa się z samego MCU. Masz też różne inne układy, które mogą się
> zachowywać inaczej niż myślałeś lub mieć błędy. Przykładowo UART w
> Raspberry Pi wysyłał na początku transmisji dodatkową szpilkę, która
> mogła być traktowana jako bit startu. Nie było to nigdzie opisane.
> Pracując w embedded takie i inne kwiatki spotyka się cały czas.

Zgadza się. Dlatego psu na budę debugger softwareowy w roli debuger
hardwareowego. To najzwyczajneij zupełnie inne zagadnienie.

>> Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu
>> musisz ich używać, to masz kiepsko napisany kod.
> To jest akademicka teoria. Powiedz twórcom GDB, że zmarnowali swój czas

Obserwacja z pola bitwy: prawidłowe pisanie kodu minimalizuje potrzebę
używania debuggera. Do zera? Nie. Blisko zera? Tak. Mówiąc "pisanie
kodu" mam na myśli testowanie go a dopiero potem pisanie. Zwyczajowo
waga unit testów znaczaco przekracza wagę kodu produkcyjnego.

Obserwacja z innego pola: debuggery softwareowe nie nadają się do
*rzeczywistych* systemów hardwareowych gdzie istnieją zalezności
czasowe. Do tego bezpieczniej jest stosować symulatory logiczne z
emulacją cpu i peryferiów. Tylko wtedy nie wiadomo czy bug jest u mnie
czy w emulacji. I takie symulatory za darmo się nie rozdają.

Ja ten problem rozwiązywałem kiedyś kradnąć rdzeń AVR z projektu MAME i
dorabiając ręcznie napisany emulator pewnego peryferium, dzięki czemu
udało się namierzyć buga, ale to jednorazowy wyskok, raczej desperacja.

> :) Debuger jest normalnym narzędziem i sięganie po niego nie musi wcale
> źle świadczyć o programiście. Jego brak jest ograniczeniem środowiska.

Nie o tym mowa.

W środowisku softwareowym, debugger to normalne narzędzie z łatwo
(zazwyczaj) powtarzalnymi przypadkami.

W środowisku hardwareowym jest to narzędzie skrajnie trudne do użycia.
Wyobraź sobie debugowanie przez JTAG procesora, który ma wysyłać co
milisekundę heartbeat do watchdoga zewnątrznego. Zatrzymujesz go na
breakpoincie i jesteś umarty.

Albo symulujesz całość *systemu* hardwareowego i tam debugujesz w
komfortowych warunkach, albo masz na głowie niezliczone ilosci problemów
z faktem że czas mimo zatrzymania programu pędzi dalej, przerwania się
nie obsługują, bufory się przepełniają, ciekłe kryształy się elektrolizują.

gdb to nie jest narzędzie do debugowania w hardware, poza śmiesznie
prostymi przypadkami debugowania kodu wysokopoziomowego. Co akurat robi
się prawie zawsze na maszynei dev, a nie w hardware.

>> Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest
>> mało potrzebny.
> Piszesz o nich jak o bibliotekach libc. Tymczasem mają one nieraz błędy
> i słabą dokumentację.

Zupełnie jak wiele kawałków hardware, używanych codziennie. Ogólnie
świat hardware to nic specjalnie pewnego. Więc niejako karę za hobby
embedded niech będzie czujnośc, że wszędzie czają się bugi, a te
hardwareowe są najweselsze.

>> Ale nie jestem przekonany, czy środowiska do embedded są znakomite.
>> Jak na razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na
>> same słowa "embedded IDE".
> No właśnie :) Tym bardziej Arduino IDE :)

Od Arduino jak najdalej. Nie miej wrażenia, że jesli zapytałem o
religijnośc poglądów na Arduion, to jestem fanem. To Qpa. Ale pozwole
sobie na jeden komplement: mimo wymachiwania pięściami przez 60latków z
embedded, wprowadził tylnymi drzwiami C++ do świata uC. Podziękowania
się należą, nowe pokolenie programistów embedded będzie dzieki temu
bardziej ateistyczne.