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.
pytajacy
był wątek na ten temat " PROJEKTOWANIE URZĄDZEŃ PRACUJĄCYCH W ŚRODOWISKACH Z ZAKŁÓCENIAMI "
dokładnie sprzed roku 5.6.2013
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
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
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.
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ę...
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
70% (!!) kodu drivera NVIDI to workaroundy problemtatycznego hardware...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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.