Po co atmegi, pice, stmy jak jest Raspbberry....

Żeby nie mieć problemu z podpinaniem peryferiów i brakiem pinów wybierz coś innego niż Raspberry, np. jakiegoś BeagleBone'a a jak Ci mało mocy obliczeniowej to coś w stylu CubieBoard.

to taka ogólna moda, żeby jebać programistów assemblerowych, może chodzi o misję tuska/europy, żeby wszystko było totalnie kontrolowane i regulowane...

Tak dla Twojej wiadomości: najbardziej krytyczna czasowo część jądra Linuxa jest napisana w asemblerze. A jądro to wykorzystane jest np. w takim sobie nic nie znaczącym Androidzie (pół roku temu było MILIARD aktywnych urządzeń z tym systemem). Czyli jednak na coś się przydają programujący w asm.

nie wydaje mi się, cały czas da się widzieć ostre najazdy na asm... bo to było tak, że jak oni chcieli C (ch... wie po co) to my asm... no to oni "to ch... z wami" i zaczęli budować takie cudeńka ja arduino, rapsbery i inne gotowce dla jedynie słusznie rozumiejących...

Podaje Ci suche fakty, Twoje "wydawanie się" tego nie zmieni.

Użytkownik "platformowe głupki" napisał w wiadomości grup dyskusyjnych:m145dh$gj4$ snipped-for-privacy@node2.news.atman.pl...

Próbowałeś to leczyć? Jakim świrem trzeba być by ni z dupy ni z pietruchy wyskoczyc z assemblerem i z tej pozycji podjąć "dysputę" polityczną?

Może byś sobie jakąs pracę znalazł, cy cóś?

W dniu 09.10.2014 o 00:13, Ghost pisze:

Pracę mają ci z grantami od tuska/gronkiewicz (kopacz pending), jeszcze nie zauważyłeś? ;D

Użytkownik "butek" napisał w wiadomości grup dyskusyjnych:5435b83d$0$3169$ snipped-for-privacy@news.neostrada.pl...

W dniu 09.10.2014 o 00:13, Ghost pisze:

Anotak, tylko po co im granaty?

Wyglądają ładnie, ale i są +-dwa razy droższe. Czy ras-pi wystarczy, pewnie zależy od zastosowania, czasem wystarczy.

pzdr bartekltg

W dniu 2014-10-08 o 16:13, Marek pisze:

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

systemu

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

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

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

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

W dniu 2014-10-09 o 10:13, Marek pisze:

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

On 2014-10-08 16:13, Marek wrote: [...]

IMO nie ma. MIPS i ARM to w zasadzie "the same shit". Jedynie w celach poznawczych można/warto to zrobić.

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

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

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.

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.

W dniu środa, 8 października 2014 10:13:55 UTC-4 użytkownik Marek napisał:

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.

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

kilobajtów

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.