On 15/11/2021 19:57, Grzegorz Niemirowski wrote:
>> Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR.
>> Miliony programistów Arduino raczej by go znalazły.
> Oczywiście nie mówię o bugach w AVR. Chodzi o to, że urządzenie nie
> składa się z samego MCU. Masz też różne inne układy, które mogą się
> zachowywać inaczej niż myślałeś lub mieć błędy. Przykładowo UART w
> Raspberry Pi wysyłał na początku transmisji dodatkową szpilkę, która
> mogła być traktowana jako bit startu. Nie było to nigdzie opisane.
> Pracując w embedded takie i inne kwiatki spotyka się cały czas.

Zgadza się. Dlatego psu na budę debugger softwareowy w roli debuger
hardwareowego. To najzwyczajneij zupełnie inne zagadnienie.

>> Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu
>> musisz ich używać, to masz kiepsko napisany kod.
> To jest akademicka teoria. Powiedz twórcom GDB, że zmarnowali swój czas

Obserwacja z pola bitwy: prawidłowe pisanie kodu minimalizuje potrzebę
używania debuggera. Do zera? Nie. Blisko zera? Tak. Mówiąc "pisanie
kodu" mam na myśli testowanie go a dopiero potem pisanie. Zwyczajowo
waga unit testów znaczaco przekracza wagę kodu produkcyjnego.

Obserwacja z innego pola: debuggery softwareowe nie nadają się do
*rzeczywistych* systemów hardwareowych gdzie istnieją zalezności
czasowe. Do tego bezpieczniej jest stosować symulatory logiczne z
emulacją cpu i peryferiów. Tylko wtedy nie wiadomo czy bug jest u mnie
czy w emulacji. I takie symulatory za darmo się nie rozdają.

Ja ten problem rozwiązywałem kiedyś kradnąć rdzeń AVR z projektu MAME i
dorabiając ręcznie napisany emulator pewnego peryferium, dzięki czemu
udało się namierzyć buga, ale to jednorazowy wyskok, raczej desperacja.

> :) Debuger jest normalnym narzędziem i sięganie po niego nie musi wcale
> źle świadczyć o programiście. Jego brak jest ograniczeniem środowiska.

Nie o tym mowa.

W środowisku softwareowym, debugger to normalne narzędzie z łatwo
(zazwyczaj) powtarzalnymi przypadkami.

W środowisku hardwareowym jest to narzędzie skrajnie trudne do użycia.
Wyobraź sobie debugowanie przez JTAG procesora, który ma wysyłać co
milisekundę heartbeat do watchdoga zewnątrznego. Zatrzymujesz go na
breakpoincie i jesteś umarty.

Albo symulujesz całość *systemu* hardwareowego i tam debugujesz w
komfortowych warunkach, albo masz na głowie niezliczone ilosci problemów
z faktem że czas mimo zatrzymania programu pędzi dalej, przerwania się
nie obsługują, bufory się przepełniają, ciekłe kryształy się elektrolizują.

gdb to nie jest narzędzie do debugowania w hardware, poza śmiesznie
prostymi przypadkami debugowania kodu wysokopoziomowego. Co akurat robi
się prawie zawsze na maszynei dev, a nie w hardware.

>> Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest
>> mało potrzebny.
> Piszesz o nich jak o bibliotekach libc. Tymczasem mają one nieraz błędy
> i słabą dokumentację.

Zupełnie jak wiele kawałków hardware, używanych codziennie. Ogólnie
świat hardware to nic specjalnie pewnego. Więc niejako karę za hobby
embedded niech będzie czujnośc, że wszędzie czają się bugi, a te
hardwareowe są najweselsze.

>> Ale nie jestem przekonany, czy środowiska do embedded są znakomite.
>> Jak na razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na
>> same słowa "embedded IDE".
> No właśnie :) Tym bardziej Arduino IDE :)

Od Arduino jak najdalej. Nie miej wrażenia, że jesli zapytałem o
religijnośc poglądów na Arduion, to jestem fanem. To Qpa. Ale pozwole
sobie na jeden komplement: mimo wymachiwania pięściami przez 60latków z
embedded, wprowadził tylnymi drzwiami C++ do świata uC. Podziękowania
się należą, nowe pokolenie programistów embedded będzie dzieki temu
bardziej ateistyczne.

do góry

On 15.11.2021 17:46, heby wrote:

> Pod spodem jest ten sam kompilator gcc, używany w projektach komercyjnych.

Co więcej, Arduino zrobiło jedną, bardzo ważną rzecz - wprowadziło na
większą skalę obiektowość do świata mikrokontrolerów. Właściwie
wszystkie biblioteki dla tego ekosystemu są pisane jako klasy C++, ze
wszystkimi zaletami wynikającymi z dziedziczenia. Na przykład biblioteki
graficzne są definiowane jako warstwa abstrakcji, z interfejsem do
operacji I/O w formie metod czysto wirtualnych. Te metody potem
implementuje autor sterownika wyświetlacza, który dziedziczy po
bibliotece graficznej.
I nie żebym miał cokolwiek przeciwko tradycyjnemu C - sam piszę kod do
większości swoich projektów w ten sposób. Jednak mamy XXI wiek, w MCU
nie trzeba już liczyć bajtów i cykli, a dzieciakom dzisiaj zaczynającym
zabawę z programowaniem w przyszłości prędzej przyda się umiejętność
sprawnego pisania obiektowego kodu.

do góry

heby <h...@p...onet.pl> napisał(a):
> Zgadza się. Dlatego psu na budę debugger softwareowy w roli debuger
> hardwareowego. To najzwyczajneij zupełnie inne zagadnienie.

Zgadza się. Ja tylko piszę, że debugger jest przydatny i wolę środowisko,
które go ma od środowiska, którego go nie ma. Czy się pisze na AVR czy jakiś
Threadripper od czasu do czasu trzeba sprawdzić jaki jest stan zmiennych,
rejestrów czy też je zmodyfikować. Z wielu różnych powodów, nie dlategto, że
ktoś użył za mało abstrakcji.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

Atlantis <m...@w...pl> napisał(a):
> Co więcej, Arduino zrobiło jedną, bardzo ważną rzecz - wprowadziło na
> większą skalę obiektowość do świata mikrokontrolerów. Właściwie wszystkie
> biblioteki dla tego ekosystemu są pisane jako klasy C++, ze wszystkimi
> zaletami wynikającymi z dziedziczenia. Na przykład biblioteki graficzne są
> definiowane jako warstwa abstrakcji, z interfejsem do operacji I/O w
> formie metod czysto wirtualnych. Te metody potem implementuje autor
> sterownika wyświetlacza, który dziedziczy po bibliotece graficznej.
> I nie żebym miał cokolwiek przeciwko tradycyjnemu C - sam piszę kod do
> większości swoich projektów w ten sposób. Jednak mamy XXI wiek, w MCU nie
> trzeba już liczyć bajtów i cykli, a dzieciakom dzisiaj zaczynającym zabawę
> z programowaniem w przyszłości prędzej przyda się umiejętność sprawnego
> pisania obiektowego kodu.

Podpisuję się pod wszystkim :)
Przy okazji polecam obejrzeć bardzo ciekawą prezentację pokazującą, że C++
może dać mniejszy kod niż C.
https://www.youtube.com/watch?v=PDSvjwJ2M80

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 16/11/2021 11:26, Grzegorz Niemirowski wrote:
>> Zgadza się. Dlatego psu na budę debugger softwareowy w roli debuger
>> hardwareowego. To najzwyczajneij zupełnie inne zagadnienie.
> Zgadza się. Ja tylko piszę, że debugger jest przydatny i wolę
> środowisko, które go ma od środowiska, którego go nie ma.

Owszem, czasem się przydaje. Przydawał by się 100x bardziej, gdyby
zawierał symulator SoC. A tak, to tylko zabawka powodująca więcej
problemów niż rozwiązująca.

Tak czy inaczej, utracenie mozliwosci debugowania w małym programiku na
AtTiny, jest w zasadzie niczym cennym. Ot, gadżet, mało użyteczny w
praktyce.

do góry

On 2021-11-14 17:46, heby wrote:
> On 13/11/2021 09:40, Bool wrote:
>> Dodam tylko że Arduino mnie kompletnie nie interesuje.
>
> To jakiś pogląd religijny?

Nie, ale nazwa Arduino to taki fake.
Fajne powstają rozszerzenia harwarowe łatwo je obsłuzyć, ale nie
używałem nigdy narzędzi zapisujących ext .ino.
Może kwestia przyzwyczajenia.
A gdy ktoś mówi/pisze: "procesor Arduino", nie brzmi poważnie.

do góry

To prawda, jednak w 20MHz ATMega (czy 32MHz XMega) trochę niekorzystnie
wypada overhead zasobów. To są sterowniki do najprostszych zadań. Prosta
maszynę stanów łatwiej napisać w C (włącznie z nauką tegoż pisania).

do góry

On 16.11.2021 18:30, Pcimol wrote:

> To prawda, jednak w 20MHz ATMega (czy 32MHz XMega) trochę niekorzystnie
> wypada overhead zasobów. To są sterowniki do najprostszych zadań. Prosta
> maszynę stanów łatwiej napisać w C (włącznie z nauką tegoż pisania).

To oczywiste, przy czym dzisiaj coraz rzadziej zaczynając nowy projekt
sięga się po ośmiobitowe MCU (pomijając obecne problemy na rynku
półprzewodników) dużo łatwiej kupić jakiś układ STM32, który w tej samej
cenie zaoferuje co najmniej dziesięć razy tyle pamięci, szybsze
taktowanie i bogatszy zestaw peryferiów. W takiej sytuacji dodatkowy
narzut wynikający z użycia C++ nie jest wielkim problemem.

I jasne - kod pod MCU pisze się inaczej, bo cały czas trzeba uważać ze
stosowaniem kontenerów i algorytmów z STD, które dość intensywnie
korzystają z dynamicznej alokacji pamięci, jednak sama przejrzystość
obiektowego kodu jest sporą zaletą.

No i poza tym gdy ktoś już porządnie opanuje C++, to potem zrozumienie
"czystego C" przychodzi raczej łatwo.

do góry

Pcimol <...@...com> napisał(a):
> A gdy ktoś mówi/pisze: "procesor Arduino", nie brzmi poważnie.

Niektórzy używają nazw Arduino i AVR zamiennie.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On Mon, 15 Nov 2021 20:22:11 +0100, heby <h...@p...onet.pl> wrote:
> sobie na jeden komplement: mimo wymachiwania pięściami przez
> 60latków z
> embedded, wprowadził tylnymi drzwiami C++ do świata uC.
> Podziękowania
> się należą, nowe pokolenie programistów embedded będzie dzieki temu
> bardziej ateistyczne.

Szczerze mówiąc nie wiem co chciałeś powyższym przekazać. Moje
doświadczenia z udostępnienia Arduino (i C++) znajomej osobie 60+
(prawie 70) jest takie, że kod jaki ona pisze to nie ma nic wspólnego
C++ a wygląda jak rzutowanie Pascala na C.

--
Marek

do góry