Bledy timingowo-dynamiczne w systemach mikroprocesorowych (dlugie)

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? :-)

Reply to
Jack Houseman
Loading thread data ...

Zdobądź ICD2 i będzie łatwiej

Reply to
szlovak

Jack Houseman snipped-for-privacy@chello.pl pisze:

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 ;-(

Reply to
Patryk Sielski

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 :-)

Reply to
Jack Houseman

Jack Houseman snipped-for-privacy@chello.pl pisze:

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.

Reply to
Patryk Sielski

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.