Mikrokontrolery przyjazne dla amatorów

On 2016-01-09 00:09, Marek wrote: [...]

Wiesz, Hello Worldy i blinking LEDy to i ja piszę bezbłędnie. :-D

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 :).

On 2016-01-09 10:46, Marek wrote: [...]

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. :-)

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.

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.

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.

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

Dooobre :)

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

J.

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

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 ;)

On 2016-01-09 12:15, Sebastian Biały wrote: [...]

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.

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. :-)

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.

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.

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.

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ć.

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.

On 2016-01-09 13:42, Sebastian Biały wrote: [...]

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.

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. :-)

Wychodzi na to. że czytanie skryptów GNU linkera to chyba mój fetysz. :-)

On 2016-01-09 13:28, Marek wrote: [...]

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.

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

a.

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

Marek Borowski snipped-for-privacy@nazwisko.com napisał(a):

Nie zauważyłem problemów na F4, L0 i L1.

Skrypty linkera zawsze udawało mi się znaleźć Googlem.

No coż, sprawdze jeszcze raz. Uzywasz EmbSysRegView czy cos innego ?

Smutne jest to, że środowiska za spora kase też nie dzialają w pełni poprawnie.

Kupilem CrosWorks to crashowalo sie przy debugowaniu programu pisanego w C++. Na rozwiazanie problemu przez support w sumie sie nie doczekałęm. (Przeszedlem na TrueStudio).

Kupilem TrueStudio który też ma problem z debugowaniem programu C++ jako tasku FeeRTOSa. I tu też dałem sobie spokój z korespodowaniem z supportem. Aczkolwiek jeden inny bład zgłoszony przeze mnie został w nowej wersji poprawiony.

Pozdrawiam

Marek