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