Oznakowanie CE, właściwy sposób zachowania mikrokontrolera

Może zobacz jeszcze temat "Dyrektywa Maszynowa"

R.K.

Witajcie

Po pierwsze musisz próbować tak zaprojektować elektronikę aby zminimalizować wnikanie zakłóceń zewnętrznych. Proponuję Ci aby przetestować dla siebie urządzenie pod kontem reakcji na zakłócenia. Robiliśmy to wypożyczonym pistoletem a także metodami uproszczonymi jak zapalarką do gazu. Pistolet profesjonalny umożliwia definiowanie między innymi energii zakłócenia. Co ciekawe zdaża się że zakłócenie o niższej emergii może powodować inne problemy niż mocjiejsze.

Zwróć uwagę na obszar zastosowań urządzenia. przemysł / motoryzacja / biuro. To wpływa na sposób kontroli na EMC

Po drugie w programie powinieneś zapewnić zapamiętanie stanu istotnych zmiennych po ich modyfikacji w pamięci niezależnej od zasilania. Logika programu powinna mieć na celu również zamaskowanie efektów zadziałania WDT. Projektowałem urządzenie pomiarowe wymagające zatwierdzenia typu, pracujące z wyjątkowo podłych warunkach. Częste składowanie i odtwadzanie nie pogorszyło właściwiści metrologicznych

Co do dyrektywy maszynowej, niedopuszczalne są niespodziewane, niekontrolowane ruchy maszyny.

Powodzenia

RomanF

Użytkownik "Robot" <Robot_nie_mam snipped-for-privacy@hotmail.com napisał w wiadomości news:eqilfi$mee$ snipped-for-privacy@atlantis.news.tpi.pl...

Robot napisał(a):

Przecież reset nie powoduje automatycznie kasowania pamięci. Sprawdzasz stan pamięci (komórek testowych) i jeśli są prawidłowe to robisz gorący restart i omijasz inicjalizację liczników. Jeśli zawartość pamięci jest nieprawidłowa to robisz zimny restart i czyścisz pamięć.

Dziękuję za odpowiedzi.

Urządzenie będzie w dodatkowej metalowej szafie i zasilanie będzie przez UPS.

Piszesz, że urządzenie ma maskować działanie watchdoga. A co, jeśli urządzenie steruje procesem czasu rzeczywistego i zanik zasilania i tak spowoduje przerwanie procesu, bez możliwości kontynuacji po włączeniu zasilania?

Chodzi o to, że z tego co piszesz, wynika, że urządzenie ma działać, po włączeniu zasilania, od takiego stanu, jaki miało przed zanikiem zasilania. Ok, rozumiem. Ale u mnie przerwa w zasilaniu, powoduje, że cały proces się rozsypuje.

Robot

Użytkownik "Robot" <Robot_nie_mam snipped-for-privacy@hotmail.com napisał w wiadomości news:eqq5hu$n4n$ snipped-for-privacy@nemesis.news.tpi.pl...

To są tzw. "siły wyższe" . Ten fragment może cię nie interesować. Maszyna ma się po powrocie zasilania nie popsuć, ani niczego nie uszkodzić. Najbardziej prawdopodobne jest zgłupienie mikroprocesora od czegokolwiek, choćby od załączenia jakiegoś "zakłócacza" (lutownica transformatorowa, spawarka TIG, potężny silnik, stycznik , nadajnik radiowy itp.), czy błędów w programie. Lepiej, żeby maszyna stanęła, zamiast wykonywać nieskoordynowane ruchy "powrotu do zera".

Mariusz Dybiec napisał(a):

Mozesz podac przyklad jak to wykonac w avr-gcc? Jak obejsc inicjalizacje zmiennych, lub przeczytac zawartosc ich komorek w ram przed inicjalizacja?

Pozatym pomysl co prawda moze i wyglada dobrze, ale nie ryzykowalbym wznawiac procesu wg danych w ramie/rejestrach procesora, ktory poszedl w maliny (bo przeciez cos ten reset spowodowalo). Jesli program sie zawiesil, i to spowodowalo zadzialanie watchdoga - to znaczy ze jakas komorka pamieci miala zla wartosc (np okreslajaca adres skoku), lub nastapil blad odczytu kolejnego rozkazu z pamieci programu (i tez niewiadomo co ten rozkaz zrobil z ramem). Tak czy inaczej dane w ramie sa conajmniej niepewne a rejestry procesora chyba sa zawsze czyszczone harwarowo. Moze gdyby zastosowac 'backup' komorek ramu co jakis czas i trzymanie ich kopii wraz z crc rowniez w ramie (lub dataflash, jak miejsce i czas pozwala), to by sie dalo przywrocic stan sprzed resetu.

BartekK napisał(a):

Przyznam, że nie wiem bo dopiero zaczynam w C :) ale może jakaś wstawka asemblerowa w boot.s czy startup.c?

Nie chodzi ci o cały ram tylko o kilka liczników, które możesz przechowywać w wydzielonej części ramu. Możesz zawartość zabezpieczać checksumą. Jeśli przy restarcie checksuma będzie zła to znaczy, że dane nie zachowały integralności.

Moze gdyby zastosowac 'backup' komorek ramu co jakis czas i

Musiałbyś pisać do flasha przy każdym ruchu a flash wytrzymuje chyba

1Mcykli zapisu. Najlepiej dać enkodery absolutne i zawsze przy restarcie sprawdzać położenie.

Mon, 12 Feb 2007 22:13:43 +0100, na pl.misc.elektronika, Mariusz Dybiec napisał(a):

Witam. Jest do tego gotowa sekcja noinit - zmienne oznaczone tym atrybutem nie są automatycznie zerowane . Do tego flagi rodzaju restartu, zeby wiedzieć kiedy nadać początkowe wartości - np. .... if (MCUSR & _BV(PORF)) { // włączenie zasilania // tutaj zerujemy wszystkie indeksy rejestracji i wskaźniki stanu urządzenia, // które przy resecie watchdoga są utrzymywane jako zmienne NOINIT MCUSR &= ~_BV(PORF); // skasowanie flagi poziomem niskim WatchdogCounter=0; LiveTime=0; PendingFlags.Byte=0; // wyzerowanie flag trwania procesów EepromPendingFlags.Byte=0; // wyzerowanie flag zapisu do pamięci SysFlags.Byte=0; // wyzerowanie flag systemowych IdleFlags.Byte=0; // wyzerowanie flag trybu uśpienia PrevMeaState=btnReleased; PrevRecState=btnReleased; PENDING_PWR_ON=true; SysState=stIdle; PrevSysState=stIdle; wdt_enable(WDTO_120MS); BeginTime.year=0; BeginTime.month=0; BeginTime.day=0; BeginTime.SecInDay=0; RecTimeCounter=0; ResetRec(); READY_TO_IDLE=true; }

Jurek Szczesiul napisał(a):

Interesujące. Byłbym wdzięczny gdybyś napisał jeszcze jak coś takiego wygląda dla ARMa np LPC2148.

Panowie,

Wszystko ładnie... możemy kontynuować proces po resecie spowodowanym przez watchdog. Ale, jak sami zauważyliście, istnieje możliwość, że "liczniki", na skutek zakłóceń, uległy zamazaniu i wtedy lipa. Możemy trzymać ważne dane poza kontrolerem, ale co się stanie, jeśli zakłócenia dosięgną i tamte dane. Chodzi mi o to, co w zgodzie z duchem CE powinien zrobić układ, jeśli po prostu nie da się kontynuować po ustaniu zakłócenia. A co jeśli mamy np. proces czasu rzeczywistego i zakłócenia paraliżują układ na jedną krytyczną sekundę i cały proces się rozsypuje... wznowienie działania po ustaniu zakłóceń nie ma już sensu

-- z czymś takim ja mam do czynienia. Wydaje mi się, że dobrym rozwiązaniem byłoby wtedy zatrzymanie procesu, a nie nieudolna próba kontynuacji. Jak uważacie? Oczywiście należy starać się, aby zakłócenia określone normami nie wpływały na działanie urządzenia, ale jeśli już, to co robić?

Pozdrawiam Robot

Robot napisał(a):

Zapisuj z checksumami.

Dlatego rozróżnia się restart z utratą kontekstu (zimny) od restartu z zachowaniem kontekstu (gorący). Tak masz np w sterownikach PLC. Wystarczy w obsłudze zimnego dać np postój, włączenie syreny i oczekiwanie na wciśnięcie klawisza parkowania. Jak robisz na własnym układzie z mikrokontrolerem to musisz sam zdecydować co oznacza utrata kontekstu. Dlatego musisz wydzielić dane programu istotne dla pracy maszyny i sprawdzać ich integralność (zachowanie kontekstu) i chronić przed wyczyszczeniem gdy nie są uszkodzone. A pozostała pamięć w tym rejestry procesor ulegają wyczyszczeniu przy resecie.

Jeszcze na temat: jak ma się zachować urządzenie w trakcie badań, chociaż zaraz pewnie poprawią mnie ci, którzy się na tym znają :) W zależności od tego jaką normę zastosujesz, urządzenie elektroniczne ma kontynuować pracę w trakcie zakłóceń albo jedynie odzyskać sprawność po ustaniu zakłóceń. Pewnie to jaką normę EMC zastosujesz zależy od tego jakie normy maszynowe musisz spełnić.

Jeśli masz obawy że nie będziesz w stanie zrobić tego dobrze na mikrokontrolerze to zastanów się nad zastosowaniem sterownika PLC.

Dzięki za odpowiedź.

Ok, czyli stosując sumy kontrolne mogę stwierdzić, czy dane w mikrokontrolerze i dodatkowej pamięci uległy zniekształceniu. Powiedzmy, że okazało się, że wszystkie moje zabezpieczenia (dodatkowa pamięć niezależna od zasilania) poległy pod wypływem zakłóceń i nie mam szans kontynuować normalnej pracy maszyny. Rozumiem, że wtedy powinienem nie dopuścić do tego, aby maszyna zaczęła wykonywać niekontrolowane ruchy -- to jestem w stanie zapewnić, ale raczej nie można oczekiwać, że będę kontynuował pracę, po tak dotkliwych zakłóceniach, jakby nigdy nic.

Pozdrawiam Robot

Otoz to. Jesli robisz termostat do pieca, to od biedy mozna zalozyc ze jesli suma kontrolna sie zgadza, to nastawa jest poprawna. Odczytujemy i termostatujemy.

Jak juz piszesz "maszyna" .. to najrozsadniejsze sie chyba wydaje zapalenie alarmu, wylaczenie i wlaczenie hamulcow.

A i tak trzeba uwazac zeby jakas zapalniczka i komorka nie spowodowala obciecia palcow mechanika .. lub poparzenia :-)

J.