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

[deshipu]

Taki już urok polskich forów. Przyzwyczaiłem się.

[ethanak]

@Elvis: jeśli ktoś pisze bzdury, to uważam za stosowne zamieścić sprostowanie. Podejrzewam, że kol. deshipu takoż.

To nie jest forum onetu, gdzie Antek Emigrant może swoje mniemania publikować, a poważne (mam nadzieję) forum o robotyce, czyli o połączeniu mechaniki, informatyki i elektroniki (o cybernetyce może nie wspomnę). A tu nigdzie nie ma miejsca na własne poglądy polityczne.

No bo przecież gdyby ktoś tych bzdur nie prostował, młody adept robotyki przeczytałby sobie taki jeden z drugim post różnych wielce nądrych automatyków, i jeszcze gotów by był pomyśleć że to prawda...

[Elvis]

A skoro już się odezwałem to może i odniosię do tematu - najwięcej racji w całej dyskusji miał moim zdaniem FlyingDutch. Oczywiście wszystko zależy od tego jak bardzo chcemy mieć system czasu rzeczywistego, ale podsumowując pomysły:

* FPGA - najlepsze jeśli chcemy mieć czasy rzędu nanosekund, ale ms to wieki i strzelanie z armaty do wróbla. Oczywiście można, ale nie trzeba

* mikrokontroler - tutaj jest po prostu najłatwiej. Czasy reakcji, czy obługi przerwań można po prostu policzyć (jak w przypadku AVR), albo chociaż oszacować (STM32). Najważniejsze, że czasy są przewidywalene

* Raspberry / sterownik jądra - mikroproceosor Cortex-A nie zapewnia pełnego prztwarzania w czasie rzeczywistym. Od tego są rdzenie Cortex-R albo Cortex-M. Cortex-A jest układem aplikacyjnym i nigdy nie mamy 100% pewności jakie opóźnienie się pojawi (chociaż można je zmniejszać oraz nad nimi panować). W przypadku czasów rzędu milisekund jest to całkiem wykonalne, ale w przypadku Linux-a wymagałoby napisania własnego sterownika. Wtedy można wykorzystywać przerwania, a sama obsługa zdarzeń będzie relatywnie szybka.

* Sterownik w przestrzeni użytkownika - niezależnie czy w C, czy języku interpretowanym Java/C#/Python czy cokolwiek innego, będzie miał znaczne opóźnienia związane z przełączaniem kontekstu oraz przechodzieniem między trybami jądra i użytkownika. Oczywiście pisząc niskopowiomowo mamy większą kontrolę nad opóźnieniami, ale pewnych rzeczy nie przeskoczymy.

A co do kompilacji / interpretacji, to Java/C#/Python oraz większość wynalazków z platformy .Net (w tym C++) jest kompilowana tylko do kodu pośredniego (bytecode). Taki kod nie może być wykonywany przez procesor, wymaga interpretacji, która może być wspomagana optymalizacją (JIT). Takie rozwiązania świetnie się sprawdzają w przypadku aplikacji, ale nie pasują do rozwiązań związanych ze sterowaniem - i tutaj Mellon miał w pełni rację.

[Mellon]

Tylko dlaczego 99% tego postu Ci dwaj koledzy piszą nie na temat (nawet zanim ja się włączyłem). Jak pisałem, że Python nie jest typowym językiem używanym przez automatyków, to zacząłem być obrażany jakby wszyscy musieli się ze wszystkimi zgadzać i używać tylko Python-a.

Fajny język ale nie dla każdego zastosowania.

deshipu o sowich wywodach 10 stron pisze o "interpretowanych" języka, co nie jest tematem głównym tego posta. I to po raz setny chyba.

[ Dodano: 29-03-2018, 14:46 ]

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.

Fala krytyki młodego adepta. To każdego by zniechęciło do czegokolwiek

[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

[deshipu]

Elvis, wszystko pięknie, ale zwróć uwagę dla kogo to ma być. Nie sądzę, żeby ktoś, kto właśnie opanował Arduino i planuje się powoli zabierać za Raspberry Pi mógł "do końca tygodnia" nauczyć się programować FPGA, pisać sterowniki do kernela albo w pełni kontrolować ARMy. Nie mówiąc już o budżecie na zakup nizbędnych do tego narzędzi i materiałów. Ja wiem, że się chcecie pochwalić specjalistyczną wiedzą i doświadczeniem, ale zejdźcie na ziemię — ten człowiek nawet nie wie o czym piszecie. Dodajcie do tego fakt, że jednocześnie pyta o wyklikiwanie aplikacji i szybko dojdziecie do wniosku, że to właśnie wy piszecie nie na temat.

Nie o to chodzi kto ma rację, ale o to, żeby pomóc osobie, która zadała pytanie. W pytaniu były przy tym błędne założenia, które sprostowaliśmy (potem kilka osób próbowało je prostować w drugą stronę, stąd cała dyskusja).

[Elvis]

Dlatego napisałem że moim zdaniem najlepsza rada była od kolegi FlyingDutch - stm32 i biblioteki cube.

[FlyingDutch]

Dlatego napisałem że moim zdaniem najlepsza rada była od kolegi FlyingDutch - stm32 i biblioteki cube.

Cześć Elvis,

nie wiesz jak się Cieszę, że znów pojawiłeś się na forum 😃 (abstrahując całkowicie od tematu tej dyskusji).

Napisz coś od czasu do czasu w "układach programowalnych" bo nic się tam nie dzieje - bez Ciebie jest niesamowicie nudno.

Z Elvisem zgodzę się w jednym - takie dyskusje mogą zniechęcać początkujących.Przecież sami też kilkanaście/kilkadziesiąt lat temu nie mieliśmy żadnej wiedzy, każdy musi jakoś zacząć. Rozumiem, że "fałszywe" poglądy powinny być sprostowane, ale można to zrobić bez "zaperzania się" i obrzucania epitetami.

Rozumiem też zdanie Deshipu, że ktoś początkujący nie zdecyduje się na programowanie ARMów niskopoziomowo w C.

Ja zamieściłem swoje zdanie, ale napisałem, że można się z nim nie zgadzać i nie czułbym się obrażony jeśli ktoś ma inne zdanie 🙂

Pozdrawiam,
Wszystkich

[ Dodano: 29-03-2018, 15:53 ]

Dodajcie do tego fakt, że jednocześnie pyta o wyklikiwanie aplikacji i szybko dojdziecie do wniosku, że to właśnie wy piszecie nie na temat.

.

Cześć Deshipu,

ale właśnie w IDE "Keil uVision 5" (IDE dla ARMów) jest graficzne narzędzie do tworzenia GUI dla LCD (dużo można wyklikać). Oczywiście są ograniczenia wielkości kodu wynikowego dla darmowej licencji "Lite" itp. - jednak zacząć można.

To tak "na boku" bo podzielam twoją argumentację, że dla początkującego nie jest to najlepszy wybór 😉

Pozdrawiam

[Lukaszm]

Elvis, mam pytanie do

mikroproceosor Cortex-A nie zapewnia pełnego prztwarzania w czasie rzeczywistym. Od tego są rdzenie Cortex-R albo Cortex-M.

Co rozumiesz przez przetwarzanie w czasie rzeczywistym?

[Mellon]

A to automatycy zajmują się sterowaniem, nie informatycy od zakleszczonego papieru w drukarce.

Zacięta drukarka to chyba właśnie automatyka jest, nie?

Drukarka to urządzenie elektroniczne powszechnego użytku zawierające różne układy. Ale ich naprawą zajmują się elektronicy.

[ Dodano: 29-03-2018, 17:32 ]

Elvis, mam pytanie do

mikroproceosor Cortex-A nie zapewnia pełnego prztwarzania w czasie rzeczywistym. Od tego są rdzenie Cortex-R albo Cortex-M.

Co rozumiesz przez przetwarzanie w czasie rzeczywistym?

Wymaganie takie powinien autor sprecyzować. Ale racja - Cotex-R zdecydowanie lepszy.

[deshipu]

Dlatego napisałem że moim zdaniem najlepsza rada była od kolegi FlyingDutch - stm32 i biblioteki cube.

Czyli kolega ma wyrzucić te arduina i rasberry pi, które już ma, zamówić nowe płytki prototypowe i uczyć się od zera programowania stm32?

[FlyingDutch]

Dlatego napisałem że moim zdaniem najlepsza rada była od kolegi FlyingDutch - stm32 i biblioteki cube.

Czyli kolega ma wyrzucić te arduina i rasberry pi, które już ma, zamówić nowe płytki prototypowe i uczyć się od zera programowania stm32?

Cześć Deshipu,

ja absolutnie tak nie twierdzę, myślę, że bardziej sensowne byłoby zweryfikowanie założeń.

Zakładając, że RPI jest "jednostką centralną" układu a Arduino układami wykonawczymi, musimy jeszcze brać pod uwagę opóźnienia wynikające z komunikacji RPI <-> Arduino.

I z tego powodu nie tylko opóźnienia rzędu milisekund wynikające z czasów przełączania tasków w OS nie wchodzą w grę tylko dużo dłuższe (to chyba jakoś wszystkim umknęło).

Wygląda na to, że poczatkujący kolega zrobił blędne założenia i teraz powinien je zweryfikowac. Jeśli jednak, będzie przy nich obstawał powinien być świadom, że środkami jakimi chciałby to zrealizować nie da się tego osiągnąć.

Pozdrawiam

[Elvis]

Lukaszm, zanim zaczniemy kolejną gówno-burzę:

ARMv7 provides three profiles:

ARMv7-A Application profile, described in this manual. Implements a traditional ARM architecture

with multiple modes and supporting a Virtual Memory System Architecture (VMSA) based

on an MMU. Supports the ARM and Thumb instruction sets.

ARMv7-R Real-time profile, described in this manual. Implements a traditional ARM architecture with

multiple modes and supporting a Protected Memory System Architecture (PMSA) based on

an MPU. Supports the ARM and Thumb instruction sets.

ARMv7-M Microcontroller profile, described in the ARMv7-M Architecture Reference Manual.

Implements a programmers' model designed for fast interrupt processing, with hardware

stacking of registers and support for writing interrupt handlers in high-level languages.

Implements a variant of the ARMv7 PMSA and supports a variant of the Thumb instruction

set.