Odporne programy

był wątek na ten temat " PROJEKTOWANIE URZĄDZEŃ PRACUJĄCYCH W ŚRODOWISKACH Z ZAKŁÓCENIAMI "

dokładnie sprzed roku 5.6.2013

U¿ytkownik "pytajacy" snipped-for-privacy@poczta.fm napisa³ w wiadomo¶ci news: snipped-for-privacy@googlegroups.com... Witam, mam pro¶bê, czy mogliby¶cie mi podes³aæ linki na temat sposobów pisania programów aby zwiêkszyæ odporno¶æ na zak³ócenia? Czy w ogóle takie rozprawy teoretyczne istniej± w internecie? Mam na my¶li takie opisy, jak na przyk³ad obliczania CRC programu i sprawdzania co jaki¶ czas czy flash siê przypadkiem nie przeprogramowa³.

Bo z mojego do¶wiadczenia, walka z zak³óceniami za pomoc± software-u to raczej walka z wiatrakami.

------------ To nie jest walka z wiatrakami. Software jest jednym z elementów EMC urz±dzenia. To jak reaguje na przyk³ad na zak³ócenia w transmisji wp³ywa na to, czy urz±dzenie siê pozbiera po Surge, Burst, EST,

Kiedy¶ dawno (10 lat temu) widzia³em jak±¶ notê ST na ten temat. Du¿o ró¿nych wytycznych tam by³o - np. czym wype³niaæ puste obszary (ju¿ nie pamiêtam co tam pisali, ale pamiêtam, ¿e o tym by³o). P.G.

W dniu poniedziałek, 2 czerwca 2014 14:58:58 UTC+2 użytkownik sundayman napisał:

Dzięki, ten artykuł ATMEL-a coś niecoś opisuje.

Może i masz rację. Ale zastanawiam się np. nad sterownikami PLC. Tam jest jakiś system i myślisz że on spełnia takie wymagania? Bo jakoś nie jestem przekonany jeśli chodzi o odporność systemu Windows użytego w panelach dotykowych, będących jednocześnie sterownikami PLC, z firmy EATON.

pytający

Bo z mojego do¶wiadczenia, walka z zak³óceniami za pomoc± software-u to raczej walka z wiatrakami.

i sluszne te wnioski... nalezy usuwac zrodla zaklocen lub zaklocenia w ich zrodlach.

co jednak nie zmienia faktu, że pewne techniki warto stosować w programowaniu - chociażby opisywane tu już "nadmiarowe" zapisywanie ważnych danych,

Pytałeś wprawdzie o rozwiązania softwareowe, ale korzystając z okazji TI ma całkiem ciekawy kit i procesor.

Click -->

Czy może ktoś się tym "bawił"?

Piotrek

Nie zmienia,,, jednak nie nalezy spodziewac sie zbyt wiele. W sytuacji gdy zaklocenia powoduja przypadkowe skoki programu, postawienie nawet kilku rownoleglych procesorow i systemu elekcyjnego pomiedzy nimi nie gwarantuje pewnosci dzialania.

W dniu 2014-06-02 19:49, sundayman pisze:

Czy na przykład nadpisywanie wszystkich rejestrów konfiguracyjnych po każdym odczycie z urządzenia peryferyjnego jak ADC.

W dniu 2014-06-02 14:46, pytajacy pisze:

Dzięki.

Ale macie jakieś konkretnie doświadczenie w tym temacie? Bo to wszystko wydaje mi się stosowaniem raczej dla spokoju sumienia.

Bo ja mam takie doświadczenia: Przypadek nr 1: urządzenie zawieszało się na wskutek pracy stycznika i żadne moje zabiegi programowe nie pomogły (procesor 89C51, obudowa DIP40). Dopiero rozwiązanie sprzętowe pozwoliło uodpornić urządzenie na zakłócenia od stycznika.

Przypadek nr 2: urządzenie/sterownik stosowane w różnych środowiskach gdzie programy są całkowicie inne za każdym razem pisane prawie od zera, bez zachowania jakichkolwiek zaleceń. I urządzenia działają (procesor AVR, obudowa TQFP44).

Fakt, w obydwu przypadkach zastosowano różne sposoby zasilania, inne prowadzenie ścieżek itd. Po prostu w drugim przypadku lepiej zaprojektowany układ.

Czy te zabiegi programistyczne to przypadkiem nie odprawianie czarów nad urządzeniem?

pytajacy

W dniu 2014-06-03 09:57, pytajacy pisze:

I tak i nie :) Układ AD7730. Bardzo wrażliwy na zakłócenia. Sam zresztą tez mocno emitował ze swojego zegara. Często się wieszał w warunkach przemysłowych. Nadpisywanie rejestrów poprawiło sytuację ale nie do końca. W jednym z rejestrów jeden bit kontrolował prace jego zegara. Jak ten się przestawił to niestety nie podbierał danych z SPI i nic nie mogłem już nadpisać (ani odczytać). Pomogła prowizoryczna zmiana na płytce, umożliwiająca sprzętowe resetowanie układu gdy procek wykrył, że układ nie odpowiada. Ostatecznie uciekłem od niego na rzecz ADS.

U¿ytkownik "pytajacy" snipped-for-privacy@poczta.fm napisa³ w wiadomo¶ci news: snipped-for-privacy@googlegroups.com...

moje zabiegi programowe nie pomog³y (procesor 89C51, obudowa DIP40). Dopiero rozwi±zanie sprzêtowe pozwoli³o uodporniæ urz±dzenie na zak³ócenia od stycznika.

Nie napisa³e¶ na wstêpie ¿e chodzi o softwareowe rozwi±zywanie problemów ¼le zaprojektowanego hardware'u. To oczywi¶cie nie ma najmniejszego sensu. Najpierw trzeba poprawiæ hardware. Warunkiem wstêpnym dyskusji o EMC jest nie stosowanie obudów DIP. Spójrz na ni± z boku i zobacz jaka jest powierzchnia na przyk³ad obwodu od GND do struktury IC i dalej do VCC i przez kondensator do GND. A spójrz np. na TQFP44 gdzie piny VCC i GND s± obok siebie. Stosunek powierzchni tych obwodów to stosunek spodziewanych problemów z jedn± i drug± p³ytk±.

Ale i w dobrze zaprojektowanym urz±dzeniu te¿ jaki¶ kwant promieniowania kosmicznego mo¿e jaki¶ bit przestawiæ i choæ nie ma pewno¶ci to jest szansa, ¿e odpowiednio napisany program jako¶ siê z tego wygrzebie. P.G.

Jestem świadom że źle zaprojektowany hardware nie da się programowo uodpornić EMC. Z tym się zgodzę. Ale właśnie chodzi mi o te szanse programowe na wygrzebywanie się z problemów. I myślę, że akurat promieniowanie kosmiczne tutaj nie jest problemem. Choć może się mylę...

U¿ytkownik "pytajacy" snipped-for-privacy@poczta.fm napisa³ w wiadomo¶ci news: snipped-for-privacy@googlegroups.com...

Ale w³a¶nie chodzi mi o te szanse programowe na wygrzebywanie siê z problemów. I my¶lê, ¿e akurat promieniowanie kosmiczne tutaj nie jest problemem. Choæ mo¿e siê mylê...

Na ile promieniowanie kosmiczne jest problemem - nie mam pojêcia (to tak trochê ¿artem by³o).

Je¶li przyj±æ, ¿e jaki¶ czynnik mo¿e co¶ w procesorze poprzestawiaæ (w rejestrach statycznych, a nie Flash) to program, który:

- w pêtli g³ównej (gdy nie ma nic do roboty) w ko³o odnawia ustawienia wszystkich swoich interfejsów itp,

- przestrzeñ woln± ma wype³nion± skokiem na pocz±tek, a nie NOPem (szybciej odzyska ¶wiadomo¶æ po losowym skoku),

- itp. powinien byæ bardziej odporny ni¿ program, który tego nie robi. P.G.

ROTFL! Tą wypowiedzią "zniknąłeś" 99% współczesnych sprzetów konsumenckich od smartfona poczynając a na podzespołach PC kończąc. Np. średnio

Użytkownik "Marek" snipped-for-privacy@fakeemail.com napisał w wiadomości news: snipped-for-privacy@news.neostrada.pl...

Nie wiem za dokładnie o czym piszesz, ale czy dalej jesteśmy w kontekście EMC i DIP ? P.G.

Głównie ogólnie w kontekście nieprawidłowo zaprojektowanego hardware, którego problematyczne działanie trzeba łatać softwarowo.