[C++][Atmeg8] Termometr na wyświetlaczach 7-segmentowych
[C++][Atmeg8] Termometr na wyświetlaczach 7-segmentowych
Witam, mam problem z termometrem na wyświetlaczach 7-segmentowych. Wyświetlacz 3x7SEG. Wspólna Anoda.Na razie nie wyświetlam cyfry po przecinku. Temperaturę chyba zczytuję dobrze, lecz co jakiś czas na wyświetlaczu pojawiają się 00, bądź jakieś inne śmieci. Co jest nie tak w tym programie? I jeszcze jeden problem. Otóż na pierwszym wyświetlaczu, tak jak by w tle, lekko świeciły segmenty z cyfry z drugiego wyświetlacza, natomiast na drugim - z pierwszego wyświetlacza. Czym to może być spowodowane?
Kolego ile chcesz jeszcze założyć tematów o tym samym urządzeniu ? Masz już jeden o DS1820, może w nim sprecyzuj wszystkie niedoróbki.
Co do "Duszków" na wyświetlaczach, prawdopodobnie źle przemiatasz wyświetlacz w programie. TZN. gasisz pierwszy wyświetlacz, zapalasz drugi i dopiero wystawiasz, na wyświetlacz drugą cyfrę, to powoduje że przez ułamek ms. na drugim wyświetlaczu świeci cyfra z pierwszego, a ponieważ czas ten jest za krótki aby wyświetlacz zaświecił pełną mocą powstaje efekt ducha, w tle innej cyfry, którą tam wstawiasz.
Powinno wyglądać to tak:
Wystawiasz na pierwszy wyświetlacz cyfrę, zapalasz go na jakiś czas, gasisz go wystawiasz, cyfrę dla drugie, i dopiero go zapalasz. Inaczej mówiąć, zmiany cyfr musisz mieć w czasie kiedy, żadna Anoda nie jest aktywna.
Jak więc napisać program ?
Najpierw trzeba uświadomić sobie pewne fakty.
Pierwszy, najważniejszy jest taki że każdy program który steruje wyświetlaczem, 7-SEG, diodowym itd, jest programem synchronicznym.
Co to oznacza ?
Wszystkie zdarzenia w programie muszą dziać się synchronicznie,w takt zegara systemowego dotyczy to odświeżania wyświetlacza, czytania klawiatury, odczytu DSa w twoim przypadku też.
Co jest zegarem systemowy ?
W naszym przypadku są to przerwania od Timera który steruje wyświetlaczem. Jak teraz sobie ustalić odświeżanie wyświetlacza ? Tutaj właśnie zaczyna się zabawa w projektowanie, bo trzeba odpowiedzieć sobie na pewne pytania, i poczynić pewne założenia.
Pierwsze pytanie ile czasu trwa procedura odczytu danych z DSa1820 ? Jeżeli mniej niż ½ z 5ms luzik.
Drugie pytanie. Ile czasu trwa ta sama procedura odczytu z DSa1820, jeżeli pojawi się błąd transmisji, lub komunikacji ? Jeżeli mniej niż ½ z 5ms. luzik. To czy zwraca jakiś error to kwestia poboczna, w tym momencie nieistotna.
Dla czego mniej niż ½ z 5ms ?
To wynika z założenia które przyjąłem, a które teraz objawię
Otóż przyjąłem że każdy wyświetlacz musi być odświeżany z 50Hz, i jest ich 4, nic nie szkodzi że ty masz 3 (da to ~62,5Hz co niczemu nie szkodzi), dla 4 po prostu łatwiej się liczy, i programuje bo znikają ułamki. 50Hz x 4 wyświetlacza daje 200 wywołań procedury / sek. 1sek = 1000ms / 200 = 5ms.
Więc dla czego ½ z 5ms? Otóż te 5ms, to czas graniczny i lepiej zdążyć co najmniej w czasie o połowę krótszym, co nie znaczy że jak wyrobimy się w ¾ tego czasu to program sie wysypie, ale lepiej mieć większy margines błędu, niż mniejszy.
Z tymi założeniami można dopiero budować program, ale dziś mi się już więcej pisać nie chce.
Dodam jeszcze tylko że z tych założeń wynika, iż programu dla urządzeń z wyświetlaczami LED, nie da się pisać na tzw. pałę, sklecając je z przypadkowych fragmentów kodu. Trzeba je projektować, albo przynajmniej znać wzór wg. którego się je pisze.
Co do "Duszków" na wyświetlaczach, prawdopodobnie źle przemiatasz wyświetlacz w programie. TZN. gasisz pierwszy wyświetlacz, zapalasz drugi i dopiero wystawiasz, na wyświetlacz drugą cyfrę, to powoduje że przez ułamek ms. na drugim wyświetlaczu świeci cyfra z pierwszego, a ponieważ czas ten jest za krótki aby wyświetlacz zaświecił pełną mocą powstaje efekt ducha, w tle innej cyfry, którą tam wstawiasz.
Powinno wyglądać to tak:
Wystawiasz na pierwszy wyświetlacz cyfrę, zapalasz go na jakiś czas, gasisz go wystawiasz, cyfrę dla drugie, i dopiero go zapalasz. Inaczej mówiąć, zmiany cyfr musisz mieć w czasie kiedy, żadna Anoda nie jest aktywna.
Jak więc napisać program ?
Najpierw trzeba uświadomić sobie pewne fakty.
Pierwszy, najważniejszy jest taki że każdy program który steruje wyświetlaczem, 7-SEG, diodowym itd, jest programem synchronicznym.
Co to oznacza ?
Wszystkie zdarzenia w programie muszą dziać się synchronicznie,w takt zegara systemowego dotyczy to odświeżania wyświetlacza, czytania klawiatury, odczytu DSa w twoim przypadku też.
Co jest zegarem systemowy ?
W naszym przypadku są to przerwania od Timera który steruje wyświetlaczem. Jak teraz sobie ustalić odświeżanie wyświetlacza ? Tutaj właśnie zaczyna się zabawa w projektowanie, bo trzeba odpowiedzieć sobie na pewne pytania, i poczynić pewne założenia.
Pierwsze pytanie ile czasu trwa procedura odczytu danych z DSa1820 ? Jeżeli mniej niż ½ z 5ms luzik.
Drugie pytanie. Ile czasu trwa ta sama procedura odczytu z DSa1820, jeżeli pojawi się błąd transmisji, lub komunikacji ? Jeżeli mniej niż ½ z 5ms. luzik. To czy zwraca jakiś error to kwestia poboczna, w tym momencie nieistotna.
Dla czego mniej niż ½ z 5ms ?
To wynika z założenia które przyjąłem, a które teraz objawię
Otóż przyjąłem że każdy wyświetlacz musi być odświeżany z 50Hz, i jest ich 4, nic nie szkodzi że ty masz 3 (da to ~62,5Hz co niczemu nie szkodzi), dla 4 po prostu łatwiej się liczy, i programuje bo znikają ułamki. 50Hz x 4 wyświetlacza daje 200 wywołań procedury / sek. 1sek = 1000ms / 200 = 5ms.Więc dla czego ½ z 5ms? Otóż te 5ms, to czas graniczny i lepiej zdążyć co najmniej w czasie o połowę krótszym, co nie znaczy że jak wyrobimy się w ¾ tego czasu to program sie wysypie, ale lepiej mieć większy margines błędu, niż mniejszy.
Z tymi założeniami można dopiero budować program, ale dziś mi się już więcej pisać nie chce.
Dodam jeszcze tylko że z tych założeń wynika, iż programu dla urządzeń z wyświetlaczami LED, nie da się pisać na tzw. pałę, sklecając je z przypadkowych fragmentów kodu. Trzeba je projektować, albo przynajmniej znać wzór wg. którego się je pisze.
Ostatnio zmieniony 22 gru 2013, 22:05 przez kayron, łącznie zmieniany 1 raz.
W takim razie wywołujesz jakąś procedurę/funkcję, która koliduje z podprogramem odświeżania wyświetlacza, włażąc mu w jego czas. Prawdopodobnie odczytujesz DSa w "losowych" momentach, a ponieważ, jego procedury też będą korzystały z jakiś przerwań, czy delayów, to powstaje desynchronizacja, w pracy wyświetlacza, o której pisałem wyżej.
Bez kompletnego kodu, ciężko tu coś wróżyć, ale większość programów z DSami cierpi właśnie z tego powodu, że różne funkcje nie są synchronizowane, i włażą sobie w przypadkowym czasie w paradę.
Tak zerknąłem to sekwencja inicjująca 1WAR trwa ok 960us, teraz niech bit trwa 15us, to odczyt z magistrali może spokojnie trwać 2-3ms teraz niech ci wlezie w tym czasie jakieś przerwanie w paradę, to ci się dziwy zaczynają dziać Dla tego tak ważne jest synchronizowanie wszystkiego, żeby jedno nie wlazło drugiemu, w grządki z pomidorami
.
Diagram czasowy poprawnie napisanej aplikacji powinien wyglądać mniej więcej TAK:
Oczywiście rysunek jest poglądowy i przedstawia Idę działania programu.
Bez kompletnego kodu, ciężko tu coś wróżyć, ale większość programów z DSami cierpi właśnie z tego powodu, że różne funkcje nie są synchronizowane, i włażą sobie w przypadkowym czasie w paradę.
Tak zerknąłem to sekwencja inicjująca 1WAR trwa ok 960us, teraz niech bit trwa 15us, to odczyt z magistrali może spokojnie trwać 2-3ms teraz niech ci wlezie w tym czasie jakieś przerwanie w paradę, to ci się dziwy zaczynają dziać Dla tego tak ważne jest synchronizowanie wszystkiego, żeby jedno nie wlazło drugiemu, w grządki z pomidorami
.Diagram czasowy poprawnie napisanej aplikacji powinien wyglądać mniej więcej TAK:
Oczywiście rysunek jest poglądowy i przedstawia Idę działania programu.
- Załączniki
-