Sprawa wygląda tak, że siedze nad tym długo, a w Internecie nie znalazłem nic, co by mi pomogło. Szukałem dość dużo i już zaczynam się frustrować.
Nie chodzi o delay trwający 750ms, bo ten wyeliminowałem. Rzecz jest m.in. w tych, które trwają od kilku do aż 500µs (reset pulse).
Śmiem przypuszczać, że to właśnie za przyczyną tych krótkich opóźnień wyświetlacze siedmiosegmentowe lekko "drgają" (gasną na bardzo krótko).
Jeżeli prescaler któregoś z timer-ów ustawię na zbyt niski to na wyświetlaczu zaczynają się pojawiać "bzdury" - myślę, że w jakiś sposób kolidują one z kilkumikrosekundowymi opóźnieniami.
W przypadku konwersji temperatury (zamiana dwóch bajtów na postać "do wyświetlenia") nie odczułem żadnego problemu: temperatura w pomieszczeniu jest wyświetlana tak, jak należy. Na razie nie zaprzątałem sobie głowy jakimiś większymi zakresami. Nie stosowałem jakichś skomplikowanych metod, więc kompilator nie powinien zrobić z tego jakiegoś "cyrku", mimo, że zrealizowałem to dość "chałupniczo".
Mam takie pytania:
1. Czy jest jakaś możliwość realizacji komunikacji z DS18B20, która nie będzie uzależniona od delay-ów?
2. Czy własne napisanie delay-ów może mi w czymś pomóc?
3. Jeżeli chciałbym zrealizować coś bardziej skomplikowanego to powinienem "dołożyć" jeszcze jeden µC, żeby uniknąć niespodzianek? Miałoby się to wiązać z przerwaniami zewnętrznymi i paroma innymi rzeczami opartymi o timery.
4. Czy biblioteka z dallas semiconductors może mi w czymś pomóc?
DS18B20 nie jest zasilany pasożytniczo, a wyświetlacze siedmiosegmentowe są multipleksowane. Użyłem też ośmiobitowego rejestru przesuwnego w celu "zaoszczędzenia" kilku pinów.
Fusebity ustawione fabrycznie (taktowanie 1MHz).
Będę wdzięczny za wszelkie sugestie.
edit: volatile są w nadmiarze - to chyba nie jest problem?
Nie chodzi o delay trwający 750ms, bo ten wyeliminowałem. Rzecz jest m.in. w tych, które trwają od kilku do aż 500µs (reset pulse).
Śmiem przypuszczać, że to właśnie za przyczyną tych krótkich opóźnień wyświetlacze siedmiosegmentowe lekko "drgają" (gasną na bardzo krótko).
Jeżeli prescaler któregoś z timer-ów ustawię na zbyt niski to na wyświetlaczu zaczynają się pojawiać "bzdury" - myślę, że w jakiś sposób kolidują one z kilkumikrosekundowymi opóźnieniami.
W przypadku konwersji temperatury (zamiana dwóch bajtów na postać "do wyświetlenia") nie odczułem żadnego problemu: temperatura w pomieszczeniu jest wyświetlana tak, jak należy. Na razie nie zaprzątałem sobie głowy jakimiś większymi zakresami. Nie stosowałem jakichś skomplikowanych metod, więc kompilator nie powinien zrobić z tego jakiegoś "cyrku", mimo, że zrealizowałem to dość "chałupniczo".
Mam takie pytania:
1. Czy jest jakaś możliwość realizacji komunikacji z DS18B20, która nie będzie uzależniona od delay-ów?
2. Czy własne napisanie delay-ów może mi w czymś pomóc?
3. Jeżeli chciałbym zrealizować coś bardziej skomplikowanego to powinienem "dołożyć" jeszcze jeden µC, żeby uniknąć niespodzianek? Miałoby się to wiązać z przerwaniami zewnętrznymi i paroma innymi rzeczami opartymi o timery.
4. Czy biblioteka z dallas semiconductors może mi w czymś pomóc?
DS18B20 nie jest zasilany pasożytniczo, a wyświetlacze siedmiosegmentowe są multipleksowane. Użyłem też ośmiobitowego rejestru przesuwnego w celu "zaoszczędzenia" kilku pinów.
Fusebity ustawione fabrycznie (taktowanie 1MHz).
Będę wdzięczny za wszelkie sugestie.
edit: volatile są w nadmiarze - to chyba nie jest problem?
Kod: C / C++
