> W swoim czasie NASA skupowała płyty główne od PC/XT celem pozyskania
> procesorów i8088. Bo dobrze przetestowane i ze względu na szerokość
> ścieżki odporne na promieniowanie kosmiczne. Pathfinder wysłany na
> Marsa miał w sobie Z80. Też z podobnych powodów. Może też pójść tą
> drogą? Stary, poczciwy i stylowy 8051 nie spełnia wymagań?

Jeśli coś z rodziny 8051 to z kilkukanałowym ADC, więc
"stare" 8051 intela odpadają. Do tego nie wiem jakby
wyglądał pobór prądu.

SM

do góry

> jak wysoko chcesz lecieć ?? jak nie wyżej niż 30km to atmega 8 swobodnie
> daje rade. kilkanaście razy ten proc jak i podobne wysłałem nawet powyżej
> 30km i działały bez problemu, wróciły całe i zdrowe.

Duuużo dalej i na długo.

SM

do góry

> Niska orbita czy przestrzeń międzyplanetarna? Na jak długo? "Zyciowo ważne",
> czy może się czasem mylić?

Bardzo daleko i na długo.

> FLASH nie jest zbyt dobrym rozwiązaniem, OTP jeszcze gorszym,

No to tutaj źle myślałem. Sądziłem że to OTP "wypali" się na stałe
(coś jak PROM) a FLASH może się rozprogramowywać.

> chyba, że
> włożysz trochę pomyślunku. Procesor jest prawie obojętny, jak wystarczy 8051
> to bierz, najlepiej w wersji PROM,

Standardowy 8051 nie ma kilukanałowego ADC.

> Na pokładzie ISS jest kupa IBM790 laptopów z FLASH-PROMami na burcie.Nasz
> Dolch też nie miał żadnych problemów z przekłamaniami we Flashu. Seryjne
> EEPROMy na naszych kartach są jednak programowane na nowo (z twardego dysku)
> przy każdym starcie urządzenia. OK, przy max. 1000 startach programu przez 8
> lat można sobie na to pozwolić.

Trochę zbyt skomplikowane jak układzik który miałby
tylko zrobić kilka pomiarów ADC i puścić to na RSa.

> Największym problemem jest robota papierkowa. Możesz coś więcej napisać co
> robisz i gdzie to ma lecieć?

Dokładnie nie wiem. Chyba jakaś sonda.

> W przypadku agencji kosmicznych musisz zrobić testy na wibracje, gazowanie,
> palność w atmosferze tlenowej, trucizny, stabilność mechaniczną,
> bezpieczeństwo aktywne i pasywne, i cyliony innych rzeczy.

A to już nie moja brocha. Ja miałbym tylko zrobić
niewielki, mały "kawałek".

>
> Waldek

SM

do góry

>
> Niska orbita czy przestrzeń międzyplanetarna? Na jak długo? "Zyciowo ważne",
> czy może się czasem mylić?
> FLASH nie jest zbyt dobrym rozwiązaniem, OTP jeszcze gorszym, chyba, że
> włożysz trochę pomyślunku.

Tak właśnie zastanawiałem się również nad stroną programową.

Czy nie dobrym rozwiązaniem by było zrobienie procka
na "superodpornym" FPGA. Rejestry i "trochę" roboczego
RAMu na zmienne siedziałoby też w FPGA. Do niego podpiąć
pamięć FLASH z programem.

"Procek" w FPGA pobierałby kod programu z FLASHa i działał
jak interpreter choćby nawet BASICa. Każdy token byłby zapisany
wielobajtowo (co najmniej 2 bajty), np. pierwszy bajt - kod tokena
, drugi bajt jego XOR 255. Albo też więcej bajtów z sumą CRC.
Mamy więc kontrolę czy program we FLASH nie uległ samomodyfikacji.
Drugi plus to stała długość każdej instrukcji.
Program w pamięci FLASH byłby zapisany np. trzykrotnie.
Niech ma długość 1KB. Mamy więc program od 0 do 1023. Potem
to samo od 1024 do 2047 i znów to samo od 2048 do 3072.
FPGA leci normalnie z programem od 0 do 1023, jeśli nie zgodzi
mu się CRC na instrukcji to wtedy dodaje offset + 1024
i próbuje pobrać instrukcję z jej kopii. Jeśli znów błąd
to znów z kolejnej.

Albo jeszcze lepiej. Podłączone do FPGA kilka zewnętrznych
pamięci FLASH. Powiedzmy 3. Przy pobieraniu kolejnej
instrukcji FPGA zmienia nr FLASH z którego pobiera instrukcję
(dzięki temu w kółko przemieli i zweryfikuje każdego FLASHa)
Jeśli stwierdzi błąd, wówczas przeprogramowuje błędny sektor
w uszkodzonym FLASH korzystając z danych zawartych w dwóch
pozostałych FLASHach.

Mamy samonaprawiający się układ do tego jeszcze z możliwością
zdalnego przeprogramowania.


Chyba w wolnej chwili spróbuję taką zabawkę sobie zrobić :)
Kiedyś pisałem kompilatory i interpretery więc nie będzie
z tym większego problemu.

Pozdrawiam,
SM

do góry

SM wrote:

>> Niska orbita czy przestrzeń międzyplanetarna? Na jak długo? "Zyciowo
>> ważne", czy może się czasem mylić?
>
> Bardzo daleko i na długo.
>
>> FLASH nie jest zbyt dobrym rozwiązaniem, OTP jeszcze gorszym,
>
> No to tutaj źle myślałem. Sądziłem że to OTP "wypali" się na stałe
> (coś jak PROM) a FLASH może się rozprogramowywać.

OTP jest praktycznie EPROMem. Flash też, ale ma już wbudowany CRC, więc jest
trochę lepszejszy ;-). Aha, oczywiście musisz wziąć SLC-Flash.

>> chyba, że
>> włożysz trochę pomyślunku. Procesor jest prawie obojętny, jak wystarczy
>> 8051 to bierz, najlepiej w wersji PROM,
>
> Standardowy 8051 nie ma kilukanałowego ADC.
>
>> Na pokładzie ISS jest kupa IBM790 laptopów z FLASH-PROMami na burcie.Nasz
>> Dolch też nie miał żadnych problemów z przekłamaniami we Flashu. Seryjne
>> EEPROMy na naszych kartach są jednak programowane na nowo (z twardego
>> dysku) przy każdym starcie urządzenia. OK, przy max. 1000 startach
>> programu przez 8 lat można sobie na to pozwolić.
>
> Trochę zbyt skomplikowane jak układzik który miałby
> tylko zrobić kilka pomiarów ADC i puścić to na RSa.
>
>> Największym problemem jest robota papierkowa. Możesz coś więcej napisać
>> co robisz i gdzie to ma lecieć?
>
> Dokładnie nie wiem. Chyba jakaś sonda.
>
>> W przypadku agencji kosmicznych musisz zrobić testy na wibracje,
>> gazowanie, palność w atmosferze tlenowej, trucizny, stabilność
>> mechaniczną, bezpieczeństwo aktywne i pasywne, i cyliony innych rzeczy.
>
> A to już nie moja brocha. Ja miałbym tylko zrobić
> niewielki, mały "kawałek".

No to masz szczęście, choć mnie to nie ominęło.
Pomysł z wielokrotnym zapisem programu jest niegłupi. Ewentualnie, jak już
chcesz robić voting, to dać flashe różnych producentów. Tylko kwestia wagi
całości. Pewnie wystarczy jeden.
Aha, tak apopos: ekranowanie całości może pogorszyć sprawę. Kumpel mi
tłumaczył, że ekranowanie spowalnia wysokoenergetyczne cząstki, które mają
szansę "przeprogamować" komórki pamięci, lub nawet uszkodzić procesor.
Cząstki wysokoenergetyczne przelatują bez problemu.

Waldek

do góry

>...
> No to masz szczęście, choć mnie to nie ominęło.
> Pomysł z wielokrotnym zapisem programu jest niegłupi. Ewentualnie, jak już
> chcesz robić voting, to dać flashe różnych producentów. Tylko kwestia wagi
> całości. Pewnie wystarczy jeden.


Pewnie tak. Kwestia prawdopodobieństwa zmiany FLASHa. Można by
w jednym FLASHu wgrać ten sam soft np. 4 razy i w przypadku
błędu przeprogramować zły sektor pobierając dane z 3 pozostałych
dobrych banków programu (chociaż jeden z 3 pozostałych
to już chyba na pewno będzie OK).

W sumie to nawet nie trzeba robić interpretera języka
wyższego poziomu. Wystarczyłby rdzeń jakiegoś procka z dodanym
bajtem kontrolnym dla każdej instrukcji procesora.
Sprawę również polepszy i uprości stała długość
kodów rozkazu.

To samo można by zrobić z RAM dla zmiennych.

Dajemy 3 RAMy. Wspólna szyna adresowa, szyna danych
(załóżmy 8 bitów D0..D7) każdej pamięci osobno, ale
schodzi się razem za dwukierunkowymi buforami
(coś w stylu 74245). Czyli FPGA ma szynę danych tylko 8 bit.
Zapis odbywa się tak, że bufory otwieramy w kierunku
do RAM, WR i CE sterujemy razem. Wszystkie 3 RAMy
zostają zapisane tak samo.
Odczyt otwiera tylko jeden bufor, po czym RD i CE
znów sterujemy razem. Zwarcia na lini danych
nie będzie, bo pozostałe dwa bufory nie puszczają.

I teraz mały numer. Do linii danych pamięci RAM
podłączamy komparatory 8 bit. Jeden porównuje
8bit D0..D7 pamięci nr 1 z pamięcią nr 2.
Drugi porównuje 8bit D0..D7 pamięci nr 2 z 3,
a trzeci 1 z 3. Każdy z 3 komparatorów daje
sygnał do FPGA że jest nierówność. FPGA wtedy
wie, która kość ma złą (zmienioną) wartość -
tylko jedno wejście będzie sygnalizować równość.
Wtedy procek ponawia odczyt ale z buforem
otwartym tylko na jednej z dwóch dobrych RAM, po czym
od razu robi zapis "naprawiający" do wszystkich
trzech RAM.

Szybkie, łatwe, sprzętowe, nie wymaga dodatkowych
obliczeń (jakaś CRC), i do tego "naprawialne".

SM

do góry

> ...
> Dajemy 3 RAMy. Wspólna szyna adresowa, szyna danych
> (załóżmy 8 bitów D0..D7) każdej pamięci osobno, ale
> schodzi się razem za dwukierunkowymi buforami
> (coś w stylu 74245). Czyli FPGA ma szynę danych tylko 8 bit.
> Zapis odbywa się tak, że bufory otwieramy w kierunku
> do RAM, WR i CE sterujemy razem. Wszystkie 3 RAMy
> zostają zapisane tak samo.
> Odczyt otwiera tylko jeden bufor, po czym RD i CE
> znów sterujemy razem. Zwarcia na lini danych
> nie będzie, bo pozostałe dwa bufory nie puszczają.
>
> I teraz mały numer. Do linii danych pamięci RAM
> podłączamy komparatory 8 bit. Jeden porównuje
> 8bit D0..D7 pamięci nr 1 z pamięcią nr 2.
> Drugi porównuje 8bit D0..D7 pamięci nr 2 z 3,
> a trzeci 1 z 3. Każdy z 3 komparatorów daje
> sygnał do FPGA że jest nierówność. FPGA wtedy
> wie, która kość ma złą (zmienioną) wartość -
> tylko jedno wejście będzie sygnalizować równość.
> Wtedy procek ponawia odczyt ale z buforem
> otwartym tylko na jednej z dwóch dobrych RAM, po czym
> od razu robi zapis "naprawiający" do wszystkich
> trzech RAM.
>

Tak teraz pomyślałem że to jest rzeczywiście dobre!

"Zwykły" głupi procek z jedną szyną danych i adresową
oraz sygnałem HALT czy coś takiego.
3 kości SRAM na zmienne, 3 kości FLASH na program.
Pomiędzy nimi pośredniczy FPGA. Zapis do 3 RAM jedno
cześnie, zapis do FLASH jednocześnie, odczyt z jednej
RAM i jednego FLASH. W momencie odczytu i stwierdzeniu
przez FPGA nierówności, procek dostaje HALT na bieżący
cykl odczytu po czym FPGA przeprowadza operację
"naprawczą". Po czym puszcza procek dalej.

Oczywiście procek musiałby okresowo odczytywać
np. w przerwaniu bajt po bajcie cały RAM i FLASH
aby wymusić okresowe kontrole zmiany bajtów
w pamięciach. No albo przerzucić to na FPGA
i przyblokowywać procek - coś jak odświeżanie DRAM.

SM

do góry

Dnia 09-02-2010 o 12:11:21 SM <b...@k...com.pl> napisał(a):

> "Zwykły" głupi procek z jedną szyną danych i adresową
> oraz sygnałem HALT czy coś takiego.
> 3 kości SRAM na zmienne, 3 kości FLASH na program.
> Pomiędzy nimi pośredniczy FPGA.


Rewelacja ;-)
A teraz weź pod uwagę, że konfiguracja FPGA to też RAM i
prawdopodobieństwo jego przekłamania jest podobne, jak przekłamania RAMu
przez to FPGA nadzorowanego. CPLD też nie rozwiązuje problemu, z tej
prostej przyczyny, że jego konfiguracja to prawdopodobnie EEPROM lub Flash
i "szansa" że się przekłamie jest podobna, jak w przypadku nadzorowanej
pamięci (zakładając, że są wykonane w tej samej technologii - może się
okazać, że sama pamięć była bardziej odporna).

Sorry :-P

ae

do góry

SM pisze:
>>
>> Niska orbita czy przestrzeń międzyplanetarna? Na jak długo? "Zyciowo
>> ważne", czy może się czasem mylić?
>> FLASH nie jest zbyt dobrym rozwiązaniem, OTP jeszcze gorszym, chyba,
>> że włożysz trochę pomyślunku.
>
> Tak właśnie zastanawiałem się również nad stroną programową.
>
> Czy nie dobrym rozwiązaniem by było zrobienie procka
> na "superodpornym" FPGA. Rejestry i "trochę" roboczego
> RAMu na zmienne siedziałoby też w FPGA. Do niego podpiąć
> pamięć FLASH z programem.
>
> "Procek" w FPGA pobierałby kod programu z FLASHa i działał
> jak interpreter choćby nawet BASICa. Każdy token byłby zapisany
> wielobajtowo (co najmniej 2 bajty), np. pierwszy bajt - kod tokena
> , drugi bajt jego XOR 255. Albo też więcej bajtów z sumą CRC.
> Mamy więc kontrolę czy program we FLASH nie uległ samomodyfikacji.
> Drugi plus to stała długość każdej instrukcji.
> Program w pamięci FLASH byłby zapisany np. trzykrotnie.
> Niech ma długość 1KB. Mamy więc program od 0 do 1023. Potem
> to samo od 1024 do 2047 i znów to samo od 2048 do 3072.
> FPGA leci normalnie z programem od 0 do 1023, jeśli nie zgodzi
> mu się CRC na instrukcji to wtedy dodaje offset + 1024
> i próbuje pobrać instrukcję z jej kopii. Jeśli znów błąd
> to znów z kolejnej.
>
> Albo jeszcze lepiej. Podłączone do FPGA kilka zewnętrznych
> pamięci FLASH. Powiedzmy 3. Przy pobieraniu kolejnej
> instrukcji FPGA zmienia nr FLASH z którego pobiera instrukcję
> (dzięki temu w kółko przemieli i zweryfikuje każdego FLASHa)
> Jeśli stwierdzi błąd, wówczas przeprogramowuje błędny sektor
> w uszkodzonym FLASH korzystając z danych zawartych w dwóch
> pozostałych FLASHach.
>
> Mamy samonaprawiający się układ do tego jeszcze z możliwością
> zdalnego przeprogramowania.
>
>
> Chyba w wolnej chwili spróbuję taką zabawkę sobie zrobić :)
> Kiedyś pisałem kompilatory i interpretery więc nie będzie
> z tym większego problemu.
>
> Pozdrawiam,
> SM

Witam.
Proponuje lekture nt. bledow typu SEU (single event upset) i sposobach
ich korekcji.

Pozdrawiam
Marcin Stepien

do góry

> Rewelacja ;-)
> A teraz weź pod uwagę, że konfiguracja FPGA to też RAM i
> prawdopodobieństwo jego przekłamania jest podobne, jak przekłamania RAMu
> przez to FPGA nadzorowanego. CPLD też nie rozwiązuje problemu, z tej
> prostej przyczyny, że jego konfiguracja to prawdopodobnie EEPROM lub
> Flash i "szansa" że się przekłamie jest podobna, jak w przypadku
> nadzorowanej pamięci (zakładając, że są wykonane w tej samej technologii
> - może się okazać, że sama pamięć była bardziej odporna).
>
> Sorry :-P
>
> ae

To trzeba zrobić gotowca - scalak który będzie obsługiwał
w opisany przeze mnie sposób 3 RAMy a nie korzystać
z układów programowalnych - aby mieć przynajmniej
jeden element który będzie w 99,99999...% bezbłędny.

SM

do góry