AVR po latach

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.

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.

środa, 17 listopada 2021 o 19:37:59 UTC-6 snipped-for-privacy@math.uni.wroc.pl napisał(a):

Tak, ALE! :) Wyjasnienie nizej.

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.

Robiłem to dziesitki razy, na tej grupie, trzeba było uważać.

Np taki:

foo() { DisableInterruptsInThisScope guard;

No to masz RIIA.

Drugi. Kompiluje się g++. Pierwszy też, ale drugi jest *niewątpliwie*.

Oba skompilują tak samo.

Dlatego postulatem nie jest uzywanie g++ tylko pisanie w C++.

Tfu, RAII.

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

No i właśnie nie rozumiałeś, więc C++ nie dla Ciebie.

Celem tego kodu była eliminacja BIAŁKA z procesu tworzenia się bugów.

W twoim przypadku, białko zostało i niczym się to nie rózni od ręcznego pisania sei(); return;.

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

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

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

Co wydarzy się 3x rzadziej, niż w twom ręcznie wydziarganym kodzie.

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,

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.

Nie, nie dostałem. :) Ty tego białka nie wyeliminowałeś, tylko je przesunąłeś w inne miejsce.

Ech, czyli jednak dyskutowanie o prawdopodobieństwach. Szkoda.

Bo ty tak mówisz?

Czy to miganie diodą, czy sterowanie promem kosmicznym, w obu przypadkach scope nie powinien być tak rozległy, że autor przestaje nad nim panować.

O, czyli może jednak będzie konstruktywnie. No to dajesz.

Mateusz

Zmniejszyłem je. Z wielu miejsc usunąłem. Na tym polega proces eliminacji białka.

Branża języków programowania dyskutuje własnie o tym, kiedy mowa o językach programowania. Szkoda, mogli by rozmawiać o dupach.

Tak, z mojej grupy byś wyleciał, dodatkowo z solidym kopniakiem za niepojmowanie podstaw bezpieczeństwa.

Ale jest rozległy. I co teraz? Oferujesz "gapmiy się bardziej wnikliwie". Ja oferuje "upewnijmy się, że to co można, da się zautomatyzować".

Już było, tylko jesteś niepełnosprytny.

A ile płacisz?

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

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.

Problem że ten "bardziej cywilizowany sposób", 40 lat temu, to było goto w BASICu. I z tym kłopot największy.

Za pomocą tego magicznego guard? Wmówiłeś to sobie, uprawiasz tylko kreatywną księgowość.

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

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

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

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.

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.

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.

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.

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?

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.

To dość dawno, p.m.e. wnikliwie czytam pewnie z rok czy dwa.

Hmm, podałeś piękny przykład socjalizmu - ustroju dzielnie i skutecznie (chyba jednak nie) zwalczającego problemy, które nie występują w kapitaliźmie. Mechanizm RAII stosowany po to, by "usunąć kategorię bugów", która pojawia się w wyniku kodowania, które nie jest nawet strukturalne. Wiem że BASIC ryje beret nieodwracalnie... I wiem też, że w C można pisać programy FORTRANowe. Sztuka i nauka w tym, by tego nie robić.

Zaś takie cli() na początku i sei() na końcu funkcji można sobie zrobić za pomocą __attribute__. Tylko co, jeśli przerwania musisz włączyć w połowie funkcji? Np. w ISR w programie bardziej skomplikowanym niż miganie diodą? Pewnie dałoby się to zrobić lepiej - ale urządzenie musi iść na obiekt jutro, bo za pół roku to takie oprogramowanie zrobi też Hindus, a może i Chińczyk.

Słabe. Jeszcze bym chciał coś lepszego.

To może odwrotnie - czy drugi nie skompiluje się gcc? Przecież nie było tam nawet: for(int i = 0 ; i < 100 ; ++i ) Czym one się w ogóle różnią? Pewnie tym, co zwróci $ echo $_ Ciekawe co będzie w tym drugim przypadku. Nie powinno być: void main() {} ?

Rozwiązywałe kiedyś test 50 pytań z Javy i C++ u takiej jednej fajnej "rekruterki" (rozpraszała, podobnie jak taka jedna fajna z zakładu metod matematycznych informatyki na egzaminie z prawdopodobieństwa ;) Java była OK, za co ją uwielbiam (ciekawe czy jest gcj na AVR?), C++ koszmarne - ale to Twoje jest jeszcze trudniejsze.

Tak samo albo nie. Jakoś to mocno "akademickie" - czy dobrze odbieram "grupę" i "review"? I to jeszcze akademickie młodego pokolenia, co pierwszy komputer miało z windows 95...

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

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

Tak, od ~10 lat minimum.

Ten przykałd rozwiązuje problem powszechnie występujacy w programach C w embedded, czyli tansapcyjności flag. Przerwań, bo łatwe, ale masy innych tez łatwo tym osiągnać.

Mechanizm RAII jest używany tam, gdzie jest przydatny. Tu jest przydatny.

Tak, dlatego eliminujemy go z C i pojawia się potrzeba użycia czegoś lepszego. C++ jest za darmo.

Wiec wyjasnij to embedowcom, u których goto jest podstawą wzroców programowania.

A takie "enableDisplay()" i "disableDisplay()" też?

Przyczepiłeś się użycia w przypadku 1, ale nie widzisz pozostałych N-1 przypadków, gdzie wzorzec projektowy ...scoped... jest znacznie wygodniejszy i bezpieczniejszy niż debilizmy z goto.

To masz dodatkowy scope w połowie funkcji.

Jesli przerwania musisz wyłączyć pomiędzy scopeami funkcji, to prawdopodobnie masz coś mocno spieprzone we flow algorytmu i niewiele tu można pomóc, musi wystarczyć modlitwa.

scope stosuje się własnie w programach znacznie bardziej skomplikowanych niż miganie diodą. Aby w ogóle dało się je utrzymać dalej, niż etap migania diodą.

Mówisz o pisaniu na odpierdol? Łopanie, to oczywiscie goto i nastepny.

Poważne oprogramowanie przeszło by review, testy automatyczne, statyczną analizę, analizę formalną, linting, akceptację SQA. Ale na odpierdol nie, ja w ogole nie mówie o takiej kategorii oprogramowania. Być może to miganie diodą było by w respiratorze, więc wtedy też.

Choć nawet w tym na odpierdol wolałbym RAII, niż 30 goto.

To proponuj.

Niczym istotnym. Właśnie odkryłeś że przejście na C++ jest za darmo. A mimo to dev 60+ broni się rękami i nogami, wymyślając co chwile nowe debilizmy do obrony epoki kamienia goto-wanego.

Nie. Nie powinno. Będzie zero. Gwarantowane. ISO 9899:201x 5.1.2.2.3

Jak sobie wyobrażasz heap na AVR? Java jest językiem, w którym cieżko się piszę bez allokacji na heapie. Innymi słowy nie jest możliwa do użycia na AVR w sposób pełny. Co innego C++ - w nim używania heapu nie ma obowiązku.

Istnieją podzbiory Javy np. na karty SIM, ale nie chciałbyś w tym pisać, to jest żenujące i przypomnia tortury.

To są podstawy C++. Nie ma nic prostszego niż RAII.

"grupa" i "review" nie mają nic wspólnego z "akademickością". Są normalnymi narzędziami używanymi przez prawie wszystkie firmy zajmujące się pisaniem programów, a nie dicking around.

Bywają "akademickości" gdzie o nich nie słyszano i dalej uczą Delphi, dajac na koniec magistry.

Myślę, że przeoczyłeś jakieś ~40 lat rozwoju informatyki.

Masz 30 miejsc wyjścia z funkcji? No, to faktycznie przykładny kod.

#define return goto gameover

albo

#define return TUTAJ_UZYWAMY_GOTO

albo

static void func_internal() { [...] }

void func() { _disable(); func_internal(); _enable(); }

Ale znowu - ja nie mam zamiaru wykłócać się z usenetowym krzykaczem. Wskazuję tylko, że innowacja którą przedstawiasz jest bardzo dyskusyjna. I nie jest to z mojej strony krytyka C++ (którego znam słabo), tylko podanego przykładu. Zapytałem o jakiś poważniejszy przykład, ale wolałeś się obrazić.

Patrz wyżej.

No fajnie, ale to też nie ma nic wspólnego z C++.

Już któryś raz zamiast pokazać kod stosujesz argumenty ad personam. To świadczy zarówno o tobie, jak i o idei którą tak zaciekle bronisz.

Mateusz

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.

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

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.

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

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.

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.

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.