Wyświetlacz TM1637 błędy podczas wyświetlania

[shady]

Hej

Mam podłączony do malinki wyświetlacz 7 segmentowy oparty na układzie TM1637. Co jakiś czas wkrada się jakiś błąd w wyświetlanych liczbach, jakiś segment się nie zapali albo zapali się inny lub w ogóle jakaś wartość z czapy. Wyświetlacz mam połączony skrętką FTP około 10m długości. Wcześniej miałem odcinek z 20cm i też było to samo.

Zastanawiam się czego to może być wina. Czy są to jakieś zakłócenia na przewodach. Tak na szybko podejrzałem na oscyloskopie jak to wygląda i zastanawiają mnie te szpileczki, czy one mogą mieć jakiś wpływ? Później postaram się nałapać trochę więcej.. Jeszcze kwestia tego łagodnie opadającego zbocza na pierwszym zdjęciu... co to może być? Czy powinienem podciągnąć te linie rezystorem do zasilania??

Edytowano Styczeń 4, 2021 przez shady

[polihedron]

1. wyświetlacz na TM1637 potrafi czasem dużo prądu pobierać, sprawdź czy masz wystarczająco odpowiednie zasilanie,

2. dodaj duży kondensator przy nim jeśli jeszcze nie masz,

3. podłącz pod dowolne arduino na 5V i zobacz czy to samo się dzieje, 

4. komunikacja z mcu jest chyba po i2c, 10m przewodu to całkiem dużo, sprawdź czy masz odpowiednie pull-upy na każdej lini, przy 3V3 dałbym coś około 1k. 

[ethanak]

5 minut temu, polihedron napisał:

komunikacja z mcu jest chyba po i2c

To nie jest i2c tylko jakiś własnościowy protokół, nie wymaga rezystorów podciągających (wręcz przeciwnie, jak dodasz to może przestać świecić).

[marek1707]

Tymi "szpileczkami" na razie się nie martw. Nie wiemy jakie sygnały pokazałeś i gdzie je mierzyłeś (na Malinie względem jej GND czy na module, z masą sondy zaczepioną na module), ale rozumiem, że pierwszy to dane a drugi to zegar. No i martwi mnie ten wolno opadający sygnał danych. Jeżeli jest zdjęty w tej samej skali czasowej co zegar, to tu może być problem. Najlepiej gdybyś pokazał oba sygnały z dwóch kanałów jednocześnie. Dane muszą być stabilne gdy zegar jest w stanie wysokim a tutaj ktoś ma straszny problem ze ściąganiem do zera i to jest niepokojące. Podciągnięcie linii do plusa jeszcze pogorszy sprawę. Także zmierz i pokaż wykres, jakieś dwa bajty transmisji wystarczą poczynając od zdarzenia START. Czy coś jeszcze wisi na tej szynie?

To nie jest I2C, ale elektrycznie i logicznie bardzo podobne. Linia danych jest dwukierunkowa a obie mają być podciągnięte opornikami do plusa. Zą zdarzenia START, STOP a odbiornik danych potwierdza bajty na 9 bicie ACK. Tylko że w I2C ściąganie w dół jest bezproblemowe a w górę idzie znacznie wolniej, bo z opornika. Tutaj dzieje się coś dziwnego, może to problem drivera programowego w Malinie? Bo podejrzewam, że bit-banging zrobili i może jakoś źle kierunek portu danych zmieniają? Ale wtedy opornik by ciągnął do plusa, a tu do zera tak wolno zjeżdża..

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

1 minutę temu, marek1707 napisał:

Linia danych jest dwukierunkowa a obie mają być podciągnięte opornikami do plusa.

To powiedz mi, dlaczego kiedyś (kiedy ja głupi myślałem że to i2c) wszystko zadziałało dopiero po wywaleniu rezystorów? A jestem na 99% przekonany że transmisja leci w jedną stronę (ale się nie upieram).

[polihedron]

4 minuty temu, ethanak napisał:

To powiedz mi, dlaczego kiedyś (kiedy ja głupi myślałem że to i2c) wszystko zadziałało dopiero po wywaleniu rezystorów? A jestem na 99% przekonany że transmisja leci w jedną stronę (ale się nie upieram).

niedawno przerabiałem temat z tym wyświetlaczem, pull-upy nie blokują transmisji, w bibliotece clk i data są jako inputs ustawione, można dodawać.:)

chyba z tego korzystałem:

https://github.com/avishorp/TM1637/blob/master/TM1637Display.cpp

Edytowano Styczeń 4, 2021 przez polihedron

[marek1707]

https://www.mcielectronics.cl/website_MCI/static/documents/Datasheet_TM1637.pdf

To driver wyświetlaczy i klawiatury. Muisz jakoś odczytywać jej stan, prawda? A linia nazywa się DIO.

[ethanak]

OK, to źle myślałem 😞 Już się czegoś znowu nauczyłem...

[polihedron]

4 minuty temu, marek1707 napisał:

https://www.mcielectronics.cl/website_MCI/static/documents/Datasheet_TM1637.pdf

To driver wyświetlaczy i klawiatury. Muisz jakoś odczytywać jej stan, prawda? A linia nazywa się DIO.

a tak, racja, domyślnie są jako wejścia.:)

[marek1707]

Po wyjaśnieniu kwestii podstawowych 🙂 czekamy na obrazek z oscyloskopu.

[shady]

22 minuty temu, marek1707 napisał:

Po wyjaśnieniu kwestii podstawowych 🙂 czekamy na obrazek z oscyloskopu.

Jutro powinno się udać;)

[shady]

Witajcie

Załączam dwa obrazki z oscylogramami ale to nie jest to co bym chciał Wam pokazać. Zaczynam żałować każdej wydanej złotówki na ten chiński wynalazek który zakupiłem za nie małe pieniądze. Myślałem, że uda zapisać się trochę transmisji na pendrive i później na spokojnie przeanalizować to na komputerze. Na razie same problemy z tym urządzeniem. Jeżeli chodzi o to co udało się podejrzeć to nie wiem czy oba te kanały są zsynchronizowane bo jakoś dziwnie to wygląda. Domyślam się, że ch1 to zegar a ch2 to dane. Czemu w takim razie takt zegara ma takie przerwy, nie widać już tutaj tego wolno opadającego zbocza, pewnie dlatego że wtedy badałem przebieg na niepodłączonym wyświetlaczu. Teraz podpiąłem się przy działającym układzie. Natomiast pojawiają się takie dziwne trochę jakby pilaste przebiegi.

[marek1707]

No tak, ale podpięcie wyświetlacza zupełnie zmienia układ. Po pierwsze pojawiają się podciągi do Vcc więc gdy nikt nie steruje linią to nie ma już tego wolnego opadania, tylko powolny wzrost napięcia (to nic złego). Po drugie widać, że obie linie są sterowane programowo (bit-bang) i stąd te zatrzymania zegara - tym się nie przejmuj. Natomiast sygnały wyglądają generalnie dobrze. Trochę niepokojąco wyglądają te lekkie wzrosty poziomu odniesienia. Np dokładnie na środku (czasu/ekranu) zarówno zegar jak i dane podniosły się lekko. To może oznaczać jakiś problem z masą, dużymi prądami czy coś. Co jest w tym systemie oprócz Maliny i wyświetlacza? A jeśli okaże się (a na 50% tak jest), że problemem jest tzw. signal integrity to będziesz potrzebował dobry, dwukanałowy oscyloskop z pasmem min. 100-200MHz i dwie dobre sondy z takim pasmem. Drugie 50% zostawiam jednak na błędy w bibliotece obsługi tego scalaka..

[shady]

Malina jest podłączona do zasilacza 5v o wydajności 2A, do maliny jest jedynie podłączona jeszcze magistrala 1-wire z 2 dallasami. 
Kupiłem niedawno siglent’a SHS806 ze względu na jego uniwersalność związaną z przenośnością. Jak rozumiem nie bardzo się nadaje do takiego typu diagnostyki? Wydawało mi się, że w miarę z dobrą szczegółowością uda się złapać kilka sekund danych i przeanalizować na komputerze, ale jak na razie nie mogę znaleźć sterowników pod windowsa. Nagrywanie też jest jakieś ułomne bo chyba 100ms trzeba ustawić podstawę czasu. Więc przy tak szybkich przebiegach to będzie słaba rozdzielczość, chyba że się mylę... marne mam jeszcze doświadczenie w tym temacie. 

JN

[marek1707]

Nie skupiaj się na długości pamięci oscyloskopu. Do badania tego typu rzeczy nie potrzeba sekund nagrań. To nie jest analiza całych ramek danych tylko pojedynczych zboczy. Jeśli port/kabelek jest w stanie prawidłowo wysłać jeden impuls zegara, to zrobi to dobrze także milion razy. Zdarzenia które Cię (obecnie) interesują mają mikrosekundy. I takim rzeczom będziesz się przyglądał. Jeśli oba sygnały (zegar i dane) dochodzą do wejść scalaka niezniekształcone i bez dziwnych odbić, szpileczek czy stanów przejściowych, to od strony sprzętowej nie będzie się do czego przyczepić. I tu rola oscyloskopu się kończy*. Przeciwieństwem tego są problemy z błędną pracą programu/biblioteki. Jeśli ona coś robi źle, np. gubi się w sterowaniu pinami lub wysyła złe bajty informacji lub jakoś łamie protokół, to wtedy faktycznie potrzebny jest analizator protokołu (może I2C wystarczy, ale nie wiem), ale to dwa różne narzędzia. Rozejrzyj się za takim sprzętem, bo to w odróżnieniu od oscyloskopu jest tanie. Najpopularniejszy to prosty Saleae za 30-40zł. To zwykłe, kilkubitowe wejście cyfrowe z zapamiętywainiem timestampów a cała analiza robiona jest w kompie. Naprawdę warto to mieć w swoim warsztacie. Pokazuje tylko jedynki i zera, ale przy łamaniu protokołów to wystarcza pd warunkiem, że wcześniej oscyloskopem upewniłeś się o intergralności sygnałów.

* Są oscyloskopy z analizą podstawowych protokołów komunikacyjnych i czasem do prostych prac to wystarcza, ale w tego typu sprawach lepiej używać czegoś z jeszcze większą pamięcią i możliwościami analizy zdarzeń.