Konkretnej rekomendacji ci nie podam, ale może zacząć tutaj:
formatting link
Informacje niestety z przed kilku lat, ale nie pytasz przecież o quad core 64 bit. TI ma u siebie trochę produktów z tego segmentu, można też ewentualnie myśleć o soft-core do jakiegoś FPGA. Zdaje się Actel coś miał. Pozdrawiam.
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ń?
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. Procesor jest prawie obojętny, jak wystarczy 8051 to bierz, najlepiej w wersji PROM, 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ć. Największym problemem jest robota papierkowa. Możesz coś więcej napisać co robisz i gdzie to ma lecieć? 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.
Z twardego dysku? Mam nadzieję, że on nie jest tam specjalnie po to. Bo chyba lepiej programować z drugiego EEPROMa (a następnie ten drugi z pierwszego). Zawsze to trochę zaoszczędzonej masy wynoszonej w kosmos.
nie. EEPROMy są na kartach w komputerze (z Windowsem 2000 na burcie), więc dysk jest i tak. Do tego dysk zmienny, na którym przesyłamy dane z kosmosu na ziemię. Kolega przesyła dane na kartach SD. Zapisuje wszystko 16 razy w różnych blokach karty. Na razie nie miał żadnych problemów i dane dawało się zawsze zrekonstruować. Ale on ma góra 20-30kB danych, my do 60GB.
Myślałem, że chodzi o chodzi o urządzenie, które jak się je kopnie na orbitę, to już z tamtąd nie wraca.
Mam teraz przed soba diwajs, który jak żeśmy projektowali, to nijak nie można było polegać na pamięci eeprom (a może flash) wbudwanej do procesora. Kazaliśmy programiscie zapisywać stałe kalibracyjne w kilku miejscach, a jak trzeba było z nich skorzystać, to rozstrzygało głosowanie.
Przebijam. Mnie był potrzebny jeden bajt. To dopiero kosmiczna technologia.
Z tego co widzę to nie tyle procki, ale właśnie FPGA są dość dobrze przebadane pod tym kątem. Do tego ciężko znaleźć procka z wymaganiami "space" a wśród FPGA wybór jest całkiem spory.
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.
OTP jest praktycznie EPROMem. Flash też, ale ma już wbudowany CRC, więc jest trochę lepszejszy ;-). Aha, oczywiście musisz wziąć SLC-Flash.
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.
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".
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.
Dnia 09-02-2010 o 12:11:21 SM snipped-for-privacy@korinsj.com.pl> napisał(a):
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).
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.
ZTCW FPGA sa dosc dobrze 'przetrenowane' pod wzgledem warunkow kosmicznych. Tylko ze nie ma po co 3 kosci pamieci - prosciej ta pamiec zrobic w srodku FPGA jesli nie trzeba megabajtow (teraz jest duzo latwiej niz np: 5 lat temu).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.