Co w Arduino piszczy? cz.1

[Elvis]

Wakacyjny upał ma czasem swoje zalety. Mając dosyć urlopu można poświęcić chwilę lub dwie na hobby, a nawet napisać mały artykuł. Niby wszyscy znają  Arduino, ale czym ono jest? Jak zostało zaprojektowane i skonfigurowane? Jaki jest jego związek z C oraz C++? Mając wolną chwilę postanowiłem zagłębić się trochę w kodach i dokumentacji. Do czego dotarłem?

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

[marek1707]

"Bez wzmacniacza, pobór prądu przez diodę zakłócałby komunikację – wzmacniacz sprawia, że dioda działa normalnie, a linia SCK nie jest obciążana. "

Moim zdaniem ten właśnie szczegół nie jest dobrze rozwiązany. Przecież domyślnie porty AVR są wejściami a to znaczy, że oba tranzystory wyjściowe pinu nie działają i na dodatek wewnętrzny rezystor podciągający jest wyłączony. To powoduje, że dopóki ktoś nie zaprogramuje linii SCK na wyjście (lub nie włączy podciągania) wejście wzmacniacza wisi w powietrzu. W zależności od egzemplarza wzmacniacza diodka LED może wtedy świecić, nie świecić lub migotać sobie dowolnie. Co więcej, dotknięcie palcem pinu SCK a nawet zbliżenie ręki może dawać objaw zapalania lub szybkiego (50Hz) mrugania LEDa. Nawet tutaj na Forum mieliśmy już pytania w tej sprawie. Zwykły opornik 100-220k do masy, który absolutnie nie obciążałby portu - rozwiązałby problem pochłaniając przypadkowy prąd polaryzacji wejścia wzmacniacza.

Projektanci Arduino mieli dobre intencje, pewnie przeczytali coś o wzmacniaczach, ale tylko na schemacie wiszące w powietrzu linie mają 0V. W rzeczywistości.. przydaje się czasem ktoś w zespole z pojęciem o sprzęcie...

Fajny pomysł na zajrzenie pod podszewkę systemu. Ciekaw jestem dalszych artykułów i Twojego zdania o tym, co Arduino robi z naszym ślicznym kodem źródłowym zawierającym przecież tylko setup() i loop(). Oglądanie tego po preprocessingu może być interesującą lekcją wyjaśniającą wiele dziwnych problemów z kompilacją co bardziej skomplikowanych programów.

[Elvis]

Racja, dziękuję Marku za uwagi Mnie tak zabolało wykorzystywanie wzmacniacza jako komparatora, że nawet nie zwróciłem uwagi na wiszące wejścia. W każdym razie wydaje mi się ciekawe popatrzeć na Arduino trochę dokładniej, nie tylko podłączyć i cieszyć migającą diodą. Ja zajmuję się bardziej programowaniem niż sprzętem, wiec to co mnie najbardziej boli to mity dotyczące programowania i na nich chciałem się skupić. Jednak nie można dobrze programować systemów wbudowanych, nie rozumiejąc jak działa sprzęt - stąd wstęp, chociaż ogólnie, omawiający hardware.

[Czaro]

Świetny artykuł (y)

Ciekawi mnie porównanie tych samych kodów napisanych w framework'u ardu oraz C i ich objętości

Co do użycia wzmacniacza jako komparatora w jaki sposób możemy to zastąpić by stało się wydajniejsze?

[#R2D2#]

Świetny artykuł, zapowiada się bardzo ciekawa seria. Taki kurs Arduino dla zaawansowanych.

[Elvis]

Czaro okazuje się że Arduino używa gcc, czyli standardowego kompilatora C/C++. Więc jedyna różnica między programami może wynikać z:

1) użycia C++

2) bibliotek

Kompilatory C++ bywają mniej wydajne niż czystego C, ale w przypadku prostego programu nie powinno być dużej różnicy. Natomiast tym co istotnie wpływa na wielkość i wydajność programu są niewątpliwie użyte biblioteki. Jednak porównywanie programów nie jest łatwe - wszystko będzie zależało od tego jaki program testowy napiszemy.

[deshipu]

Kompilatory C++ bywają mniej wydajne niż czystego C

Chyba wręcz przeciwnie. Nie tylko C++ ma sprytniejsze optymalizacje, ale jeszcze kompilator ma z języka więcej informacji, więc może więcej zrobić.

[szyss]

Racja, dziękuję Marku za uwagi Mnie tak zabolało wykorzystywanie wzmacniacza jako komparatora....

Nie wiem czego się tak czepiacie zastosowania wzmacniacza operacyjnego zamiast komparatora w takiej prostej aplikacji? Wzmacniacz w tym układzie nie będzie gorszy od komparatora. Komparator oczywiście jest zoptymalizowany do swojej pracy i lepszy od wzmacniacza operacyjnego w roli komparatora ale do aplikacji specjalizowanych i szybkich. Tutaj nie ma to znaczenia, więc to nie jest błędem projektowym.

Do kolegi "deshipu".

"Chyba wręcz przeciwnie. Nie tylko C++ ma sprytniejsze optymalizacje, ale jeszcze kompilator ma z języka więcej informacji, więc może więcej zrobić."

Ciekawa teoria, może tobie jest wygodniej pisać w C++ i się wydaje że wszystko jest super zoptymalizowane, ale jak by nie było to każda architektura ma swoje instrukcje i jest przetrawiane na kod maszynowy. To co tobie się wydaje za optymalne, dla architektury procesora (mikro) może być porażką po kompilacji. Dla aplikacji "kluczowych" jest język C z ograniczeniami, aby wszystko działało tak jak ma a ty tu wyskakujesz o C++ jako super optymalny https://en.wikipedia.org/wiki/MISRA_C

Wszystko na temat, pozdrowionka

[Elvis]

szyss, niestety nie jestem ekspertem jak chodzi o układy analogowe, ale mam nadzieję że Marek napisze więcej o różnicach między wzmacniaczami operacyjnymi, a komparatorami.

Z mojej strony mogę tylko powiedzieć, że w kilku całkiem mądrych książkach spotkałem się z informacjami, że pomimo identycznego symbolu obu elementów wcale nie można ich zastępować bezkarnie. O ile pamiętam główna różnica dotyczyła zachowania układów przy znacznym napięciu różnicowym - wzmacniacz jest projektowany do pracy przy napięciu różnicowym bliskim zeru. W przypadku podłączenia jako komparator może zachowywać się bardzo nietypowo, np. zanegować sygnał na wyjściu albo "zatrzasnąć" się w skrajnym stanie. Niestety nie mogę teraz sprawdzić gdzie takie mądrości wyczytałem, ale jeśli będzie zainteresowanie to mogę dołączyć linki do literatury - ale dopiero jak wrócę do domu.

deshipu, pierwszy raz słyszę żeby kompilator C++ dawał wydajniejszy kod niż C, ale może coś się zmieniło ostatnimi laty. W sumie byłoby ciekawe porównać jakość kodu w przypadku gcc - może ktoś szukać fajnego tematu na inżynierkę?

Z mojego doświadczenia mogę tylko zapewnić, że w C++ o wiele łatwiej o - niejako niechcący, przygotowanie potwornie nieefektywnego kodu. Nie tak dawno pracowałem przy projekcie, który właśnie wykorzystywał C++ w miejsce starszego programu w C. Moment nieuwagi i kod nie mieścił się w pamięci biednego STM32. W C chociaż byłoby widać że kodu przybywa, a kompilator C++ wygenerował kod niemal bezboleśnie.

[deshipu]

deshipu, pierwszy raz słyszę żeby kompilator C++ dawał wydajniejszy kod niż C, ale może coś się zmieniło ostatnimi laty. W sumie byłoby ciekawe porównać jakość kodu w przypadku gcc - może ktoś szukać fajnego tematu na inżynierkę?

Z mojego doświadczenia mogę tylko zapewnić, że w C++ o wiele łatwiej o - niejako niechcący, przygotowanie potwornie nieefektywnego kodu. Nie tak dawno pracowałem przy projekcie, który właśnie wykorzystywał C++ w miejsce starszego programu w C. Moment nieuwagi i kod nie mieścił się w pamięci biednego STM32. W C chociaż byłoby widać że kodu przybywa, a kompilator C++ wygenerował kod niemal bezboleśnie.

No ja się właśnie dziwię, bo z tego co pamiętam jak był taki straszny hype na C++ i wszyscy go reklamowali, to właśnie jednym kluczowych argumentów było to, że dzięki tym wszystkim dodatkowym "const" i dzięki sprytnemu systemu szablonów i unikaniu systemu makr kompilator ma więcej informacji i może dużo więcej optymalizacji zastosować, podczas gdy kompilator C *musi* wygenerować dokładnie taki kod, jaki mu napisałeś, bo nigdy nie wie co miałeś na myśli. No ale to było ładnych parę lat temu, nie wiem, może kompilatory C jakoś od tego czasu nadgoniły.

Oczywiście to co piszesz o napisaniu kiepskiego programu "niechcący" jest prawdą dla każdego środowiska -- w każdym języku da się napisać fatalny kod.

Na inżynierkę to chyba jestem już trochę za stary.

Ciekawa teoria, może tobie jest wygodniej pisać w C++ i się wydaje że wszystko jest super zoptymalizowane, ale jak by nie było to każda architektura ma swoje instrukcje i jest przetrawiane na kod maszynowy. To co tobie się wydaje za optymalne, dla architektury procesora (mikro) może być porażką po kompilacji. Dla aplikacji "kluczowych" jest język C z ograniczeniami, aby wszystko działało tak jak ma a ty tu wyskakujesz o C++ jako super optymalny https://en.wikipedia.org/wiki/MISRA_C

Wszystko na temat, pozdrowionka

Um, no chyba nie bardzo wszystko na temat. Tak naprawdę, to bym powiedział, że trochę taki non-sequitur. Co ma do rzeczy to, że każdy procesor ma swoje instrukcje, skoro każdy ma też swój kompilator zarówno C jak i C++ pod te instrukcje właśnie zoptymalizowany? To nie jest tak, że dla C używam kompilatora natywnego, a do C++ kompilatora z x86. I jeden i drugi będzie mieć optymalizacje specyficzne dla danej platformy. C++ po prostu będzie mieć ich więcej, bo język pozwala na wpisanie większej ilości informacji o tym co tak naprawdę chcesz zrobić, dzięki czemu kompilator ma większe pole do popisu. Oczywiście to, że kompilator *może* więcej optymalizacji zastosować nie znaczy, że na każdej platformie musi. Szczególnie jeśli jest to gcc, a nie kompilator dostarczony przez producenta platformy -- często nikomu się nie chciało optymalizacji pisać, szczególnie jak platforma jest bardzo egzotyczna. Co nie zmienia faktu, że potencjał jest.

Drugi non-sequitur, to link do strony o płatnym standardzie, którego nawet nie mogę przeczytać. Za to w trzecim akapicie tej strony jest informacja o istnieniu tego samego standardu dla C++, więc nie wiem co to ma udowadniać. Jeśli to wszystko na ten temat od ciebie, to jest to żałośnie mało.

[Harnas]

Próbowałem ostatnio przepisać parę funkcji w C na STM32 co jednej klasy C++. W SW4STM32 po prostu "skonwertowałem" projekt na C++ i dodałem nową klase. Samo dodanie jednej klasy spowodowało wzrost objętości kodu o jakieś 15KB, a stworzenie obiektu za pomocą "new" zjadało 40KB (na szczęście dało się stworzyć obiekt poza pętlą główną jako globalny). Przerzuciłem potem obsługę EEPROMA do C++ i przybyło kolejne 15KB, potem następna klasa, i z 55KB obecnie miałem jakoś 115KB więc stwierdziłem że to nie ma sensu i wróciłem do wersji na czystym C. Dodam że wszystkie klasy zostały użyte tylko raz (po jednym obiekcie z każdej klasy).

[deshipu]

Wiesz, że używanie klas nie jest w C++ obowiązkowe?

[Elvis]

A jakie są plusy C++ w porównaniu z C jeśli nie używa się obiektów?

[deshipu]

Nie mam pojęcia, nie znam się na C++. Ale dużo ludzi używa, więc jakieś muszą być.

[Maniek93]

Apropo c vs c++