RTV forum PL | NewsGroups PL

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

mikrokontroler military/(aero)space 8bit

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Mikrokontrolery 8-bitowe do aplikacji kosmicznych: Szukam małego rozwiązania w wersji militarnie!

Goto page Previous  1, 2

SM
Guest

Tue Feb 09, 2010 11:59 am   



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

SM
Guest

Tue Feb 09, 2010 12:11 pm   



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

Andrzej Ekiert
Guest

Tue Feb 09, 2010 12:29 pm   



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

Quote:
"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 Wink
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

Marcin Stepien
Guest

Tue Feb 09, 2010 12:55 pm   



SM pisze:
Quote:

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

SM
Guest

Tue Feb 09, 2010 3:09 pm   



Quote:
Rewelacja Wink
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

Jerry1111
Guest

Tue Feb 09, 2010 3:15 pm   



On 09/02/2010 11:29, Andrzej Ekiert wrote:
Quote:
Dnia 09-02-2010 o 12:11:21 SM <biuro@korinsj.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 Wink
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).

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

--
Jerry1111

Piotr \"Curious\" Slawins
Guest

Thu Feb 11, 2010 3:32 am   



SM wrote:

Quote:
Witam,

Poszukuję mikrokontrolerka, niewielkiego, 8bit,
coś w stylu 8051, AVR8bit, itp ale w wersji
military/(aero)space, a dokładniej to tylko "space".
hmm, tak poczytuje... moze lepiej dowiedziec sie gdzie ta

'sonda' ma leciec? bo jesli w kierunku 'od slonca' to
przeciez promieniowanie nie jest az takim problemem...

gorzej jesli w kierunku slonca ;)

i druga sprawa - moze zamiast czarowac z duplikowaniem
pamieci (przeciez to wazy...) po prostu uzyc byle jakiego
avrka czy pica + 8051 z PROM ktore bedzie mu okresowo 'odswiezac'
pamiec programu przez ISP ? Smile
powiedzmy co 1sek bedzie zatrzymywal procka, odczytywal zawartosc jego
pamieci weryfikujac ja z danymi w PROM, jesli cos sie bedzie roznic -
bedzie programowac jeszcze raz. jesli flash ulegnie uszkodzeniu - moze
czekac na dane z 'bazy' ktore bedzie wrzucac zamiast oryginalnego programu
i 'od biedy' trzymac je w SRAM.
(dzieki temu sonda nie padnie na amen, co najwyzej straci czesc
funkcjonalnosci)

no i dodatkowo mozna trzymac wazne dane w jakiejs 'odpornej' zewnetrznej
kosci (serial) flash, chocby jakas karta sd 1G - dosc miejsca zeby wszystko
zapisywac po 100x... jesli to mega wazne to mozna uzyc dwoch takich (lub
mniejszych ale bardziej odpornych na promieniowanie) kosci i umiescic je w
innych osiach, chociaz cos czuje ze maly dysk 1.8" bedzie tu lepszym
rozwiazaniem.





--

Waldemar Krzok
Guest

Thu Feb 11, 2010 9:29 pm   



Piotr "Curious" Slawinski wrote:


Quote:

i druga sprawa - moze zamiast czarowac z duplikowaniem
pamieci (przeciez to wazy...) po prostu uzyc byle jakiego
avrka czy pica + 8051 z PROM ktore bedzie mu okresowo 'odswiezac'
pamiec programu przez ISP ? Smile
powiedzmy co 1sek bedzie zatrzymywal procka, odczytywal zawartosc jego
pamieci weryfikujac ja z danymi w PROM, jesli cos sie bedzie roznic -
bedzie programowac jeszcze raz. jesli flash ulegnie uszkodzeniu - moze
czekac na dane z 'bazy' ktore bedzie wrzucac zamiast oryginalnego programu
i 'od biedy' trzymac je w SRAM.
(dzieki temu sonda nie padnie na amen, co najwyzej straci czesc
funkcjonalnosci)

no i dodatkowo mozna trzymac wazne dane w jakiejs 'odpornej' zewnetrznej
kosci (serial) flash, chocby jakas karta sd 1G - dosc miejsca zeby
wszystko zapisywac po 100x... jesli to mega wazne to mozna uzyc dwoch
takich (lub mniejszych ale bardziej odpornych na promieniowanie) kosci i
umiescic je w innych osiach, chociaz cos czuje ze maly dysk 1.8" bedzie tu
lepszym rozwiazaniem.

To może od razu dysk 8" Wink. Jak dysk, to lepiej mniejszy dać, po grzyba
1.8". Mam 0.85", 6GB. Kosztuje ok. 25$. Najlepszy byłby fusible link prom,
ale takich już chyba nie uświadczysz, choć pewnie gdzieś by się 16k czy 32k
jeszcze znalazły. Na program więcej nie potrzeba. Twardy dysk ma pewne
problemy, musisz draństwo ogrzewać lub chłodzić. Bardzo nie lubią próżni
(wiem z doświadczenia). Przy starcie masz dość duże przeciążenia. Choć przy
użyciu rosyjskich rakiet największe przeciążenia i wahania temperatur są
podczas transportu kolejowego do Kazachstanu (to nie kawał!!).

Waldek

Michał Baszyński
Guest

Fri Feb 12, 2010 11:43 pm   



W dniu 2010-02-11 21:29, Waldemar Krzok pisze:
Quote:
Twardy dysk ... Bardzo nie lubią próżni (wiem z doświadczenia)

bo głowice nie mają na czym wisieć?

--
Pozdr.
Michał

Butek
Guest

Sat Feb 13, 2010 12:07 am   



W dniu 10-02-11 21:29, Waldemar Krzok pisze:
Quote:
Bardzo nie lubią próżni (wiem z doświadczenia).

Tak z ciekawosci: chodzi o proznie "na zewnatrz", prawda? Czy to tylko
mit, ze obudowa dysku twardego jest dosc porzadnie hermetyczna?

--
butek
Safety note: Don't put all your enriched uranium hexafluoride in one
bucket. Use at least two or three buckets and keep them in separate
corners of the room. This will prevent the premature build-up of a
critical mass.

Maciek
Guest

Sat Feb 13, 2010 2:00 am   



Użytkownik Butek napisał:
Quote:
Tak z ciekawosci: chodzi o proznie "na zewnatrz", prawda? Czy to tylko
mit, ze obudowa dysku twardego jest dosc porzadnie hermetyczna?

Nie jest hermetyczna. Ma papierową naklejkę - filtr.


badworm
Guest

Sun Feb 14, 2010 9:04 pm   



Dnia Sat, 13 Feb 2010 00:07:38 +0100, Butek napisał(a):

Quote:
Tak z ciekawosci: chodzi o proznie "na zewnatrz", prawda? Czy to tylko
mit, ze obudowa dysku twardego jest dosc porzadnie hermetyczna?

Oczywiście, że mit. Otwór służący do wyrównywania ciśnienia jest
zaklejony filtrem, który został tak dobrany, by się nie zużył przez cały
zakładany okres życia dysku.
--
Pozdrawiam Bad Worm badworm[maupa]post{kopek}pl
GG#2400455 ICQ#320399066

Goto page Previous  1, 2

elektroda NewsGroups Forum Index - Elektronika Polska - Mikrokontrolery 8-bitowe do aplikacji kosmicznych: Szukam małego rozwiązania w wersji militarnie!

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map