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

do góry

W dniu 2017-03-08 o 22:21, sundayman pisze:
> 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...
Małych fpga nie znajdziesz, dałby małego procka 8 pin jakiegoś atiny.

--

--
Pozdr
Janusz

do góry

> Małych fpga nie znajdziesz, dałby małego procka 8 pin jakiegoś atiny.

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.

do góry

> Zasilanie 5V.

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

do góry

sundayman wrote:

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

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

do góry

sundayman wrote:

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

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

do góry

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:o9qsuj$qa7$...@n...news.atman.pl...
sundayman wrote:
>> 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.

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

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

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

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.

do góry

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

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


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

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

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

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

do góry

> zasilić z 3,6V. A jak dostanie 20V w wyniku surge i się choć jedna
> komórka tranzystora wyjściowego stopi, to co?

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.

do góry

Użytkownik "sundayman" napisał w wiadomości grup
dyskusyjnych:o9rsjf$d48$...@n...icm.edu.pl...
>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ć.

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

Te przepalanki Actela jakby bezpieczniejsze ...

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

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

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

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.

do góry