Atlantis wrote:

> W dniu 2014-05-16 14:14, jacek pozniak pisze:
>
>> To fakt, ale chyba przyznasz, że celem działania systemu nie jest
>> permanentne resetowanie się.
>
> Oczywiście. Co nie znaczy, że taką sytuację też powinno się przewidzieć.
> Lepszy reset, niż zawieszenie systemu wywołane np. jakimś silnym
> zakłóceniem elektromagnetycznym. W przypadku MCU użytkownik pewnie nawet
> nie zauważy, że urządzenie na moment przestało działać. Nie można już
> mieć takiej pewności, jeśli zastosujemy OS, który będzie potrzebował
> paru minut na ponowne uruchomienie siebie samego i wszystkich usług.
> Kolejna sprawa to odzyskanie sprawności po utracie zasilania. W
> niektórych przypadkach lepiej, żeby system wstał natychmiast. Weźmy na
> przykład jakąś stację monitorującą jakiś proces lub zjawisko. Każda
> minuta przestoju to przeoczone dane.
Powiem wprost; nie wiem co jest lepsze, to są akademickie dyskusje ponieważ
nikt nie powinien do krytycznych zastosowań wybierać rozwiązania opartego na
RPi ani na jakimś niesprawdzonym STM, AVR, PICu.
Do takich zastosowań to przede wszystkim rozwiązania SPRAWDZONE.

>
>
>> Zgadzam się ale dodam, że to zależy od zastosowania projektu, w bardziej
>> złożonym, pisanym przez Ciebie też może się okazać, że nie będziesz mógł
>> machać tym pinem tak często jak chcesz.
>
> Przewaga i tak ciągle pozostaje po stronie MCU. Pisząc wsad sami
> decydujemy jakie działania zostaną podjęte. Tymczasem nawet mały system
> operacyjny ma cały zestaw swoich usług, które nie zawsze można tak łatwo
> wyłączyć, nawet jeśli z nich nie korzystamy. Dobrze napisany program na
> MCU (zdarzenia, brak pętli opóźniających) będzie działał o wiele
> sprawniej niż to samo odpalone na jakimś systemie.
Tak to prawda pod warunkiem dookreślenia sformułowania "będzie działał o
wiele sprawniej"
>
> Oczywiście nie mówię, że komputerki na kawałku małego PCB są złe.
> Wszystko zależy od zastosowania. Prostej stacji pogodowej, zegara nixie
> albo zamka elektronicznego nie budowałbym na RasPi, tylko posłużyłbym
> się zwykłym MCU. Tutaj nawet zwykła ATmega się sprawdzi.
> Natomiast robiąc radio internetowe albo odtwarzacz sieciowych
> multimediów nie bawiłbym się w pisanie wszystkiego od podstaw, tylko
> wziąłbym RasPi, odpaliłbym na nim MPD i dopisał prosty program do
> obsługi sprzętowego interfejsu.
Zgadzam się.
>
>
>> No to chyba tylko coś w rodzaju RPi, tam masz to już oprogramowane, ew
>> dopisujesz własny driver do swojego hardware.
>
> Mówisz o szyfrowaniu czy kolorowych wyświetlaczach? Wydaje mi się, że
> pod STM32 też są do tego narzędzia i biblioteki.
Może są, ale np. taki xWindows (jęśli robiłbym coś a'la kiosk albo coś
innego graficznego) lub ssh (jeśli robiłbym szyfrowane połaczenia) lub
webserwer (co mi obsłuży wiele połaczeń na raz) lub baza danych lub
cokolwiek bardziej zaawansowanego niż "machanie pinem" to wolałbym wziąć
raczej z Linuksa niż z jakichś bibliotek do STM32.
Ja nie mówię, że STM jest zły. Po prostu świat idzie do przodu i opieranie
się na "gołym metalu", jakikolwiek szlachetny on by nie był, nie wnosi nic
nowego.
To tak jak z Indianami i przysłowiowymi koralikami i lusterkami, które im z
Europy przywożono; ładnie błyszczały, kolorowe były, ale i tak nic nowego
nie wnosiły, bo naprawdę wartościowe było złoto.


jp