eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikamikrokontroler military/(aero)space 8bit
Ilość wypowiedzi w tym wątku: 27

  • 11. Data: 2010-02-09 05:32:43
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: SM <b...@k...com.pl>

    > 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


  • 12. Data: 2010-02-09 05:33:23
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: SM <b...@k...com.pl>

    > 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


  • 13. Data: 2010-02-09 05:38:53
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: SM <b...@k...com.pl>

    > 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


  • 14. Data: 2010-02-09 06:04:04
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: SM <b...@k...com.pl>

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


  • 15. Data: 2010-02-09 09:53:31
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: Waldemar Krzok <w...@z...fu-berlin.de>

    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


  • 16. Data: 2010-02-09 10:59:55
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: SM <b...@k...com.pl>

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


  • 17. Data: 2010-02-09 11:11:21
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: SM <b...@k...com.pl>

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


  • 18. Data: 2010-02-09 11:29:51
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: "Andrzej Ekiert" <d...@t...pl>

    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


  • 19. Data: 2010-02-09 11:55:41
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: Marcin Stepien <m...@w...pl>

    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


  • 20. Data: 2010-02-09 14:09:11
    Temat: Re: mikrokontroler military/(aero)space 8bit
    Od: SM <b...@k...com.pl>

    > 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

strony : 1 . [ 2 ] . 3


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: