PCF8583 - nieprawidłowe wyświetlanie godziny, Atmega8, zakłócenia w sieci?

Witam,

czy ktoś miewał równie podobne wybryki związane z działaniem układu zegarka PCF8583 ???

.... otóż chodzi sobie na nim zegarek już naprawdę ładnych parę miesięcy, obsługuje to wszystko Atmega8 i generalnie wszystko jest ok, gdyby nie to , że już kilka razy zdarzyło się (chyba jakieś przepięcie w sieci albo nie wiem co ), że np przychodzę sobie do domu a tu wyświetla się godzina np: A6:46 i zegarek normalnie działa myślałem, że ma wbudowane jakieś ograniczenia i nie mogą wpaść inne wartości w komórki pamięci w których przetrzymywany jest czas a tymczasem

jak mówię zdarzyło się to naprawdę rzadko bo może ze 2-3 razy ale to ciekawe zjawisko godziny typu: BC:74 lub inne krzaczki - nie zawsze literki czasem były tam przypadkowe wartości - oczywiście po ustawieniu wszystko wracało do normy

raz zdarzyło to się w czasie burzy

RTC PCF8583 jest układem sprawdzonym w bardzo wielu aplikacjach. Ma swoje wady, ale prawidłowo zastosowany pracuje latami i nie ma z nim żadnych problemów. Piszę to na podstawie swoich opracowań, których było co najmniej kilka, a każda była powielana wielokrotnie przez różnych ludzi. Programy sterujące dla AVR oraz '51 i nigdy ani ja, ani żaden z użytkowników moich opracowań nie miał problemów z tym układem. Można się spierać co do jego dokładności w funkcji napięcia i temperatury, ale nie o działanie funkcjonalne. Moim zdaniem popełniłeś błędy konstrukcyjne, które zmniejszyły odporność c a ł e g o urządzenia na zakłócenia, a musisz wiedzieć, że dobra konstrukcja to nie tylko program i procesor. Pozdrawiam.

soft.sc -> ależ ja się nie chcę spierać i wmawiać , że PCF8583 jest jakiś wadliwy. Pewnie że może być tak, że wina leży po mojej stronie jeśli chodzi o układ ale z drugiej strony zegarek to nie respirator który podtrzymuje życie więc nie będę też dla tego układu rozbudowywał technologii antyzakłóceniowej rodem z kosmosu

jak zauważyłeś nawet słowem nie zarzucam scalaczkowi jakiegoś opóźniania czy pośpiechu bo nie o to idzie - tu zachowuje się ok

chciałem tylko zapytać czy ktoś miał może podobny przypadek z tym scalaczkiem i jak piszę skoro zdarzyło się to może mi ze 2-3 razy na 6 miesięcy nieprzerwanej pracy całości to rzeczywiście rzadko - z tym raz podczas burzy.

tym bardziej zdziwił mnie fakt, że jeśli były to zakłócenia to nie doprowadziły one do "szału" procka, który mógł się zawiesić czy coś. Wszystko działało dalej bez błędu tylko te błędne wartości godzin i minut.

i pewnie, jeśli okaże się tutaj, że ktokolwiek kiedyś miał podobne problemy to też zgodzę się że co najwyżej po drodze popełniłem jakiś błąd

pozdrawiam

Oczywiście, że zegarek to nie respirator i ja wcale nie mówię o technice kosmicznej. Wystarczy odpowiednie rozplanowanie węzłów zasilania i "szkolne" prowadzenie mas. Poza tym ważne jest blokowanie zasilania kondensatorami 100n i 10n każdego układu w projekcie no i najważniejsze - dobrze dobrany i zrobiony zasilacz. Ważna jest też jakość i sposób podłączenia bufora bateryjnego (koniecznie z elektrolitem za diodą). Te proste zabiegi pomagają wyeliminować 100% typowych zakłóceń a nietypowe zdarzają się raz na rok albo rzadziej. Właśnie takie proste zabiegi pomagają pozbywać się kłopotów z zakłóceniami w konstrukcjach amatorskich, a nie technika z kosmosu. Pozdrawiam.

soft.sc -> w pełni się z tobą zgadzam co do podstawoych sposobów zabezpieczeń jakie opisałeś, czyli odpowiednie kondensatory w odpowiednich miejscach i przy zasilaniu bateryjnym. Tak się składa, że ja sam tłumaczę to samo wielu osobom tu na elektrodzie a co za tym idzie dokładnie to stosuję. W moim układzie zegarka każdy scalak zaopatrzony jest w kondensator 100n i 47uF jak najbliżej nóżek zasilania, podobnie przy nóżkach stabilizatora 7805 i tak jak piszesz naprawdę dobrze się to sprawdza. Być może mogłem dać jeszcze jakiś dławiczek do zasilania PCFa np 10uH czy coś podobnego ale uznałem że to co zrobiłem jest wystarczające. A pomimo to choć tak rzadko że można ten problem zbagatelizować ale wystąpiło takie zjawisko.

Dodam, że zasilacz w postaci transformatora i prostownika z kondensatorami jest oddalony od samego układu - bo wykorzystałem poprostu jakiś zasilacz stabilizowany 12V od starego switcha czy huba (koncentratora sieciowego). Podobne rozwiązania często stosuję i naprawdę rzadko zawodzą z jakimiś tam przypadkowymi resetami itp.

bardziej mi chodzi o sam fakt, że nawet ręcznie (programowo) można wymusić takie dziwne wartości godzin i minut a scalak dalej będzie odliczał czas nie zdając sobie sprawy że godzina w nim jest np 43:77.

mirekk36 napisał:

...bardziej mi chodzi o sam fakt, że nawet ręcznie (programowo) można wymusić takie dziwne wartości godzin i minut a scalak dalej będzie odliczał czas nie zdając sobie sprawy że godzina w nim jest np 43:77.

Tak sobie czytam ten wątek i ... nie mogę wyjść ze zdumienia
Dlaczego "przyczepiłeś się" do PCF-a , a nie do swojego kodu
Nawet gdyby PCF zaczął odmierzać "dziwny" czas , to dziesiątki godzin nie mogą być większe od 3 Spójrz do dokumentacji i przypatrz się budowie komórki o adresie 4.

Piotrek

soft.sc
Skoro masz tak duze doswiadczenie z tym scalakiem to chcialem sie Ciebie poradzic jednej rzeczy. Otoz wspominasz o elektrolicie za dioda. Zastanawia mnie to, czy ze wzgledu na dosc duza uplywnosc kondensatora elektrolitycznego nie zmniejszy to zywotnosci baterii.
PCF8583 pobiera typowo 10uA z 5V gdy I2C jest nieaktywne (czyli akurat przy zasilaniu bateryjnym). Zastanawiam sie czy przypadkiem ta uplywnosc elektrolitu nie sprawi, ze laczny pobor sie podwoi.
Robiles kiedys takie testy?

marmur99

zumek -> nie przyczepiłem się tylko skojarzyłem ten rzadki fakt, który ciężko mi zasymulować, przepięciami- bo wtedy się to zdarzało....

... ale masz rację chyba popełniłem błąd w swoim kodzie, bo rzeczywiście komórka o adresie 4 przechowuje dziesiątki godzin tylko na 2 bitach, a ja zdaje się nie maskuję tych 2 bitów odpowiedzialnych nie za dziesiątki godzin i chyba stąd ten problem - sprawdzę to dokładnie - choć nadal zastanawiam się dlaczego to występuje ... ale z drugiej strony może jeszcze gdzieś jakiś babol mi siedzi w kodzie

pozdrówka

ok - sprawdziłem, poprawiłem - rzeczywiście teraz już nigdy nie pokaże mi się dziwna godzina - jednak to nadal nie wyjaśnia dlaczego czasem wskakują dziwne wartości do tych komórek godzin i minut. Bo to że zamaskowałem 2bity w dziesiątkach godzin nie rozwiązuje tego problemu że tam nagle pojawiają się nieprzewidziane wartości ...

... żeby jednak nikt nie mówił że się wciąż czepiam PCFka - oczywiście zakładam że to nadal może być jeszcze jakiś błąd w moim kodzie co nie oznacza, że nie znajdzie się może nikt komu się podobnie coś w nim przestawiło podczas jakichś zakłóceń elektrycznych (bo nie mówię przecież o normalnej pracy - podczas której też nie odnotowuję żadnych problemów)

Cytat:

Skoro masz tak duże doświadczenie z tym scalakiem

Drogi kolego. Fakt, że zrobiłem kilka urządzeń na tym scalaku powielonych w kilku czy kilkudziesięciu egzemplarzach, wcale nie świadczy o poziomie eksperta. Swoje konstrukcje opieram na ogólnych zasadach projektowania tego typu urządzeń, a tym co piszę chcę zwrócić uwagę kolegi mirekk36 na bezsensowność obwiniania jakiegoś układu o wrażliwość na zakłócenia. Każdy jest wrażliwy na swój sposób, a do rejestrów PCF da się wpisać dowolne liczby i do czasu "przejścia" przez zero będzie liczył głupoty - to nie procesor, który takie rzeczy może sprawdzać i korygować w razie pomyłki.
Jeśli chodzi o kondensator zwykle stosuję kondensatory tantalowe o pojemności 1uF (w zupełności wystarczy), którego upływność jest mimo wszystko niewielka, a zysk z jego zastosowania jest znacznie większy. Dioda stanowi rezystancję, a po każdej rezystancji w zasilaniu powinno się stosować elektrolity. Pozdrawiam.

soft.sc napisał:

... chcę zwrócić uwagę kolegi mirekk36 na bezsensowność obwiniania jakiegoś układu o wrażliwość na zakłócenia. Każdy jest wrażliwy na swój sposób, a do rejestrów PCF da się wpisać dowolne liczby i do czasu "przejścia" przez zero będzie liczył głupoty - to nie procesor, który takie rzeczy może sprawdzać i korygować w razie pomyłki.

sorry ale albo jesteś jakimś dużym dzieckiem z mlekiem pod nosem albo nie potrafisz w ogóle brać udziału w dyskusji .... albo trzecie - nie potrafisz za bardzo czytać

... tyle razy tłumaczę, że prawdopodobnie może to i ja popełniam jeszcze jakiś błąd ale dyskusja polega na tym aby spróbować coś konkretnego podpowiedzieć jak np zumek o tym jak zapisaywana jest godzina pod adresem 04 ... (chociaż też nie wiem dlaczego uznał że ja się czepiam scalaka a nie swojego kodu) - ale pomimo to uwaga była cenna muszę przyznać

może jeszcze coś innego źle odczytuję po I2C bo procedurkę w asm wykorzystałem ze stronki atmela .... chociaż odczyt chyba nie powinien dokonywać jakichś błędnych wpisów do tego scalaka

dlatego pytanie dotyczy tego czy ktoś także spotkał się z tym, że w przypadku jakiegoś dziwnego przepięcia być może wpadły do rejestrów minut czy godzin jakieś dziwne wartości - albo może ktoś też miał podobny problem i może coś powiedzieć z doświadczenia gdzie mógłbym jeszcze szukać jakiegoś błędu w sofcie. Pytanie nie jest tendencyjne i nie ma na celu obwiniać żadnego biednego scalaka (napisałem to tym razem mam nadzieję wyraźnie aby co niektórzy nie mieli znowu problemów z czytaniem)

Stary. Jesteś jakiś agresywny, a ja od początku piszę: NIE, NIE SPOTKAŁEM SIĘ Z TAKIM PRZYPADKIEM. Tylko ty jakoś nie potrafisz tego wyczytać i ruszyć mózgiem co może być przyczyną. A tu nikt nie jest wróżką i nie widzi coś tam spłodził. Może nie piszę wprost, ale przesłanie było jasne. Pozdrawiam i kończę z tą bezcelową dyskusją. Pozdrawiam.

Cześć !!!

Masz problem z PCF to raczej mało prawdopodobne

Szybciej bym obstawiał kiepski zasilacz do atmegi lub jakieś urządzenie o charakterze indykcyjnym w okolicy

Jdsoul -> oczywiście im więcej będzie tu takich odpowiedzi, że to może być wina głównie zasilacza - chociaż to dziwne że może on siać w takich przypadkach tylko po PCFku ale jasne - może przecież i tak być.... bo tak szczerze mówiąc to nawet nie zadałem sobie trudu aby rozebrać tą puszkę zasilacza od koncentratora żeby zobaczyć na ile i jak on działa - zresztą przy tak rzadko powtarzającym się problemie to nie jest aż tak istotne

.... oczywiście przychylam się do tego że to może być tylko coś u mnie skoro naprawdę nikomu się to z nim nie zdarza, i temu też służy ten wątek aby np potwierdziło się, że nikt takich dziwnych przypadków nie miał poza mną - to wtedy jak mnie zaczną wkurzać te dziwne godziny po przepięciach to zacznę szukać wad m.inn w zasilaniu nadal (pomimo to że dałem kondensatorki blokujące jak mi się wydaje prawidłowo) ale może to u mnie za mało.

Witam
Z tego co sobie przypominam, podobny komunikat ( a moze ten sam A6) pojawiał się przy zbyt szybkiej próbie czytania kolejnych ramek (odstęp STOP od START). Sprawdz swój czas i jeśli leży zbyt blisko wartości minimalnej, to go zwiększ.
Zakłócenia to oczywiście także dodatkowe przyczyny występowania dziwnych odczytów
Pozdrawiam

Ja kiedyś natrafiłem na takie dziwne godziny, może nie wyskoczyło B ileś tam, ale godzina 38 już wystarczyło do lol'a
Uruchamiałem jakieś urządzenie (akurat coś koło PCFa) wieć co za tym idzie maiłem cuda na lini zasilania

Zumek ma po częsci racje, niby nie da sie ustawić "większej" godziny, ale być może PCF ma wiecej bitów do których zwykły smiertelnik nie ma dostępu.
Nie wiadomo też jak PCF sprawdza godzine. Może tylko sprawdza czy spełniany jest warunek godzina=24 (a nie godzina>23) i w tedy następuje wyzerowanie rejestru. I tutaj droga do wyświetlenia głupot jest otwarta.

Przyszła mi pewna myśl do głowy, nigdy tego nie próbowałem, ale można by spróbować wpisac mu taką głupią wartość. Ciekawe jak PCF zareaguje na taki zabieg

Tak czytam i czytam i się zastanawiam czemu obwiniacie tego PCF'a? Przecież odczyt czasu, zmienne do ktorych zrzucany jest wynik i wyświetlanie realizuje uC zatem stawiałbym na coś z programem/procesorem. Zakres zmiennych odpowiedzialnych za czas jest przynajmniej 8-bit zatem wpisanie większej wartości do zmiennej jest możliwe w procesorze.

Ch.M. -> twój argument o tych zbyt szybkich ramkach mocno do mnie przemawia - więc wypróbuję i tu dać jakieś opóźnienia.

bolek -> pewnie, że zumek i inni mają rację aby jak najbardziej się zabezpieczać programowo popieram to - byłem tylko ciekawy czy ktoś poza mną zobaczył godzinę choćby 30:26 w wyniku jakiegoś przepięcia - ale to wszystko potwierdza tylko fakt, że muszę popracować nad polepszeniem warunków zasilania i jego filtrowania. Tak czy inaczej cieszę się że jeszcze ktoś widział taką godzinę z "kosmosu" na PCFku - niezależnie już przez co - bo jak wspominałem wcale nie mam zamiaru obwiniać PCFka tylko szukać porad co zrobić aby przed takimi zakłóceniami się obronić na przyszłość.

snow -> zgadzam się generalnie, ale chodzi o to, że zwykle większość czasu tylko odczytuję godzinę z PCFka, natomiast potem (po takiej mini awarii) obojętnie czy zresetuję cały układ czy nie to dziwna godzina pozostaje.

Dzięki wszystkim za wypowiedzi - utwierdza mnie to tylko w przekonaniu, że jednak bardziej trzeba zadbać może o zasilanie i programowo ew zabezpieczyć się przed dziwnymi wartościami (korygować je) tym bardziej jeśli coś obok może doprowadzać do zakłóceń elektrycznych

Cześć Mirekk36

Jak widzę jesteś empirystą i człowiekiem z doświadczeniem więc:

1. Stwórz w Atmedze licznik odczytów czasu z PCF - ile to jest w jakimś dłuższym okresie;
2. Stwórz licznik ilości resetów Atmegi w tym samym okresie, i jeśli to możliwe zapis momentu wystąpienia resetu
3. Analizuj poprawność odczytu z PCF np. za pomocą porównania odczytanych danych z poprawnie występującymi i stwórz licznik ilość danych niepoprawnych

Wszystkie liczniki umieść w EEPROM Atmegi, potem wyciągnij ich wartość do terminala lub czegoś takiego i masz odpowiedź na swoje pytania. Statystyka zazwyczaj nie kłamie . Jeśli wszystko jest stabilne i Atmega wogóle nie pada , to może za szybko chcesz czytać układ czasem niektóre wytrzymują tylko 400 kHz,

Jeśli nic do PCF nie zapisujesz i pojawiają się błędy w odczytywanych danych to możesz reklamować układ u producenta .

Jeśli ilość resetów w czasie pracy będzie duża to masz przeklamania transmisji PCF Atmega wynikającą z błędów zasilania lub jakiegoś dziwnego zakłócenia w twojej sieci, w otoczeniu układu, może gdzieś w okolicy pracuje piec martenowski lub przejeżdża wielki tramwaj albo masz zimny lut na płytce, jakiś błąd w styku, luźne wtyki zasilania etc..

I to właściwie tyle.
Mam PCF w kilku zastosowaniach fabrycznych i jakoś dobrze zaprojektowane układy pracują wyjątkowo stabilnie , nawet przy dość długich przerwach w zasilaniu bateryjka sobie radzi i kwarce też zazwyczaj są stabilne nawet te zegarkowe w końcu ze dwóch ludzi w PHILIPSIE nad tym układzikiem trochę posiedziało.

A swoją drogą to jak działa twój układ czy przypadkiem nie popycha PCF 3 razy na sekundę lub coś podobnego .

Jdsoul -> reklamować scalaka nie mam i nie miałem zamiaru bo jak mówię zbieram z nim doświadczenia i raczej jak sam mówiłem widzę, że gdzieś wina może leżeć w filtrowaniu zasilania. Tak więc nie wusuwaj wniosków za mnie że uważam iż producent scalaka popełnił jakieś błędy - akurat ja jestem zawsze od tego najdalej i zwykle szukam błędów u siebie, a tu chciałem tylko potwierdzić czy może ktoś miał z nim podobne przygody być może również przy jakichś kłopotach z zasilaniem - więc nie rozpędzaj się dalej proszę w takich dywagacjach bo znowu ten temat zejdzie na manowce.

odnośnie jak to okresliłes "popychania" to jeśli popychaniem jest dokonywanie z niego regularnie odczytów to tak "popycham PCFa" ale nie 3 razy na sekundę tylko raz na sekundę - może to za dużo? hmm ale wątpię aby to mu szkodziło.

pozdr

Nie oto mi chodzi jak często tylko generalnie o zasadę działania twojego zegarka
Bo jak wiesz na czas odczytu PCF zamraża wynik

Druga sprawa to jednak spróbuj zdebugować zabawkę jako całość co ci szkodzi Nawet w Bascu to banalna zabawa ,a nauka co do konstrukcji i niezawodności urządzeń bardzo pouczająca

A propos to badania niezawodności są bardzo pożyteczne bo zapewniają ograniczenie strat produkcyjnych

Jdsoul napisał:

...
Bo jak wiesz na czas odczytu PCF zamraża wynik ...

cały program do tego zegarka napisałem w asemblerze i pierwszy raz tak naprawdę obsługiwałem w nim właśnie tego ukochanego PCFka ... tzn to zamrażanie na czas tak krótkiego odczytu raz na sekundę chyba nie powinno mu przeszkodzić - w końcu kiedyś trzeba go odczytywać

... pierwszy raz też w asemblerze robiłem obsługę I2C. Tak jak zasugerował wcześniej kolega Ch.M. spróbuję jak tylko będę miał czas dać jakieś minimalne opóźnienia pomiędzy startem a kolejnym rozkazem odczytującym. Chociaż skorzystałem na żywca z procedurek do I2C w trybie programowym wprost z ATMELa więc teoretycznie powinny działać dobrze.

naprawdę tak dogłębnie to zajmę się debugowaniem dokładnym całego softu jeśli te dziwne godziny zaczną się pojawiać zbyt często - bo jak mówię przy takiej średniej jak narazie 2-3razy/5miesięcy to nie chce mi się nawet zmieniać czegoś w zasilaniu. Ale gdy stanie się to bardziej upierdliwe to zacznę działać

pozdr

No to fajny wątek

Dorzucę conieco ze swoich doświadczeń z tym układem.

Pierwszy dopracowany układ z użyciem PCF8583 jaki robiłem, to było coś w rodzaju "komputerka samochodowego" (temperatura, napięcie, zegar z automatyczną zmianą czasu zima/lato). W kilka chwil po odpaleniu miałem "dziwne" rezultaty na polu godzin (szczegółów nie podam, to było ze 2 lata temu) - pomimo że zasilanie było z zasilacza stabilizowanego (laboratoryjny). Stosunkowo szybko wpadłem na pomysł z maskowaniem wartości - w końcu w nocie aplikacyjnej producent NIGDZIE NIE GWARANTUJE że nieużywane bity w polu godzin będą zawsze zero, prawda ? Może faktycznie czytałem go za często lub za szybko. Po zastosowaniu maskowania układ wyświetla poprawnie DO DZIŚ (a jest zamontowany w pojeździe co najmniej półtora roku).
Wniosek nasuwa się sam - producent uprościł konstrukcję układu, oszczędzając pewnie ze 2 centy na cenie 1 egzemplarza, co jednak ma swój negatywny skutek w postaci takiej jak opisuje ten wątek. Ważna nauka - konstruktor nigdy nie powinien zakładać, że świat jest idealny. Jeśli coś nie jest pewne (jak wartości nieużywanych bitów w komórkach pamięci) należy pomyśleć i się przed tym zabezpieczyć.

al777 -> dzięki za cenne info (na takie uwagi i spostrzeżenia praktyczne również liczyłem w tym temacie właśnie) a możesz mi podpowiedzieć w czym pisałeś program do procka? dla mnie to o tyle istotne, że ja jak czytałeś robiłem to w asemblerze i po raz pierwszy. Też na początku nie maskowałem bitów do momentu uwagi tutaj kolegi zumka. Zapewne popełniłem jeszcze inne błędy o jakich tu mowa ale zastanawiam się właśnie czy np gdy napiszę na drugi raz taką obsługę w Bascomie to czy wtedy uda się pominąć ew błędy programowe jeśli chodzi chociażby o obsługę I2C itp....

dlatego to pytanko w czym ty akurat pisałeś swój soft?

pozdrówka

Osobiście zdarzyło mi się popełnić kilka różnych czasomierzy na PCF'ie, zarówno we współpracy z 89xx51 jak i AVR'kami - piszę w bascomie. Uwaga co do maskowania niewykorzystanych bitów w odczytanym bajcie jest bardzo zasadna. Uwzględniając brak wiedzy na temat faktycznej zawartości rejestru z którego potrzebuję tylko połowy bitów stosuję maskowanie praktycznie we wszystkich takich przypadkach, z PCF'em włącznie. Ostatnio walczyłem z RDS'em to wiem o czym mówię...
Co do obsługi I²C to trudno w bascomie coś popsuć. Zawsze poszczególne wartości odczytuję hurtem (od sekund po miesiąc) i nie zdarzyło mi się zaobserwować jakichkolwiek trudności. Zdaję sobie sprawę, że w asemblerze sam musisz zadbać o odpowiedni timing procedury obsługi I²C, więc w tym węszyłbym największe prawdopodobieństwo błedu. Taka sugestia na boku...

redart -> no właśnie o to mi chodziło pytając poprzedniego kolegę w czym pisał soft. A że sam od niedawna zafascynowałem się Bascomem to też pomyślałem sobie, że nie będąc zmuszonym do własnoręcznego dbania o timingi itp - to wszystko powinno być dobrze - bo te procedury opracowane w Bascomie są już dobrze posprawdzane i uniwersalne .... dlatego kolejne układy w większości będę robił w oparciu głównie o Bascom ew z wstawkami asemblerowymi bo przecież dosyć łatwo to ożenić razem

Przepraszam że dopiero teraz odpowiadam. Cały kod pisałem w C (kompilator Raisonance - darmowa wersja generuje do 4kB kodu - mnie wystarczyło).
Garść szczegółów, jeśli kogoś interesuje :
Do całości był wyświetlacz LCD 2x40 linii, termometry na linearyzowanych termistorach (przetwarzanie R->f) - max. błąd był ok. 5 st. Celciusza w zakresie -15...+25, więc metody nie polecam (to był poligon doświadczalny, ze zdobyciem dobrych i tanich czujników temperatury miałem problemy).
Pomiar napięcia też robiony był prymitywnie - zliczanie czasu ładowania kond. tantalowego 2.2uF zasilanego przez źródło stałoprądowe (JFET ze zwartą bramką do źródła) i porównanie tej piły z napięciem proporcjonalnym do zasilającego (czyli mierzonego) - błąd był max. rzędu 0.3V przy wskazaniach z zakresu 11...15V. Też nie rewelacja, ale przy takim prymitywnym układzie ...

Generalnie macie racje czasem Producent "PHILIPS" nie uwzględnia "dziwnych" danych bo zakłada, że chcemy osiągnąć dokładnie to co chcemy
i jemu te dane które udostępnia są wystarczające
Ale od czego są przykłady aplikacji dostarczone przez producenta, czasem pojawiają się tam "zbędne" fragmenty kodu itp. Bo z pkt. asm zawsze można szybciej

Znaczącym tematem wpływajacym na jakość oprogramowania w ogóle jest zabezpieczenie go przed działaniami i błędami wynikającymi ze złej manipulacji zewnętrznej, złych danych wejściowych, "uszkodzeniowego" połączenia spodziewanych peryferiów, czy nawet przewidywanych w otoczeniu zakłóceń etc. Owszem zawsze zabiera to miejsce w kodzie, ale poco nam potem niespodzianki

Procedury I2C w zależności od konkretnie wskazanego urządzenia to jedno, ale czas wykonania operacji w urządzeniu peryferyjnym też powinien być uwzględniony w procedurze obsługi niezależnie od stosowanego protokołu , a jedynie na podastawie osiągów czasowych podanych w karcie danego scalaczka

Przykładem może być obsługa wyświetlacza LCD, gdzie brak zastosowania opóźnień generuje błędy i nikt z tym za mocno nie dyskutuje jak trzeba 30 ms to trzeba chociaż serducho boli

Ja osobiście np. czytając czy zapisując pamięci EEPROM zawszę daję chwilkę oddechu układowi na wykonanie zadanych operacji.

Problem, o którym mówie był prawie niezauważalny przy 1-2 MIPS, ale teraz nie ma już problemu z 16-32 MIPSi, a urządzenia peryferyjne pozostają te same np. rzeczony PCF on poprostu szybciej rady nie da

Dodano po 1 [minuty]:

Chociaż przyłączony procek by dał

Trafiłem na ten temat, bo szukam procedur w asemblerze do PCF8583 , odczyt,zapis (zegar, kalendarz, alarmy). Proszę jeśli ktoś posiada w swoich zbiorach.

Spotkało mnie doświadczenie z dziwnym zachowaniem się tego zegara jak wyżej w postach. Problem rozwiązałem programowo, jako że ten pojawiał się sporadycznie. Podaję fragment programu z odczytem zegara z PCF8583.