W dniu 2016-01-09 o 00:09, Marek pisze:
> On Fri, 8 Jan 2016 18:59:13 +0100, Sebastian Biały<h...@p...onet.pl>
> wrote:
>> Dlaczego? STM supportuje w większości cpu jtag, dorzucasz openeocd
> + gdb
>> i masz de facto pelny debug pod czym chcesz.
>
>> Chyba wszystkie army z tej okolicy debuguje się identycznie i
> raczej
>> *niczego* nie brakuje, może poza sprzetowymi pułapkami
>
> Zastanawia mnie bardzo często ostatnio używany argument "łatwości
> debugu". Praktycznie nigdy nie miałem potrzeby debugować (a programuje
> unices, mcu 8 i 32bit}. Serio średnio tak wszyscy kiepsko teraz
> programują, że bez debuga ani rusz, wręcz staje się to kryterium wyboru
> narzędzi/platformy??
>

kwestia komplikacji softu. w 99% debugger nie jest potrzebny, ale jak
trafisz na ten 1% bez niego, to problem potrafi zjeść zdecydowanie za
duzo czasu

a.

do góry

On 2016-01-09 00:09, Marek wrote:
[...]
> Zastanawia mnie bardzo często ostatnio używany argument "łatwości
> debugu". Praktycznie nigdy nie miałem potrzeby debugować (a programuje
> unices, mcu 8 i 32bit}.
Wiesz, Hello Worldy i blinking LEDy to i ja piszę bezbłędnie. :-D

do góry

On Sat, 9 Jan 2016 00:17:43 +0100, Artur Miller <n...@n...com>
wrote:
> kwestia komplikacji softu. w 99% debugger nie jest potrzebny, ale
jak
> trafisz na ten 1% bez niego, to problem potrafi zjeść zdecydowanie
za
> duzo czasu

Z tego wynika, że ten 1% ma decydujące kryterium wyboru
dyskwalifiujące środowiska bez (dobrego) debuggera, dla mnie to jest
zaskakujące.
Odkładając argument czasu, który do mnie przemawia w okolicznościach
komercyjnych, to w warunkach hobbystycznych takiego znaczenia
(przynajmniej dla mnie) nie ma.
Zdarzyło mi się oczywiście debugować coś ledem (bo innej możliwości
nie było) ale w życiu bym wtedy nie wypadł by pójść na łatwiznę i
użyć debuggera :).

--
Marek

do góry

On 2016-01-09 10:46, Marek wrote:
[...]
> Zdarzyło mi się oczywiście debugować coś ledem (bo innej możliwości nie
> było) ale w życiu bym wtedy nie wypadł by pójść na łatwiznę i użyć
> debuggera :).
Gdy ktoś rzeźbi w sofcie embedded to mrugający LED czy też oscyloskop to
są również debuggery. Bo służą do usuwania bug-ów. :-)

do góry

W dniu 2016-01-09 o 10:46, Marek pisze:
> On Sat, 9 Jan 2016 00:17:43 +0100, Artur Miller <n...@n...com> wrote:
>> kwestia komplikacji softu. w 99% debugger nie jest potrzebny, ale
> jak
>> trafisz na ten 1% bez niego, to problem potrafi zjeść zdecydowanie
> za
>> duzo czasu
>
> Z tego wynika, że ten 1% ma decydujące kryterium wyboru
> dyskwalifiujące środowiska bez (dobrego) debuggera, dla mnie to jest
> zaskakujące. Odkładając argument czasu, który do mnie przemawia w
> okolicznościach komercyjnych, to w warunkach hobbystycznych takiego
> znaczenia (przynajmniej dla mnie) nie ma.
> Zdarzyło mi się oczywiście debugować coś ledem (bo innej możliwości nie
> było) ale w życiu bym wtedy nie wypadł by pójść na łatwiznę i użyć
> debuggera :).
>

decydujące może nie jest, ale... dla mnie osobiście ma dość duże
znaczenie. chyba, że zostajemy na sterowaniu do bramy albo wyłącznikach
do lampki :) wtedy pozostaje zdefiniować gdzie kończy się "amator" a
gdzie zaczyna "poważny amator" :)

a.

do góry

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.

do góry

Dnia Sat, 9 Jan 2016 12:15:36 +0100, Sebastian Biały napisał(a):

> Intensywne wpatrywanie się w kod nie pomogło

Dooobre :)
--
Jacek
-Co robi Jarosław jak ma ochotę popieprzyć?
-Odwraca kota ogonem... :)

do góry

Dnia Sat, 9 Jan 2016 12:15:36 +0100, Sebastian Biały napisał(a):
> 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.

Ano - nie ma jak.
Tym niemniej sporo bledow lezy po stronie programisty (dokumentacji
etc.), i debugger tu sporo upraszcza namierzenie bledu.
Przydatna rzecz.

J.

do góry

On Sat, 9 Jan 2016 10:15:24 +0100, JDX <j...@o...pl> wrote:
> Wiesz, Hello Worldy i blinking LEDy to i ja piszę bezbłędnie. :-D

Wbrew pozorom wcale nie to miałem na myśli :)

--
Marek

do góry

On Sat, 9 Jan 2016 12:15:36 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> wpatrywanie się w kod nie pomogło. Miganie diodą co najwyżej
określa że
> działa lub nie działa.

Miałem na myśli komunikację ledem, ja w ten sposób zwracałem
mignieciami wartości liczbowe np. rejestrów, oczywiście w hex ;)

--
Marek

do góry