AVR po latach

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.

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

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.

Atlantis snipped-for-privacy@wp.pl napisał(a):

Podpisuję się pod wszystkim :) Przy okazji polecam obejrzeć bardzo ciekawą prezentację pokazującą, że C++ może dać mniejszy kod niż C.

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.

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.

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 snipped-for-privacy@b.com napisał(a):

Niektórzy używają nazw Arduino i AVR zamiennie.

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.

To czemu 99% softu napisanego w C++ dziala wolno? Nie umieją pisać poprawnie?

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 snipped-for-privacy@fakeemail.com napisał(a):

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

Proble nie polega na pasywnym ignorowaniu tylko aktywnym atakowaniu z powodu ignorancji. Było tez i na tej grupie.

Podaj przykład takiego softu, który jest napisany w *czymś* i C++ i w tym drugim wypadku działa wolno.

Ja podam:

main.c: int main() { int i; for( i = 0 ; i < 100 ; ++i ) foo();

return 0; }

main.cpp: int main() { int i; for( i = 0 ; i < 100 ; ++i ) foo(); }

Ten drugi, twierdzisz, jest napisany wolno?

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.

Progrmujesz zawodowo w C++?

, bo kogo innego?? KDE/plasma

Masz KDE Plasma napisany w C do porównania?

Bo to trudny język. Dlategpo nie dasz go 60-latkowi który pół życia pisał w Keilu na 8051.

Akurat linkowanie z stdc++ raczej jest mało uzyteczne w embedded, ale w przypadku KDE raczej nie jest powodem spowolnień.

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.

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