Janusz <j...@o...pl> napisał(a):
> Tak, ale styl avr studio został i o to mi chodziło.

Przyczym ten styl jest od AVR Studio 5, pierwszej wersji bazującej na Visual
Studio Shell. Przedtem było AVR Studio 4, które było tak naprawdę innym
oprogramowaniem, wymagającym doinstalowania kompilatora.

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

do góry

On 14/11/2021 22:53, Grzegorz Niemirowski wrote:
>> To jakiś pogląd religijny?
> Są wystarcząjące obiektywne argumenty przeciw.

A które?

do góry

On 15/11/2021 08:36, Bool wrote:
>> To jakiś pogląd religijny?
> Jestem kompletnie areligijny.
> Narzędzia dla hobbystów zostawiam hobbystom.

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

Jeśli, z powodów religijnych, uważasz to za narzedzie dla hobbystów,
zerknij na platformio. Jest "profesjonalny", cokolwiek to znaczyć by miało.

do góry

heby <h...@p...onet.pl> napisał(a):
> A które?

1. Prymitywne IDE, niewiele bardziej zaawansowane od Notatnika, bez
możliwości debugowania
2. Biblioteki pisane na kolanie
3. Dziwna konstrukcja z setup/loop
4. Ukrycie użycia timera i wielu innych rzeczy, bo ma być przede wszystkim
prosto
Arduino nie powstało i nie jest rozwijane z myślą o profesjonalistach.
Wywodzi się z projektu Wiring, który miał artystom pozwolić tworzyć
automatyczne lub interaktywne instalacje. Nieprzypadkowo w Arduino nie ma
projektów tylko szkice. Dlatego jest spoko do szybkiego prototypowania a nie
poważniejszych zastosowań.

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

do góry

On 15/11/2021 18:30, Grzegorz Niemirowski wrote:
>> A które?
> 1. Prymitywne IDE, niewiele bardziej zaawansowane od Notatnika, bez
> możliwości debugowania

1) Możesz zostawić środowiko arduino i używać
Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.

2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu. Często
ta emulacja sprzetu jest milion razy trudniejsza. Dlatego wymysliliśmy
techniki pisania kodu, które praktycznie redukują potrzebę debugowania
na *prawdziwym* targecie, asymptotycznie do zera. Zaryzykuje że
poprawnie napisany program w języku C/C++ będzie wymagał debugowania w
emulatorze CPU w mniej niż promilu przypadków. Za to będzie znakomicie
debugował się na hoście.

> 2. Biblioteki pisane na kolanie

Nikt nie każe z nich korzystać. Przypomnę tylko, że firma Atmel dla SAM7
miała na kolanie napisane *wszystko* do stanu który powodował wymioty na
sam widok tej niewiarygodnej fuszerki. Jak bym nie wiązał tego
dziadostwa z Arduino, tylko z embedded. Tam wszystko jest dziadowskie do
granic absurdu i nikomu to nie przeszkadza.

> 3. Dziwna konstrukcja z setup/loop

W 99% programów pojawi się taki setup/loop.

> 4. Ukrycie użycia timera i wielu innych rzeczy, bo ma być przede
> wszystkim prosto

Albo abstrakcyjnie. Sugeruje nie mylić pojęć.

> Arduino nie powstało i nie jest rozwijane z myślą o profesjonalistach.
> Wywodzi się z projektu Wiring, który miał artystom pozwolić tworzyć
> automatyczne lub interaktywne instalacje. Nieprzypadkowo w Arduino nie
> ma projektów tylko szkice. Dlatego jest spoko do szybkiego
> prototypowania a nie poważniejszych zastosowań.

Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych IDE"
skoro kod nie jest większy niż max kilka stron na ekranie i może być
pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć tak
nisko bym nie upadał.

do góry

heby <h...@p...onet.pl> napisał(a):
> 1) Możesz zostawić środowiko arduino i używać
> Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.

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

> 2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu. Często ta
> emulacja sprzetu jest milion razy trudniejsza. Dlatego wymysliliśmy
> techniki pisania kodu, które praktycznie redukują potrzebę debugowania na
> *prawdziwym* targecie, asymptotycznie do zera. Zaryzykuje że poprawnie
> napisany program w języku C/C++ będzie wymagał debugowania w emulatorze
> CPU w mniej niż promilu przypadków. Za to będzie znakomicie debugował się
> na hoście.

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.

>> 2. Biblioteki pisane na kolanie
> Nikt nie każe z nich korzystać.

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

> W 99% programów pojawi się taki setup/loop.

Pojawia się, ale jest to sztuczne zaciemnianie.

> Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
> padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych IDE"
> skoro kod nie jest większy niż max kilka stron na ekranie i może być
> pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć tak nisko
> bym nie upadał.

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

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

do góry

On 15/11/2021 18:57, Grzegorz Niemirowski wrote:
>> 1) Możesz zostawić środowiko arduino i używać
>> Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.
> Idąc za ciosem można zrezygnować z Arduino zupełnie.

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

>> 2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu.
>> Często ta emulacja sprzetu jest milion razy trudniejsza. Dlatego
>> wymysliliśmy techniki pisania kodu, które praktycznie redukują
>> potrzebę debugowania na *prawdziwym* targecie, asymptotycznie do zera.
>> Zaryzykuje że poprawnie napisany program w języku C/C++ będzie wymagał
>> debugowania w emulatorze CPU w mniej niż promilu przypadków. Za to
>> będzie znakomicie debugował się na hoście.
> 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.

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.

>>> 2. Biblioteki pisane na kolanie
>> Nikt nie każe z nich korzystać.
> Więc kłania się punkt 1 - można zrezygnować z Arduino całkowicie, skoro
> nie oferuje żadnej dużej wartości.

Dokładnie do tego dążę.

>> W 99% programów pojawi się taki setup/loop.
> Pojawia się, ale jest to sztuczne zaciemnianie.

Akurat to jest prawdziwe rozjaśnianie intencji ;)

>> Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to
>> padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych
>> IDE" skoro kod nie jest większy niż max kilka stron na ekranie i może
>> być pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć
>> tak nisko bym nie upadał.
> Nawet krótki kod wolę pisać w wygodnym IDE.

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

do góry

heby <h...@p...onet.pl> napisał(a):
> 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 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 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).

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

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

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

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

do góry

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

do góry

heby <h...@p...onet.pl> napisał(a):
> 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.

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

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

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

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

do góry