Jakie MCU wybrać do programowalnego timera z funkcją autodiagnostyki?

Wed Mar 08, 2017 10:21 pm   

Ok, założę nowy wątek - żeby omówić pomysł powstały pod wpływem uwag
kolegów ( i może koleżanek ?? Żadna się nie ukrywa pod nic nie znaczącym
nickiem ??).

Zatem - mam taką wizję:

Układ "timera" programowalnego, który :

- posiada licznik czasu powiedzmy 8 bitowy, odliczający od zadanego
czasu w dół. Co sekunda.

- licznik ten może być ustawiony przez MCU jakimś portem szeregowym, z
użyciem jakiegoś "adresu" czy "hasła" - aby zminimalizować ryzyko zapisu
przypadkowym ciągiem.

- jest możliwość startu i stopu - również odpowiednimi "komendami".

Po starcie, aż do osiągnięcia "0" jest aktywne wyjście "przekaźnik".
Czyli wyjście = (stan licznika > 0).

Jeżeli licznik nie zostanie zatrzymany przed odliczeniem do zera,
oczywiście wyłącza "przekaźnik", zapisuje informację o incydencie do
jakiegoś przerzutnika ( który można odczytać przez MCU ), oraz resetuje MCU.

Dodatkowo - MCU powinien mieć możliwość wyboru częstotliwości zegara
tego timera : dla normalnej pracy odliczamy co 1 Hz, oraz w drugiej
opcji jakoś szybciej.

Dlaczego ? Żeby MCU mógł podczas autodiagnostyki systemu sprawdzić
działanie tego licznika - bez konieczności czekania 255 sek.
Nie jest to ryzykowne - bo jeżeli podczas "normalnej" pracy zegar by
pracował nieprawidłowo (szybciej) to czas będzie krótszy a nie dłuższy.

Dobrze by też było, żeby oprócz zapisu licznika MCU mógł też odczytać
jego stan.

Oraz, żeby po jego zapisaniu i wystartowaniu licznik nie mógł być
ponownie zapisany aż do poprawnego zakończenia danego odliczania.



Taka mniej więcej struktura.
Jakiego typu układ programowalny byłby tu odpowiedni ? Nie za duży nie
za mały ?
Zasilanie 5V. SMD. Nie wiem, czy jakieś typy są mniej czy bardziej
predystynowane do zast, przemysłowych...

Doświadczenie mam z tego typu układami dokładnie zerowe - zatem przy
okazji się nauczę może czegoś.

Wed Mar 08, 2017 10:32 pm   

W dniu 2017-03-08 o 22:21, sundayman pisze:


--

--
Pozdr
Janusz

Wed Mar 08, 2017 10:41 pm   

Kolega nie śledził wątku w części "I"
Właśnie chodzi o to, żeby nie robić na MCU, tylko "sprzętowo".
Oczywiście, nie FPGA, ale jakieś tam PAL,GAL, MACH, CPLD są i cała kupa
tego rodzaju wynalazków.

Thu Mar 09, 2017 12:53 am   

Cafam, 3.6V ponieważ Xmega w okolicy...

Thu Mar 09, 2017 7:33 am   

sundayman wrote:


Ale co Ci za różnica, czy to będzie MCU czy FPGA, skoro zamiana
nie rozwiązuje podstawowego problemu, czyli sprzętowej awarii
stopnia sterującego przekaźnikiem? Komórki IO są zasadniczo jednakowe
w MCU i PLD. Pisano Ci już o tym, że w przeciążonym krzemie zazwyczaj
awaria jest na zwarcie w wyniku dyfuzji na złączu, prowadzącej do
powstania dobrze przewodzącego stopu, i to jest dla Ciebie najgorszy
scenariusz.

Są techniki radzenia sobie z tym, opisane m.in. w książce GE o
tyrystorach z lat 70. -- kilka redundantnych par sterujących obciążeniem
i coś na kształt transformatora Ferrantiego do wykrywania niejednakowych
przepływów. Ale, wybacz szczerość, nie jesteś
zainteresowany rozwiązaniem *kluczowych* problemów, tylko poczuciem
się lepiej poprzez nawalenie pseudozabezpieczeń w rodzaju watchdogów.
Urządzenia o wysokich wymaganiach bezpieczeństwa muszą mieć
dodatkowe zabezpieczenia mechaniczne (np. klocek z ołowiu na
linii wiązki promieniowania), w samą elektronikę nikt nie wierzy.

Gdyby projekt miał być ultrabezpieczny, to bym poważnie rozważył
sterowanie przekaźnika wzmacniaczem magnetycznym. Jak coś padnie,
to w dobrą stronę.

Pozdrawiam, Piotr

Thu Mar 09, 2017 7:52 am   

sundayman wrote:


Zabezpieczenie będzie zasługiwało na swoją nazwę dopiero wtedy, gdy
uchroni użytkownika przy całkowitym padzie płytki sterującej, w tym
na zwarcie dowolnego układu scalonego. Tym się proponuję zająć, a
nie rozważaniami, ile Hz ma mieć przebieg sterujący i czy da się
zasilić z 3,6V. A jak dostanie 20V w wyniku surge i się choć jedna
komórka tranzystora wyjściowego stopi, to co?

Pozdrawiam, Piotr

Thu Mar 09, 2017 10:02 am   

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:o9qsuj$qa7$1@node1.news.atman.pl...
sundayman wrote:

Ale uszkodzenie IO jest malo prawdopodobne.
Za to zawieszenie programu bardzo prawdopodobne :-)

A jak juz usterki sprzetowe rozpatrujemy, to przeciez tranzystor
sterujacy przekaznikiem moze sie zewrzec, przekaznik moze sie skleic,
mucha moze wleciec miedzy styki itp :-)


Ale to nie sa kluczowe problemy :-)

Swoja droga - jak to w NASA robia ?
Tam ponoc trzeba przewidziec mozliwosc uszkodzenia dowolnego elementu,
wiec ...
4 tranzystory i 2 przekazniki ?

6 tranzystorow i 3 przekazniki ? Wszak element sie moze na dwie strony
zepsuc - nie wylaczy lub nie wlaczy ...

J.

Thu Mar 09, 2017 4:33 pm   

Tak, ale MCU jest ze swojej natury bardziej podatne na awarie, chociażby
z uwagi na sekwencyjny sposób działania.
W FPGA nie ma zmiennych, które mogą się "przestawić", nie programu,
który może się posypać.



Teoria jest dobra, tylko mało praktyczna.
Są sytuacje, w których nie można dać klocka z ołowiu.
A jeżeli chcesz powiedzieć, że struktura systemu nie ma znaczenia, bo i
tak ostatecznie powinien być klocek z ołowiu...


Spróbuj się trzymać założeń.
A one są takie - układ elektroniczny, o jak najmniejszej podatności na
zakłócenie działania z powodu EM.

Teraz - czy jest twoim zdaniem różnica w działaniu MCU, w którym jeden
bit w jakimś rejestrze zostaje przestawiony (bez uszkadzania go nawet) -
a taką samą sytuacją dla CPLD ?

Twoim zdaniem są to sytuacje o takim samym prawdopodobieństwie "awarii" ?

Thu Mar 09, 2017 4:36 pm   

Oczywiście diwajs posiada wszystkie możliwe zabezpieczenia przed tym.
Różne tam transile, warystory, a nawet gazowe wyładowcze, itp itd.

Zresztą tutaj jest odrobinę podobna sytuacją - system jest zasilany z
aku, z doładowanie z solarów. Więc przepięcie może powstać tylko z
powodu EM.

Tak że uwaga słuszna, ale pomijamy ją tutaj bo to inny temat.

Thu Mar 09, 2017 5:46 pm   

Użytkownik "sundayman" napisał w wiadomości grup
dyskusyjnych:o9rsjf$d48$1@news.icm.edu.pl...

Zalezy ktore.
Ogolnie - duzo tam elektroniki, a kazda drobna zmiana moze byc
tragiczna w skutkach :)

Te przepalanki Actela jakby bezpieczniejsze ...


CPLD to jeszcze inna bajka, ale przestawienie 1 bitu konfiguracji w
takim FPGA ... no, moze szczesliwie w jakims nieuzywanym i izolowanym
obszarze.


Akurat w FPGA technologia zblizona do RAM czesta, wiec przypadkowe
przestawienie bitu mysle ze podobnie prawdopodobne jak w rejestrze.
CPLD zdaje sie, ze zazwyczaj zbudowane inaczej - to predzej jak
przestawienie zawartosci flasha.

Ale o bledzie w bardziej skomplikowanym programie nawet nie ma co
wspominac - na pewno jest kilka :-)


J.

Thu Mar 09, 2017 6:51 pm   

Użytkownik "sundayman" napisał w wiadomości grup
dyskusyjnych:o9ptqc$sj3$1@node1.news.atman.pl...

Ogolnie - CPLD.

PAL/GAL - troche za male, FPGA - za duze, ale moze na kilka takich
licznikow w sam raz.
Mach obecnych nie znam - moga byc za duze, a moze akurat w sam raz.

Mozesz sie zainteresowac Actel/microsemi - jesli ciagle robia swoje
"antifuse" ... to jest bezpieczne :-)

https://www.microsemi.com/products/fpga-soc/reliability
https://www.microsemi.com/products/fpga-soc/antifuse-fpgas

One generalnie beda za duze do tego celu ... ale to tylko kwestia ceny
:-)

J.

Thu Mar 09, 2017 9:28 pm   

sundayman wrote:


Masz na to jakieś konkretne dane, czy jedynie po prostu głęboko w to
wierzysz?


Masz za to olbrzymi zbiór funkcji logicznych, który po trafieniu
choćby cząstką promieniowania kosmicznego może się stać zupełnie
innym zbiorem oraz konfigurowalny routing, który w wyniku tych samych
zjawisk nagle może zacząć routować sygnały gdzie indziej, niż to
sobie założyłeś. FPGA to jest jeden wielki statyczny RAM, pooglądaj
sobie zdjecia struktur. Zajmuje całą płytke krzemową. Wystarczy
przerzucić jeden jedyny bicik w tym RAMie i masz problem. Nie
wspominając o tym, że FPGA ze względu na swoją złożoność i wymagane
parametry
wykonuje się na znacznie nowszych liniach, w tym 22 nm. No to teraz
sobie sam odpowiedz, o ile łatwiej tą samą kaskadą ładunków zmienić
stan kwadracika o boku 22nm w stosunku do kwadracika o boku 180nm,
nie wspominając o tym, że tych pierwszych jest też nieporównywalnie
więcej, bo w procesorze przerzutników jest mniej.


To nie jest teoria, tylko czasami wręcz wymaganie prawne przy atestacji
urządzeń, w tym do terapii radiacyjnej: mechaniczne blokady kluczowych
podsystemów. Nie masz przysłowiowego klocka z ołowiu, nie będzie
pieczątki z Reichsadlerem, nie wejdziesz na rynek. Konkretne zgony za
tym stoją:

https://pl.wikipedia.org/wiki/Therac-25


Są też sytuacje, że nie można nie dać. Nie wiem, jaką Ty masz,
ale piszesz coś o ryzyku sprowadzaniu zagrożenia zdrowia i życia,
więc się zastanów dwa razy, zanim kogoś owdowisz.


Trzymam się ich dokładnie: wzmacniacz magnetyczny zbudowany z dwóch
odpowiednio dobranych do silnika gotowych transformatorów sieciowych
zaliczam do układów elektronicznych i to rozwiązujących pewne kluczowe
problemy ze sterowaniem silnikiem. Nie musisz tego rozwiązania lubić,
w końcu to Ty jesteś konstruktorem, a nie ja, co nie zmienia faktu,
że w mojej ocenie jest najpewniejsze. Pokochaj, znienawidź -- Twoja sprawa.


W CPLD też są przerzutniki, i to cała masa. Dodatkowo, oba urządzenia
są oparte o pamięć flash, która jest niepewna i stosunkowo nietrwała.


Moje zdanie, czyli de facto wiara, jest tu zupełnie nieistotne.
Znaczenie mają wyłącznie wyniki rzetelnych pomiarów, uwzględniające
statystykę. Ja nimi nie dysponuję. Ty, przypuszczam, też nie.
Robi się więc z tego jałowa dyskusja o uprzedzeniach.

Gdybym miał zgadywać, to najmniej pewne bądą FPGA, potem wielobitowe
MCU, a na końcu 8-bitowe MCU i CPLD, bez jasnego faworyta. Stosunkowo
pewne będą sprzętowe układy półprzewodnikowe, a najpewniejsza logika
magnetyczna, bo trudno popsuć kawałek drutu.

Pozdrawiam, Piotr

Thu Mar 09, 2017 9:37 pm   

Użytkownik "Piotr Wyderski" napisał w wiadomości
sundayman wrote:

Ale czy aby na pewno zaowocowaly wymogiem mechanicznej blokady w
Reichprzepisach ?


Piotrze - ale czy on potrafi silnik na dobre wylaczyc ?
Bo ze schematu tego najprostszego, to by wynikalo ze to tylko dlawik,
wiec nadal niemaly prad plynie
(IMO - zaroweczka powinna swiecic )

Moze i silnik sie juz nie obroci, ale lepiej, zeby elektryk po kablach
nie macal.

No i pojdz na calosc - cala logike na wzmacniaczach magnetycznych, bo
co bedzie, jak piorun walnie od strony wyjscia - tranzystor sterujacy
wejsciem przetrwa ? :-)

J.

Thu Mar 09, 2017 10:08 pm   

W dniu 09.03.2017 o 21:28, Piotr Wyderski pisze:

Wierzę w krasnoludki.
Imo w MCU pojedynczy błąd będzie miał gorsze skutki niż w CPLD jest
oczywisty, już choćby z uwagi na ilość zasobów zaangażowanych w operację.


Dlatego, żeby miało to sens, należałoby wybrać taki chip, który będzie
jak najlepiej dopasowany do zagadnienia.
Opisany przeze mnie timer to mniej więcej tyle, co zapewne timer w MCU.
Za to bez całej reszty.


Tylko, że to jest gadanie oderwanie od konkretnego przypadku.
Szkoda czasu na mielenie tego.To nie jest prasa, pod którą ktoś wsadzi
głowę. Żeby się zdarzyło nieszczęście, musiałoby nastąpić kilka rzeczy,
których początkiem mogłoby być nie wyłączenie tego przekaźnika.

Dlatego - w ramach możliwości, a także jakby nie było - pewnej edukacji
- myślę nad tym.


Tłumaczyłem już jak to wygląda. Piszesz w sumie słusznie, ale nie
trzymasz się konkretnego przypadku.
W urządzeniach konkurencji wszystko działa ja jednej Atmedze. Bez
żadnych tego typu "zabezpieczeń". Nawet nikt tam nie pomyślał o tym.
To co robię jest zapewne "na wyrost" - ale jestem widocznie wyjątkowo
przewrażliwony A co mi szkodzi ?

Jak przykręcam kołkami uchwyt pod TV też wolę dać 8mm zamiast 6mm. Które
pewnie i tak wystarczyłyby. No widać, jakieś zboczenie.



Zrozum żesz wreszcie, że sens ma dyskusja w wyznaczonych ramach
Ja wiem lepiej chyba - nie ma sensu wymyślanie cudów na kijku, ponieważ
ani nie ma takiej konieczności, ani nie takiej możliwości.

Tu chodzi o dodanie jakiegoś miejsca po przecinku do obecnego ryzyka
wystąpienia określonej sytuacji. Tak jak jest - nie jest źle.
Chodzi o to, żeby albo poprawić o tyle ile można, albo pozostawić -
usuwając problemy, które stwarza MCU2.


Schemat opisanego timera mogę zrobić sam na bramkach, na schemaciku.
Ile to będzie procent "schematu" Atmegi 8 ?



No więc właśnie - sens ma znalezienie układu, najlepiej jednorazowo
programowalnego, o zasobach adekwatnych do takiego licznika.
Czy logika zrobiona na 74xx jest pewniejsza niż na jakimś PAL'u na
przykład ? Nie wiem - tego bym się chętnie dowiedział jak i dlaczego.

Ale - powiem tak szczerze, że być może sprawę załatwia zasadniczo
np. RTC/watchodog , programowany via I2C, z funkcją alarmu.
Bo właściwie mój opis do tego się sprowadza - taki programowany I2C
watchdog.

Ale fajniej by było sobie to samemu zrobić - zwłaszcza, że od lat się
zabieram do nauki FPGA.

Thu Mar 09, 2017 10:35 pm   

J.F. wrote:


Mnie się kilkukrotnie przytrafiło, z przyczyn różnych.
Ale przytrafiła mi się też awaria mostka Graetza. Ja
już nie wierzę w półprzewodniki, najwyraźniej drażniąc
tym Kolegę wątkotwórcę.


Ja bym się (znów z praktyki) bał spurious reset.
Nigdy mi się program nie zawiesił, natomiast resety bez przyczyny miewałem.


Nie wiem, co robią w NASA, ale manual GE opisuje dokładnie Twoje
rozwiązanie 6-elementowe (w kilku wariantach). Dowolny element się
może dowolnie uszkodzić, a całość działa nadal sprawnie, aż się pan
Zenek-konserwator zdecyduje ruszyć odwłok i wymieni moduł bez wyłączania
maszyny.

Pozdrawiam, Piotr