Discussion:
AVR po latach
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
Bool
2021-11-13 08:40:43 UTC
Permalink
Po kilkunastu latach przerwy i rzeźbieniu głównie na ARM, muszę się przeprosić z AVR. Potrzebuję
małego, jak najtańszego uC z kilkoma GPIO i jednym ADC. Mój wybór padł na attiny806.

Jako że wypadłem z obiegu, chciałem zapytać jak obecnie wygląda sprawa z narzędziami? Jakie IDE
obecnie warto wybrać? Ja pamiętam czasy AVR Studio, później chyba był ATMEL Studio, a teraz chyba
Microchip Studio.
Jak wygląda programowanie i debugowanie tych małych AVR? Mają jakiś bootloder na UART?

Dodam tylko że Arduino mnie kompletnie nie interesuje.
Janusz
2021-11-13 09:03:16 UTC
Permalink
Post by Bool
Po kilkunastu latach przerwy i rzeźbieniu głównie na ARM, muszę się
przeprosić z AVR. Potrzebuję małego, jak najtańszego uC z kilkoma GPIO i
jednym ADC. Mój wybór padł na attiny806.
Jako że wypadłem z obiegu, chciałem zapytać jak obecnie wygląda sprawa z
narzędziami? Jakie IDE obecnie warto wybrać? Ja pamiętam czasy AVR
Studio, później chyba był ATMEL Studio, a teraz chyba Microchip Studio.
Dalej jest Avr Studio, teraz 7, Mikrochip ma swoje ide.
Post by Bool
Jak wygląda programowanie i debugowanie tych małych AVR? Mają jakiś bootloder na UART?
Tu masz stronę
https://www.microchip.com/en-us/product/ATTINY806

Stare miały spi ten attiny który wybrałeś jest z tych nowszych i ma
udpi, czyli taki szeregowy interfejs, gdzieś na elektrodzie jest opisana
przejściówka usb-rs która programuje albo kupujesz snap-a
https://kamami.pl/programatory-avr/578657-mplab-snap-programator-debugger-dla-mikrokontrolerow-microchip-pg164100.html
Post by Bool
Dodam tylko że Arduino mnie kompletnie nie interesuje.
--
Janusz
Bool
2021-11-15 07:47:41 UTC
Permalink
Post by Janusz
Dalej jest Avr Studio, teraz 7, Mikrochip ma swoje ide.
Microchip zmienił ostatnio nazwę Atmel Studio (AVR Studio) na Microchip Studio.
Oprócz tego jest jeszcze Microchip MPLAB. Bezpłatny kompilator bez optymalizacji.
Post by Janusz
Stare miały spi ten  attiny który wybrałeś jest z tych nowszych i ma udpi, czyli taki szeregowy
interfejs, gdzieś na elektrodzie jest opisana przejściówka usb-rs która programuje albo kupujesz snap-a
https://kamami.pl/programatory-avr/578657-mplab-snap-programator-debugger-dla-mikrokontrolerow-microchip-pg164100.html
Zgłębiłem temat i te attiny series 0, series 1 wyglądają bardzo obiecująco.
Janusz
2021-11-15 14:49:27 UTC
Permalink
Post by Bool
Post by Janusz
Dalej jest Avr Studio, teraz 7, Mikrochip ma swoje ide.
Microchip zmienił ostatnio nazwę Atmel Studio (AVR Studio) na Microchip Studio.
Tak, ale styl avr studio został i o to mi chodziło.
Post by Bool
Oprócz tego jest jeszcze Microchip MPLAB. Bezpłatny kompilator bez optymalizacji.
Ona jest tylko trzeba za nią ekstra zapłacić :(
Post by Bool
Post by Janusz
Stare miały spi ten  attiny który wybrałeś jest z tych nowszych i ma
udpi, czyli taki szeregowy interfejs, gdzieś na elektrodzie jest
opisana przejściówka usb-rs która programuje albo kupujesz snap-a
https://kamami.pl/programatory-avr/578657-mplab-snap-programator-debugger-dla-mikrokontrolerow-microchip-pg164100.html
Zgłębiłem temat i te attiny series 0, series 1 wyglądają bardzo obiecująco.
Nowe atmegi są jeszcze ciekawsze :) można sobie kupić atmega4809
curiosity nano
https://www.microchip.com/en-us/development-tool/DM320115
gdzie oprócz procka mamy też programator/debuger po usb.
--
Janusz
Grzegorz Niemirowski
2021-11-15 15:26:43 UTC
Permalink
Post by Janusz
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/
Irek.N.
2021-11-13 14:18:32 UTC
Permalink
A masz te chipy już na półce?
Bo to już nie te czasy, że można sobie "wybierać".
Właśnie chciałem "dopchnąć" zamówienie w Farnellu żeby mieć darmową
wysyłkę i pomyślałem o prockach, ale takich starego sortu, bo takie
nadal używane są w pewnym stale rotującym projekcie. Szukam sobie
czegokolwiek z gatunku 89S8253 i niezłe pustki widzę. Żeby tak stare
procki zeszły? Wydawało mi się, że o rodzinie '51 świat już zapomniał i
nie będzie problemu, a tu proszę, niespodzianka. W TME też widzę, że
nośności nowo postawionych regałów nie testują. Za pół roku skończą mi
się zapasy, jak nie uda się dokupić :(

Miłego.
Irek.N.
heby
2021-11-14 16:46:25 UTC
Permalink
Post by Bool
Dodam tylko że Arduino mnie kompletnie nie interesuje.
To jakiś pogląd religijny?
Grzegorz Niemirowski
2021-11-14 21:53:50 UTC
Permalink
Post by heby
To jakiś pogląd religijny?
Są wystarcząjące obiektywne argumenty przeciw.
--
Grzegorz Niemirowski
https://www.grzegorz.net/
heby
2021-11-15 16:44:09 UTC
Permalink
Post by Grzegorz Niemirowski
Post by heby
To jakiś pogląd religijny?
Są wystarcząjące obiektywne argumenty przeciw.
A które?
Grzegorz Niemirowski
2021-11-15 17:30:08 UTC
Permalink
Post by heby
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/
heby
2021-11-15 17:40:00 UTC
Permalink
Post by Grzegorz Niemirowski
Post by heby
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.
Post by Grzegorz Niemirowski
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.
Post by Grzegorz Niemirowski
3. Dziwna konstrukcja z setup/loop
W 99% programów pojawi się taki setup/loop.
Post by Grzegorz Niemirowski
4. Ukrycie użycia timera i wielu innych rzeczy, bo ma być przede
wszystkim prosto
Albo abstrakcyjnie. Sugeruje nie mylić pojęć.
Post by Grzegorz Niemirowski
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ł.
Grzegorz Niemirowski
2021-11-15 17:57:43 UTC
Permalink
Post by heby
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.
Post by heby
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.
Post by heby
Post by Grzegorz Niemirowski
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.
Post by heby
W 99% programów pojawi się taki setup/loop.
Pojawia się, ale jest to sztuczne zaciemnianie.
Post by heby
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/
heby
2021-11-15 18:07:59 UTC
Permalink
Post by Grzegorz Niemirowski
Post by heby
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.
Post by Grzegorz Niemirowski
Post by heby
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.
Post by Grzegorz Niemirowski
Post by heby
Post by Grzegorz Niemirowski
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ążę.
Post by Grzegorz Niemirowski
Post by heby
W 99% programów pojawi się taki setup/loop.
Pojawia się, ale jest to sztuczne zaciemnianie.
Akurat to jest prawdziwe rozjaśnianie intencji ;)
Post by Grzegorz Niemirowski
Post by heby
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"?
Grzegorz Niemirowski
2021-11-15 18:19:42 UTC
Permalink
Post by heby
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.
Post by heby
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).
Post by heby
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ć :)
Post by heby
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/
heby
2021-11-15 18:34:19 UTC
Permalink
Post by Grzegorz Niemirowski
Post by heby
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).
Post by Grzegorz Niemirowski
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.
Post by Grzegorz Niemirowski
Post by heby
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).
Post by Grzegorz Niemirowski
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.
Post by Grzegorz Niemirowski
Post by heby
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".
Grzegorz Niemirowski
2021-11-15 18:57:55 UTC
Permalink
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/
heby
2021-11-15 19:22:11 UTC
Permalink
Post by Grzegorz Niemirowski
Post by heby
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.
Post by Grzegorz Niemirowski
Post by heby
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.
Post by Grzegorz Niemirowski
:) 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.
Post by Grzegorz Niemirowski
Post by heby
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.
Post by Grzegorz Niemirowski
Post by heby
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.
Grzegorz Niemirowski
2021-11-16 10:26:18 UTC
Permalink
Post by heby
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/
heby
2021-11-16 17:18:58 UTC
Permalink
Post by Grzegorz Niemirowski
Post by heby
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.
Marek
2021-11-17 10:45:15 UTC
Permalink
Post by heby
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
heby
2021-11-17 17:18:00 UTC
Permalink
Post by Marek
Post by heby
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.
Proble nie polega na pasywnym ignorowaniu tylko aktywnym atakowaniu z
powodu ignorancji. Było tez i na tej grupie.
Marek
2021-11-17 17:49:06 UTC
Permalink
Post by heby
Proble nie polega na pasywnym ignorowaniu tylko aktywnym atakowaniu z
powodu ignorancji. Było tez i na tej grupie.
Możesz podkręcić jasność wypowiedzi?
--
Marek
heby
2021-11-17 17:52:39 UTC
Permalink
Post by Marek
Post by heby
Proble nie polega na pasywnym ignorowaniu tylko aktywnym atakowaniu z
powodu ignorancji. Było tez i na tej grupie.
Możesz podkręcić jasność wypowiedzi?
Na tej grupie padały już takie argumenty przeciwko C++, w embedded:

- jest wolniejszy od C
- produkuje więcej kodu
- musisz używać klas bo inaczej to nie C++
- templates powodują eksplozje binariów i nikt nie wie jak działają a
ponadto się nie kompilują
- nikt tak nie robi
- nikt tak nie będzie robił
- to zabawka, prawdziwi programiści ...
- itp.

Oczywiście, wszystkie to debilizmy, wynikające z ignorancji i konserwatyzmu.
Marek
2021-11-17 18:11:45 UTC
Permalink
Post by heby
Oczywiście, wszystkie to debilizmy, wynikające z ignorancji i konserwatyzmu.
Ok, tylko moje doświadczenia, na których oparłem swoją wypowiedź to
tak z poza embedded. Na razie z ostrożności procesowej nie krytykuję
C++ w embedded. Zobaczymy jak to dalej pójdzie.
--
Marek
Bool
2021-11-15 07:36:16 UTC
Permalink
Post by heby
Post by Bool
Dodam tylko że Arduino mnie kompletnie nie interesuje.
To jakiś pogląd religijny?
Jestem kompletnie areligijny.
Narzędzia dla hobbystów zostawiam hobbystom.
heby
2021-11-15 16:46:04 UTC
Permalink
Post by Bool
Post by heby
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.
Atlantis
2021-11-16 08:03:59 UTC
Permalink
Post by heby
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.
Grzegorz Niemirowski
2021-11-16 10:51:53 UTC
Permalink
Post by Atlantis
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.

--
Grzegorz Niemirowski
https://www.grzegorz.net/
Marek
2021-11-17 11:05:17 UTC
Permalink
On Tue, 16 Nov 2021 11:51:53 +0100, "Grzegorz Niemirowski"
Post by Grzegorz Niemirowski
Podpisuję się pod wszystkim :)
Przy okazji polecam obejrzeć bardzo ciekawą prezentację pokazującą, że C++
może dać mniejszy kod niż C.
http://youtu.be/PDSvjwJ2M80
To czemu 99% softu napisanego w C++ dziala wolno? Nie umieją pisać
poprawnie?
--
Marek
Grzegorz Niemirowski
2021-11-17 13:51:37 UTC
Permalink
Post by Marek
To czemu 99% softu napisanego w C++ dziala wolno? Nie umieją pisać
poprawnie?
Statystyka zaczerpnięta z...?
--
Grzegorz Niemirowski
https://www.grzegorz.net/
Marek
2021-11-17 15:17:28 UTC
Permalink
On Wed, 17 Nov 2021 14:51:37 +0100, "Grzegorz Niemirowski"
Post by Grzegorz Niemirowski
Statystyka zaczerpnięta z...?
Oczywiście, że z własnego doświadczenia, bo kogo innego?? KDE/plasma
koszmar, przez 20 lat ciągle wycieki pamięci, puchunący ksysguard do
jakiś chorych rozmiarów. Parę dni temu znowu doświadczyłem oom
killer na maszynie z 14GB RAM, na której jest tylko sesja kde + FF
+Chrome. 14GB mało do przeglądania stron, serio?? Maszyna
nieużywalna przez to przez pół godziny.
Sam exec aplikacji zlinkowanej z stdc++ zawsze widać widać
wolniejszy. Ja dopuszczam info, że c++ może być lepsze i szybsze ale
c z tego jak w większości przypadków nie umieją tego zrobić dobrze.
Zresztą na tym filmie był przykład nadmiarowego linkowania z stdc++.
--
Marek
Marek
2021-11-17 18:08:44 UTC
Permalink
Progrmujesz zawodowo w C++?
Nie. Zawachałem się czy napisać "Niestety".
Masz KDE Plasma napisany w C do porównania?
Słusznie. Ale przez ostatnich 25 lat doświadczenia ręcznej
kompilacji tysięcy projektów w różnych językach i ich późniejszego
testowania zawsze jakoś tak wychodziło, że jak coś było w C++ to
zawsze startowało dłużej i zżerało zasoby. Oczywiście można to uciąć
argumentem porównawczym jakim teraz próbujesz. Można. W takim razie
chciałbym w końcu przed śmiercią zobaczyć jakieś pełen user space
(desktop+browser+cokolwiek) działający szybko, resposnywnie i bez
zżerania zasobów, tak żebym przed tym klęknął z podziwem.
--
Marek
heby
2021-11-17 18:20:45 UTC
Permalink
Post by Marek
Progrmujesz zawodowo w C++?
Nie. Zawachałem się czy napisać "Niestety".
Wiec będziesz miał duży kłopot utrzymać tezę: "to wina C++".
Post by Marek
Masz KDE Plasma napisany w C do porównania?
Słusznie. Ale przez ostatnich 25 lat doświadczenia  ręcznej kompilacji
tysięcy projektów w różnych językach i ich późniejszego testowania
zawsze jakoś tak wychodziło, że jak coś było w C++ to zawsze startowało
dłużej i zżerało zasoby.
Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
wykona się wolniej i dlaczego?
Post by Marek
Oczywiście można to uciąć argumentem
porównawczym jakim teraz próbujesz.
To nie *ja* porównuje C++ to reszty świata. Ja mogę co najwyżej
wyjasnić, że C++ jest tak samo szybki jak C. Czy uważasz, że C jest
wolny? I względem czego jest wolny?

Prawie 100% problemów z prędkoscią jezyka programowania wynika z
gównianej jakosci programisty.

Nie dotyczy JavaScriptu. Tam wszystko jest do dupy, język i programiści
na raz.
Post by Marek
Można. W takim razie chciałbym w
końcu przed śmiercią zobaczyć jakieś pełen user space
(desktop+browser+cokolwiek) działający szybko, resposnywnie i bez
zżerania zasobów, tak żebym przed tym klęknął z podziwem.
Nikt go nie potrzebuje. OSy będą tak szybkie, jak tylko możliwe, ale nie
szybsze niż granica "wkurwienia na obecnej wydajności hardware". Każde
przyśpieszenie sprzętowe jest natychmiast konsumowane przez dodatkowe
ficzery, potrzebne debilom, jak kolorowe animowane przyciski.

Czasy szybkich, pisanych optymalnie GUI, zniknęły razem z Amigą.

Tak, Amiga miała *obiektowe* GUI.
Marek
2021-11-17 18:31:39 UTC
Permalink
Post by heby
To nie *ja* porównuje C++ to reszty świata. Ja mogę co najwyżej
wyjasnić, że C++ jest tak samo szybki jak C. Czy uważasz, że C jest
Wydaje mi sie, że nie zrozumiałeś o czym mówię. Ja nie krytykuję C++.
Ja tylko krytykuję to, co w nim jest napisane i dlaczego źle.
--
Marek
heby
2021-11-17 19:27:06 UTC
Permalink
?? Ja krytykuję jakość softu. Tak się składa, że najczęściej używane
nacodzień jest w C++.
Piszcie porządnie, wtedy krytyki nie będzie.
Piszemy porządnie. Ale nie wszyscy.
To można powiedzieć o dowolnym innym języku.
Ale jakoś C++ obrywa  najwięcej za wszystkie.
Nie zauważyłem. Być może tylko Ty jesteś tym tłumem krytykującym C++ za
wydajność.
heby
2021-11-17 19:32:08 UTC
Permalink
Post by heby
Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
wykona się wolniej i dlaczego?
Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++.
Jeden z nich na pewno jest.

Na tym polega proble m ludzi związanych z embedded. Wydaje im się, w
swojej ignorancji, że kod C++ to biliardy klas, i eniony templejtów.

Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język
*bardzo* przydatnym w embedded, bez narzutu wydajności.
Przykład zły,
bo oba kody skracają się do tej samej abstrakcji wspólnej dla obu
języków.
To dalej oznacza, że jeden z nich na pewno jest w C++.
Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i żeby
proces zajął min 2GB ram. ;)
To jest właśnie opinia niedzielnego programisty embedded o C++. Z nią
walczę.

Ale ale ... zmartwię Cię. Niektóre porządnie napisane przykłady z
*klasami* kompilują się do wydajnijszego kodu, niż goła pętla w C... to
dlatego że C++ zawiera więcej konstrukcji pozwalajacej wyrazić cel, a
nie tylko metodę jego osiągnięcia, wiążac kompilatorowi ręce.
Dawid Rutkowski
2021-11-18 14:52:45 UTC
Permalink
Post by heby
Post by heby
Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
wykona się wolniej i dlaczego?
Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++.
Jeden z nich na pewno jest.
Na tym polega proble m ludzi związanych z embedded. Wydaje im się, w
swojej ignorancji, że kod C++ to biliardy klas, i eniony templejtów.
Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język
*bardzo* przydatnym w embedded, bez narzutu wydajności.
Napisz choć kilka przykładów.
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.
Post by heby
Przykład zły,
bo oba kody skracają się do tej samej abstrakcji wspólnej dla obu
języków.
To dalej oznacza, że jeden z nich na pewno jest w C++.
Który? I dlaczego?
Post by heby
Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i żeby
proces zajął min 2GB ram. ;)
To jest właśnie opinia niedzielnego programisty embedded o C++. Z nią
walczę.
Ale ale ... zmartwię Cię. Niektóre porządnie napisane przykłady z
*klasami* kompilują się do wydajnijszego kodu, niż goła pętla w C... to
dlatego że C++ zawiera więcej konstrukcji pozwalajacej wyrazić cel, a
nie tylko metodę jego osiągnięcia, wiążac kompilatorowi ręce.
No to którym kompilatorem "lepiej" się skompiluje program napisany w C - kompilatorem C czy C++?
J.F
2021-11-18 15:09:04 UTC
Permalink
Post by Dawid Rutkowski
Post by heby
Post by heby
Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
wykona się wolniej i dlaczego?
Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++.
Jeden z nich na pewno jest.
Na tym polega proble m ludzi związanych z embedded. Wydaje im się, w
swojej ignorancji, że kod C++ to biliardy klas, i eniony templejtów.
Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język
*bardzo* przydatnym w embedded, bez narzutu wydajności.
Napisz choć kilka przykładów.
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.
Piotr kiedys wymienial.

Chocby izolacja nazw procedur w klasie - i nie musisz wymyslac
unikalnych nazw, czy martwic sie, ze gdzies w bibliotece juz jest jest
tak nazwana funkcja.

W malych uC wydawało mi się to niewielką zaletą - nad małym programem
można zapanowac. Ale jak sie uC rozbudowały.
Post by Dawid Rutkowski
Post by heby
Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i żeby
proces zajął min 2GB ram. ;)
To jest właśnie opinia niedzielnego programisty embedded o C++. Z nią
walczę.
Ale ale ... zmartwię Cię. Niektóre porządnie napisane przykłady z
*klasami* kompilują się do wydajnijszego kodu, niż goła pętla w C... to
dlatego że C++ zawiera więcej konstrukcji pozwalajacej wyrazić cel, a
nie tylko metodę jego osiągnięcia, wiążac kompilatorowi ręce.
No to którym kompilatorem "lepiej" się skompiluje program napisany w C - kompilatorem C czy C++?
Jeszcze kwestia, jak mocny musi byc procesor, żeby sie te konstrukcje
naprawde wydajnie kompilowaly.

C++ na 8051? :-)

No, ciekawe, czy by sie udalo ubrac te 3 rodzaje pamieci w klasy ...
nie, chyba nie :-)

J.
heby
2021-11-18 16:22:51 UTC
Permalink
Post by Dawid Rutkowski
Post by heby
Tymczasem to bardzo dużo małych, drobnych detali które czynią ten język
*bardzo* przydatnym w embedded, bez narzutu wydajności.
Napisz choć kilka przykładów.
Robiłem to dziesitki razy, na tej grupie, trzeba było uważać.

Np taki:

foo()
{
DisableInterruptsInThisScope guard;

[...]
return;
[...]
return;
[...]
return;
}
Post by Dawid Rutkowski
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.
No to masz RIIA.
Post by Dawid Rutkowski
Post by heby
Przykład zły,
bo oba kody skracają się do tej samej abstrakcji wspólnej dla obu
języków.
To dalej oznacza, że jeden z nich na pewno jest w C++.
Który? I dlaczego?
Drugi. Kompiluje się g++. Pierwszy też, ale drugi jest *niewątpliwie*.
Post by Dawid Rutkowski
Post by heby
Ale ale ... zmartwię Cię. Niektóre porządnie napisane przykłady z
*klasami* kompilują się do wydajnijszego kodu, niż goła pętla w C... to
dlatego że C++ zawiera więcej konstrukcji pozwalajacej wyrazić cel, a
nie tylko metodę jego osiągnięcia, wiążac kompilatorowi ręce.
No to którym kompilatorem "lepiej" się skompiluje program napisany w C - kompilatorem C czy C++?
Oba skompilują tak samo.

Dlatego postulatem nie jest uzywanie g++ tylko pisanie w C++.
heby
2021-11-18 16:27:27 UTC
Permalink
Post by heby
No to masz RIIA.
Tfu, RAII.
Mateusz Viste
2021-11-18 16:32:41 UTC
Permalink
Post by heby
foo()
{
DisableInterruptsInThisScope guard;
[...]
return;
[...]
return;
[...]
return;
}
Spodziewałem się jakiejś faktycznej wartości dodanej, a tu zawód. :)

To co podałeś to przecież nic innego jak to:

foo() {
_disable();
[...]
goto gameover;
[...]
goto gameover;
[...]
goto gameover;

gameover:
_enable();
}


Mateusz
Mateusz Viste
2021-11-18 17:01:02 UTC
Permalink
Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.
Cel szczytny, ale taki jakby mało realistyczny. A raczej: realistyczny,
ale kiedy zostanie osiągnięty, to już dawno nie będziemy potrzebni.
W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań.
Jedna kategoria bugów została właśnie usunięta: "zapomniałem załączyć
przerwania".
W konkursie wystartowała natomiast kategoria nowa: "zapomniałem ustawić
scope guard na włączenie przerwań".

No i teraz można się spierać o styl, jakieś prawdopodobieństwa,
zwyczaje itd, ale liczyłem że podasz po prostu inny przykład, który
wykazałby wyższość tych plus-plusów w sposób bezdyskusyjny.

Mateusz
heby
2021-11-18 17:12:14 UTC
Permalink
Post by Mateusz Viste
Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.
Cel szczytny, ale taki jakby mało realistyczny. A raczej: realistyczny,
ale kiedy zostanie osiągnięty, to już dawno nie będziemy potrzebni.
Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się błedu
w kodzie. Kazde takie miejsce przyczynia się do mniejszej ilości bugów.

Programowanie w językach wyższego poziomu własnie na tym polega: na
zmniejszeniu ilosci potencjalnych miejsc z pomyłką.
Post by Mateusz Viste
W moim nie da się wyjśc ze scope funkcji bez właczenia przerwań.
Jedna kategoria bugów została właśnie usunięta: "zapomniałem załączyć
przerwania".
W konkursie wystartowała natomiast kategoria nowa: "zapomniałem ustawić
scope guard na włączenie przerwań".
Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.
Post by Mateusz Viste
No i teraz można się spierać o styl
Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa kodu.
Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
grupach 60+ to może być coding standard.

, jakieś prawdopodobieństwa,
Post by Mateusz Viste
zwyczaje itd, ale liczyłem że podasz po prostu inny przykład, który
wykazałby wyższość tych plus-plusów w sposób bezdyskusyjny.
Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach miganai
diodą nie ma problemu i stąd ten problem z rozumieniem tej wyższości.

To jeszcze jeden:

UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;

Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7 to
jest poważny problem.

Mogę ten kod napisać sprytnie. Tak sprytnie, że użycie złej flagi będzie
niemożliwe na złym porcie. I w dodatku bez zmiany składni, którą widzisz
na górze, wyłącznie używając C++, wrapując enumeratory, przeciążając
operatory i na zawsze zapominając o błędnych flagach. I bez śladu
obciążenia w kodzie wynikowym, asm będzie zawierał tą samą instrukcję.

Tak, to też da się zastąpić uwaznym gapieniem się w kod, wiec doskonale
zdaje sobie sprawę, że nie będziesz pojmować po co to komu. Bo przeciez
wszystko da się napisać w asm, jak się jest uważnym hackerem.
Mateusz Viste
2021-11-18 17:28:57 UTC
Permalink
Post by heby
Dostałeś wlaśnie metodę eliminacji białka z procesu tworzenia się
błedu w kodzie.
Nie, nie dostałem. :)
Ty tego białka nie wyeliminowałeś, tylko je przesunąłeś w inne miejsce.
Post by heby
Post by Mateusz Viste
W konkursie wystartowała natomiast kategoria nowa: "zapomniałem
ustawić scope guard na włączenie przerwań".
Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.
Ech, czyli jednak dyskutowanie o prawdopodobieństwach. Szkoda.
Post by heby
Nie pojmujesz że to nie jest styl. To zwiększanie bezpieczeństwa
kodu. Są miejsca, gdzie takie gówno oparte o goto wyleciało by z
hukiem na review razem z autorem tego szamba.
Bo ty tak mówisz?
Post by heby
Ten przewyższa, tylko nie pojmujesz, najwidoczniej w projektach
miganai diodą nie ma problemu i stąd ten problem z rozumieniem tej
wyższości.
Czy to miganie diodą, czy sterowanie promem kosmicznym, w obu
przypadkach scope nie powinien być tak rozległy, że autor przestaje nad
nim panować.
Post by heby
UART0CTL = 1<<UART0_DOUBLE | 1<<UART0_REVERSE | 1<<UART1_FAST;
Ten kod ma buga. Nie do znalezienia oczami natychmiast. Użyto złej
flagi, od innego uarta. W czasach ludzi robiących #define UART0_FOO 7
to jest poważny problem.
Mogę ten kod napisać sprytnie.
O, czyli może jednak będzie konstruktywnie. No to dajesz.

Mateusz
Mateusz Viste
2021-11-18 18:19:41 UTC
Permalink
Zmniejszyłem je. Z wielu miejsc usunąłem.
Za pomocą tego magicznego guard? Wmówiłeś to sobie, uprawiasz tylko
kreatywną księgowość.
Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
zautomatyzować".
Ale ja przecież nie proponuję gapienia się. Objaśniam tylko, że to co
starasz się wypromować jako "argument za C++ w embedded" wcale nie
potrzebuje C++.
Post by Mateusz Viste
No to dajesz.
A ile płacisz?
Czyli ta łatwość usuwania białka C++ w ramach flag wymaga założenia
projektu i zainwestowania roboczogodzin? No to ja dziękuję za taki
postęp. Jak ma być skomplikowanie to równie dobrze w C mogę sobie
złożyć system do sprytnego zarządzania flagami.

Mateusz
heby
2021-11-18 18:40:28 UTC
Permalink
Post by Mateusz Viste
Zmniejszyłem je. Z wielu miejsc usunąłem.
Za pomocą tego magicznego guard?
Tak. Wyeliminował wszystkie źrodła błedu "zapomniałem włączyć" teraz i w
przyszłosci, z tej funkcji.

Oczywiście można go usunąć przypadkiem. Można wiele rzeczy zrobić, to
tylko białko. Idę o zakłąd że ilosc takich przypadków będzie o rząd
wielkosci mniejsza, niż przypadków "zapomniałem gdzieś zawołać goto w 30
miejscach".
Post by Mateusz Viste
Wmówiłeś to sobie, uprawiasz tylko
kreatywną księgowość.
Dziwnym trafem ta "kreatywna księgowość" jest powszechnie używanym
wzorcem projektowym w całym C++, dając zaskakująco wysoki poziom
bezpieczeństwa transakcji.

Podpowiem kilka generyków: std::mutex::scoped_lock, boost::scoped_ptr,
boost::scoped_array itd.

Każdy da się napisać na goto. I wylecieć kopniakiem za drzwi, bo to nie
lata 60te.
Post by Mateusz Viste
Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej
wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się
zautomatyzować".
Ale ja przecież nie proponuję gapienia się.
Dokładnie to oferujesz. Mówisz: "ale uważaj, przed każdym wyjściem z
funkcji musisz zawołać goto". Ja tego nie mówie. Samo prawidłowo zawoła
się to, co ma się zawołać, nie muszę żyć w ciągłym strachu, mam 1
miejsce a nie 30, do popełnienia błedu.
Post by Mateusz Viste
Objaśniam tylko, że to co
starasz się wypromować jako "argument za C++ w embedded" wcale nie
potrzebuje C++.
Zrobiłeś jakiś mechanizm działajacy w podobny sposob na poziomie *tego*
konkretnie przypadku. Po refaktoringu środka funkcji, ja nie muszę się
martwić i mam gwarantowane wywołanie sei(), Ty musisz się męczyć i
przeglądać kod, czy ktoś nie zapomniał zawołać goto. Innymi słowy mój
zysk to bezpieczeństwo refaktoringu tej funkcji, bezpieczeństwo jej
pisania i przejrzystośc kodu.

Wiec albo chcesz mieć szambo, jak proponujesz, albo automatyzację. I
tak, nie da się tego zrobic w C. Można tylko napisać identyczny przykład
i wymachiwać "nie ma żadnej różnicy". Ona jest, nie widzisz jej, bo nie
piszesz nic więcej niż miganie diodą i nigdy nie przyszło Ci do głowy że
ktoś będzie tą funkcję zmieniał, w czasie jej życia, 100 razy.
Post by Mateusz Viste
A ile płacisz?
Czyli ta łatwość usuwania białka C++ w ramach flag wymaga założenia
projektu i zainwestowania roboczogodzin?
Tak. Ja inwestuje raz. Kod taki (o podobnej funkcjonalnosci) napisałem
już kilka razy, komercyjnie. Za każdym razem używałem go w setkach, jak
nie tysiącach miejsc. Więc ja zapłaciłem raz, a dobrze.

Niejaki Mateusz, za każdym razem jak robi UART= płaci na nowo koszta
potencjalnych bugów, w kółko używając technik z epoki kamiennej do
podwyższania jakości kodu, czyli cichej modlitwy, że się nie pomylił.

Przykro mi, że kod nie jest za darmo. Jestem znudzony edukowaniem za
friko każdego, kto jest za wielkim ignorantem, aby zrobic to samodzielnie.
Post by Mateusz Viste
No to ja dziękuję za taki
postęp.
Nie pojmujesz nawet tego, że ten kod da się napisać generycznie i używać
gdzie chcesz, *zmniejszajac* koszty błedów.

Pisałeś kiedyś coś więcej, niż hello world?
Post by Mateusz Viste
Jak ma być skomplikowanie to równie dobrze w C mogę sobie
złożyć system do sprytnego zarządzania flagami.
To złóż i pochwal się. Ale nie zapłacę za niego z prostej przyczyny: nie
będzie mieć śladu zalet względem statycznych checków C++. Wiem to
dlatego, że widziałem ich na pęczki. Każdy gówno wart.

A najbardziej zabawne, że to dopiero początek tego, co C++ pozwala
zrobić dobrego w kodzie embedded, a Ty już nie pojmujesz gdzie zalety,
bo ci assembler przesłania.
J.F
2021-11-18 19:56:32 UTC
Permalink
Post by heby
Dokładnie to oferujesz. Mówisz: "ale uważaj, przed każdym wyjściem z
funkcji musisz zawołać goto". Ja tego nie mówie. Samo prawidłowo
zawoła się to, co ma się zawołać, nie muszę żyć w ciągłym strachu,
mam 1 miejsce a nie 30, do popełnienia błedu.
Masz 30 miejsc wyjścia z funkcji? No, to faktycznie przykładny kod.
Jak mam obsluge bledow w funkcji, to sie zaczynaja wyjscia mnozyc.
Bo bledow moze byc mnostwo - np brak portu, brak prawa dostepu do
portu, brak odpowiedzi w zalozonym czasie, niezrozumiala odpowiedz,
zgloszony bład przez urzadzenie na porcie, błędna wartosc.

Moim sztandarowym przykladem jest raczej przeszukanie dwuwymiarowej
tablicy.

To IMO jakos tak bylo, ze jak poczatkujacy pisze w Basicu czy
Fortranie, to wkrotce pisze kod pelny "dzikich" goto.

Wirth to chyba zauwazyl, wymyslil jezyk strukturalny,
ale czasem naprawde przykro patrzec, jakie cuda wyprawiali programisci
w Pascalu, aby nie użyć zadnego goto.
Ktore w jezyku było, ale przeciez nie wypada ...


J.
J.F
2021-11-19 08:43:16 UTC
Permalink
Post by J.F
Jak mam obsluge bledow w funkcji, to sie zaczynaja wyjscia mnozyc.
Bo bledow moze byc mnostwo - np brak portu, brak prawa dostepu do
portu, brak odpowiedzi w zalozonym czasie, niezrozumiala odpowiedz,
zgloszony bład przez urzadzenie na porcie, błędna wartosc.
W tym wypadku też mnogość wyjść może być problemem, bo szybko wychodzą
[...]
i prędzej czy później o czymś zapomnisz. Tzn. może nie ty, ale ja
void *buf = NULL;
int port = 0;
buf = alokuj_bufor();
if (!buf) goto poleglem;
if (!napisz_na_port() goto poleglem;
if (!odbierz_z_portu() goto poleglem;
return(sukces);
if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(fail);
w przypadku sukcesu tez mozemy chciec zwolnic zasoby, wiec raczej

int err_code=0;

if (!buf) {err_code=BUF_ALL; goto poleglem;}
if (!napisz_na_port() {err_code=PORT_Write; goto poleglem;}
if (!odbierz_z_portu() {err_code=PORT_READ; goto poleglem;}

err_code=SUCCESS

poleglem:

if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(err_code);
albo, jeśli kto naprawdę uczulony na goto, to całość ubrać w jakąś
niby-pętlę która wykonuje się raz, a wychodzić z niej breakiem...
Ale
to już kombinowanie na siłę, aby tylko nie zhańbić się goto przed
pryszczatą młodzieżą.
Jak krokow wiecej to moze byc nieglupie - przygotowac taki
mini program do wykonania.

Mozna tez
int err_code=0;

if (!buf) err_code=BUF_ALL;
if (!err_code && !napisz_na_port()) err_code=PORT_Write;
if (!err_code && !odbierz_z_portu()) err_code=PORT_READ;

err_code=SUCCESS

if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(err_code);

no i niby poprawniej, tylko program niepotrzebnie sprawdza pare razy
blad ... a co tam, szybkie procki mamy


ewentualnie

int err_code=0;
if (!buf) err_code=BUF_ALL;
else if (!napisz_na_port()) err_code=PORT_Write;
else if (!odbierz_z_portu()) err_code=PORT_READ;

err_code=SUCCESS

if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(err_code);

Superczytelne :-P

Gorzej, jak sie drzewko decyzyjne komplikuje ...

J.
Mateusz Viste
2021-11-19 09:01:37 UTC
Permalink
Post by J.F
w przypadku sukcesu tez mozemy chciec zwolnic zasoby, wiec raczej
int err_code=0;
if (!buf) {err_code=BUF_ALL; goto poleglem;}
if (!napisz_na_port() {err_code=PORT_Write; goto poleglem;}
if (!odbierz_z_portu() {err_code=PORT_READ; goto poleglem;}
err_code=SUCCESS
if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(err_code);
Detale zależą już od założeń konkretnego przypadku - API może
przewidywać, że po nawiązaniu komunikacji port pozostaje otwarty na
potrzeby dalszych operacji. Jeśli nie, to oczywiście masz słuszność.
Post by J.F
Mozna tez
int err_code=0;
if (!buf) err_code=BUF_ALL;
if (!err_code && !napisz_na_port()) err_code=PORT_Write;
if (!err_code && !odbierz_z_portu()) err_code=PORT_READ;
err_code=SUCCESS
if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(err_code);
no i niby poprawniej, tylko program niepotrzebnie sprawdza pare razy
blad ... a co tam, szybkie procki mamy
Można. Tylko po co? Aby zmniejszyć czytelność kodu i dodać
niepotrzebnych kroków, coby za wszelką cenę uniknąć goto?
Post by J.F
ewentualnie
int err_code=0;
if (!buf) err_code=BUF_ALL;
else if (!napisz_na_port()) err_code=PORT_Write;
else if (!odbierz_z_portu()) err_code=PORT_READ;
err_code=SUCCESS
if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(err_code);
Superczytelne :-P
No właśnie, czytelność na tyle słaba, że zapomniałeś o końcowym "else" i
awaria gotowa. A w efekcie kompilator i tak przetłumaczy to wszystko
na kilka goto...

Mateusz
heby
2021-11-19 08:44:17 UTC
Permalink
if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(fail);
Ten fragment kodu nie jest za darmo. Innymi słowy ideologię "da się na
goto" dostałeś w bonusie z runtime checkiem.

Samo życie ideologa C.
J.F
2021-11-19 09:53:02 UTC
Permalink
Post by heby
if (buf) zwolnij_bufor();
if (port) zamknij_port();
return(fail);
Ten fragment kodu nie jest za darmo. Innymi słowy ideologię "da się na
goto" dostałeś w bonusie z runtime checkiem.
Samo życie ideologa C.
Niby owszem, ale mozna przeciez tez tak:

void *buf = NULL;
int port = 0;

buf = alokuj_bufor();
if (!buf) goto poleglem_buf;
if (!napisz_na_port() goto poleglem_write;
if (!odbierz_z_portu() goto poleglem_read;
return(sukces);

poleglem_read:
poleglem_write:
zamknij_port();
poleglem_buf:
zwolnij_bufor();
return(fail);

Popierasz, nie popierasz?

Fakt, ze to juz bliskie czystej strukturze na if-else.

Tylko ze czasem algorytm nie ma takiejs czystej struktury.

J.
Mateusz Viste
2021-11-19 10:07:05 UTC
Permalink
void *buf = NULL;
int port = 0;
buf = alokuj_bufor();
if (!buf) goto poleglem_buf;
if (!napisz_na_port() goto poleglem_write;
if (!odbierz_z_portu() goto poleglem_read;
return(sukces);
zamknij_port();
zwolnij_bufor();
return(fail);
Maszynowo niewątpliwie czyściej, ale dostrzegam potencjalny
problem w czynniku ludzkim - bo teraz programista musi wiedzieć, do
którego labela wykonać jmp.

Metoda "sprawdzam wszystko w jednym miejscu" ma tę zaletę, że jest
bardzo łatwo w użyciu i trudno o pomyłkę. Fakt, zmarnujemy na tym kilka
instrukcji JZ/JE, ale jeśli zależałoby nam na tak daleko posuniętej
oszczędności, to po prostu użylibyśmy NASM... Swoją drogą, ciekawe jak
RAII w C++ to tłumaczy. Domniemywam, że właśnie tak - bo przecież musi
pamiętać/sprawdzać co zostało zainicjalizowane, a co nie. Sprawdzi ktoś?

Mateusz
Mateusz Viste
2021-11-19 10:34:22 UTC
Permalink
Post by Mateusz Viste
Maszynowo niewątpliwie czyściej, ale dostrzegam potencjalny
problem w czynniku ludzkim - bo teraz programista musi wiedzieć, do
którego labela wykonać jmp.
Muszę tu uściślić, że przy bardzo małej ilości możliwości, kiedy trudno
by programista się pomylił, to podejście z paroma labelami *może* być
fajne. Kwestia wyczucia punktu równowagi.

Tutaj jest ładny przykład w ten deseń:
https://github.com/git/git/blob/master/dir.c#L3653

Swoją drogą - w kodzie git-a naliczyłem 759 wystąpień goto. Ale to
przecież poziom migania diodą, więc nic dziwnego. :-)

Mateusz
Mateusz Viste
2021-11-18 20:47:12 UTC
Permalink
Wylatujesz za drzwi nie tylko z kopniakiem, ale jeszcze z wilczym
biletem na pracę w IT.
Przypomnę, że pisałeś wcześniej że "w C nie da się tego zrobić". Teraz
ci po prostu łyso. :-)
Wlasnie napisałeś kiepski, ale emulator RAII. I po co było bredzić o
goto?
goto ma swoje niszowe zastosowania. To, co dziś nazywa się "RAII"
istniało przed C++ i wykorzystywało właśnie goto. Zresztą nie tylko ja
o tym bredzę:
https://www.kernel.org/doc/Documentation/process/coding-style.rst

"The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done. If
there is no cleanup needed then just return directly."
Poważniejszy przykład mogę podrzucić jeśli chcesz, ale czy aby na
char value = cast_with_range_check< char >( intValue );
W kodzie produkcyjnym nic się nie zmienia, w kodzie dla unit testów
masz tam w środku zaawansowane sprawdzanie czy wartość mieści się w
zakresie typu.
Ciekawa konstrukcja. Nie mam pewności, czy to w praktyce mogłoby być mi
użyteczne, bo jeśli castuję większe do mniejszego to obwarowuję
operację stosownymi asercjami. Czy w takiej sytuacji ten
cast_with_range_check<> ma jakieś zalety? Pytam szczerze i bez przekąsu.
Ja tu bronie jakiejś idei? Robisz gówniany kod na goto, który
świadczy o zerowej wiedzy z zakresu bezpieczeństwa kodu i to w imię
"Łojezu, nie wolno używać C++, bo przyjdzie babajaga i zje!" i to ja
czegoś zaciekle bronię? Żartujesz?
Tak, bronisz. Podałeś tezę pt. "C++ najlepszy do programowania w
embedded" i uargumentowałeś ją kiepskim przykładem. Zapytałem o lepszy.
I zaczęło się.
To co, piszesz to zabezpieczneie przed podaniem złej flagi do uartu,
w C?
Ja zupełnie tego nie potrzebuję. To ty podałeś te flagi jako kolejny
przykład wyższości C++ "w embedded"... Ale okazało się niestety, że to
przykład tylko wirtualny.


Mateusz
heby
2021-11-18 21:06:28 UTC
Permalink
Post by Mateusz Viste
Wylatujesz za drzwi nie tylko z kopniakiem, ale jeszcze z wilczym
biletem na pracę w IT.
Przypomnę, że pisałeś wcześniej że "w C nie da się tego zrobić". Teraz
ci po prostu łyso. :-)
Nie, dalej twierdze że nie da się zrobic RAII w C. Można emulatowac
pojedyncze przypadki, jak Twój przykłąd. Przeciez oba są
Turing-complete, więc można napisać żałosny kod o identycznej logice jak
inny kod.
Post by Mateusz Viste
Wlasnie napisałeś kiepski, ale emulator RAII. I po co było bredzić o
goto?
goto ma swoje niszowe zastosowania.
Ma. Ale prawde mówiąc są tak niszowe, że nie użyłem go od chyab 20 lat.
Mimo zawodowej pracy w C++.
Post by Mateusz Viste
To, co dziś nazywa się "RAII"
istniało przed C++ i wykorzystywało właśnie goto.
Nie. To nie ma jedno z drugim nic wspólnego. RAII to nie jest inne goto.
To w ogóle nie jest nawet obok.

Jak chcesz już analogii, to Twoje "goto" jest bliżej exceptionów z C++,
one też przerywają flow kodu.

RAII jest najbliżej konstrukcji try {} finally {}.
Post by Mateusz Viste
Zresztą nie tylko ja
https://www.kernel.org/doc/Documentation/process/coding-style.rst
Podałeś przykład kodu, w którym religijnośc jest ważna, wazniejsza niż
zdrowy rozsądek. Nic dziwnego, że nie ma wyjścia i trzeba korzystać z
mechanizmów, które są śmieszne, żałosne i niebezpieczne, bo C++ nie
wolno bo nie wolno.

Ja oczywiście znam rozsądne argumenty za C w kernelu, ale znam też
głośno powtarzane, nierozsądne.
Post by Mateusz Viste
"The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done. If
there is no cleanup needed then just return directly."
No widzisz, a reszta świata ma finally. Czyli reszta świata się myli.

Kolesie od kernela nie mają wyjścia: pracują w toksycznym środowisku w
którym jednym pytaniem o coś lepszego niż C zbywa się "you're full of
shit" i podobnyumi argumentami merytorycznymi. Wiem, słyszałem
wielokrotnie. Kernel linuxa to nie jest specjalnie dobry argument w
jakiejkolwiek dyspucie o jakosci i bezpieczeństwie kodu, chyba że
potrzebujesz wyznaczyć poziom zerowy.
Post by Mateusz Viste
char value = cast_with_range_check< char >( intValue );
W kodzie produkcyjnym nic się nie zmienia, w kodzie dla unit testów
masz tam w środku zaawansowane sprawdzanie czy wartość mieści się w
zakresie typu.
Ciekawa konstrukcja. Nie mam pewności, czy to w praktyce mogłoby być mi
użyteczne, bo jeśli castuję większe do mniejszego to obwarowuję
operację stosownymi asercjami.
Potraktuj to jaki uniwersalną, generyczną asercję.
Post by Mateusz Viste
Czy w takiej sytuacji ten
cast_with_range_check<> ma jakieś zalety? Pytam szczerze i bez przekąsu.
Tak. Jeśli popełniasz błąd, to raz a nie 500 razy w każdym możliwym miejscu.

Wyobraź sobie że musisz rozpatrzeć:
a) signed/unsigned
b) mały/duży
c) float/int
d) double/single
e) ttmath/magic_int256_t

I wszystkie ich kombinacje. To jest kilkaset asercji i czasami cieżkich
obliczeń, z gwarnacja buga.

Twoja metoda to technika rozpryskowa, czyli wpierniczmy te asercje
wszędzie po kodzie, a każda inna.

Moja technika to generalizacja i abstrakcja problemu to template,
którego nie da się użyć źle. W dodatku o jakości zapewnianej unit
testami. C++ daje mi do tego calu trywialne i wygodne narzędzie.

Oczywiscie, za chwile wyskoczy jakiś hacker z hasłem "ale ja to mogę
zrobic na #define, potrzymaj mi kota".

Tak, wszystko jest turing-complete, brainfuck, whitespace, intersil też.
Da się zrobic na #define. I w brainfucku. I ja też kiedyś robiłem na
#define. Ale już nie robie. To dziecinada.
Post by Mateusz Viste
Ja tu bronie jakiejś idei? Robisz gówniany kod na goto, który
świadczy o zerowej wiedzy z zakresu bezpieczeństwa kodu i to w imię
"Łojezu, nie wolno używać C++, bo przyjdzie babajaga i zje!" i to ja
czegoś zaciekle bronię? Żartujesz?
Tak, bronisz. Podałeś tezę pt. "C++ najlepszy do programowania w
embedded"
Nie. Podalem tezę "można zerowym kosztem pisać kod lepszy niż w C" bo
niczym się od gołego C nie różni.

Do programowania embedded jest najlepszy język, który najlepiej pasuje
do zagadnienai które chcesz rozwiązać.

W przypadku C vs C++ argumentacja że "C++" jest gorszy od C, wymagała
odpowiedzi. I tak doszliśmy do twojego goto, jako panaceum na problemy
3-go świata programistów z epoki kamienia łupanego.
Post by Mateusz Viste
i uargumentowałeś ją kiepskim przykładem. Zapytałem o lepszy.
I zaczęło się.
Wiec zauważ o czym dysputa była. Dysputa jest o tym, że C nie jest
lepszy od C++, bo C++ to C + *przydatne* rzeczy. Więc niejako na bazie
czystej logiki nawet...
Post by Mateusz Viste
To co, piszesz to zabezpieczneie przed podaniem złej flagi do uartu,
w C?
Ja zupełnie tego nie potrzebuję.
No własnie. Innymi słowy jesteś wyznawcą podejścia hackerskiego do
programowania.

"Ja się nie mylę, po co mi to całe bezpieczeństwo".

Ja wręcz odwrotnie: "bezpieczeństwo i testowanie a potem kodowanie".

I różnica jest taka, że ja wiem jak to przenieśc do embedded.
Post by Mateusz Viste
przykład wyższości C++ "w embedded"... Ale okazało się niestety, że to
przykład tylko wirtualny.
Ja bym go nazwał konkretnym, ale ja pracuje zawodowo w takim języku,
więc co ja tam mogę wiedzieć.
Mateusz Viste
2021-11-19 09:59:43 UTC
Permalink
Moje odpowiedzi w tym wątku są specjalnie przerysowane, aby spuścić z
Ciebie powietrze z farfoclami goto.
Nie, jesteś po prostu cham i krzykacz, a zamiast merytorycznych
argumentów wolisz naubliżać zza anonimowego nicka. Nie dziwię się, bo
to częste w tej branży.

Wyciąłem z twojej wypowiedzi wszelkie chamstwo, odniosę się więc do
tego, co zostało (niewiele).
ta twoja pogradzana statystyka gra obecnie pierewsze skrzypce w
dużym embedded.
Nie, nie pogardzam. Sam stosuję.
Zwróć uwagę, że nie padł z twojej strony ani jeden argument po co
*nie* stosować.
Bo ja niczego nie bronię. Ja tylko pytam o rozwinięcie twojej tezy "C++
jest najlepsze w embedded" na konkretnych przykładach.
I nie milion. Na razie te dwie, czyli RAII i szablony, załataiają
większośc problemów niedzielnego programisty embeede
C++ to jednak nieco szerszy temat niż tylko RAII i szablony. Jak
rozumiem, sugerujesz używanie C++ "tak, jak by to było C, z dodatkiem
dwóch-trzech nowości bo przecież to darmo jest". Ja uważam takie
podejście ze nieodpowiedzialne, bo jeśli używam narzędzia do poważnych
zastosowań, to muszę panować nad nim w 100% aby nie dać się zaskoczyć
jakimś nieznanym zachowaniem. To trochę tak, jakbyś doradzał pilotowi
lecieć samolotem z milionem gałek, bez znajomości większości z nich
("bo te trzy tutaj po lewej załatwią większość sytuacji, a tych innych
po prostu nie dotykaj"). A potem okazuje się, że drugi pilot zna inny
zestaw gałek i tak sobie dłubią każdy w inny sposób i wpadają we własne
pułapki.

Mateusz
Mateusz Viste
2021-11-19 19:38:47 UTC
Permalink
Post by Mateusz Viste
Nie, jesteś po prostu cham i krzykacz
Pełna zgoda.
Reasumując, spotkał się cham z ignorantem. No to skoro ustaliliśmy
na czym stoimy, to może uda się dojść do jakichś budujących wniosków.
Nie spotykam się na codzień z ludzmi uważającymi że goto to coś
lepszego od RAII, więc wypacz napływ emocji.
Podałem sposób, w jaki można rozwiązać problem który ilustrowałeś
przykładem. Nie twierdzę, że to lepsze niż nowoczesne RAII. Twierdzę
natomiast, że RAII nie jest tak naprawdę żadną rewolucją i przykład
który podałeś słabo odzwierciedla jego ewentualną wartość dodaną. A tak
promowałeś C++, że naprawdę spodziewałem się jakiegoś life-changera.
Wymyslasz jak obejśc rozwiązania gotowe, robiąc takie same, tylko
znacznie gorsze.
Nie nie, ja niczego nie wymyślam. Ja to po prostu stosuję, bo to
codzienność w pracy programisty C. Ja rozumiem, że cię to brzydzi.
Mnie brzydzą lambdy, funkcje wirtualne i templaty.
Gubiąc po drodze wszytkie zalety jakie istnieją z generalizacji,
skupiajac się na bezsensownych przykładach
Przecież ja od początku pisałem, że te przykłady są bez sensu i
prosiłem o jakąś dobitniejszą demonstrację.
Rozmawiamy o technologi będącej na rynku do 30 lat, które
najzwyczajniej przespałeś i teraz dorabiasz głupie filozofie "jest
niepewna" itd. Chowasz swoją ignorancję za głupimi argumentami.
Nie pisałem nic o "niepewnej technologii". Pisałem, że C++ to nie tylko
C z RAII, tylko dużo większy kombajn i zanim programista zacznie
cokolwiek w nim dłubać to musi go całego ogarnąć. Włącznie z tymi
milionami rzeczy, których sam nie będzie używał - bo nie wiadomo czy
kolega obok ich nie użyje i trzeba będzie z tym kodem potem walczyć.
Chyba nie zakładasz, że komuś kto nie ma pojęcia o C++ polecam jego
używanie? Polecam *zapoznanie* się.
Nawołujesz do używania "fragmentów". Dodatkowo argumentując, że "to
jest za darmo", a to bardzo myląca promocja. Zapoznać się oczywiście
warto - ze wszystkim. I żeby nie było: ja nie jestem żadnym
przeciwnikiem C++. Kilka lat temu przeczytałem książkę o nim, i
wstukałem nawet kilka hello-worldów. Po prostu nie przekonało mnie to,
by zgłębiać temat dalej.

Na zakończenie zapytam zupełnie z innej beczki, bo chodzi to za mną
cały dzień: dlaczego używasz/zachwalasz git-a, skoro jego kod to
(cytując twoje słowa) "szambo"?

Mateusz
Mateusz Viste
2021-11-19 20:54:27 UTC
Permalink
Post by Mateusz Viste
to może uda się dojść do jakichś budujących wniosków.
Nie uda się.
Dobra, to zaprzestaję prób. Niekompatybilne interfejsy widocznie. A i
grupowicze już pewno ostro zanudzeni tym wątkiem.
Post by Mateusz Viste
Oczywiście że tak. Podałeś kilka przykładów: szambo z goto, emulacje
RAII na podziale funkcji na kawałki. Za oba wylatujesz z kopniakiem
za drzwi na review kodu, bo lata 80 słusznie minęły.
(...)
Na codzień pracuje z Subversion, który jest optymalny do zagadnień
jakie mam. Git nie ma żadnej zalety, a same wady, w mojej konkretnej
sytuacji.
Łolaboga, ale to przecież też szambo! Mnóstwo takich obrzydliwości tam
siedzi:

/* Create the environment and databases. */
svn_err = open_databases(fs, TRUE, format, path);
if (svn_err) goto error;

/* Initialize the DAG subsystem. */
svn_err = svn_fs_base__dag_init_fs(fs);
if (svn_err) goto error;

error:
return svn_error_compose_create(svn_error_trace(cleanup_fs(fs)));

Powinni tego kopniaka dostać i wilczy bilet. Tak samo jak ci od Git-a
zresztą. :)

W kodzie subversion wyliczyłem 458 użyć goto. Ech, amatorzy.
No ale to i tak lepiej niż w Git, gdzie tych goto siedzi 759.

Mateusz
heby
2021-11-19 21:06:39 UTC
Permalink
Post by Mateusz Viste
Post by Mateusz Viste
Na codzień pracuje z Subversion, który jest optymalny do zagadnień
jakie mam. Git nie ma żadnej zalety, a same wady, w mojej konkretnej
sytuacji.
Łolaboga, ale to przecież też szambo! Mnóstwo takich obrzydliwości tam
Tak. Kod SVN jest gówno wart. Cieszę się, że wreszcie pojmujesz. Na
forach dev svn siedzi masa ideologów, kłócących się o to, jak nie użyć
innego, lepszego rozwiązania. Byłem, widziałem, podziękowałem.
Post by Mateusz Viste
Powinni tego kopniaka dostać i wilczy bilet. Tak samo jak ci od Git-a
zresztą. :)
Zgadza się. Zdecydowanie wolałbym w grupie czystego studenta, niż 60+
dev z grupy SVN. Szkoda czasu na prostowanie vintage.
Post by Mateusz Viste
W kodzie subversion wyliczyłem 458 użyć goto. Ech, amatorzy.
No ale to i tak lepiej niż w Git, gdzie tych goto siedzi 759.
Nie jeden raz nie przekonałem się co do jakosci kodu SVN/GIT. To
narzędzia, których używam, z powodów które nie zawsze są moim wyborem. I
tak, SVN ma od groma bugów, któe trzeba nauczyć się omijać. Jak już
pisałem w innym miejscu: jakośc oprogramowania dąży do granicy pomiędzy
dziadostwem a wkurwieniem.

Dobrze jest nie dokładać do tego cegiełek, ale rób jak uważasz.

PS. Używam też kernela Linuxa, też napisanego na odpierdol. Możesz
spokojnie z tego się śmiać. Ja goto nie używam. Nie wiem, może
najzwyczajniej nie znalazłem przez 20 lat powodu.
Dawid Rutkowski
2021-11-19 21:19:04 UTC
Permalink
Post by Mateusz Viste
Mnie brzydzą lambdy, funkcje wirtualne i templaty.
Wirtualne czy przeciążone?
Przeciążone to klątwa, gorsze od nich jest chyba tylko przeciążanie operatorów.
Choć te lambdy to coś równie walniętego.
Kurtałka, zdałem sobie sprawę, że u tej fajnej rekruterki byłem przed 2007 - więc nie było na tym teście jeszcze C++11, nie mówiąc o C++14...

Funkcje wirtualne są OK, dziwne, że w klasach można w ogóle robić nie-wirtualne - no ale pułapki to podstawa.
Echh, jakim satori było, że w C można mieć wskaźnik do funkcji - i wywołać taką funkcję przez ten wskaźnik.
Wszystkie sterowniki w Linuxie mają własne write, read, ioctl...
Pascale mogą się schować.

Marek
2021-11-19 21:00:41 UTC
Permalink
Mój nick nie zmienił się od 20 kilku lat. Trudno o coś mniej
anonimowego, wystraczy śladowa ilośc woli.
Zmienił się. Pisałeś niedawno pod pseudonimem Sebastian Biały, teraz
heby. Czemu już nie S. Biały?
--
Marek
Mirek
2021-11-18 20:43:21 UTC
Permalink
Branża języków programowania dyskutuje własnie o tym, kiedy mowa o
językach programowania. Szkoda, mogli by rozmawiać o dupach.
Ale po co ci jakieś dupy - toż to białko ;)
--
Mirek.
Piotrek
2021-11-18 17:41:33 UTC
Permalink
Post by heby
[...]
Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
grupach 60+ to może być coding standard.
Nie to, żebym się obruszył o 60+ ...

Ale przecież styl projektowania/programowania nie zależy od wieku
autora. Tylko raczej od tego czy gość trafił do zawodu w wyniku
ostatniej łapanki przeprowadzonej w środowisku piekarzy, czy też w
bardziej cywilizowany sposób.

Piotrek
heby
2021-11-18 17:45:38 UTC
Permalink
Post by Piotrek
Post by heby
Są miejsca, gdzie takie gówno oparte o goto wyleciało by z hukiem na
review razem z autorem tego szamba. Choć zdaje sobie też sprawę, że w
grupach 60+ to może być coding standard.
Nie to, żebym się obruszył o 60+ ...
Ale przecież styl projektowania/programowania nie zależy od wieku
autora.
Zależy. Przykro mi to stwierdzić, ale zalezy. W embedded w szczególności.

Isnieje korelacja między używaniem konstrukcji hackerskich i
niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi, nie
odosobnione.
Post by Piotrek
Tylko raczej od tego czy gość trafił do zawodu w wyniku
ostatniej łapanki przeprowadzonej w środowisku piekarzy, czy też w
bardziej cywilizowany sposób.
Problem że ten "bardziej cywilizowany sposób", 40 lat temu, to było goto
w BASICu. I z tym kłopot największy.
Piotrek
2021-11-18 19:03:00 UTC
Permalink
Post by heby
Post by Piotrek
Nie to, żebym się obruszył o 60+ ...
Ale przecież styl projektowania/programowania nie zależy od wieku autora.
Zależy. Przykro mi to stwierdzić, ale zalezy. W embedded w szczególności.
Isnieje korelacja między używaniem konstrukcji hackerskich i
niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi, nie
odosobnione.
Przede wszystkim jak ktoś zaczynał w IT 40 lat temu to aktualnie raczej
zajmuje się odcinaniem kuponów od tego co osiągnął w życiu (zawodowym),
a nie kodowaniem.

Tak więc będę się upierał, że w przypadku profesjonalistów problem
zależności jakości kodu od wieku programisty jest IMHO marginalny.

Natomiast nie neguję zależności jakości kodu od wcześniej wykonywanego
zawodu ;-)

Ale przede wszystkim od doświadczenia zawodowego (przy założeniu, że
gość ma zdefiniowaną ścieżkę kariery, ma mentora, bierze udział w
szkoleniach, etc.)
Post by heby
Post by Piotrek
Tylko raczej od tego czy gość trafił do zawodu w wyniku ostatniej
łapanki przeprowadzonej w środowisku piekarzy, czy też w bardziej
cywilizowany sposób.
Problem że ten "bardziej cywilizowany sposób", 40 lat temu, to było goto
w BASICu. I z tym kłopot największy.
?

Nie traktuj tego osobiście ale IMHO masz wypaczone pojęcie o technologii
i zakresie kształcenia (studentów informatyki) w latach 80.

Inną sprawą jest to czy rzeczeni studenci mogli wykorzystać nabytą
wiedzę w pracy zawodowej.

Ale regresu typu Simula/Smalltalk/C++ -> BASIC raczej bym się nie
spodziewał.

Piotrek
heby
2021-11-18 19:47:04 UTC
Permalink
Post by Piotrek
Post by heby
Isnieje korelacja między używaniem konstrukcji hackerskich i
niebezpiecznych, a wiekiem developera. Są to moje, subiektywne
oczywiscie, obserwacje. Ale sądząc po dyskusjach z moimi znajomymi,
nie odosobnione.
Przede wszystkim jak ktoś zaczynał w IT 40 lat temu to aktualnie raczej
zajmuje się odcinaniem kuponów od tego co osiągnął w życiu (zawodowym),
a nie kodowaniem.
W moim otoczeniu programistów 60+ jest mało, ale istnieją. W embedded
jest ich znacznie wiecej, choć to statystyka subiektywna, ale jak mówie,
sporo znajomych z mojego otoczenia ma podobne.
Post by Piotrek
Tak więc będę się upierał, że w przypadku profesjonalistów problem
zależności jakości kodu od wieku programisty jest IMHO marginalny.
Korelacja jest miedzy wiekiem, a nie "od 60+". Przeciętny 50-latek
będzie znacznie bardziej skłonny do używania void* niż 40-latek. A
30-latek znowu, bedzie znał np. C# i nie zdziwi go lambda w C++.
Post by Piotrek
Natomiast nie neguję zależności jakości kodu od wcześniej wykonywanego
zawodu ;-)
Taka występuje oczywiście. Dam Ci jeszcze inny przykład: wśród
programistów z Ukrainy zauważyłem korelacje w preferowanych wzorcach
projektowych. Skłaniających się w okolice antywzorca "golden hammer". I
to nie zależy od miejsca, skad pochodzą, z tej Ukrainy. Tak jak by
problem istniał gdzieś w samym centrum nauczania.

To trochę jak kiedyś Bielecki, mający wpływ na nauczanie (kiepskie)
programowania w PL.
Post by Piotrek
Post by heby
Post by Piotrek
Tylko raczej od tego czy gość trafił do zawodu w wyniku ostatniej
łapanki przeprowadzonej w środowisku piekarzy, czy też w bardziej
cywilizowany sposób.
Problem że ten "bardziej cywilizowany sposób", 40 lat temu, to było
goto w BASICu. I z tym kłopot największy.
?
Starsi programiści potrafią rozwiązać każdy problem używając outdated
konstrukcji w języku.

Wyjśc ze scope? Goto! (zamiast poprawnej struktury)
Zawołać pointer? C-style (zamiast std::function/lambda)
Zwrócić dwie zmienne? Przez argumenty!
Polimorfizm? void* i enum cast rozwiązuje wszystkie problemy.

Widać wyraźną alergicznośc na konstrukcje bezpieczniejsze, ponieważ
"lepsze jest wrogiem dobrego" jak mawiają ludzie starający sie ukryć
swoją ignorancję.
Post by Piotrek
Nie traktuj tego osobiście ale IMHO masz wypaczone pojęcie o technologii
i zakresie kształcenia (studentów informatyki) w latach 80.
Czy w latach 80 uczono C++ z RAII? Nie. Nie uczy się go, tak na
marginesie, do dzisiaj. Lata od 90 pod 2020 mam zarówno ogarnięte od
strony ucznia/studenta jak i wykładowcy. Natomiast tak, uczono na
uczelniach kiepskich jezyków programowania i zalewano betonem kiepskie
nawyki. O ile człowiek młody, to jest też elastyczny. Znów starszy, z
uwagi na biologie, przyjmuje postawę w opozycji do nowości. To
naturnalne, stwierdzam bardziej fakt, niż narzekam.
Post by Piotrek
Inną sprawą jest to czy rzeczeni studenci mogli wykorzystać nabytą
wiedzę w pracy zawodowej.
Zwyczajowo nie, programowanie uC w latach 80/90 w wiekszości odbywało
się w asm i sporadycznie w idiotycznych dialektach C. Po 20 latach
pisania na 8051 trudno się dziwić, że jak ktoś mówi o RAII to pojawia
się natychmiastowa reakcja alergiczna. Mnie to nie dziwi ani torchę i
nie zamierzam tego zmieniać. Ten problem rozwiąże biologia.
Post by Piotrek
Ale regresu typu Simula/Smalltalk/C++ -> BASIC raczej bym się nie
spodziewał.
Języki dąża do bycia coraz to bardziej dziadowskimi, ale ciągle
uzytecznymi. JavaScript, jako najgorsze guano obecnie używane, jest nie
dosc że bardo popularny, to również bardzo wysoko płatny.

Całość tego procesu wynika z faktu, że nie ma na rynku zawodowych
programistów. Są jedynie Ci z łapanki, którzy nie pojmą RAII w C++, ale
pojmą jak zrobić obrazek z licznikiem w Node.js.

Ja tego nie zamierzam zmieniać, ale dziadostwo w moim otoczeniu
uprzątam, jesli tylko mam okazję. Jeszcze mi się chce.
a***@math.uni.wroc.pl
2021-11-18 20:25:57 UTC
Permalink
Nie to, ?ebym si? obruszy? o 60+ ...
Ale przecie? styl projektowania/programowania nie zale?y od wieku autora.
<snip>
Tylko raczej od tego czy go?? trafi? do zawodu w wyniku ostatniej
?apanki przeprowadzonej w ?rodowisku piekarzy, czy te? w bardziej
cywilizowany spos?b.
Problem ?e ten "bardziej cywilizowany spos?b", 40 lat temu, to by?o goto
w BASICu. I z tym k?opot najwi?kszy.
?
Nie traktuj tego osobi?cie ale IMHO masz wypaczone poj?cie o technologii
i zakresie kszta?cenia (student?w informatyki) w latach 80.
Inn? spraw? jest to czy rzeczeni studenci mogli wykorzysta? nabyt?
wiedz? w pracy zawodowej.
Ale regresu typu Simula/Smalltalk/C++ -> BASIC raczej bym si? nie
spodziewa?.
Elektronika na PWr 1982: programowanie to byl Fortran 66, czesc
grup Pascal. W tym czasie PWr kupila sporo ZX81, tam faktycznie
byl Basic. Mikroprocesory to byl 8080 (bylo tez o Z80), programowanie
w asemblerze. Na RIAD-ach byl tez PL/I i Algol. Byl tez Prolog,
ale chyba tylko dla malej grupki wybrancow. 2-3 lata pozniej
na komputerki domowe byl Pascal, C, Forth, Logo (Basic tez...).
Sporo bylo pisane w asemblerze.

Inna sprawa ze w 1982 dostep do komputerow byl ograniczony i
sporo studentow tego nie lapalo. Ale jak ktos zalapal i
glebiej wchodzil w programowanie to dosc szybko zostawial
Basic i Fortran za soba.
--
Waldek Hebisch
ptoki
2021-11-17 23:06:29 UTC
Permalink
Post by heby
Nie. Dałem Ci przykład dwóch programów, jeden w C drugi w C++. Który
wykona się wolniej i dlaczego?
Daj spokój, dobrze wiemy, że żaden z nich nie jest w C++. Przykład
zły, bo oba kody skracają się do tej samej abstrakcji wspólnej dla
obu języków. Ten drugi napisz porządnie w C++, pętlę zrób obiektowo i
żeby proces zajął min 2GB ram. ;)
Pozwol ze sie wlacze sie w dywagacje.
Problem tutaj jest nie w tym co moze zrobic C++ i C albo asembler tylko w tym co ludzie sobie pisza.
Jeden mowi ze C++ to kobyla a drugi mowi ze nie bo on robi w C++ i programy mu wychodza nieduze.
Jeden mowi ze arduino to gówno bo cos tam zmontowal i mu pamieci zabraklo albo sie sypalo a drugi powie ze on zrobil co innego, uzyl innych bibliotek i mu dzialalo dlugo, wydajnie i stabilnie.

Problem jest w tych generalizacjach.
Zeby temat wyjasnic trzeba by to samo zagadnienie zaimplementowac w obu srodowiskach, porownac kod wynikowy i stabilnosc/szybkosc dzialania.
Nikt tego nie zrobi, klocic mozna sie tedy do zarzygania.

I druga uwaga:
Sporo softow dzis jest powolna nie dlatego ze jest obiektowa czy napisana w kompilatorze takim czy owakim tylko dlatego ze albo jest okrutnie skomplikowana albo zbyt wiele procesow wewnetrznych zalezy od siebie i od asynchronicznych procesow zewnetrznych.

Czemu KDE dziala wolno? Trza by zapuscic profiler. Trza by oblozyc go tcpdumpem i straceami.
Wtedy mozna sie dokopac czemu tyle muli.

I w praktyce moze sie okazac ze to nie jezyk jest winny a po prostu zawilosc aplikacji ktora sobie cos tam zbiera, monitoruje i nie czysci listy (tak jak to robil, i moze robi windows) przez co monitoruje mase smiecia co nikomu potrzebne nie jest. Ale to nie wina C++.

Jedno dodam na koniec.
Bardzo duzo dzis sie odbywa synchronicznie przez siec. Albo pol asynchronicznie (user czeka, nic kliknac nie moze a apka odpytuje zdalny interfejs czy cos sie juz zrobilo czy nie).
I te sprawdzenia niestety sa czesto uruchamiane szeregowo a do tego logika aplikacji czeka na choc jedno uaktualnienie kazdego statusu zeby userowi cos tam pokazac.

Otwierasz file managera a on odpytuje wszystkie dyski, wszystkie sieciowe udzialy, jakiegos blututa, pendrive i to w dobrych okolicznosciach trwa i w efekcie okienko zamiast pojawic sie natychmiast i potem odswierzyc 2-4-10 razy rysuje sie raz ale po sekundzie lub dwu.

W tym czasie user czeka.
Czy to sie da obejsc? Nie sadze. Moze wycinajac pewne funkcje by sie dalo ale IMHO z paru powodow to zaklete kolko.

Czy bedzie lepiej? Tez nie sadze. Jak widze ile sie gówna produkuje bo w webie jest szybciej/prosciej to jestem przekonany ze nie bedzie lepiej.
heby
2021-11-17 18:14:53 UTC
Permalink
Zazwyczaj tak. Ale znacznie częsciej to polaga na braku wiedzy czym
jest C++, dla obserwatorów z zewnatrz. Popularna opinia o C++ to np.
taka, że to jest "new DuzaKlasa". No więc w embedded to psu na budę i
nie o to chodzi.
Czy ja muszę wiedzieć czym jest C++ żeby stwierdzić, że oprogramowanie X
w nim napisane korbi i mi nie odpowiada pod względem responsywności?
W momencie kiedy piszesz "To czemu 99% softu napisanego w C++ dziala
wolno?" bierzesz na siebie odpowiedzialność za stwierdzenie, że to wina
C++. Najwidoczniej przeprowadziłeś dogłębne badania i okazało się, że to
język jest winień, nie złożonośc problemu, kiepscy programiści, tylko
język właśnie.

Co jest oczywistą nieprawdą.
Marek
2021-11-17 18:26:57 UTC
Permalink
Post by heby
W momencie kiedy piszesz "To czemu 99% softu napisanego w C++
dziala
wolno?" bierzesz na siebie odpowiedzialność za stwierdzenie, że to wina
C++. Najwidoczniej przeprowadziłeś dogłębne badania i okazało się, że to
Nie, oczywiście z powodu braku porównania aż tak daleko się nie
posuwam.
--
Marek
Marek
2021-11-17 18:25:54 UTC
Permalink
znacznie gorszych i popularniejszych od niego. Jak choćby gówniany
JavaScript, który odpowiada za 90% wqrwu w internecie i nie
wykluczone,
że w KDE.
A ten JS to uruchamiany jest przez soft napisany w czym? :)
--
Marek
heby
2021-11-17 19:33:50 UTC
Permalink
A kodzie maszynowym. W gruncie rzeczy.
Chyba maszyny do pisania.
To tylko taki żart, że wydajność JS jest niby z winy embedowania go do C++.

Wszystko jest embedowane do kodu maszynowego, na końcu. To on jest
wszystkiemu winien.
a***@math.uni.wroc.pl
2021-11-18 01:37:58 UTC
Permalink
Podaj przyk?ad takiego softu, kt?ry jest napisany w *czym?* i C++ i
w
tym drugim wypadku dzia?a wolno.
No poda?em przyk?ad siebie jako usera u?ywaj?cego od 25 lat g??wnie
softu C++ i ci?gle tak samo korbi jak korbi? 25 lat temu. I tylko
dzi?ki wzrostu wydajno?ci CPU i ilo?ci ramu rozw?j tego softu nie
doprowadzi? do kompletnej jego nieuzywalno?ci (mam na my?li s?ab?
responsywno?? czy u?ycie zasob?w).
To ze programy dzialaja powoli jest niezalezne od jezyka. Po
prostu tak dziala prawo Parkinsona: programy zuzywaja cale
dostepne zasoby (w tym czas). Jedyny sposob na powiekszenie
szybkosci to "zmniejszenie" zasobow, tzn. gdyby userzy sie
zbuntowali i odmowili uzywania nowych programow.

Przy tym wymagania stawiane desktopowym programom mocno
sie roznia od embedded, wiec to co sie dzieje na desktopach
to jest nie na temat jak piszemy o programowaniu MCU.

W embedded prawo Parkinsona tez dziala, ludzie wstawiaja
Raspberry Pi z 1GB RAM i 1GHz zegarem w miejsca gdzie
lepiej by dzialal MCU z 16k flashu i zegarem kilka-kilkadziesiat
MHz.

Wracajac do C++ na MCU: jest sporo przykladow programikow
ktore robia proste ale pozyteczne rzeczy napisanych w C++
gdzie kod jest ponizej 3 kB. Oczywiscie w 3 kB kodu
wynikowego nie da sie wrzucic wszyskich ficzerow C++,
ale wlasnie o to chodzi: uzywasz to co jest potrzebne
a reszte pomijasz. No i sa pulapki: jak Ci przyjdzie
do glowy zlinkowac program z libstdc++ to masz ponad
100kB w plecy...
--
Waldek Hebisch
Marek
2021-11-18 11:14:32 UTC
Permalink
Post by a***@math.uni.wroc.pl
To ze programy dzialaja powoli jest niezalezne od jezyka. Po
Tak, to wiemy. Cały czas zwracam uwagę, że nie krytykuję C++ tylko
programy w nim napisane źle.
Post by a***@math.uni.wroc.pl
prostu tak dziala prawo Parkinsona: programy zuzywaja cale
dostepne zasoby (w tym czas). Jedyny sposob na powiekszenie
szybkosci to "zmniejszenie" zasobow, tzn. gdyby userzy sie
zbuntowali i odmowili uzywania nowych programow.
Ależ ja o tym mówię od 40 lat, pierwsze prawo konsumenta: nie
konsumować! Ale to niestety nie działa. Przez to mamy DRM i inne
upierdliwości. Gdyby ludzie zaprzestali kupować sprzętu z DRM
musiałoby to zniknąć z rynku.
Post by a***@math.uni.wroc.pl
Przy tym wymagania stawiane desktopowym programom mocno
sie roznia od embedded, wiec to co sie dzieje na desktopach
to jest nie na temat jak piszemy o programowaniu MCU.
Oczywiście, moja dygresja dotyczy tego co się dzieje w desktopach.
--
Marek
ptoki
2021-11-18 15:10:10 UTC
Permalink
Post by a***@math.uni.wroc.pl
W embedded prawo Parkinsona tez dziala, ludzie wstawiaja
Raspberry Pi z 1GB RAM i 1GHz zegarem w miejsca gdzie
lepiej by dzialal MCU z 16k flashu i zegarem kilka-kilkadziesiat
MHz.
Tak, ALE! :)
Wyjasnienie nizej.
Post by a***@math.uni.wroc.pl
Wracajac do C++ na MCU: jest sporo przykladow programikow
ktore robia proste ale pozyteczne rzeczy napisanych w C++
gdzie kod jest ponizej 3 kB. Oczywiscie w 3 kB kodu
wynikowego nie da sie wrzucic wszyskich ficzerow C++,
ale wlasnie o to chodzi: uzywasz to co jest potrzebne
a reszte pomijasz. No i sa pulapki: jak Ci przyjdzie
do glowy zlinkowac program z libstdc++ to masz ponad
100kB w plecy...
Najsmieszniejsze w tym jest to ze o ile zrobienie sobie termostatu rzeczywiscie zajmie te 3kb (lub pewnie mniej) nawet w arduino przy uzyciu gotowych bibliotek ALE
bardzo czesto tworca sobei zazyczy kontrole i monitoring zdalny. Czyli wifi, http(s), jakas autoryzacja, jakies kolejki, moze scheduler zachowan...
I program nie miesci sie w attiny.
Nie miesci sie w byle atmega bo trzeba by przynajmniej taki z ethernetem.
Mozna zrobic na esp8266 czy podobnych rozwiazaniach ale jak malina kosztuje to samo, ma ssh, ogarnia ssl, moze hostowac baze, moze miec zabbixa czy inna grafane to czemu nie uzyc?

Smieszne jest to ze z punktu widzenia hobbysty to dobry kierunek. Z punktu widzenia gigantow tez!

I dlatego ludki chca i C++ i arduino i maline bo kosztuje podobnie, a pozwala na wiecej.

A ludzie tacy jak w tym watku, broniacy minimalizmu (lub atakujacy rozrzutnosc) czy jeszcze inaczej motywowani to w praktyce mniejszosc.
Maja slusznosc w pewnych aspektach ale ogolny trend od dawna byl taki ze minimalizm nie poplaca.

Sprawdza sie czasem (minecraft, notepad++, esp8266) ale ogolnie preferencja jest aby miec wiecej za te same pieniadze. Fakt ze to powoduje pewne problemy (zawodnosc, wiecej wektorow ataku itp) jednak nie zmienia tego trendu mimo ze to calkiem wazne aspekty.
Marek
2021-11-17 11:58:08 UTC
Permalink
On Tue, 16 Nov 2021 11:51:53 +0100, "Grzegorz Niemirowski"
Post by Grzegorz Niemirowski
http://youtu.be/PDSvjwJ2M80
Przecież ten koleś nie ma.pojecia o C. Do testu szybkości używa
malloc? Zamiast size_t używa unsingned i? Ręcznie wypełnia tablicę
zamiast memset??? Odechciało się dalej tego oglądać troszkę....
--
Marek
Pcimol
2021-11-16 17:30:20 UTC
Permalink
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).
Atlantis
2021-11-16 18:30:42 UTC
Permalink
Post by Pcimol
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.
Pcimol
2021-11-16 17:22:41 UTC
Permalink
Post by heby
Post by Bool
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.
Grzegorz Niemirowski
2021-11-17 09:53:53 UTC
Permalink
Post by Pcimol
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/
Astralny Rębajło
2021-11-19 12:37:12 UTC
Permalink
Post by heby
Post by Bool
Dodam tylko że Arduino mnie kompletnie nie interesuje.
To jakiś pogląd religijny?
Narzędzie jak każde inne. Dobre do tego do czego zostało stworzone.
Nigdy nie korzystałem, ale ostatnio zaszła taka potrzeba.
Trza było umieścić wsad grbl do atmegi, poszło prawie gładko.
Z punktu widzenia osób które nie chcą się doktoryzować z :
- języka c, konfiguracji IDE
- obsługi programatora
- softu do projektowania pcb
- trawienia, wiercenia, zakupów każdej drobnej części osobno w celu zaświecenia diodą

... ten soft jest idealny:) Zaoszczędza dobrych kilka dni pracy.


Tak poza tym najtańsze pice są tańsze od najtańszych avr.
Bool
2021-11-15 07:37:32 UTC
Permalink
Bo to już nie te czasy, że można sobie "wybierać".
Jestem tego w pełni świadomy. To jest właśnie powód dla którego rozglądam się za czymś nowym.
Loading...