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

Thu Nov 18, 2021 4:09 pm   

On Thu, 18 Nov 2021 06:52:45 -0800 (PST), Dawid Rutkowski wrote:

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.

Thu Nov 18, 2021 4:52 pm   

środa, 17 listopada 2021 o 20:32:15 UTC+1 heby napisał(a):

Napisz choć kilka przykładów.
Dla ustalenia uwagi w porównaniu do C, żeby nie wynajdywać koła.


Który? I dlaczego?


No to którym kompilatorem "lepiej" się skompiluje program napisany w C - kompilatorem C czy C++?

Thu Nov 18, 2021 5:10 pm   

środa, 17 listopada 2021 o 19:37:59 UTC-6 anti...@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.

Thu Nov 18, 2021 5:22 pm   

On 18/11/2021 15:52, Dawid Rutkowski wrote:

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

Np taki:

foo()
{
DisableInterruptsInThisScope guard;

[...]
return;
[...]
return;
[...]
return;
}


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

Thu Nov 18, 2021 5:27 pm   

On 18/11/2021 17:22, heby wrote:

Tfu, RAII.

Thu Nov 18, 2021 5:32 pm   

2021-11-18 o 17:22 +0100, heby napisał:

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

Thu Nov 18, 2021 5:47 pm   

On 18/11/2021 17:32, Mateusz Viste wrote:

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

Thu Nov 18, 2021 6:01 pm   

2021-11-18 o 17:47 +0100, heby napisał:

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

Thu Nov 18, 2021 6:12 pm   

On 18/11/2021 18:01, Mateusz Viste wrote:

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.

Thu Nov 18, 2021 6:28 pm   

2021-11-18 o 18:12 +0100, heby napisał:

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

Thu Nov 18, 2021 6:38 pm   

On 18/11/2021 18:28, Mateusz Viste wrote:

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?

Thu Nov 18, 2021 6:41 pm   

On 18.11.2021 18:12, heby wrote:

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

Thu Nov 18, 2021 6:45 pm   

On 18/11/2021 18:41, Piotrek wrote:

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.

Thu Nov 18, 2021 7:19 pm   

2021-11-18 o 18:38 +0100, heby napisał:

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

Thu Nov 18, 2021 7:40 pm   

On 18/11/2021 19:19, Mateusz Viste wrote:

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.