Powrót do AVR: Wybór IDE i narzędzi do programowania attiny806

Mon Nov 15, 2021 6:57 pm   

heby <heby@poczta.onet.pl> napisał(a):

Idąc za ciosem można zrezygnować z Arduino zupełnie.


Moje doświadczenia są zgoła odmienne. Nie wiem do czego miałby mi być
potrzebny emulator CPU. Kod pracuje w jakimś urządzeniu i komunikuje się z
innymi układami. Potrzebna jest możliwość sprawdzania co się dzieje w
rzeczywistym układzie. Tu przydaje się oscyloskop, analizator stanów
logicznych oraz debuger.


Więc kłania się punkt 1 - można zrezygnować z Arduino całkowicie, skoro nie
oferuje żadnej dużej wartości.


Pojawia się, ale jest to sztuczne zaciemnianie.


Nawet krótki kod wolę pisać w wygodnym IDE.

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

Mon Nov 15, 2021 7:07 pm   

On 15/11/2021 18:57, Grzegorz Niemirowski wrote:

Dokładnie tak. Przecież to był tylko pretekst do ewaluacji
"hobbystyczne" vs "profesjonalnie" gdzie oba, to tylko inna odmiana
dziadostwa, typowego dla embedded.


Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na
poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać
kod obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na
poziomie 95% coverage, gdzie po stronie AVR znajduja się juz tylko gołe
read/write do rejestrów uartu. Nie wiem gdzie tu miejsce dla
oscyloskopu, to ostateczność.

To kwestia bardziej jakości kodu i umiejętności pisania abstrakcyjnego,
ale blisko sprzetu.

Zaznaczam, że wbrew opini niedzielnych programistów C++, ta abstrakcja
przychodzi z zerowym obciązeniem dla kodu wynikowego, nie pojawi się
nawet instrukcja więcej.


Dokładnie do tego dążę.


Akurat to jest prawdziwe rozjaśnianie intencji ;)


I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
tylko tyle potrzeba w 99% wypadków pisania kodu embedded.

Co innego gdy to jest hobbystyczne pisanie na ATTINY. Tam można sobie
pomigać diodą w symulatorze, wiadomo. Ale czy to nie jest aby własnie
"hobbystyczne"?

Mon Nov 15, 2021 7:19 pm   

heby <heby@poczta.onet.pl> napisał(a):

Wiadomo, że można (i powinno się) pisać na podstawie dokumentacji i bez
uruchamiania kodu po każdej napisanej linijce. Chodzi o to, że praktycznie
zawsze coś potem nie działa i wcale niekoniecznie z Twojej winy.


Nie tylko Modbus jest na świecie. Poza tym mówimy o styku programowania z
elektroniką. Jeśli oscyloskop nie jest potrzebny, to jest to albo prosty
projekt albo embedded wysokopoziomowe (odległe od sprzętu).


Wiadomo :)

W każdym razie ta część wątku zaczęła się od emulatora CPU. Arduino i tak go
nie ma, więc nie ma co tu drążyć :)


Wracamy więc do początku wątku. Jeśli ktoś wybiera znakomite środowisko
zamiast Arduino IDE, to nie ze względów religijnych ale dlatego, że jest
ono... znakomite :)

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

Mon Nov 15, 2021 7:34 pm   

On 15/11/2021 19:19, Grzegorz Niemirowski wrote:

Nie, dalej nie rozumiesz. Ja nie mówie o pisaniu zgodnie z dokumentacją
i wymagania nieomylności.

Ja mówie o pisaniu kodu w sposób, który redukuje potrzebę debugowania w
sprzęcie do zera lub blisko zera. To wymaga innych technik
programowania, niż stosowane w embedded, w szczególności przeproszenia
sie z C++ (przez co czeka nas przeczekanie obecnego pokolenia
programistów embedded, jako że to problem białkowy).


Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR.
Miliony programistów Arduino raczej by go znalazły.


Ani jedno ani drugie. Możesz napisać skomplikowany projekt blisko
sprzetu, w 95% pokryty testami po stronie komputera dev. To nie jest
rocket science. To normalna praktyka pisania kodu na dowolną platoformę,
od superkomputerów do attiny.

Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu musisz
ich używać, to masz kiepsko napisany kod.

Zgodzę się, że czasami mogą być przydatne przy uruchamianiu kodu, ale
zazwyczaj to oznacza, że coś jest spieprzone i nieprzetestowane
wcześniej, lub błąd masz w konkretyzacji abstrakcji (gdzie zwyczajowo
kodu wiele nie ma).


Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest
mało potrzebny.


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

Mon Nov 15, 2021 7:57 pm   

heby <heby@poczta.onet.pl> napisał(a):

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.


To jest akademicka teoria. Powiedz twórcom GDB, że zmarnowali swój czas
Debuger jest normalnym narzędziem i sięganie po niego nie musi wcale źle
świadczyć o programiście. Jego brak jest ograniczeniem środowiska.


Piszesz o nich jak o bibliotekach libc. Tymczasem mają one nieraz błędy i
słabą dokumentację.


No właśnie Tym bardziej Arduino IDE :)

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

Mon Nov 15, 2021 8:22 pm   

On 15/11/2021 19:57, Grzegorz Niemirowski wrote:

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


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.


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.


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.


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.

Tue Nov 16, 2021 9:03 am   

On 15.11.2021 17:46, heby wrote:


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.

Tue Nov 16, 2021 11:26 am   

heby <heby@poczta.onet.pl> napisał(a):

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/

Tue Nov 16, 2021 11:51 am   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

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/

Tue Nov 16, 2021 6:18 pm   

On 16/11/2021 11:26, Grzegorz Niemirowski wrote:

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.

Tue Nov 16, 2021 6:22 pm   

On 2021-11-14 17:46, heby wrote:

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.

Tue Nov 16, 2021 6:30 pm   

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

Tue Nov 16, 2021 7:30 pm   

On 16.11.2021 18:30, Pcimol wrote:


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.

Wed Nov 17, 2021 10:53 am   

Pcimol <a@b.com> napisał(a):

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

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

Wed Nov 17, 2021 11:45 am   

On Mon, 15 Nov 2021 20:22:11 +0100, heby <heby@poczta.onet.pl> wrote:

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