Mikrokontrolery 8-bitowe do aplikacji kosmicznych: Szukam małego rozwiązania w wersji militarnie!

Mon Feb 08, 2010 6:49 pm   

Witam,

Poszukuję mikrokontrolerka, niewielkiego, 8bit,
coś w stylu 8051, AVR8bit, itp ale w wersji
military/(aero)space, a dokładniej to tylko "space".

Narazie nie wiem jakie dokładnie miałby mieć
wymagania, ale zapewne:
- temp. -55..+125 st.C. (to ma nawet ATmega32)
- zapewne OTP, bo nie wiem jaki wpływ będzie miało
promieniowanie kosmiczne na FLASH
- niewielki pobór prądu.

Co ciekawe, tutaj wyczytałem:

http://www.microcontroller.com/news/microchip_SuitSat1_NASA.asp

że poszedł nawet PIC18F8722.

Czy ktoś się orientuje, czego właściwie można by
użyć? Coś niewielkiego, 8bit.

Pozdrawiam,
SM

Mon Feb 08, 2010 7:10 pm   

Witam

Konkretnej rekomendacji ci nie podam, ale może zacząć tutaj:

http://klabs.org/index_klabs_dot_org.htm

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.

Paweł

Mon Feb 08, 2010 8:47 pm   

Pan SM napisał:


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ń?

--
Jarek

Mon Feb 08, 2010 8:52 pm   

SM wrote:

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.


--
VSS
http://vss.pl

Mon Feb 08, 2010 9:39 pm   

SM wrote:


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.

Waldek

Mon Feb 08, 2010 10:40 pm   

Jarosław Sokołowski wrote:


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.

Waldek

Mon Feb 08, 2010 10:50 pm   

Pan Waldemar Krzok napisał:


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.

--
Jarek

Mon Feb 08, 2010 11:56 pm   

Pan Waldemar Krzok napisał:


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.

--
Jarek

Tue Feb 09, 2010 12:20 am   

On Mon, 08 Feb 2010 22:40:53 +0100, Waldemar Krzok wrote:

Tak swoja droga to ciekaw jestem jak to jest z rzeczywista
odpornoscia. Male te bity na kartach, i chyba analogowe, ale i na
twardzielu domeny malutkie - promieniowane tego nie rusza ?

J.

Tue Feb 09, 2010 6:31 am   

Bardzo ciekawa stronka.


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.

Pozdrawiam,
SM

Tue Feb 09, 2010 6:32 am   

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

Tue Feb 09, 2010 6:33 am   

Duuużo dalej i na długo.

SM

Tue Feb 09, 2010 6:38 am   

Bardzo daleko i na długo.


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


Standardowy 8051 nie ma kilukanałowego ADC.


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


Dokładnie nie wiem. Chyba jakaś sonda.


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


SM

Tue Feb 09, 2010 7:04 am   

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

Tue Feb 09, 2010 10:53 am   

SM wrote:


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.

Waldek