Jeśli TWI jest sprzętowe, to jednoznacznie wskazuje na oscylator. W jakiś cudowny sposób CKDIV8 i/lubCKSELx są różne. Ewentualnie można (zdaje się) z poziomu softu mnipulować zegarem.
Pozdr
Jeśli TWI jest sprzętowe, to jednoznacznie wskazuje na oscylator. W jakiś cudowny sposób CKDIV8 i/lubCKSELx są różne. Ewentualnie można (zdaje się) z poziomu softu mnipulować zegarem.
Pozdr
PcmOl pisze:
załadowanie rejestru wewnętrznego zegara po inicjalizacji TWI spowodowało że wyświetlacz przestał mi reagować lub pokazywał kaszanę.
Dnia Sat, 9 Apr 2016 13:23:47 +0200, Sebastian Biały napisał(a):
Zegar jest ok. Wyjście, którego stan jest zmieniany w przerwaniu od timera wywoływanym co 1 sekundę, działa jak trzeba niezależnie od tego, którym kompilatorem skompiluję program.
Więc szukaj: a) problemów z jakimś delay(), prawdopodobnie jest napisana przez dyletanta b) zainteresuj się czy przerwania "wyrabiają" się poprzez ich eliminacje c) Zwróć uwagę czy aby na pewno poprawnie ustawiasz bity, np., stary gcc mógł gdzieś dawać zero a nowy uninitialized w wyniku błedów w kodzie. Sprawdź warningi.
Nie mialem problemów tego typu z kodem przy migracji gcc na avr i arm. Zazwyczaj było lepiej lub tak samo poza corner cases jak liczenie floatów gdzie często są bugi.
badworm pisze:
Ale timer jest sprzętowy, jego przerwania muszą działać jak trzeba. Może coś się zmieniło w programowym I2C i trzeba go inaczej obsługiwać/inicjalizować.
mam taki szalony pomysł, może Ktoś spoza po napisać jak podejrzeć kod assemblerowy na jaki została przetłumaczona problematyczna funkcja?
Niestety poza PO sami tumaniści. Prawdziwi iluminaci i powolni murarze tylko w PO. Ale uchylę rąbka tajemnicy:
badworm snipped-for-privacy@post.pl napisał(a):
Czy mógłbyś wystawić gdzieś całość kodu?
Have something to add? Share your thoughts — no account required.
Ask the community — no account required