Skocz do zawartości

Co w Arduino piszczy? cz.1


Elvis

Pomocna odpowiedź

html_mig_img

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.

  • Lubię! 1
Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

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.

Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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.

Link do komentarza
Share on other sites

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

Link do komentarza
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.