W dniu 2014-10-08 o 16:13, Marek pisze:
> Większość poleca przejść na jakiegoś ARM'a, ale czy to na pewno ma sens?

Musisz chyba sobie odpowiedzieć na pytanie, czy potrzebujesz systemu
operacyjnego i jesteś w stanie nad nim zapanować czy też jesteś w stanie
zaspokoić wszystkie swoje wymagania bez OS.

Linuxy bywają przyjemne, ale musisz pamiętać, że uzależniają Cię one
właściwie w 100% od producenta sprzętu.
Jeśli producent stwierdzi, "mam w dupie ten moduł sprzętowy" to nie
będzie do niego nowego jądra, a moduły sprzętowe jakoś tak mają, że
zawsze coś tam jest tak zrobione, że jądro bez poprawek "prawie pasuje.".
I wtedy masz do wyboru, zostać guru od jądra Linuxa albo porzucić sprzęt.
Okazuje się po prostu w pewnym momencie, że ze starym jądrem nie
skompiluje Ci się program, na którym oparłeś swój system, a właśnie
opublikowali w necie opis dziury i booty wyszukują jak szalone tej
wersji w sieci i ją atakują....
Dodatkowo nie panujesz nad zależnościami czasowymi w systemie, coś tam
się gdzieś, kiedyś wykonuje ale do końca nie masz na to wpływu i
krytyczny proces czasem Ci się zatrzyma w najmniej oczekiwanym momencie.

Z drugiej strony system operacyjny to szybkie dodawanie nowych
funkcjonalności, bez jakiejkolwiek wiedzy o ich działaniu...

--
AWa.

do góry

On Thu, 09 Oct 2014 09:06:14 +0200, "Andrzej W."
<a...@w...pl> wrote:
> Musisz chyba sobie odpowiedzieć na pytanie, czy potrzebujesz
systemu
> operacyjnego i jesteś w stanie nad nim zapanować czy też jesteś w
stanie
> zaspokoić wszystkie swoje wymagania bez OS.

Komplikacja układów, które czasami buduje mają funkcjonalności
pokrywające się z OSem (tcpip,obsługa fat32,,USB), niby wszystko
działa ale jak się zacznie abusować taki układ to coś dziwnego się
dzieje, albo tcp po przetransferowaniu 1GB zgubi pakiet i jest
czkawka lub przerwanie transferu albo driver fat32 przy zamykaniu
dwumilionowym pliku zgubi cluster, niby nic wielkiego ale fsck nie ma
więc pena trzeba i tak wyciągać i czyścić w PC...nawet w pewnej
chwili słabości chciałem sportować fsck... ale po co? Bez sensu jak
mam tu wszystko pod ręką w OS. Soft do mcu udostępniany przez
producentów lub społeczności chyba jednak nie jest tak dobrze
przetestowany i sprawdzony jak kernel Linuxa i w ekstremalnych
warunkach coś się krzaczy. Oczywiście można powiedzieć: zgłoś
problem, poprawią itp...

> Linuxy bywają przyjemne, ale musisz pamiętać, że uzależniają Cię
one
> właściwie w 100% od producenta sprzętu.
> Jeśli producent stwierdzi, "mam w dupie ten moduł sprzętowy" to nie

Ale moment, przecież te 3 przykładowe komputery płytkowe mają chyba
wsparcie w driverach do wszystkich układów na płytce czy czegoś nie
zrozumiałem?
Dostaje Rasp i muszę sam dopisać sobie driver do jego eth/usb/etc,
czy driver jest ale niedopracowany i trzeba się przyzwyczaić, że od
czasu do czasu wisi?
Linuxem zajmuje się zawodowo i drivery lub modyfikacje kernela
popełniać mi się zdarzało ale szczerze mówiąc po to chce wybrać taką
platformę płytkową aby skupić się wyłącznie na userlandzie i nie
przejomwać się, że np. driver czasami eth odstawi jakieś hocki. Jak
urządzenie włączam ma działać bezawaryjnie aż do wyschnięcia jego
elektrolitów :).

> Dodatkowo nie panujesz nad zależnościami czasowymi w systemie, coś
tam
> się gdzieś, kiedyś wykonuje ale do końca nie masz na to wpływu i
> krytyczny proces czasem Ci się zatrzyma w najmniej oczekiwanym
momencie.

Tego jestem świadom, akurat nie mam potrzeb realizować układów RT.

> Z drugiej strony system operacyjny to szybkie dodawanie nowych
> funkcjonalności, bez jakiejkolwiek wiedzy o ich działaniu...

O to mi chodzi. Chyba już wyrastam z fascynacji śledzenia jak pakiet
przechodzi przez kolejne warstwy systemu.

--
Marek

do góry

W dniu 2014-10-09 o 10:13, Marek pisze:
> Ale moment, przecież te 3 przykładowe komputery płytkowe mają chyba
> wsparcie w driverach do wszystkich układów na płytce czy czegoś nie
> zrozumiałem?
> Dostaje Rasp i muszę sam dopisać sobie driver do jego eth/usb/etc, czy
> driver jest ale niedopracowany i trzeba się przyzwyczaić, że od czasu
> do czasu wisi?

Piszę o RPI.
Sterowniki są zamknięte, nie masz kodu.
Czy działa? Eeee...
Działa coraz lepiej, początkowe wersje oprogramowania waliły się przy
większym transferze po Eth, trzeba było jakieś cuda robić w systemie.
Tak samo obsługa SD, jeśli pisałeś na kartę regularnie to system plików
był całkowicie rozj.... po kilku tygodniach. I to tak, że żadne fsck nie
pomogło.
Zmiany w jakiś tam plikach konfiguracyjnych, podnoszenia napięcia
rdzenia, zaczęło to jakoś działać, ale ostatnio nie wykorzystuje RPI do
przetwarzania danych więc trudno mi ocenić stabilność.
Konieczność przeróbek zasilania przy portach USB co by zwykłe Wi-Fi nie
powodowało klęknięcia systemu.
RPI to fajna zabawka, ale do urządzenia co ma biegać 24/7 i działać do
tego to raczej bym tego nie wsadził.


--
AWa.

do góry

On 2014-10-08 16:13, Marek wrote:
[...]
> Na pic32 to już średnio zaawansowane układy wykorzystujące tcp, usb
> storage itp.Co wybrać dalej po pic32? Większość poleca przejść na
> jakiegoś ARM'a, ale czy to na pewno ma sens?
IMO nie ma. MIPS i ARM to w zasadzie "the same shit". Jedynie w celach
poznawczych można/warto to zrobić.

do góry

On Thu, 09 Oct 2014 10:35:24 +0200, "Andrzej W."
<a...@w...pl> wrote:
> Piszę o RPI.
> Sterowniki są zamknięte, nie masz kodu.
> Czy działa? Eeee...
> Działa coraz lepiej, początkowe wersje oprogramowania waliły się
przy
> większym transferze po Eth, trzeba było jakieś cuda robić w
systemie.
> Tak samo obsługa SD, jeśli pisałeś na kartę regularnie to system
plików
> był całkowicie rozj.... po kilku tygodniach. I to tak, że żadne
fsck nie
> pomogło.

To żeś mnie podłamał bo by "stryjek zamienił siekierkę na kijek".
Ciekawe czy pozostałe 2 płytki tak samo "działają"?

--
Marek

do góry

On Thu, 09 Oct 2014 10:46:06 +0200, JDX <j...@o...pl> wrote:
> IMO nie ma. MIPS i ARM to w zasadzie "the same shit". Jedynie w
celach
> poznawczych można/warto to zrobić.

Nie chcę aby Twoja skrajna opinia diametralnie zmieniła sens tego
wątku :). Przecież na mipsach i armach działają stabilnie OSy, jeśli
są problemy to raczej w sofcie a nie cpu... I raczej o komplikację
softu tu idzie. Jeśli używając dedykowany mcu chcemy uzyskać
funkcjonalność OSa ALE używając dedykowany (często egotyczny) soft to
są problemy. Wtedy chyba prościej użyć sprawdzony OS...

--
Marek

do góry

On 2014-10-09 11:31, Marek wrote:
> On Thu, 09 Oct 2014 10:46:06 +0200, JDX <j...@o...pl> wrote:
>> IMO nie ma. MIPS i ARM to w zasadzie "the same shit". Jedynie w
> celach
>> poznawczych można/warto to zrobić.
>
> Nie chcę aby Twoja skrajna opinia diametralnie zmieniła sens tego
> wątku :). Przecież na mipsach i armach działają stabilnie OSy, jeśli
> są problemy to raczej w sofcie a nie cpu...
Aby było jasne, wcale nie uważam że architektury MIPS i ARM są do bani.
IMO po prostu są na tyle podobne, że nie warto doktoryzować się z
drugiej jeśli ma się już doktorat z pierwszej. Zwłaszcza w
zastosowaniach domowych.

> I raczej o komplikację softu tu idzie. Jeśli używając dedykowany mcu
> chcemy uzyskać funkcjonalność OSa ALE używając dedykowany (często
> egotyczny) soft to są problemy. Wtedy chyba prościej użyć sprawdzony
> OS...
Tak BTW to po co od razu rzucać się na kobyłę jaka jest Linux? Przecież
są dostępne stosunkowo proste pod względem koncepcji jak i kilobajtów
źródeł OS-y (a może raczej schedulery???) takie jak np. FreeRTOS czy NutOS.

do góry

W dniu środa, 8 października 2014 10:13:55 UTC-4 użytkownik Marek napisał:
> Wydaje mi się, że dochodzę powoli do momentu, w którym musze dokonać
> pewnego wyboru. Jak dotąd budowałem układy realizujące własne potrzeby
> automatyki "w domu i zagrodzie" (czasami też u znajomych). Wcześniej
> na 8bit mcu teraz częściej na 32bit (pic32).
> Na pic32 to już średnio zaawansowane układy wykorzystujące tcp, usb
> storage itp.Co wybrać dalej po pic32? Większość poleca przejść na
> jakiegoś ARM'a, ale czy to na pewno ma sens?

Już Ci pisano że pic32 to MIPS. ARM jest bardziej popularny
więc zmiana ma trochę sensu, ale chyba nie tracisz wiele
zostając przy pic32.

> Jaki ma sens
> konsolidowanie od nowa potrzebnego softu (do tcp, do USB itp itd)
> plus pisanie/portowanie własnego, projektowanie płytki ze wszystkimi
> niezbędnymi komponentami dookoła cpu/mcu jak jest coś gotowego takie
> jak Raspberry Pi?
> Czy w zastosowaniach ogólnych ma sens brnięcie w jakiś dedykowany mcu
> zamiast użyć gotowca, gdzie mamy wszystko gotowe w systemie a
> elementy wykonawcze można podłączyć jako rozszerzenie do gpio?

Raspberry Pi jako MCU to dość uboga konstrukcja. Od MCU klasy
pic32 oczekuję szergu wbudowanych urządzeń (liczniki, ADC,
interfejsy I2C i SPI, ...). Raspberry Pi ma jedno I2C, jedno
SPI i port szeregowy, czyli mniej niż wiele 8-bitowców.
Do tego szybkość obsługi GPIO poprzez driwer w jądrze jest
dość skromna (jeden człowiek próbował zrobić programową
obsługę MIDI proprzez GPIO i okazało się że szybkość była
zbyt mała). Oczywiście możesz napisać własny driwer w
jądrze który zrobi z GPIO co należy. Ale taki driwer
raczej będzie trudniejszy od oprogramowania dedykowanego
MCU.

Osobiście jestem entuzjastą Raspberry Pi, ale widzę je
raczej jako koordynator do którgo poprzez I2C czy SPI
podłącza się dedykowane MCU. Tzn. Raspberry Pi może
serwować webowe UI, decydować o ogólej strategii,
ale specyficzne zadania, szczególnie te krytyczne
czasowo robiłyby MCU. Oczywiście, jak chcesz pomachać
kilkoma przekaźnikami przez interfejs webowy to
Raspberry Pi zrobi to dobrze. Ale, np. tania czujka
ultradzwiękowa wymaga precyzynego zliczania krótkich
odstępów czasu i tu Raspberry Pi ma problem.

Jak piszesz o gotowcach, to Arduino Pro Mini możesz
dostać za 1/10 ceny Raspberry Pi, a płytki z większymi
MCU też są w rozsądnej cenie. Czyli z gotowym prockiem
nie ma wiele problemu. Ale ciekawy układ prawdopodobnie
będzie zawierał więcej rzeczy niż procek, wiec dojdą
dodatkowe płytki. Zrobienie własnej płytki z prockiem
i dodatkami może być prostsze (szczególnie jak do gotowego
procka potrzebujesz układ zewnętrzny, a proc we własnym
układzie ma to wbudowane).

do góry

On Thu, 09 Oct 2014 13:44:15 +0200, JDX <j...@o...pl> wrote:
> Tak BTW to po co od razu rzucać się na kobyłę jaka jest Linux?
Przecież
> są dostępne stosunkowo proste pod względem koncepcji jak i
kilobajtów
> źródeł OS-y (a może raczej schedulery???) takie jak np. FreeRTOS
czy NutOS.

Widzisz to nie problem w corze OSa, ale w,komponentach typu stos tcp,
fat32 czy usb. Przecież np FreeRTOS nie daje "w pakiecie" obsługi
tcp, fs czy usb. Zresztą kiedyś testowałem i z mojego pkt widzenia to
tylko scheduler...A w pakiecie z Linuxem mam stabilny stos, drivery
do fsa itp. Tak, zgadzam się, że to kobyła w porównaniu do
dedykowanego mcu. Właśnie z tego powodu dotąd realizowałem pomysły na
dedykowanych mcu. Ale ostatnio doszedłem do takiego poziomu
komplikacji, że zaczyna być to porównywalne funkcjonalnie z tym co
by default daje "kobyła".... natomiast bez zmartwienia czy stos tcp
czy driver fs będzie w każdych warunkach działał prawidłowo.

--
Marek

do góry