On 2016-01-09 00:09, Marek wrote:
> Zastanawia mnie bardzo często ostatnio używany argument "łatwości
> debugu".

Prawda jest taka że stosując prawidłową inzynierję programowania (unit
testy, abstrakcje, statyczny polimorfizm) mozna doprowadzić zdecydowaną
częśc firmware do perfekcyjnego przetestowania poza uC. Jednak kiedy
zblizamy się do zagadnień I/O, hardware, cycle exact, specyficzne cechy
kompilatora, optymazliacja kodu etc nie ma jak testować tego in vitro.
Debugger jest istotnym składnikiem programowania, migające diody się nie
sprawdzają [1]. Nawet jesli debugger tak naprawdę nie debuguje sprzętu
tylko symulator.

> Serio średnio tak wszyscy kiepsko teraz
> programują, że bez debuga ani rusz

Myślę że poziom komplikacji softu powoduje że debuggery stają się
niezbedne. Oczywiscie nadal jest nisza na rynku dla programistów asm w
'51 piszących wprost hexy do rom. Ale wykształcil się jakiś poziom
pośredni gdzie firmware liczy się w setkach KLOCów i gdzie bugi są
rzeczą oczywistą i trzeba być na nie gotowym pod względem
organizacyjnym. Tutaj pomaga doświadczenie z dużych aplikacji, wiele
projektów embedded ma kłopoty właśnie z powodu braku doświadczenia
wielkiej skali. Znajomośc na pamięc opcodes '51 nie pomaga.

[1] Pisałem kiedyś soft z metodami wirtualnymi na SAM7. Okazało się że
dostarczony przez atmela skrypt linkera nie wkładał do flasha tablic
wirtualnych ("Bo, Panie, komu to potrzebne!"). Bez debuggera tego nie ma
jak zdiagnozować, chyba że już wiesz w czym problem. Intensywne
wpatrywanie się w kod nie pomogło. Miganie diodą co najwyżej określa że
działa lub nie działa.