NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - STM32 czy PIC32? Obszerny przegląd mikrokontrolerów dla amatorów z darmowymi narzędziami!
Goto page Previous 1, 2, 3, 4 Next
JDX
Guest
Guest
Sat Jan 09, 2016 1:00 pm
On 2016-01-09 12:15, Sebastian Biały wrote:
[...]
Quote:
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
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.
Quote:
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
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ć (wzewnę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. :-)
Quote:
[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
ż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.
Marek
Guest
Guest
Sat Jan 09, 2016 1:28 pm
On Sat, 9 Jan 2016 13:00:27 +0100, JDX <jdx@onet.pl> wrote:
Quote:
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.
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
Sebastian BiaĹy
Guest
Guest
Sat Jan 09, 2016 1:35 pm
On 2016-01-09 12:40, Marek wrote:
Quote:
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
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.
Sebastian BiaĹy
Guest
Guest
Sat Jan 09, 2016 1:42 pm
On 2016-01-09 13:00, JDX wrote:
Quote:
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 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.
Quote:
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.
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ć.
Quote:
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.
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.
JDX
Guest
Guest
Sat Jan 09, 2016 4:10 pm
On 2016-01-09 13:42, Sebastian Biały wrote:
[...]
Quote:
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,
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.
Quote:
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
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. :-)
Quote:
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.
jednostki białkowe.
Wychodzi na to. że czytanie skryptów GNU linkera to chyba mój fetysz.
JDX
Guest
Guest
Sat Jan 09, 2016 4:18 pm
On 2016-01-09 13:28, Marek wrote:
[...]
Quote:
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
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.
Artur Miller
Guest
Guest
Sat Jan 09, 2016 7:51 pm
W dniu 2016-01-09 o 13:42, Sebastian Biały pisze:
Quote:
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.
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.
Sebastian BiaĹy
Guest
Guest
Sat Jan 09, 2016 8:52 pm
On 2016-01-09 19:51, Artur Miller wrote:
Quote:
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...
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
Artur Miller
Guest
Guest
Sat Jan 09, 2016 8:59 pm
W dniu 2016-01-09 o 20:52, Sebastian Biały pisze:
Quote:
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.
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.
Marek Borowski
Guest
Guest
Mon Jan 11, 2016 10:16 pm
On 2016-01-08 20:08, Sebastian Biały wrote:
Quote:
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
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
Grzegorz Niemirowski
Guest
Guest
Mon Jan 11, 2016 10:21 pm
Marek Borowski <marek@nazwisko.com> napisał(a):
Quote:
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 ?
wszystkich odmianach chipow ? Debugowanie krokowe nie zawiesza sie
jak się za szybko klawisze wciska ? Stos wywołań jest "dekryptowany"
poprawnie ?
Nie zauważyłem problemów na F4, L0 i L1.
Quote:
Init skrypty dla gdb i linker skrypty sa dostepne czy trzeba je reczenie
pisac za kazdym razem dla nowego ukladu ?
pisac za kazdym razem dla nowego ukladu ?
Skrypty linkera zawsze udawało mi się znaleźć Googlem.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 54 days, 4 hours, 7 minutes and 52 seconds
Marek Borowski
Guest
Guest
Mon Jan 11, 2016 10:44 pm
On 2016-01-11 22:21, Grzegorz Niemirowski wrote:
Quote:
Marek Borowski <marek@nazwisko.com> napisał(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 ?
Nie zauważyłem problemów na F4, L0 i L1.
No coż, sprawdze jeszcze raz. Uzywasz EmbSysRegView czy cos innego ?
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 ?
Nie zauważyłem problemów na F4, L0 i L1.
No coż, sprawdze jeszcze raz. Uzywasz EmbSysRegView czy cos innego ?
Quote:
Init skrypty dla gdb i linker skrypty sa dostepne czy trzeba je
reczenie pisac za kazdym razem dla nowego ukladu ?
Skrypty linkera zawsze udawało mi się znaleźć Googlem.
Smutne jest to, że środowiska za spora kase też nie dzialają w pełni
reczenie pisac za kazdym razem dla nowego ukladu ?
Skrypty linkera zawsze udawało mi się znaleźć Googlem.
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
Sebastian BiaĹy
Guest
Guest
Mon Jan 11, 2016 10:58 pm
On 2016-01-11 22:16, Marek Borowski wrote:
Quote:
To tak na
szybko z przyjemnosci jakie pamietam podczas prob uzywania w/w, a ktore
prawie nie istnieja przy uzywaniu komercyjnych produktów.
szybko z przyjemnosci jakie pamietam podczas prob uzywania w/w, a ktore
prawie nie istnieja przy uzywaniu komercyjnych produktów.
Zapomniałeś jednak o czyms zupełnie innym. Komercyjne kompilatory mają
zawsze coś do dupy. Albo 0 wsparcie dla C++ albo optymializacje które
przedszkolak napisał by lepiej czy kłopoty z kodem trudniejszym niż
miganie diodą. O absurdalnych bugach z gatunku "to akurat nie działa i
co nam zrobicie" nie ma co wspomniać. Już nie mam siły brać nastepny
kompilator i punktować dziecinne braki z gatunku "będzie w wersji N+1
albo nie".
Innymi słowy: każde środowisko ma jakiś feler. Różnica polega na tym że
gcc+gdb zazwyczaj ma support community i bardzo duży zbiór ficzerów
języka. Clang podobnie. Natmiast narzedzia komercyjne mają głeboko w
d... frajera który używa ich bardziej twórczo niż przewidzial producent
(czyli np. templates). Czasem narzędzia komercyjne wygenerują lepszy
kod, ale prawie zawsze będą wymagaly "prostszego" kodu źródlowego. Firmą
robiacym chipy nie opłaca sie inwestować w programistow, w dodatku
elitarnych od tworzenia kompilatorów. Robi się byle jak, na kolanie.
Nikt tu nie pisze o lepszości gdb/gcc. To po prostu inny zbiór
problemów. Mi na SAM7 gdzie naintensywniej używalem Eclipse i gdb nie
udało się znaleźć krytycznych problemów które przekreślają to
środowisko. Wręcz przeciwnie, pracowalo się komfortowo i jestem w stanie
zrobić tam wszystko co niezbędne do debugu.
Grzegorz Niemirowski
Guest
Guest
Mon Jan 11, 2016 11:22 pm
Marek Borowski <marek@nazwisko.com> napisał(a):
Quote:
No coż, sprawdze jeszcze raz. Uzywasz EmbSysRegView czy cos innego ?
Zwykłe Eclipse z wtyczkami z http://gnuarmeclipse.sourceforge.net/updates +
OpenOCD pod Windows.
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 54 days, 5 hours, 8 minutes and 45 seconds
MichaĹ Lankosz
Guest
Guest
Mon Jan 11, 2016 11:48 pm
W dniu 2016-01-08 o 13:07, Atlantis pisze:
Quote:
Jak jest w przypadku innych rodzin? W przyszłości chciałbym się
przyjrzeć STM32. Jak wygląda robienie projektów na tę platformę z punktu
widzenia amatora? Dostępne jest darmowe środowisko i kompilator? Nie ma
żadnych ograniczeń w optymalizacji i/lub rozmiarze generowanego kodu?
przyjrzeć STM32. Jak wygląda robienie projektów na tę platformę z punktu
widzenia amatora? Dostępne jest darmowe środowisko i kompilator? Nie ma
żadnych ograniczeń w optymalizacji i/lub rozmiarze generowanego kodu?
Za pomocą STM32cubeMX generujesz projekt
http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF259242?sc=stm32cube
dla środowiska System Workbench
http://www.openstm32.org/System+Workbench+for+STM32
wszystko darmowe, oparte na gcc, eclipse, openocd i projekt robi się
automagicznie.
Oczywiście jest sporo upierdliwości, ale prostsze to na początek niż
szukanie po sieci skryptów linkera, startupu, makefile które potem
okazuje się nie pasują do siebie.
Można też użyć mbed - https://www.mbed.com/en/ - jakaś alternatywa.
--
Michał
elektroda NewsGroups Forum Index - Elektronika Polska - STM32 czy PIC32? Obszerny przegląd mikrokontrolerów dla amatorów z darmowymi narzędziami!