Bledy timingowo-dynamiczne w systemach mikroprocesorowych (dlugie)
Masz problem? Zapytaj na forum elektroda.pl
From: Jack Houseman <KILLSPAMjado_at_nospam_chello.pl>
Subject: Bledy timingowo-dynamiczne w systemach mikroprocesorowych (dlugie)
Date: Fri, 27 May 2005 15:08:30 +0200
Witam,
Ostatnio testowalem (przypadkowo dosc zreszta) moje uklady mikroprocesorowe,
chcac sprawdzic czy fragment danego programu dziala na ciut innym
procesorze (zamiast 18F452 byl 252) - aby sprawdzic szybko czy ten
procesorek jest sprawny i sie wzbudza (zamiast kwarcu 16MHz dalem kwarc
8MHz, ale +4xPLL, co dalo 32MHz). Procesorek zadzialal, ale zauwazylem, ze
nie wszystko dziala jak nalezy - mimo odp. zmian w programie
uwzgledniajacych przyspieszenie kwarcu. Generalnie chodzilo o uklady
sterowane przez I2C - choc sprzetowy I2C (w mikrorocesorze) i uwzglednienie
zmiany szybkosci kwarcu powinno sprawic, ze uklad bedzie sie zachowywal
identycznie. Ale jednak nie do konca - na wyswietlaczu zamiast danego
komunikatu pojawialy sie "robaczki". Przy czym ten komunikat jest
"ciagniety" z zewnetrznego EEPROMU. Jak dalem wpis na LCD bezposrednio z
programu procesora - bylo OK. A wiec cos jakby z obsluga I2C.
Odlaczenie pewnych ukladow I2C (DS1307 konkretnie) sprawilo, ze reszta
zaczela dzialalc poprawnie - jakby obciazenie I2C sie zmniejszylo?...
Dziwne, bo przeciez niby szybkosc I2C ta sama...
Niestety nie dysponuje ani osc. cyfrowym, ani analizatorem, zebym mogl
swierdzic co sie na tych liniach dokladnie dzieje, czy jednak szybkosc I2C
sie nie zmienila - pozostaje wiec tylko analiza "umyslowa" ;-).
Ale do czego zmierzam - widze, ze takie zmiany szybkosci kwarcu, sa byc moze
dobrym sposobem na wylapywanie bledow programowo-sprzetowych jakie moga sie
pojawiac w systemach mikroprocesorowych - zwiazanych z timingami.
Z drugiej strony rodzi sie pytanie - czy warto sie przejmowac takimi
objawami - w koncu robimy pod konkretny kwarc i skoro dziala (i to latami
czasem) bez bledow, to moze jest OK? :-)
--
Pozdrawiam
Jado
From: "szlovak" <BEZXadamkx_at_nospam_o2.pl>
Subject: Re: Bledy timingowo-dynamiczne w systemach mikroprocesorowych (dlugie)
Date: Fri, 27 May 2005 16:24:10 +0000 (UTC)
Zdobądź ICD2 i będzie łatwiej
--
Pozdrawiam
Adam
From: Patryk Sielski <psielski-usun_at_nospam_elka-usun.pw.edu.pl>
Subject: Re: Bledy timingowo-dynamiczne w systemach mikroprocesorowych (dlugie)
Date: Fri, 27 May 2005 17:04:06 +0000 (UTC)
Jack Houseman <KILLSPAMjado_at_nospam_chello.pl> pisze:
Z drugiej strony rodzi sie pytanie - czy warto sie przejmowac takimi
objawami - w koncu robimy pod konkretny kwarc i skoro dziala (i to latami
czasem) bez bledow, to moze jest OK? :-)
Zadaj sobie pytanie jakiego poziomu doskonałości oczekujesz.
Zawsze będzie jakiś błąd lub inaczej na to patrząc - zawsze można
coś poprawić.
Czy celem jest zrealizowanie projektu i wziecie kasy za działający
projekt (klienta nie interesuje jakie biblioteki dołączysz - ma
działać), czy też ambicją jest zrobienie super-wypasionego urządzenia.
Generalnie powinno się łączyć jedno z drugim, ale wiadomo jak jest ;-(
--
-= Patryk Krzysztof Sielski | (602) 643804 | GG: 3189324
-= Urządzenia i projekty elektroniczne na zamówienie
-= http://home.elka.pw.edu.pl/~psielski
From: Jack Houseman <KILLSPAMjado_at_nospam_chello.pl>
Subject: Re: Bledy timingowo-dynamiczne w systemach mikroprocesorowych (dlugie)
Date: Sat, 28 May 2005 00:22:23 +0200
Patryk Sielski wrote:
Jack Houseman <KILLSPAMjado_at_nospam_chello.pl> pisze:
Z drugiej strony rodzi sie pytanie - czy warto sie przejmowac takimi
objawami - w koncu robimy pod konkretny kwarc i skoro dziala (i to latami
czasem) bez bledow, to moze jest OK? :-)
Zadaj sobie pytanie jakiego poziomu doskonałości oczekujesz.
Zawsze będzie jakiś błąd lub inaczej na to patrząc - zawsze można
coś poprawić.
Czy celem jest zrealizowanie projektu i wziecie kasy za działający
projekt (klienta nie interesuje jakie biblioteki dołączysz - ma
działać), czy też ambicją jest zrobienie super-wypasionego urządzenia.
Generalnie powinno się łączyć jedno z drugim, ale wiadomo jak jest ;-(
W moim przypadku chodzi o system HomeAutomation - robiony nie dla kasy,
tylko dla siebie (czyli czas i oszczednosci materialowe nie sa tu
krytyczne). Poniewaz bedzie sterowal urzadzeniami w domu powninien byc w
miare niezawodny - bo moze sie to zle skonczyc :-) Nie mowie tu o
rozbudowie funkcjonalnosci, bo tą mozna w nieskonczonosć poprawiac, ale o
tym, zeby to co jest dzialalo niezawodnie.
Dlatego interesuja mnie sposoby wykrywania ew. bledow w takich systemach -
zeby moc je wyeliminowac. A okazuje sie, ze siedzi ich w kodzie calkiem
sporo - sam kod niby dobrze i niezwodnie dzialajacy w pewnych warunkach
pokazuje swoje zawodne strony.
Nazwijmy to extensywna procedura testowania majacą na celu wykrycie slabych
stron sprzetu+programu. Takie szukanie dziury w calym.
Jak juz wyzej napisalem - o dziwo - zmiana kwarcu przynosci calkiem ciekawe
efekty w postaci sypania sie programu.
Inna metoda jest np. podmienianie niektorych elementow na kompatybilne - np.
wyswietlacze LCD miewaja rozne czasowe charakterystyki i program zrobiony
pod jeden konkretny typ nie musi wcale chodzic na innym (mialem juz taki
przypadek - poprawka programu sprawila, ze przy okazji wyeliminowalem
dziwne, raz na kilka miesiecy sie pojawiajace resety LCD).
Ciekawe co jeszcze mozna wymyslic :-)
--
Pozdrawiam
Jado
---> Zegarus - Otwarty Projekt Automatyki Domowej -
http://zegaruz.republika.pl
From: Patryk Sielski <psielski-usun_at_nospam_elka-usun.pw.edu.pl>
Subject: Re: Bledy timingowo-dynamiczne w systemach mikroprocesorowych (dlugie)
Date: Fri, 27 May 2005 22:36:31 +0000 (UTC)
Jack Houseman <KILLSPAMjado_at_nospam_chello.pl> pisze:
Dlatego interesuja mnie sposoby wykrywania ew. bledow w takich systemach -
zeby moc je wyeliminowac. A okazuje sie, ze siedzi ich w kodzie calkiem
sporo - sam kod niby dobrze i niezwodnie dzialajacy w pewnych warunkach
pokazuje swoje zawodne strony.
Ja zmieniam wszystkie na wszystkie sposoby parametry wejściowe.
Kiedyś miałem do zrobienia moduł zapłonowy do motocykla.
Testowałem tak: nie 12 a 17V,
Cewka zapłonowa nie od motocykla, a od malucha,
nie 5 a 15 krpm,
długie przewody do cewki,
duży odstęp na iskrę.
Zostawiłem na dłuższy czas.
Działało.
Klientowi coś się jednak nie podobało i przyszedł po modyfikację.
Radiator modułu owinął.. taśmą izolacyjną.
Mimo tego - działał ;-)
Dlatego uważam, że jeśli urządzenie ma być bliskie doskonałości - trzeba
zmieniać wszystko, co tylko można. W ekstensywnym programowaniu najpierw
zaczyna się od programu testującego, a dopiero potem od programu
właściwego. W elektronice przydatny jest automatyczny system pomiarowy.
Zapodajesz dane wejściowe, zostawiasz na weekend i patrzysz, czy działa.
--
-= Patryk Krzysztof Sielski | (602) 643804 | GG: 3189324
-= Urządzenia i projekty elektroniczne na zamówienie
-= http://home.elka.pw.edu.pl/~psielski