On 15/11/2021 19:19, Grzegorz Niemirowski wrote:
>> 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.
> Wiadomo, że można (i powinno się) pisać na podstawie dokumentacji

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

> uruchamiania kodu po każdej napisanej linijce. Chodzi o to, że
> praktycznie zawsze coś potem nie działa i wcale niekoniecznie z Twojej
> winy.

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

>> Nie wiem gdzie tu miejsce dla oscyloskopu, to ostateczność.
> 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).

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

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

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

>> I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo
>> tylko tyle potrzeba w 99% wypadków pisania kodu embedded.
> 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 :)

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