W dniu 2014-06-02 14:46, pytajacy pisze:
> 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
>
http://sp9rqa.net/Elektronika/Soft_i_ESD.html

do góry

>
> http://sp9rqa.net/Elektronika/Soft_i_ESD.html

Dzięki.

do góry

> > co jednak nie zmienia faktu, że pewne techniki warto stosować w
> > programowaniu - chociażby opisywane tu już "nadmiarowe" zapisywanie
> > ważnych danych,
> >
> Czy na przykład nadpisywanie wszystkich rejestrów konfiguracyjnych po
> każdym odczycie z urządzenia peryferyjnego jak ADC.

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

do góry

W dniu 2014-06-03 09:57, pytajacy pisze:
>>> co jednak nie zmienia faktu, że pewne techniki warto stosować w
>>> programowaniu - chociażby opisywane tu już "nadmiarowe" zapisywanie
>>> ważnych danych,
>>>
>> Czy na przykład nadpisywanie wszystkich rejestrów konfiguracyjnych po
>> każdym odczycie z urządzenia peryferyjnego jak ADC.
>
> 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?

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.



--
pozdrawiam
MD

do góry

Użytkownik "pytajacy" <r...@p...fm> napisał w wiadomości
news:45a46d26-f047-49a5-a358-4b56cba246cf@googlegrou
ps.com...

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

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.

do góry

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


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

do góry

Użytkownik "pytajacy" <r...@p...fm> napisał w wiadomości
news:571e2f8d-7bc4-48fe-a1e3-6b65ecc7417a@googlegrou
ps.com...

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


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.

do góry

On Tue, 3 Jun 2014 11:07:51 +0200, Piotr
Gałka<p...@c...pl> wrote:
> 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.

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

--
Marek

do góry

Użytkownik "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.6211381275352197309@news.neostrada.pl
...
> On Tue, 3 Jun 2014 11:07:51 +0200, Piotr
> Gałka<p...@c...pl> wrote:
>> 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.
>
> 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...
>
Nie wiem za dokładnie o czym piszesz, ale czy dalej jesteśmy w kontekście
EMC i DIP ?
P.G.

do góry

On Tue, 3 Jun 2014 14:16:47 +0200, Piotr
Gałka<p...@c...pl> wrote:
> Nie wiem za dokładnie o czym piszesz, ale czy dalej jesteśmy w
kontekście
> EMC i DIP ?

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

--
Marek

do góry