heby <h...@p...onet.pl> napisał(a):
> Jesli ktoś bierze Cortexa w celu miganioa diodą to jest to dupny procesor
> do prostego zadania. Cena mikrokontolerów o dużej komplikacji spada do
> wartosci przy której *równie* dobrze można brać Cortexa do migania diodą
> jak i dwa tranzystory. Problem tylko w tym czy aby na tym Cortexie nie
> znajdziesz FreeRTOSa, bo akurat programista tylko to potrafił ... co może
> być piękniejszego niż deadlock wątków na preemptive multitasking, przy
> zadaniu z okolicy migania diodą? Takich faili bedzie coraz więcej ponieważ
> pojemności i wydajności mikrokontrolerów rosną a ceny spadają. Miałem w
> ręku fabryczny konwerter rs485 na ethernet. W środku miał linuxa
> (podobno). Od podpięcia zasilania do zadziałania potrzebował koło 30
> sekund. Uwierzyłem na słowo w tego Linuxa, nijak inaczej tego nie dało się
> wytłumaczyć.

OK, czyli dajmy programistom procki z 1 kB ROM i 64 bajtami RAM. Wtedy nie
będą popełniać błędów.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

Janusz <j...@o...pl> wrote:
> Przeczyta?em ciekawy blog, autor widac wi o czym pisze wi?c przyjmuj? ?e
> to nie fake_new. Wi?c do rzeczy
>
> Jest sobie w usa du?a firma samolotowa kt?rej g??wny konkurent w europie
> w pewnym momencie zrobi? lepszy samolot, wi?c jest wielka panika i praca
> na szybko, samolot nowy si? d?ugo robi i testuje wi?c bierzemy to co ju?
> jest i poprawiamy, co si? mo?e nie uda??
> okazuje si? ?e prawie wszystko.
> Silniki za s?abe, no to dajemy mocniejsze,
> nie mieszcz? si? w gondolach no to przesu?my je,
> samolot straci? stateczno??, no to sztucznie j? naprawmy, dajmy komputer,
> co mamy? stare z '96 16bitowe jednostki,
> za s?abe? no to dajmy dwa,
> Co si? mo?e nie uda??
> Wszystko, dwa rozwalone samoloty i 346 ofiar zmusi?o ich w ko?cu
> do uziemienia wszystkich B737MAX.
> https://antyweb.pl/dwa-16-bitowe-komputery-z-1996-ma
ja-naprawic-konstrukcyjne-bledy-boeinga-737-max-nie-
wiem-jak-wy-ale-ja-do-takiego-samoloty-nie-wsiade/
>

O B737MAX sporo napisano. Ten tytul wyraznie wskazuje ze autor
malo wie o dostepnych informacjach (albo celowo chce propagowac
swoje pomysly). Krotko:

1) podstawowy problem to kierownictwo. System ktory spowodawal katastrofy
zakwalifikowano jako "niekrytyczny", ot mala pomoc dla pilota, jak
sie go wylaczy to samolot bez problemu dalej bedzie lecial
2) bez korekty komputera B737MAX latal OK, ale inaczej niz B737. To
wymagaloby przeszkolenia pilotow. Z korekta komputerowa B737MAX
niby byl zgodny z B737...
3) jedna (a moze nawat obie) katastrofy zaczely sie od awarii czujnika.
Kazdy komputer mial swoj czujnik i nie mial dostepu do drugiego.
Jak czujnik nawalil to komputer probowal korygowac "bledny" kat
natarcia i rabnal w ziemie. Zaloga miala kilkadziesiat sekund
by wylaczyc "korekte". Bylo doniesienie o przynajmniej jednym
niedoszlym wypadku gdzie zaloga zdazyla... Wiekszosc zalog nie
wiedziala jak sie wylacza "korekte".
4) byla mowa o sporej ilosci decyzji kierownictwa gdzie probowano
obnizac koszty i ktore sie przyczynialy do nizszej jakosci.

Gdyby nie 1) to system wymagalby pelnej procedury dopuszczenia, z
rozsadna szansa na wylapanie problemow. Wymagalby tez nadmiarowych
czujnikow.

Mozna powiedzic ze technicznie glownym problemem bylo oprogramowanie,
np. korekta miala byc rzedu 2 stopni a oprogamowanie bez zastanowienia
walilo 70.

Ograniczona wydajnosc starych komputerow to tylko jeden czynnik,
ja bym powiedzial ze najmniej istotny.

--
Waldek Hebisch

do góry

On 29/04/2020 22:57, Mirek wrote:
> A co w tym dziwnego?

"Dzięki" linuxowi dodano przeogromną warstwę zbędnego software.

Zaznaczam że urządzenie ma otworzyć port TCP i przesyłać bajty z prawa
na lewo. I nic więcej. Nie ma tam nawet konfiguracji przez jakiegoś
weba, tylko stosuje się aplikację na komputer do zmian, a tych zmian
jest aż jedna: czy adres z dhcp czy stały.

> To na czym byś to zrobił?

Na małych biblitekach TCP które nie wymagają Linuxa. Wstawał by w
milisekundę, używałby mniejszego CPU, byłby łatwiej ogarnialny
softwareowo, ufałbym mu bardziej.

To nie jest problem wyssany z palca, byłem przekonany że problem braku
działania jest w moim kodzie. Dopiero właściciel tego cuda oświecił mnie
że potrzebuje 30 sek na wystartowanie.

do góry

On 29/04/2020 23:11, Zbych wrote:
>> A tak konkretnie to np. interfejs Renault Clip.
> No i dalej nic o tym dupnym Corteksie.

Bo to było o FPGA.

>> ceny spadają. Miałem w ręku fabryczny konwerter rs485 na ethernet. W
>> środku miał linuxa (podobno). Od podpięcia zasilania do zadziałania
>> potrzebował koło 30 sekund. Uwierzyłem na słowo w tego Linuxa, nijak
>> inaczej tego nie dało się wytłumaczyć.
> I powinieneś się cieszyć, że masz tam porządnie napisany stos tcp, który
> przeszedł niejeden chrzest bojowy a nie kolejne dzieło wystrugane na
> kolanie.

Innymi słowy aby mieć porządny stos TCP/IP musisz mieć solidny procesor
z MMU, kilkadziesiąt MB biblitek do obsługi preemptive mutitaskingu,
filesystemu, logowania, praw dostępu, obsługi eventów, oopsy do kompletu
i koniecznie jakiegoś backdoora. I to wszystko aby przesłać kilka bajtów
z lewa na prawo.

Tak, właśnie o tym mówie. Cortexy do migania diodą.

do góry

On 29/04/2020 23:38, Grzegorz Niemirowski wrote:
> OK, czyli dajmy programistom procki z 1 kB ROM i 64 bajtami RAM. Wtedy
> nie będą popełniać błędów.

Błedy które przyszły z Linuxem, są wyeliminowane, zostajesz z milion
razy mniejszą bazą kodu nad którym masz kontrolę, który można poddać
audytowi, można zweryfikować formalnie, pokryć w 100% coverage testowym.
W przypadku aplikacji krytycznych to może być kluczowe do dopuszczenia z
zastowoaniach typu "samoloty".

Dodatkowo 64 bajty ramu to zdecydowanie za dużo na miganie diodą.

Nie wykluczam jednak że gdzieś znajdę projekt migania odiodą na R-Pi. No
bo czemu w zasadzie nie ...

do góry

On 30.04.2020 08:45, heby wrote:
> On 29/04/2020 23:11, Zbych wrote:
>>> A tak konkretnie to np. interfejs Renault Clip.
>> No i dalej nic o tym dupnym Corteksie.
>
> Bo to było o FPGA.

Ale ja nie pytałem o FPGA.

>>> ceny spadają. Miałem w ręku fabryczny konwerter rs485 na ethernet. W
>>> środku miał linuxa (podobno). Od podpięcia zasilania do zadziałania
>>> potrzebował koło 30 sekund. Uwierzyłem na słowo w tego Linuxa, nijak
>>> inaczej tego nie dało się wytłumaczyć.
>> I powinieneś się cieszyć, że masz tam porządnie napisany stos tcp,
>> który przeszedł niejeden chrzest bojowy a nie kolejne dzieło
>> wystrugane na kolanie.
>
> Innymi słowy aby mieć porządny stos TCP/IP musisz mieć solidny procesor
> z MMU, kilkadziesiąt MB biblitek do obsługi preemptive mutitaskingu,
> filesystemu, logowania, praw dostępu, obsługi eventów, oopsy do kompletu
> i koniecznie jakiegoś backdoora. I to wszystko aby przesłać kilka bajtów
> z lewa na prawo.

Jeśli ten procesor i RAM kosztuje grosze to czemu nie? Wolę mieć
przetestowany soft, który pracuje na milionach serwerów 24/7 i który nie
klęknie po dostaniu kilku niezakończonych handshaków, albo stada
pofragmentowanych pakietów. A także taki, który będzie można rozbudować
o szyfrowanie transmisji, VPN jeśli będzie to konieczne.

do góry

On 30/04/2020 09:33, Zbych wrote:
>> Innymi słowy aby mieć porządny stos TCP/IP musisz mieć solidny
>> procesor z MMU, kilkadziesiąt MB biblitek do obsługi preemptive
>> mutitaskingu, filesystemu, logowania, praw dostępu, obsługi eventów,
>> oopsy do kompletu i koniecznie jakiegoś backdoora. I to wszystko aby
>> przesłać kilka bajtów z lewa na prawo.
> Jeśli ten procesor i RAM kosztuje grosze to czemu nie?

Ponieważ każda z tych zbędnych warstw wprowadza dodatkowe miejsca gdzie:
a) czają sie błędy
b) nie da się czegoś zweryfikować
c) zwiększają czasy reakcji
d) zwiększają złożoność setki razy powyżej spodziewanej

W sytuacji gdy chcesz to wsadzić do urządzenia podlegającego jakiejś
certyfikacji każda z tych rzeczy jest kłopotliwa bądź niemożliwa do
przepchnięcia.

> Wolę mieć
> przetestowany soft

Czyli Linux odpada. Chyba że zakładasz że "przetestowany" oznacza milion
instalcji Ubuntu do oglądania porno na pecetach. Obawiam się że
"przetestowany" może nie dotyczyć konkretnego niszowego rdzenia uC.

> , który pracuje na milionach serwerów 24/7

A one zaś wszystkie pracują na Twoich mikrokontolerach ...

Zaznaczam że fakt odpalenia się Linuxa na jakimś rdzeniu CPU nie oznacza
że będzie "przetestowany". W zasadzie błedy krytyczne spotykane są do
dzisiaj, a im mniej popularna platforma tym jest ich więcej. A że
platformy dla linuxa są skomplikowane z definicji, no to wiadomo że
łatwo nie będzie ...

Z drugiej strony jeśli weźmiesz jakiś procesor o prostej konstrukcji,
szanse na błędy w obsłudze hardware maleją. Możesz pisać na odpierdol i
zakładać że jak coś padnie to się najwyżej zrestartuje, ale są miejsca
gdzie jak coś padnie to spadnie. Na da się pisać bezbłednie, ale znamy
metody eliminacji błędów na etapie produkcji kodu, zdecydowana większosc
z nich nie jest w stanie ogarność złożonych systemów jak linux.

> i który nie
> klęknie po dostaniu kilku niezakończonych handshaków

Za to klęknie bo kto zapomniał wyłaczyc loga aż zajechało cały
filesystem. Albo klęknie bo masz buga w preemptive multitaskingu który
wysoczył dopiero po 40 miesiącach nieprzerwanej pracy bo się hardwareowy
licznik przekręcił. Albo okazało się że to przerwanie nigdy nikomu nie
przyszło w tym samym momencie co operacja na Flashu, a Ty jesteś
pionierem. Możesz pozerkać na grupy dysusyjne OpenWRT gdzie ludzie
miewali dokładnie takie zabawne problemy z tym "przetestowanym linuxem"
jak przerwania rebootujące system, problemy z koherencją cache itd itp.
I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC. I
jakimś trafem fakt że milion instancji Ubuntu do oglądania porno nijak
nie poprawia stabilności jajka w SoC Atherosa.

>, albo stada
> pofragmentowanych pakietów.

Co akurta jest oczywistym problemem do rozwiązania jak się pisze stos
TCP. Oczywiście można napisać kiepski stos TCP. Ale szczęśliwie lata
60te w programowaniu minęły, teraz mamy techniki zapewniajace jakość i
pilnujące specyfikacji.

> A także taki, który będzie można rozbudować
> o szyfrowanie transmisji, VPN jeśli będzie to konieczne.

Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w
perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak co
dzień.

do góry

W dniu 2020-04-30 o 08:40, heby pisze:
> On 29/04/2020 22:57, Mirek wrote:
>> A co w tym dziwnego?
>
> "Dzięki" linuxowi dodano przeogromną warstwę zbędnego software.
>
> Zaznaczam że urządzenie ma otworzyć port TCP i przesyłać bajty z prawa
> na lewo. I nic więcej. Nie ma tam nawet konfiguracji przez jakiegoś
> weba, tylko stosuje się aplikację na komputer do zmian, a tych zmian
> jest aż jedna: czy adres z dhcp czy stały.
>
>> To na czym byś to zrobił?
>
> Na małych biblitekach TCP które nie wymagają Linuxa. Wstawał by w
> milisekundę, używałby mniejszego CPU, byłby łatwiej ogarnialny
> softwareowo, ufałbym mu bardziej.
>
> To nie jest problem wyssany z palca, byłem przekonany że problem braku
> działania jest w moim kodzie. Dopiero właściciel tego cuda oświecił mnie
> że potrzebuje 30 sek na wystartowanie.

Coś podobnego widuję u siebie.
Router Drayteka wstaje w kilka, góra kilkanaście sekund.
Natomiast różne acery, tp-linki czy inne podobne potrzebują nierzadko
ponad dwie minuty, pomimo, że ich funkcjonalność jest kilkukrotnie
mniejsza od najprostszego drayteka.

Ostatnio, co zobaczyłem: iluminofonię robiło się na kilku tranzystorach.
Włączało się i działała natychmiast.
Teraz do tego zaprząga się komputery jednoukładowe albo inne dziwolągi.
Startuje to długo, pokazuje czasem nie wiadomo co, potrafi się zawiesić.


--
Pozdrawiam.

Adam

do góry

On 30.04.2020 10:05, heby wrote:

> Z drugiej strony jeśli weźmiesz jakiś procesor o prostej konstrukcji,
> szanse na błędy w obsłudze hardware maleją. Możesz pisać na odpierdol i
> zakładać że jak coś padnie to się najwyżej zrestartuje, ale są miejsca
> gdzie jak coś padnie to spadnie. Na da się pisać bezbłednie, ale znamy
> metody eliminacji błędów na etapie produkcji kodu, zdecydowana większosc
> z nich nie jest w stanie ogarność złożonych systemów jak linux.

Ostatnio oglądałem fajną prezentację włamania do SoC odpowiedzialnego za
deszyfrowanie strumienia video. W środku klon prostego 6502, któremu
wystarczyło wstrzyknąć kod do pamięci RAM i "potrząsnąć" trochę
zasilaniem, żeby się wykrzaczył i zaczął wykonywać ten kod z RAMu. Ta
sama sztuczka nawet na Cortexie-M0 ma małą szansę powodzenia, dzięki
wykrywaniu dostępu do nieistniejących adresów i dużej przestrzeni
adresowej. Nie wspominając już o większych prockach z MMU.

> I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC. I
> jakimś trafem fakt że milion instancji Ubuntu do oglądania porno nijak
> nie poprawia stabilności jajka w SoC Atherosa.

I oczywiście potrafisz udowodnić, że problemem była ta część linuksa,
która jest wspólna dla miliona instalacji ubuntu a nie specyficzna dla
SoC Atherosa?

>> , albo stada pofragmentowanych pakietów.
>
> Co akurta jest oczywistym problemem do rozwiązania jak się pisze stos
> TCP. Oczywiście można napisać kiepski stos TCP. Ale szczęśliwie lata
> 60te w programowaniu minęły, teraz mamy techniki zapewniajace jakość i
> pilnujące specyfikacji.
>
>> A także taki, który będzie można rozbudować o szyfrowanie transmisji,
>> VPN jeśli będzie to konieczne.
>
> Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w
> perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak co
> dzień.

To, że ty nie potrzebowałeś, to nie znaczy że producent tych
przejściówek nie ma klientów, którzy tego nie potrzebują.

do góry

heby <h...@p...onet.pl> napisał(a):
> Błedy które przyszły z Linuxem, są wyeliminowane, zostajesz z milion razy
> mniejszą bazą kodu nad którym masz kontrolę, który można poddać audytowi,
> można zweryfikować formalnie, pokryć w 100% coverage testowym. W przypadku
> aplikacji krytycznych to może być kluczowe do dopuszczenia z zastowoaniach
> typu "samoloty".
> Dodatkowo 64 bajty ramu to zdecydowanie za dużo na miganie diodą.
> Nie wykluczam jednak że gdzieś znajdę projekt migania odiodą na R-Pi. No
> bo czemu w zasadzie nie ...

OK, ale ja się do Linuksa nie odnosiłem tylko do tych nieszczęsnych
Cortexów. Nie mówimy też o miganiu diodą.
Nie uważam, żeby możliwość programowania bardziej wypasionego
mikrokontrolera miała prowadzić do przerośniętego i bardziej zabugowanego
kodu. Starszy, prostszy mikrokontroler ma różne ograniczenia, które
utrudniają programowanie, mogą zwiększać ryzyko błędu i wydłużają czas
tworzenia kodu.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry