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/

--
Janusz

do góry

On 29/04/2020 20:59, Janusz wrote:
> co mamy? stare z '96 16bitowe jednostki,

Pomijając projektowanie przez księgowych, akurat stare komputery w
samolocie - tak, to ma sens.

Po piersze zapewne mają certyfikaty.

Po drugie może nawet są zweryfikowane formalnie.

Po trzecie im starsza technoogia tym lepiej, jesli latasz wysoko z uwagi
na promieniowanie.

Po czwarte, skoro latają od N lat to wszelakie problemy zostały już
dawno znalezione i wykluczone. Choćby taki detal jak wibracje, kiedyś
czytałem jak w dużych kawałkach krzemu pojawił się rezonans mechaniczny,
z drganiami obudowy, ze skutkiem którego już nie pamietam (ale fatalnym).

Moc obliczeniowa tego co lata w kosmos jest znikoma, bo wazniejsze jest
aby się bity nie przestawiały same. W samolotach może zagrożenie
mniejsze, ale ciągle większe niż na ziemii.

Ponadto prawda jest taka że wole jesli sterownik krytycznego urządzenia
zawiera minimalną ilośc kodu który został przetesowany (w tym
formalnie), natomiast wolałbym nie być podpinany pod respirator
napędzany Linuxem. Jakoś tak wszystko teraz migruje do dupnych
procesorów z okolic Cortex N+1 w celu migania diodą. Może więc decyzja
nie miała podłoża ekonomicznego, tylko ktos miał w tym Boeningu resztkę
mózgu.

do góry

heby wrote on 29.04.2020 21:15:

> Jakoś tak wszystko teraz migruje do dupnych
> procesorów z okolic Cortex N+1 w celu migania diodą.

A co takiego dupnego w nich jest?

do góry

W dniu 2020-04-29 o 21:15, heby pisze:
> On 29/04/2020 20:59, Janusz wrote:
>> co mamy? stare z '96 16bitowe jednostki,
>
> Pomijając projektowanie przez księgowych, akurat stare komputery w
> samolocie - tak, to ma sens.
>
> Po piersze zapewne mają certyfikaty.
>
> Po drugie może nawet są zweryfikowane formalnie.
>
> Po trzecie im starsza technoogia tym lepiej, jesli latasz wysoko z uwagi
> na promieniowanie.
>
> Po czwarte, skoro latają od N lat to wszelakie problemy zostały już
> dawno znalezione i wykluczone. Choćby taki detal jak wibracje, kiedyś
> czytałem jak w dużych kawałkach krzemu pojawił się rezonans mechaniczny,
> z drganiami obudowy, ze skutkiem którego już nie pamietam (ale fatalnym).
>
> Moc obliczeniowa tego co lata w kosmos jest znikoma, bo wazniejsze jest
> aby się bity nie przestawiały same. W samolotach może zagrożenie
> mniejsze, ale ciągle większe niż na ziemii.
Wszystko prawda ale, moc obliczeniowa za mała i błędy w oprogramowaniu
zawiniły w katastrofach.
"Problem w tym, że jak się wydaje, Boeing tę ,,miarę" znacznie
przekroczył, obciążając leciwe komputery masą nowych zadań związanych z
naprawą niedociągnięć fizycznych 737 Max. "
"Błędy w oprogramowaniu i przeliczaniu danych doprowadziły do dwu
katastrof, w których zginęli wszyscy pasażerowie i załogi rozbitych
Boeingów."

>
> Ponadto prawda jest taka że wole jesli sterownik krytycznego urządzenia
> zawiera minimalną ilośc kodu który został przetesowany (w tym
> formalnie), natomiast wolałbym nie być podpinany pod respirator
> napędzany Linuxem. Jakoś tak wszystko teraz migruje do dupnych
> procesorów z okolic Cortex N+1 w celu migania diodą. Może więc decyzja
> nie miała podłoża ekonomicznego, tylko ktos miał w tym Boeningu resztkę
> mózgu.
No nie
"Oczywiście nie był to jedyny czynnik prowadzący do tragedii. Kolejnym
kamykiem do ogródka Boeinga była ,,udana" próba zaoszczędzenia czasu i
pieniędzy na szkolenie pilotów dla nowych maszyn. Aby przyśpieszyć
wprowadzenie samolotu na rynek, akceptowano uprawnienia pilotów
poprzednich wersji 737, o ile Ci przerobili... godzinną lekcję na iPadzie."



--
Janusz

do góry

On 29/04/2020 21:34, Zbych wrote:
>> Jakoś tak wszystko teraz migruje do dupnych
>> procesorów z okolic Cortex N+1 w celu migania diodą.
> A co takiego dupnego w nich jest?

Do migania diodą? Wszystko. Ba, często widuje w urządzeniach wypasione
FPGA które robią trywialne rzeczy. Znajomy aktywnie piszący IP cores
(FPGA/Asic) stwierdził kiedyś że wzieli do jakiegoś projektu Zynq tylko
dlatego że mieli zespół i narzędzia do niego, choć prawda jest taka że
dało się task zrealizować troszke bardziej wypasionym AVRem. Co z
automatu oznacza że będą mieli biliard elementów biernych, duży krzem w
który łatwo trafić jakiąś zapierniczającą cząstką i znacznie większy
problem jak coś padnie. Ale tak chciał klient. Nie wiem dlaczego to
wszystki migruje w tą stronę, ale mam nadzieje że w kosmos dalej będa
latać stare RISCy czy inne MIPSy z małymi zegarami a nie najnowsze i9. W
samolotach też bym wolał sprawdzony software niż wypasiony software.

do góry

On 29/04/2020 21:44, Janusz wrote:
> Wszystko prawda ale, moc obliczeniowa za mała i błędy w oprogramowaniu
> zawiniły w katastrofach.

Niedostatecznie testowano. Albo używano technik typowych dla "młodych i
dynamicznych zespołów programistów", czyli żadnych.

Problem spadku jakosci kody dotyczy chyba całego świata. Niby masz
programistę który od 10 lat pisze kod, a po chwili okazuje się że
napierniczał javascript. Taki odpowiednik pistoletu na wodę. I właśnie
go zatrudnili w embedded. "Bo ma doświadczenie w programowaniu".

> "Problem w tym, że jak się wydaje, Boeing tę ,,miarę" znacznie
> przekroczył, obciążając leciwe komputery masą nowych zadań związanych z
> naprawą niedociągnięć fizycznych 737 Max. "

Więc winien nie jest hardware tylko zespół dyletantów którzy nie
przetestowali kodu.

> "Błędy w oprogramowaniu i przeliczaniu danych doprowadziły do dwu
> katastrof, w których zginęli wszyscy pasażerowie i załogi rozbitych
> Boeingów."

Przydało my się dowiedzieć, dokładnie, gdzie te błedy były. Może się
okazać, że jak w przypadku Toyoty, jedyne co można było zrobić to
facepalm kiedy audytor zobaczył kod którego powstydził by się student
pierszego roku informatyki.

do góry

heby wrote on 29.04.2020 21:46:
> On 29/04/2020 21:34, Zbych wrote:
>>> Jakoś tak wszystko teraz migruje do dupnych
>>> procesorów z okolic Cortex N+1 w celu migania diodą.
>> A co takiego dupnego w nich jest?
>
> Do migania diodą? Wszystko. Ba, często widuje w urządzeniach wypasione

A tak konkretnie?

> FPGA które robią trywialne rzeczy. Znajomy aktywnie piszący IP cores
> (FPGA/Asic) stwierdził kiedyś że wzieli do jakiegoś projektu Zynq tylko
> dlatego że mieli zespół i narzędzia do niego

No super, ale ja pytałem o te dupne Cortexy i nic się nie dowiedziałem.

do góry

On 29/04/2020 22:05, Zbych wrote:
>>> A co takiego dupnego w nich jest?
>> Do migania diodą? Wszystko. Ba, często widuje w urządzeniach wypasione
> A tak konkretnie?

A tak konkretnie to np. interfejs Renault Clip. W gruncie rzeczy musisz
przerzucic kilka bajtów z USB na CAN lub inny protokół samochodowy. W
jedne z wersji to sporej wielkosci metalowe pudło które w środku miało
kilkanascie scalaków, w tym FPGA [1].

Obecnie z tego co widzę wypruwając sobie żyły udało im się dojść do
przesadnie skomplikowanego uC. Jak by to jeszcze autonomiczne było w
jakimś stopniu, a to współpracuje z żenujacej jakosci oprogramowniem na
komputerze ...

> No super, ale ja pytałem o te dupne Cortexy i nic się nie dowiedziałem.

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

[1] na necie nie ma już zdjęc starego Clip-a. Są tylko te nowe z
wielgachnym CPU. Nie mogę więc podeprzeć się tym przykładem w formie
graficznej.

do góry

On 29.04.2020 22:37, heby wrote:

> Miałem w ręku fabryczny konwerter rs485 na ethernet. W
> środku miał linuxa (podobno).

A co w tym dziwnego?
To na czym byś to zrobił?

--
Mirek.

do góry

heby wrote on 29.04.2020 22:37:
> On 29/04/2020 22:05, Zbych wrote:
>>>> A co takiego dupnego w nich jest?
>>> Do migania diodą? Wszystko. Ba, często widuje w urządzeniach wypasione
>> A tak konkretnie?
>
> A tak konkretnie to np. interfejs Renault Clip.

No i dalej nic o tym dupnym Corteksie.

> 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

Wreszcie coś na temat.

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

do góry