Programowanie mikrokontrolerów w czystym C - jaka różnica względem Arduino?

[tomecki]

Czy programowanie mikrokontrolerów np. atmel w czystym C jest dużo bardziej skomplikowane od arduino?

Czy warto się tym zająć? Czy jest problem z komunikacją z sensorami, czy wystarczy wgrać odpowiednie biblioteki jak do arduino i nie będzie problemów?

Jakie są plusy, minusy takiego rozwiązania?

[Treker (Damian Szymański)]

@tomecki temat rzeka, każde rozwiązanie ma swoich zwolenników. Wszystko zależy głównie od tego co chcesz robić. Główny "problem", który napotkasz podczas pisania w czystym C to brak gotowców i bibliotek, większość rzeczy trzeba zrobić samodzielnie. Wymaga to biegłego korzystania z not katalogowych, operacji na rejestrach itd. Początkujący często się wtedy zniechęcają 😉 Jeśli chcesz odejść od Arduino to w tym momencie lepszym wyborem byłoby chyba wybranie STM32 - widziałeś nasze kursy dotyczące tej tematyki? Poczytaj jak to wygląda to zobaczysz czy takie podejście jest odpowiednie dla Ciebie. Warto zerknąć na przykład tutaj: Kurs STM32 F1, migracja na HAL – #1 – wstęp, spis treści.

Powiedz też coś więcej na temat powodów Twojej chęci odejścia od Arduino - łatwiej będzie coś podpowiedzieć 😉

[tomecki]

Cytat

Powiedz też coś więcej na temat powodów Twojej chęci odejścia od Arduino - łatwiej będzie coś podpowiedzieć

Nie chodzi o odejście o arduino, lecz zgłębienie tematu programowania mikrokontrolerów. Kiedyś pisałem programy w asemblerze, więc taki poziom mi odpowiada. 

W zapytaniu chodziło mi o to, czy biblioteki sensorów dostarczone do arduino będą działać w czystym C. Z tego co piszesz, to raczej będzie problem z tym, więc to zniechęca. 

W takim tutorialu jak poniżej programowanie nie jest mocno skomplikowane. 

 

[marek1707]

"Do or do not, there is no try."

Yoda

[Polecacz 101]

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

[Treker (Damian Szymański)]

2 godziny temu, tomecki napisał:

Kiedyś pisałem programy w asemblerze, więc taki poziom mi odpowiada. 

Jeśli masz doświadczenie na poziomie ASM to na pewno dasz sobie radę, w takim razie działaj 😉

[Matthew11]

2 godziny temu, tomecki napisał:

W zapytaniu chodziło mi o to, czy biblioteki sensorów dostarczone do arduino będą działać w czystym C. Z tego co piszesz, to raczej będzie problem z tym, więc to zniechęca. 

Wzięte z półki, raczej na pewno nie zadziałają, przynajmniej nie od razu. Arduino to od dawna już nie tylko płytki i biblioteki ale ogromny framework jak inne, gdzie masz setki różnych interfejsów i określonych API. Jeśli twój procesor ma wsparcie Arduino (ktoś napisał drivery), to po dołączeniu wszystkich zależności i bibliotek do peryferiów, które ta konkretna biblioteka potrzebuje raczej powinno ostatecznie zadziałać. Tylko właśnie problem w tym, że tych zależności może być sporo, które mogą wymagać kolejnych. Inna sprawa to fakt, że większość z tych bibliotek jest napisana w C++.  

[Gość]

22 minuty temu, Matthew11 napisał:

Tylko właśnie problem w tym, że tych zależności może być sporo, które mogą wymagać kolejnych. Inna sprawa to fakt, że większość z tych bibliotek jest napisana w C++. 

I dlatego właśnie działanie programu napisanego z pominięciem arduino jest na ogół wiele szybsze i wydajniejsze ale coś za coś, arduino jest muliste ale wygodne i dlatego jest takie popularne. Nic nie stoi jednak na przeszkodzie aby miksować sobie kod dowolnie, w krytycznych czasowo miejscach wstawiać wstawki asm lub przerabiać napisane w C++ biblioteki na C, albo jeszcze oszczędzać pamięć rezygnując z zasobożernych operacji typu dzielenie, liczby zmiennoprzecinkowe lub nadużywanie zmiennych volatile lub static, gdzie się tylko da ale to wymaga czasu. Więc coś za coś, pod arduino masz wszystko na już co jest okupione często nawet 5-krotnie większym zużyciem pamięci.

[ethanak]

1 godzinę temu, atMegaTona napisał:

arduino jest muliste ale wygodne

Przesadzasz. Dobrze napisane biblioteki na Arduino wcale nie są muliste i nie wiem, czy znalazłoby się na tym forum wielu takich co potrafiliby napisać lepiej (oczywiście pomijając jeden znany wyjątek na literę e).

Muliste są owszem programy nadużywające co poniektórych konstrukcji - ale tu też nie można porównywać np. wydajności klasy String z biblioteki C++ Arduino z czymś, czego w C w ogóle nie ma.

Już słyszę argument (wiele razy powtarzany): "W moim programie w C/ASM ustawienie pinu na 1 czy 0 zajmuje jedną instrukcję, a w Arduino ileśtam".

A to przecież absolutna nieprawda. Porównuje się kod przeznaczony np. do ustawienia n-tego bitu na m-tym porcie (gdzie n i m są stałymi, a do zerowania bitu służy zupełnie inny kod) z kodem uniwersalnym, gdzie n i m trzeba sobie przeliczyć na numer portu i numer bitu a operację ustawienie/kasowanie wykonać na podstawie wartości argumentu funkcji. Tak samo w Arduino możesz zrobić sobie asemblerową wstawkę zawierającą tę nieszczęsną jedną instrukcję czy też skorzystać z digitalWriteFast (który robi dokładnie to samo, tyle że pamięta za Ciebie jaki bit na jakim porcie odpowiada jakiemu pinowi), a w C napisać funkcję uniwersalną typu digitalWrite (choćby dla uproszczenia na ATmegę 328 - polecam jako ćwiczenie).

I tak jest z 99% podobno "mulistych" bibliotek w Arduino...

Owszem, zgodzę się: jest dużo bibliotek napisanych po prostu źle. Ale z drugiej strony ta "złość" bywa czasami pozorna.

Weźmy choćby popularną bibliotekę Adafruit_GFX. Przeglądając kod możemy odnieść wrażenie, że kod jest fatalny - bo każda co bardziej skomplikowana operacja wywołuyje w jakichś pętlach writePixel (czy coś podobnego). Tyle - że ta biblioteka nigdy nie jest stosowana samodzielnie, zawsze służy jako klasa na podstawie której definiuje się drivery dla konkretnych wyświetlaczy - a dopiero tam zależnie od możliwości wyświetlacza stosuje się szybsze - chociaż specjalizowane - metody.

Tak że każdego co narzeka na mulistość Arduino mogę porównać do słabego pływaka, co narzeka że woda jest za rzadka.

Edytowano Grudzień 11, 2019 przez ethanak

[Gość]

Dnia 11.12.2019 o 13:13, ethanak napisał:

Tak że każdego co narzeka na mulistość Arduino mogę porównać do słabego pływaka, co narzeka że woda jest za rzadka.

Przekonująco o tym opowiadasz ale nawet Ty wiesz, że oprogramowanie napisane w j. C jest dużo szybsze i wydajniejsze od spełniającego te same funkcje oprogramowania w C++ a widać to szczególnie dobrze na małych platformach gdzie zasoby są ograniczone. Różnica jest natomiast tego typu, że w C++ pisze się dużo wygodniej więc więcej czasu zajmuje napisanie tego samego kodu w C który jest mniej elasyczny. Niektórzy twierdzili nawet, że C++ nie nadaje się do programowania mikrokontrolerów ale to zależy też czego się wymaga. Dostępny na rynku sprzęt również jest coraz lepszy więc takie twierdzenia zaczynają być przestarzałe tak jak AVR z 30 letnim stażem. 

Jednak, kiedy się używa starego sprzętu chcąc wykorzystać wszystkie jego możliwości należy stosować metody do tego odpowiednie czyli w tym wypadku j. C będzie znacznie lepszym rozwiązaniem.

[ethanak]

Ale wiesz, że zacytowane zdanie poza kontekstem jest bez sensu? Pisałem  bibliotekach, a nie o języku.

[tomecki]

Brak oprogramowania do sensorów jest ogromnym minusem takiego rozwiązania. 

Prędkość działania w C i C++ jest praktycznie taka sama lub lepsza w c++. Najszybsze działanie będzie w asemblerze.

Przy wyborze platformy liczy się też to, jak długo trzeba pisać dany kod. Dostępność bibliotek, gotowych rozwiązań, popularności jest też wyznacznikiem z jakiego rozwiązania należy korzystać. Np. w programowaniu obecnie lepiej korzystać z C# niż z c++, chociaż c++ jest znacznie szybsze w działaniu. 

[ethanak]

1 godzinę temu, tomecki napisał:

Brak oprogramowania do sensorów jest ogromnym minusem takiego rozwiązania. 

A do jakiego sensora brakuje Ci oprogramowania? Bo ostatnio spotkałem się z odwrotnym przypadkiem (konkretniej dla VL53L1X, gdzie z gotowców miałem pełną śliczna bibliotekę w C od ST i jakiś paszczaty wrapper w C++). Poza tym jeśli masz kod w C++ to napisanie na jego podstawie kodu w C to zabawa.

Ech, woda rzadka 😉

2 godziny temu, tomecki napisał:

Prędkość działania w C i C++ jest praktycznie taka sama lub lepsza w c++. Najszybsze działanie będzie w asemblerze.

Pozwolę sobie się nie zgodzić.

Jeśli mamy kod w C/C++ który jest prawidłowy w obu językach - będzie skompilowany na taki sam kod wynikowy. Co więcej: jeśli będziemy w C programować obiektowo, to kod w C :

x = MyMethod(&MyObject, argument);

powinien być skompilowany na ten sam kod wynikowy co kod w C++ :

x = MyObject.MyMethod(argument);

Co do asemblera... i tak, i nie. W wielu przypadkach kod wygenerowany przez kompilator z włączoną maksymalną optymalizacją będzie szybszy, niż ręcznie dziubany kod w asemblerze. Oczywiście nie jest to regułą, szczególnie dla ośmiobitowców (możliwość użycia 8-bitowej arytmetyki zamiast wymaganej w C/C++ int). Tak że nie można twierdzić że asembler będzie zawsze szybszy od C/C++.

2 godziny temu, tomecki napisał:

Np. w programowaniu obecnie lepiej korzystać z C# niż z c++, chociaż c++ jest znacznie szybsze w działaniu. 

Mówisz o programowaniu ośmiobitowych AVR-ów czy pecetów z Windowsem (bo już pod Linuksem pisanie w C# traci sens)? Bo to samo o domniemanej "lepszości korzystania" można powiedzieć o Javie czy Pythonie...

 

 

[tomecki]

4 godziny temu, ethanak napisał:

A do jakiego sensora brakuje Ci oprogramowania? Bo ostatnio spotkałem się z odwrotnym przypadkiem (konkretniej dla VL53L1X, gdzie z gotowców miałem pełną śliczna bibliotekę w C od ST i jakiś paszczaty wrapper w C++). Poza tym jeśli masz kod w C++ to napisanie na jego podstawie kodu w C to zabawa.

czyli jednak są biblioteki do sensorów w C. Otworzyłem wątek w celu uzyskania takiej odpowiedzi. 

Jeszcze nie zacząłem bawić się w to, ale wygląda to obiecująco. Szczególnie ze względu na edytor - Atmel studio  z możliwością debugowania kodu. 

4 godziny temu, ethanak napisał:

 

Co do asemblera... i tak, i nie. W wielu przypadkach kod wygenerowany przez kompilator z włączoną maksymalną optymalizacją będzie szybszy, niż ręcznie dziubany kod w asemblerze. Oczywiście nie jest to regułą, szczególnie dla ośmiobitowców (możliwość użycia 8-bitowej arytmetyki zamiast wymaganej w C/C++ int). Tak że nie można twierdzić że asembler będzie zawsze szybszy od C/C++.

Masz rację - kod w c++ może być szybszy niż w asm. Czyli programowanie w asm traci sens, oprócz wielkości programu. 

https://www.codeproject.com/Articles/1182676/Need-for-Speed-Cplusplus-versus-Assembly-Language

4 godziny temu, ethanak napisał:

Mówisz o programowaniu ośmiobitowych AVR-ów czy pecetów z Windowsem (bo już pod Linuksem pisanie w C# traci sens)? Bo to samo o domniemanej "lepszości korzystania" można powiedzieć o Javie czy Pythonie...

 

 

mówiłem o programowaniu komputerów. Zamiast c# można było podstawić javę czy pythona lub ruby. 

[ethanak]

28 minut temu, tomecki napisał:

Czyli programowanie w asm traci sens, oprócz wielkości programu. 

Nie. Często bywa potrzebne, ale raczej nie w stylu pisania całego programu w asemblerze, ale raczej do krótkich wstawek, które w C byłyby albo nieefektywne, albo zgoła niemożliwe do implementacji.

 

29 minut temu, tomecki napisał:

mówiłem o programowaniu komputerów

A miało być o mikrokontrolerach, prawda? Zresztą - nawet w świecie mikrokontrolerów masz MicroPythona, o Micro(C#|Java|Ruby) jeszcze nie słyszałem 😉