Raspberry Pi, jaki system, jaki kompilator, dokumantacje itd...

[amidar]

Cześć

Mam mały projekt który ma być oparty na Raspberry Pi. Do tej pory starczało mi Arduino, czy kilka ich połączonych razem. Jednak tym razem jednostka główna musi być silniejsza. Padło na Raspberry.

Zastanawiam się jaki system będzie najlepszy, jaki kompilator, i jakie środowisko programowania.

Python odpada, bo z wielu źródeł będę miał całkiem sporo informacji. m.in. kilka czujników temperatury, czujniki pozycji silnika krokowego, w sumie kilkanaście źródeł danych i drugie tyle wyjść do wysterowania. Całość będzie współpracowała z 2 lub 3 Arduino Nano - to jest jeszcze do przemyślenia. Raspberry ma zarządzać tym wszystkim. Język musi być kompilowany. Najprawdopodobniej będzie to bądź C++ bądź C#, myślałem jeszcze o Javie. ale to będzie zależeć od środowiska. Testowo zainstalowałem Raspbiana, Androida i Windowsa. Najgorzej z tej grypy spisywał się android. Tak więc myślę, że go nie wykorzystam. Najprawdopodobniej skupię się na Windowsie gdyż z tym systemem znam najlepiej, choć ten na Raspberry jest nieco inny. Ale... nie chciałbym odrzucać Raspbiana, mam wrażenie, że zachowuje się najlepiej.

Aplikacja na Rasbery będzie miała kilka wątków, musi mieć Gui graficzne służące do wyświetlania parametrów pracy + panel z przyciskami. Potrzebuję więc informacji dot. jakiegoś środowiska programowania. Najlepiej gdyby sam interfejs dało się "wyklikać" nie specjalnie mam czas by bawić się w tej chwili na rysowanie całości. M$ ma potężne narzędzie - Visual Studio, a jak to wygląda po stronie Raspbiana? Jest Gcc, ale nie miałem z nim żadnego kontaktu. I jeszcze jedno. Jak wygląda sprawa debudowania?

Z góry dzięki za wszelkie informacje, sugestie itp.

A... jeszcze jedno, do arduino jest masa dodatkowych bibliotek do obsługi silników krokowych, cyfrowych czujników temperatury, czy innego sprzętu. Jak to wygląda po stronie Raspberry Pi?

Być może jeżeli dało by się pozbyć jednego z Arduino uprościło by mi to cały projekt.

[deshipu]

Ojej, tyle zrobiłeś błędnych założeń, że nie wiem od czego zacząć. Może w tej kolejności, w której pisałeś:

Zastanawiam się jaki system będzie najlepszy, jaki kompilator, i jakie środowisko programowania.

Te, które najlepiej znasz, albo jesteś w stanie najszybciej się nauczyć.

Python odpada, bo z wielu źródeł będę miał całkiem sporo informacji.

Nie widzę związku.

Język musi być kompilowany. Najprawdopodobniej będzie to bądź C++ bądź C#, myślałem jeszcze o Javie. ale to będzie zależeć od środowiska.

Zarówno C# jak i Java są tak samo "kompilowane" jak Python — do kodu pośredniego wykonywanego przez maszynę wirtualną. Skąd wytrzasnąłeś wymaganie, że język ma być "kompilowany" i co właściwie przez to rozumiesz, bo chyba nie do końca rozumiesz co piszesz.

Najprawdopodobniej skupię się na Windowsie gdyż z tym systemem znam najlepiej, choć ten na Raspberry jest nieco inny.

"Nieco" to bardzo lekki eufemizm. To, co Microsoft zrobił na RPi i nazwał "Windowsem" w zasadzie żadnego związku z prawdziwym Windowsem nie ma, może poza równie tragiczną dokumentacją. To jest na szybko przerobiona wersja "Windows CE" znanego z PDA z lat 90-tych.

Potrzebuję więc informacji dot. jakiegoś środowiska programowania.

Hmm, ja na przykład do pisania kodu używam na rpi vim-a, ale możesz mieć z tym pewne problemy...

Najlepiej gdyby sam interfejs dało się "wyklikać" nie specjalnie mam czas by bawić się w tej chwili na rysowanie całości.

No to masz wybór pomiędzy QTCreator-em a Glade-em, w zasadzie. Chyba, że się ostatnio pojawiło coś nowego, muszę przyznać, że nie śledziłem rynku ostatnio.

Jest Gcc, ale nie miałem z nim żadnego kontaktu.

Miałeś, miałeś, tylko o tym nie wiesz. Całe Arduino chodzi na gcc.

Jak wygląda sprawa debudowania?

A co to takiego?

A... jeszcze jedno, do arduino jest masa dodatkowych bibliotek do obsługi silników krokowych, cyfrowych czujników temperatury, czy innego sprzętu. Jak to wygląda po stronie Raspberry Pi?

Po stronie RPi też jest cała masa bibliotek, głównie dla Pythona.

[amidar]

Całość pisana mocno chaotycznie. Za co z góry przepraszam.

deshipu wielkie dzięki za odpowiedź...

Wrócę jednak do sedna, aplikacja musi być szybka, by reagować na szybkie zmiany, będą przypadki gdy czas reakcji musi być poniżej 1 ms. wydaje się to dość "długim" czasem, jednak gdy do wykonania w tle jest jeszcze coś zaczyna brakować czasu i aplikacja nie będzie działać tak jak bym chciał. Przynajmniej tak mi się wydaje. Aplikacji z założenia musi mieć kilka wątków, kilka rdzeni powinno z tym dać sobie radę 😉 bez większych problemów.

Część z tych problemów przejmie na siebie dedykowane arduino, odsyłając tylko od czasu do czasu informację czy wszystko jest w porządku. Tam jest najbardziej krytyczny fragment aplikacji gdy po wystąpieniu sygnału (pojawia się co około 50ms) trzeba wystawić sygnał w czasie od 0-300us.

W zestawieniu języków pojawiły się i Java i C#, ten pierwszy bo wiązałem go z pisaniem pod androida na R pi. Ten drugi głównie po Windowsem. Oba mają spore ograniczenia, choć myślę, że jeżeli chodzi o środowisko to jednak pod m$ C# będzie działał zdecydowanie szybciej. Oba języki działają ka kodzie pośrednim, jednak same systemy to mocno optymalizują i często jest tak, że kod pośredni ja komputerze jest kompilowany do kodu maszynowego procesora i w takiej formie przechowywany w cachu.

Jak działa Pytkon? Nie mam pojęcia, dla mnie jest interpreterem. Może być tłumaczony na coś pośredniego, bądź docelowego nie wiem czy w trakcie uruchamiania, czy już w trakcie działania poszczególne fragmenty są zamienianie na właściwy kod.

Na tą chwilę chwilę wolałbym jednak zostać przy C, czy C++, zmierzyć się z Rasbianem, QTCreator wydaje się rozsądny.... Tyle, że dalej średnio znam to środowisko. Powiedział bym nawet, że go nie znam.

Windows dalej chodzi mi po głowie, to, że bazuje na Win CE jeszcze go nie dyskredytuje, choć wolałbym by jednak bazowało to na jądrze jakiegoś "normalnego" Windowsa. Wrażenia z uruchamiania Windowsa mam takie, że działa.... wolno, wyraźnie wolniej od Rasbiana czy Androida.

Za "debudowanie" przepraszam, oczywiście miało być debugowanie 😉

Na tą chwilę wygląda to tak, że zostają 2 arduino komunikujące się z R pi po USB. Reszta musi być już na R pi... aplikacja okienkowa + prawdopodobnie 2 lub 3 wątki w tle.

Ps. wiem, pewnie znowu namieszałem 😉 ale chcę wykorzystać sprzęt tak szybo jak się da. Pierwsze testy chciałbym przeprowadzić pod koniec tygodnia. Czasu mało.

[deshipu]

Czarno to widzę, za dużo masz na raz do ogarnięcia, żeby się wyrobić z takim terminem. No ale co się nauczysz, to twoje.

Od razu zalecałbym sobie dać spokój z szybkością reagowania na rpi, niezależnie czy to jest Python czy C++. Twój kod będzie chodził na szczycie wielkiej piramidy innego kodu: systemu operacyjnego, sterowników sprzętu, kernela, etc. — każdy kawałek będzie mieć swoje wątki, przerwania, etc. Jeśli nie znasz się na tym bardzo dobrze i nie potrafisz na systemie wymusić, żeby traktował twój program specjalnie, to masz małe szanse. Ani Android ani Linuks nie są systemami czasu rzeczywistego. O Windowsie nawet nie będę wspominał. Jak masz te Arduino podłączone, to wykorzystaj je maksymalnie do robienia wszystkich krytycznych czasowo rzeczy. Procesorki mają słabe, ale twój kod działa na nich blisko sprzętu i ma pełną kontrolę.

Na to, że środowisk nie znasz niewiele mogę pomóc — wypada się nauczyć. Jeszcze jest jedna możliwość: skoro to ma być prototyp, to zamiast rpi daj tam starego laptopa z Windowsem, którego już znasz, a potem możesz się ewentualnie zastanawiać nad optymalizowaniem. Wtedy przynajmniej masz tylko jeden problem na raz i możesz do tego podchodzić krok po kroku.

[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

[FlyingDutch]

Całość pisana mocno chaotycznie. Za co z góry przepraszam.

deshipu wielkie dzięki za odpowiedź...

Wrócę jednak do sedna, aplikacja musi być szybka, by reagować na szybkie zmiany, będą przypadki gdy czas reakcji musi być poniżej 1 ms. wydaje się to dość "długim" czasem, jednak gdy do wykonania w tle jest jeszcze coś zaczyna brakować czasu i aplikacja nie będzie działać tak jak bym chciał. Przynajmniej tak mi się wydaje. Aplikacji z założenia musi mieć kilka wątków, kilka rdzeni powinno z tym dać sobie radę 😉 bez większych problemów.

Część z tych problemów przejmie na siebie dedykowane arduino, odsyłając tylko od czasu do czasu informację czy wszystko jest w porządku. Tam jest najbardziej krytyczny fragment aplikacji gdy po wystąpieniu sygnału (pojawia się co około 50ms) trzeba wystawić sygnał w czasie od 0-300us.

Cześć,

nie jestem jakimś Guru, ale wybrałbym inną platformę do tych (rzeczywiście dość chaotycznych założeń). Ja wybrałbym jeden z najmocniejszych zestawów "STM32 Nucleo-144" (albo zbliżony Discovery) z serii F7xx, Jako kompilator (IDE) użyłbym "ARM keil uVison 5" + "STM32CubeMX". Masz w jednym wygodny kompilator i generator kodu (GUI graficzne 'rzeźbisz' graficznym kreatorem prawie jak w Visual Studio"). Ja skorzystałbym z RTOS'a + np. stos TCP/IP do komunikacji (masz też za darmo np. WebServer do konfiguracji czy server VNC jesli nie chcesz mieć LCD jako wyświetlacza, tylko łączyć się zdalnie np. za pomocą klienta VNC). Łatwo wygenerujesz szkielet aplikacji za pomocą CubeMX+Keila. Jeśli obsługa krytycznych zadań będzie wykorzystywała przerwania i użyjesz sprawnie DMA to Cortex M-7 taktowany 216 MHz da sobie radę.

Według mnie nad tak wygenerowanym kodem będziesz miał dużo większą kontrolę (oczywiście możesz używać wielu tasków RTOSa z dostrojonymi priorytetami) a ARM Cortex -M7 powinie się śmiało wyrobić. Jedyny problem to licencja na Keila, ale raczej można jak się napisze do przedstawiciela Keila w Polsce dostać 2-miesięczną licencję trial bez ograniczeń funkcjonalnych.

Ja użyłbym np. takiego zestawu "Nucleo-F767ZI":

https://kamami.pl/stm-nucleo-144/562884-nucleo-f767zi-plytka-rozwojowa-z-mikrokontrolerem-stm32f767zi.html

http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f767zi.html

lub któregoś z zestawów "STM32 Discovery" o zbliżonych parametrach.

Do tego możesz zrezygnować z tych "dodatkowych" Arduino, bo masz tyle lini I/O wyprowadzonych na złącza zestawu, że jeszcze zostaną Ci wolne. Do tego - co najważniejsze mnóstwo darmowych bibliotek i przykładów w sieci (C/C++).

Gdybyś chciał darmowego IDE to zawsze jest (nie najgorszy) "System Workbench for STM32 AC6" oparty na Eclipse (całkowicie darmowy), którego można użyć zamiast "Keil uVision", ale moim zdaniem "Keil" jest trochę lepszy (trochę więcej rzeczy automatyzuje - szczególnie jeśli chodzi o instalację bibliotek).

Ale to tylko moja osobista opinia i wiele osób może z nią polemizować.

Pozdrawiam

[PiotrekEl]

Python odpada, bo z wielu źródeł będę miał całkiem sporo informacji. m.in. kilka czujników temperatury, czujniki pozycji silnika krokowego, w sumie kilkanaście źródeł danych i drugie tyle wyjść do wysterowania.

Tym bardziej Python wskazany;) Niedawno się nim zacząłem bawić i szczerze mówiąc zadziwia mnie.

Aplikacja na Rasbery będzie miała kilka wątków, musi mieć Gui graficzne służące do wyświetlania parametrów pracy + panel z przyciskami. Potrzebuję więc informacji dot. jakiegoś środowiska programowania. Najlepiej gdyby sam interfejs dało się "wyklikać" nie specjalnie mam czas by bawić się w tej chwili na rysowanie całości.

W Pythonie to wszystko jest.

M$ ma potężne narzędzie - Visual Studio, a jak to wygląda po stronie Raspbiana?

Raspbian ma potężniejsze narzędzie -Pythona;)

A... jeszcze jedno, do arduino jest masa dodatkowych bibliotek do obsługi silników krokowych, cyfrowych czujników temperatury, czy innego sprzętu. Jak to wygląda po stronie Raspberry Pi?

Znowu odpowiedź taka sama - Python.

Tak to wygląda moim zdaniem. Nie namawiam a polecam:)

[FlyingDutch]

M$ ma potężne narzędzie - Visual Studio, a jak to wygląda po stronie Raspbiana?

Raspbian ma potężniejsze narzędzie -Pythona;)

A... jeszcze jedno, do arduino jest masa dodatkowych bibliotek do obsługi silników krokowych, cyfrowych czujników temperatury, czy innego sprzętu. Jak to wygląda po stronie Raspberry Pi?

Znowu odpowiedź taka sama - Python.

Tak to wygląda moim zdaniem. Nie namawiam a polecam:)

Cześć,

a jak za pomocą Pythona i Raspbiana obsłużysz zadania, których czas odpowiedzi ma być poniżej 1 ms. Zastanawiałeś się nad tym co napisał Deshipu na temat Raspbiana - to nie jest system czasu rzeczywistego i czas przełączania tasków/watków może tu być dłuższy niż zakładany czas reakcji systemu (takie czasy reakcji zapewniają przerwania i/lub systemy czasu rzeczywistego). Wiesz ile dodatkowych "demonów" chodzi w tle w Raspbianie?

Byłoby inaczej, gdybyś sobie "uszył" OS na miarę potrzeb - minimalny spełniający założenia (wiąże się to z konfiguracją i kompilacją jądra systemu) - wpisz w wyszukiwarce:

"Linux from scratch". Nie sądzę jednak, że twórca tego postu ma taką wiedzę (polecam tu meta-dystrybucję "Linux Gentoo", uruchamiałem ją na RPI).

Python tu sobie sam nie poradzi, trzeba użyć nisko-poziomowych mechanizmów z CPU kontrolera i/lub systemu czasu rzeczywistego (np. RTOS ARM'a lub FreeRTOS).

Jeśli rzeczywiście są wymagane tak krótkie czasy reakcji jak twórca wątku to opisał to robicie błędne założenia, bo typowy Raspbian (czy inna dystrybucja Linuxa tu sobie nie poradzi (nie mówię tu o użyciu Linuxa "szytego na miarę" dla aplikacji lecz typowej dystrybucji).

BTW: Pythona używam od ponad 10-ciu lat i rzeczywiście jest to bardzo dobry język programowania. Jednak twierdzenie, że Python rozwiązuje wszystkie problemy informatyczne jest moim zdaniem nadużyciem (nie wiem dlaczego przeważnie początkujący użytkownicy Pythona przechodzą fazę fanatyzmu na temat tego języka).

Pozdrawiam

[ethanak]

Podaj chociaż jeden sensowny powód, dla którego Python/Python3 odpada.

Jestem w stanie podać te powody dla C# czy Javy.

Rozumiem, że o prekursorach nie rozmawiamy (czyli zarówno Icon, jak i Snobol są dla Ciebie obce).

Rozumiem, że Pythona nie lubisz bo go nie rozumiesz, a nauczenie się podstaw to nie dla Ciebie?

[FlyingDutch]

Podaj chociaż jeden sensowny powód, dla którego Python/Python3 odpada.

Jestem w stanie podać te powody dla C# czy Javy.

Rozumiem, że o prekursorach nie rozmawiamy (czyli zarówno Icon, jak i Snobol są dla Ciebie obce).

Rozumiem, że Pythona nie lubisz bo go nie rozumiesz, a nauczenie się podstaw to nie dla Ciebie?

Cześć Ethanak,

podałem już te powody i są to ograniczenia wynikające z systemu operacyjnego, radziłbym się nauczyć czytać ze zrozumieniem. Te same problemy sygnalizował wcześniej Deshipu. A Pythona znam, rozumiem i używam na codzień.

Pozdrawiam

[deshipu]

Ja nie sygnalizowałem problemów z Pythonem. Wręcz przeciwnie, uważam całą twoją argumentację za, delikatnie mówiąc, kulawą. Ten cały podział na języki "interpretowane" i "kompilowane" który się wbija do głów w szkołach nie ma żadnego związku z rzeczywistością od jakichś 30 lat.

[FlyingDutch]

Ja nie sygnalizowałem problemów z Pythonem. Wręcz przeciwnie, uważam całą twoją argumentację za, delikatnie mówiąc, kulawą. Ten cały podział na języki "interpretowane" i "kompilowane" który się wbija do głów w szkołach nie ma żadnego związku z rzeczywistością od jakichś 30 lat.

Cześć Deshipu,

mówiłem o Raspbianie i jego ograniczeniach (czasy przełączania tasków) i że nie jest to system czasu rzeczywistego. Nic nie pisałem o językach kompilowanych i interpretowanych (ani o Pythonie w tym kontekście). Uważam Pythona za bardzo dobry język.

Tak samo C/C++ nie sprawdzi się z Raspbianem (jeśli rzeczywiście są zakładane tak krótkie czasy reakcji). Nadal podtrzymuję, że lepszy będzie "ARM RTOS" o bardzo małym footprint'cie i programowanie z wykorzystaniem mechanizmów CPU (np. przerwania).

Widzę, że słowo kluczowe "Python" powoduje niekontrolowany wzrost dziwnych reakcji, więc jeszcze raz napiszę: "Pythona używam i uważam za bardzo dobry i potężny język programowania (szczególnie cenię elementy programowania funkcyjnego w Pythonie).

Ale uważam, że do projektu o założeniach jak wyżej lepiej użyć innego zestawu (mikro-kontrolera) i innych narzędzi programowych.

Pozdrawiam

[deshipu]

A to ja przepraszam. Staram się nie reagować na słowo kluczowe Python, ale czasem naprawdę trudno.

Jest jeszcze jedna możliwość — istnieją na RPI systemy czasu rzeczywistego, które da się zastosować. Tylko wtedy to już jest raczej dłubanie w C i nic się "wyklikać" nie będzie dało.

[Mellon]

Standardowo Python jak i PHP standardowo są językami interpretowanymi. Czyli interpreter sprawdza każdą linię kodu pod względem poprawności. Zobacz

Język klasyczny C/C++ jest kompilowanym i z tego względu powinien wykonywać się szybciej. Java i C# korzystają z kodu pośredniego, czyli też trochę mniej wydajnie.

Python jest jednak łatwy do nauki i sterowanie wydaje się bardzo przyjemne.

Warto na początek zrobić coś nawet wolniejszego, aby potwierdzić wymagania czasowe. Ale jeśli takie wymagania czasowe są rzędu mikrosekund to chyba tylko FPGA wchodzi w grę.

Zweryfikuj doświadczalnie swoje wymagania.

[deshipu]

Standardowo Python jak i PHP standardowo są językami interpretowanymi. Czyli interpreter sprawdza każdą linię kodu pod względem poprawności. Zobacz

Powtarzasz bzdury. "Standardowy" Python, czyli cpython, kompiluje programy do kodu pośredniego i uruchamia je na maszynie wirtualnej Pythona. Nie widzisz tego, bo jest to robione automatycznie kiedy uruchamiasz swój program. Możesz sobie obejrzeć ten skompilowany program, bo dla wydajności jest on zapisywany na dysku w postaci pliku .pyc — żeby nie trzeba go było kompilować kolejny raz gdy program się nie zmienił. Jedyna różnica pod tym względem w porównaniu do Javy czy C# to to, że one wymagają skompilowania osobnym narzędziem całego programu na raz, a Python potrafi skompilować i uruchomić nawet pojedyncze linijki — tak się dzieje, kiedy korzystamy z konsoli Pythonowej, na przykład. Ale to nie znaczy, że kiedy uruchamiasz większy program, to Python nadal "sprawdza każdą linię" osobno. Tak mógł robić interpreter BASICa w latach 70-tych, ale nie współczesne języki programowania.

Niestety cały ten mit o "językach interpretowanych" jest powtarzany jak zdarta płyta przez nauczycieli, którzy nadal słuchają muzyki z kaset magnetofonowych a zegarek elektroniczny uważają za szczytowe osiągnięcie techniki.

[FlyingDutch]

Ale jeśli takie wymagania czasowe są rzędu mikrosekund to chyba tylko FPGA wchodzi w grę.

Zweryfikuj doświadczalnie swoje wymagania.

Cześć Mellon,

zgadzam się z Tobą co do weryfikacji założeń - wydaje mi się, że są nieco przesadzone.

FPGA - jak najbardziej, tylko trzeba mieć wiedzę dot. układów programowalnych (nie wiem, czy autor postu takową posiada?).

Co do CPU ARM Cortex to proponuję przeczytać chociazby ten artykuł:

Interrupt Latency on the Cortex-M processor family

https://community.arm.com/processors/b/blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

Według mnie ARM-CortexM7 z zegarem 216 MHz przy dobrze oprogramowanych przerwaniach powinień się wyrobić w zadanym czasie. Zależy to od tego jak skomplikowane są taski, które układ ma wykonać po przyjściu przerwania (może dojśc do przepełnienia stosu po pewnym czasie działania programu).

Pozdrawiam