On 2016-01-09 12:15, Sebastian Biały wrote:
[...]
> Debugger jest istotnym składnikiem programowania, migające diody się
> nie sprawdzają [1]. Nawet jesli debugger tak naprawdę nie debuguje
> sprzętu tylko symulator.
Debugger też się nie sprawdzi jeśli masz błąd w sprzęcie, zwłaszcza błąd
typu "raz działa, a raz nie" w zależności od tego, jak jest ułożony na
stole kabel Ethernet. Po czym paru dniach dzięki twojej genialności i
*prywatnemu* doświadczeniu z danym kontrolerem Ethernet okazuje się, że
osoba która przemalowywała schemat aplikacyjny kontrolera zapomniała
przemalować jeden oporek. :-) Albo projektanci sprzętu dobrali
kondensator o zbyt dużej pojemności w wyniku czego sprzęt nie do końca
działa tak jak powinien.

> 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.
No. :-) We wspomnianym wyżej przypadku zdążono już naklepać (w
zewnętrznej, znanej firmie zajmującej się montażem kontraktowym) trochę
modułów Ethernet, a później ludzie z (naszej) produkcji siedzieli i
dospawywali do płytek brakujące oporki. :-)

> [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.
No nie wiem. Ja pierwsze co bym zrobił zanim zacząłbym jeszcze cokolwiek
kompilować i linkować to zajrzałbym do skryptu linkera i przejrzał kod
startowy. :-) Niezależnie od języka programowania i niezależnie od
platformy docelowej. A później przejrzał log linkera.

do góry

On Sat, 9 Jan 2016 13:00:27 +0100, JDX <j...@o...pl> wrote:
> No nie wiem. Ja pierwsze co bym zrobił zanim zacząłbym jeszcze
cokolwiek
> kompilować i linkować to zajrzałbym do skryptu linkera i przejrzał
kod
> startowy. :-) Niezależnie od języka programowania i niezależnie od
> platformy docelowej. A później przejrzał log linkera.

Ale nie spojrzą bo teraz wszystko poukrywane w IDE zamiast oparte jak
się należy na makefile'ch. Spora część nawet nie ma pojęcia, że jest
linker i do czego służy a budowanie jego skryptów to już abstrakcja.

--
Marek

do góry

On 2016-01-09 12:40, Marek 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 ;)

Tak, ale w tym przypadku problem polega na tym ze program idzie w maliny
z powodu skodu pod NULL w tablicy wirtualnej. Nie da się tego sensownie
zdiagnozować miganiem.

do góry

On 2016-01-09 13:00, JDX wrote:
>> Debugger jest istotnym składnikiem programowania, migające diody się
>> nie sprawdzają [1]. Nawet jesli debugger tak naprawdę nie debuguje
>> sprzętu tylko symulator.
> Debugger też się nie sprawdzi jeśli masz błąd w sprzęcie

Nie do tego on służy. Do prawdzania bugów w sprzęcie na poziomie
projektu służą symulatory. Tam też są debuggery, ale zgoła inne niż do
sfotware. Ale symulatory nie pomagają na buga implementacyjnego.

> przemalować jeden oporek. :-) Albo projektanci sprzętu dobrali
> kondensator o zbyt dużej pojemności w wyniku czego sprzęt nie do końca
> działa tak jak powinien.

To wszystko problemy implementacyjne. Innymi słowy rola debugera
soft/hard zakonczyła się etap wcześniej. Choć i w takich przypadkach
czasem można coś jeszcze wydłubać debuggerem to na fakt że głosnik nie
gra bo go nie ma, debuggerem niewiele mozna poradzić.

> No nie wiem. Ja pierwsze co bym zrobił zanim zacząłbym jeszcze cokolwiek
> kompilować i linkować to zajrzałbym do skryptu linkera i przejrzał kod
> startowy. :-)

Nie. Nie robisz tego. Tym bardziej że 100% exampli dziala na tym
skrypcie poprawnie. Tylko mi nie działa. I nagle okazuje sie że jestem
pierwszy który na tym skrypcie kompiluje metode wirtualną. Napisałem do
Atmela, ale nie doczekałem się odpowiedzi, zapewne popukali się w głowę
nad biednym idiota stosującym c++. Bo kto normalny, Panie, stosuje.

Ponadto skrypty linkera to sieczka. Absolutnie nie do czytania przez
jednostki białkowe.

do góry

On 2016-01-09 13:42, Sebastian Biały wrote:
[...]
> Nie do tego on służy. Do prawdzania bugów w sprzęcie na poziomie
> projektu służą symulatory. Tam też są debuggery, ale zgoła inne niż do
> sfotware. Ale symulatory nie pomagają na buga implementacyjnego.
Ale nie wiesz czy bug jest na poziomie sprzętu. Przychodzi do ciebie,
jako systemowca, funio i mówi "Wicie, rozumicie, Ethernet nam tu
niestabilnie działa, zróbcie żeby działał stabilnie". No to siadasz i
zaczynasz dłubać, m.in. z debuggerem. Dopiero po paru dniach tak
spędzonych dochodzisz do wniosku: "K..wa! To musi być coś ze sprzętem".
Bierzesz schemat i patrzysz. Później wołasz koleżkę sprzętowca który ten
schemat malował i po kilku godzinach znajdujecie błąd.

> Nie. Nie robisz tego. Tym bardziej że 100% exampli dziala na tym
> skrypcie poprawnie. Tylko mi nie działa. I nagle okazuje sie że jestem
> pierwszy który na tym skrypcie kompiluje metode wirtualną. Napisałem do
> Atmela, ale nie doczekałem się odpowiedzi, zapewne popukali się w głowę
> nad biednym idiota stosującym c++. Bo kto normalny, Panie, stosuje.
To źle świadczy o kolesiach z Atmela. W każdym razie ja nie napisałem
ani jednej linijki poważnego kodu C++ na embedded, a wiem, że w stosunku
do C trzeba tam zapodać linkerowi dodatkowe sekcje. :-)

> Ponadto skrypty linkera to sieczka. Absolutnie nie do czytania przez
> jednostki białkowe.
Wychodzi na to. że czytanie skryptów GNU linkera to chyba mój fetysz. :-)

do góry

On 2016-01-09 13:28, Marek wrote:
[...]
> Ale nie spojrzą bo teraz wszystko poukrywane w IDE zamiast oparte jak
> się należy na makefile'ch. Spora część nawet nie ma pojęcia, że jest
> linker i do czego służy a budowanie jego skryptów to już abstrakcja.
Mejkfajl też nie załatwia wszystkiego. Ze dwa miesiące chciałem sobie
podebugować KiCada (czyli duży projekt) który jest budowany za po pomocą
make (tak, wiem, "wyżej" siedzi CMake) i poległem przy podłączaniu
odpowiednio skompilowanego kodu pod debugger (aczkolwiek nie
przykładałem się do tego "tak od serca"). Gdyby CMake potrafił generować
projekty dla Eclipse CDT używające wewnętrznego buildera zamiast make
pewnie nie miałbym tego problemu.

do góry

W dniu 2016-01-09 o 13:42, Sebastian Biały pisze:
> On 2016-01-09 13:00, JDX wrote:
>>> Debugger jest istotnym składnikiem programowania, migające diody się
>>> nie sprawdzają [1]. Nawet jesli debugger tak naprawdę nie debuguje
>>> sprzętu tylko symulator.
>> Debugger też się nie sprawdzi jeśli masz błąd w sprzęcie
>
> Nie do tego on służy. Do prawdzania bugów w sprzęcie na poziomie
> projektu służą symulatory. Tam też są debuggery, ale zgoła inne niż do
> sfotware. Ale symulatory nie pomagają na buga implementacyjnego.

zakładasz optymistycznie, że symulator jest dokładną funkcjonalną kopią
sprzętu...


a.

do góry

On 2016-01-09 19:51, Artur Miller wrote:
>> Nie do tego on służy. Do prawdzania bugów w sprzęcie na poziomie
>> projektu służą symulatory. Tam też są debuggery, ale zgoła inne niż do
>> sfotware. Ale symulatory nie pomagają na buga implementacyjnego.
> zakładasz optymistycznie, że symulator jest dokładną funkcjonalną kopią
> sprzętu...

Nie zakładam. Nie da się w żaden rozsądny sposób zaemulować pełnych cech
fizycznych sprzetu. I nikt tego nie potrzebuje, na samym koncu jest
mistrz z oscyloskopem, jesli wszystko zawiedzie. Aczkolwiek jak juz
napisałem, symulator, nawet najdoskonalszy, nie jest w stanie zdebugować
braku rezystora na płytce. Ot, trzeba znać ograniczenia. Przy czym
zaznaczam, że bardzo wiele firm zajmujących się embedded pomija
wszystkie etapy tworzenia oprogramowania i nas sam koniec lądują z
nieznanym stanem software i kilkoma diodami. Im debuggery i inne
wyszukane narzedzia są zbedne ;)

do góry

W dniu 2016-01-09 o 20:52, Sebastian Biały pisze:
> On 2016-01-09 19:51, Artur Miller wrote:
>>> Nie do tego on służy. Do prawdzania bugów w sprzęcie na poziomie
>>> projektu służą symulatory. Tam też są debuggery, ale zgoła inne niż do
>>> sfotware. Ale symulatory nie pomagają na buga implementacyjnego.
>> zakładasz optymistycznie, że symulator jest dokładną funkcjonalną kopią
>> sprzętu...
>
> Nie zakładam. Nie da się w żaden rozsądny sposób zaemulować pełnych cech
> fizycznych sprzetu.

stąd dodałem "funkcjonalną".

a.

do góry

On 2016-01-08 20:08, Sebastian Biały wrote:
> On 2016-01-08 19:19, Artur Miller wrote:
>>> Dlaczego? STM supportuje w większości cpu jtag, dorzucasz openeocd + gdb
>>> i masz de facto pelny debug pod czym chcesz.
>> po stronie CPU tak. a debuger?
>
> OpenOCD + gdb. Dalej to już kto co woli, np. Eclipse.
>
To juz plugin wyświetla poprawnie zawartość rejestrów sprzętowych we
wszystkich odmianach chipow ? Debugowanie krokowe nie zawiesza sie
jak się za szybko klawisze wciska ? Stos wywołań jest "dekryptowany"
poprawnie ? Init skrypty dla gdb i linker skrypty sa dostepne czy
trzeba je reczenie pisac za kazdym razem dla nowego ukladu ? To tak na
szybko z przyjemnosci jakie pamietam podczas prob uzywania w/w, a ktore
prawie nie istnieja przy uzywaniu komercyjnych produktów.


Pozdrawiam

Marek

do góry