> 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

> 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

> 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

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

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

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

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

Dnia 09-02-2010 o 12:11:21 SM 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

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

> 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