[TM1638] Chiński Moduł LED & Key z układem TM1638 | Nocne przygody Księżniczki Motoroli

Pozostałe układy mikrokontrolerów, układy peryferyjne i inne, nie mieszczące się w powyższych kategoriach.
Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

[TM1638] Chiński Moduł LED & Key z układem TM1638 | Nocne przygody Księżniczki Motoroli

Postautor: tasza » środa 18 kwie 2018, 23:16

#slowanawiatr

♬ ☘ Moja muzyka do kodowania ♬ ♬ ♬ ☘
♫ ♩ ♪ Collage ⚡ ☘ ⚡ Moonshine ♪ ♩ ♫
https://youtu.be/4huhmXEPujs


W ramach drobnych zmian w podejściu do grafomańskiej pisaniny postanowiłam oddzielić wątek o MB09 Monoboard od pobocznych tematów powstających ad-hoc, gdzie owa płytka pełni rolę platformy uruchomieniowej, a nie stanowi atrakcji sama w sobie. I tak oto pierwsza z `Nocnych przygód...` pisana na zasadzie – co by tu do tej Motorolki jeszcze podłączyć i zobaczyć jak działa. Oczywiście, jest to dalej (jak ktoś określił) sztuka dla sztuki, a dla mnie dodatkowo to nieustający trening klecenia w assemblerze procesora 6809 i kontynuacja rozpoczętej na jesieni przygody. To miłego czytania do poduszki.

Legginsy i Led-y

Wcześniejsze zakupy tak zwanych łachów na Aliexpress uważam za całkiem udane i potwierdzające matematyczną regułę że masa*jakość=const. Chińskie pstrokate legginsy na zajęciach pole-fit drę na potęgę, ale przy zamówionej sporej ilości problemu wielkiego z tym nie ma, no i zawsze mam nowe, w inny wzorek. A ostatnio, w ramach dalszego pogłębiania polsko–azjatyckich relacji handlowych i w trosce o zapewnienie koniunktury naszym rodzimym firmom kurierskim postanowiłam zakupić w Chinowie kilka elektronicznych klamotów.

Obrazek

Pierwszym z upatrzonych przydasiów jest moduł siedmiosegmentowych wyświetlaczy i przycisków opisywany w systemie (lang. PL) jako: "1 sztuk Klawisz Wyświetlacza Dla AVR Nowy Moduł 8-bitowy TM1638 8-bitowy Cyfrowy LED Tube" i nie ukrywam – już sam tytuł zrobił na mnie wrażenie. Cena za modułek również, ponieważ mój akurat egzemplarz kosztował deczko ponad pięć (słownie: 5) złotych.

Obrazek

Obrazek

A co on wart za tę niewielką kaskę – o tym dalej.

TM1638

Sercem płytki jest układ TM1638 firmy `Titan Micro Electronics` (no łał!) będący zintegrowanym sterownikiem wyświetlaczy siedmiosegmentowych wraz z funkcją obsługi klawiatury matrycowej.

Obrazek

To taki mały kombajn, z pomocą którego można w bardzo prosty sposób zrealizować podstawowy interfejs użytkownika, może atrakcyjnością nie wyrywający z majtek, ale całkiem funkcjonalny i co najważniejsze prosty do obsługi programowej. Dokumentacja firmowa w języku do złudzenia przypominającym angielski znajduje się na przykład tu:

:arrow: https://www.openimpulse.com/blog/wp-con ... tm1638.pdf

Dla wielbicieli kwaśnych jabłuszek polecam wersję w oryginale, wydruk pozostawiony na stoliku to gwarant szacunku na dzielnicy czy też innym biurowym open-space.

:arrow: http://www.titanmec.com/index.php/en/pr ... d/303.html

Tak ogólnie, to tych dokumentów jest w sieci kilka, na różnym poziomie estetyki, pomijając pocieszne konstrukcje językowe dokumencik zawiera wszelkie potrzebne sprawy merytoryczne i jest całkowicie wystarczający do napisania własnego oprogramowania, przerobiłam na sobie. Na marginesie, ja nie mogę oprzeć się wrażeniu, że koleżkowie mili, którzy popełnili kostkę TM1638 byli mocno zainspirowani układami firmy Maxim typu MAX6955, wyszła im równie sympatyczna konstrukcja. Otoczeniem kostki TM1638 jest garść guzików, ledów i dwa czteropozycyjne wyświetlacze, schemat zakupionej przeze mnie wersji jest luźną wariacją na temat typowej aplikacji układu i można go znaleźć na przykład na rysunku pod linkiem:

:arrow: https://www.openimpulse.com/blog/wp-con ... ematic.jpg

Ktoś się zapewne jednak napracował aby stworzyć ten schemat, więc już bez zbędnej szydery pozwolę sobie zaprezentować swoją autorską wersję narysowaną wczoraj w Kicad:

Obrazek

Na rysunku mym pojawiają się także drobiazgi w postaci sygnalizacji zasilania oraz tabelka-help z adresami diodek oraz cyfr wyświetlacza.

Bit za bitem

Od strony programowej sprawa nie jest jakoś arcyskomplikowana, to klasyczne SPI aktywowane niskim poziomem sygnału /STB, dane są odbierane przez układ wraz z narastającym zboczem sygnału CLK. Sztuka cała to wysłanie odpowiednich komend do układu, wszelkie detale w data sheet. Do świeżo wyjętego z koperty modułu podeszłam z pewną nieufnością i aby w ogóle sprawdzić czy on działa zapięłam płytkę do Arduino z wgranym przykładem z sieci.

Obrazek
Obrazek
Obrazek

:arrow: http://bienata.waw.pl/microgeek/TM1638/TM1638.ino

Przepraszam, ale nie pamiętam już skąd dokładnie ten plik pobrałam, zatem wrzucam swoją kopię. W sieci pełno jest takich demek, można sobie wybierać.

https://youtu.be/A3Tx8tcWf78

Modułek z Ardu na żywo całkiem ładnie mi zadziałał, nadesłana płytka okazała się w pełni sprawna, można zatem klecić swoje własne oprogramowanie sterujące.

Nauka chińskiego

Obrazek

Z lektury (ale jazda była) dokumentacji wyszło mi na to, że potrzebne będą procedurki zamykające podstawowe zagadnienia komunikacji z wyświetlaczem (póki co odczyt guzików pomijam, będzie potrzebne to się kiedyś dorobi). Są to kolejno: wysłanie ośmiu bitów danych w takt narastających zboczy generowanego sygnału CLK, wysłanie komendy sterującej, zapis do pamięci wyświetlacza pod zadany adres i wtenczas mamy kod jak niżej.

:arrow: https://github.com/bienata/monoboard9/b ... 1638-1.asm

Procedurka tm1638_postbyte wysyła paczkę bitow przy niemym założeniu, że procedura ją wołająca ustawiła już /STB w stan L, czyli aktywowała transfer SPI, takoż ona zakończy transfer po zwróceniu sterowania przez tm1638_postbyte

tm1638-1.asm pisze:

Kod: Zaznacz cały

      ; A - byte to send in raw form      
tm1638_postbyte:
      pshu a,b,x
      ldx      #8
      sta      temp   ; save input
.loop:
      ; dt=0; ck=0, stb - bez zmian
      anda   #%0000.0001
      beq      .skipZero
      ;set data pin H
      ldb      #DAT_TM1638
      stb      PORT_TM1638
.skipZero:
      ; ck pulse
      ; __/--
      ldb      #CLK_TM1638
      orb      PORT_TM1638
      stb      PORT_TM1638
      ; --\__
      ldb      #0
      stb      PORT_TM1638
      lda temp      ; restore for a moment
      lsra         ; >> next incoming bit
      sta temp      ; save back
      dex            ; next byte
      bne      .loop
      pulu   a,b,x      
      rts


Procedurka tm1638_command to podstawa do wydawania poleceń kostce, włączania/wyłączania wyświetlacza, zmiany jasności (wypełnienie PWM) i trybu pracy zapis/odczyt. W tejże procedurze mamy rozpoczęcie i zakończenie jednobajtowego transferu SPI.

tm1638-1.asm pisze:

Kod: Zaznacz cały

      ; A - command to execute
tm1638_command:
      pshu a,b
      ldb #0   ; strobe=0, dt=0, ck=0
      stb PORT_TM1638
      jsr tm1638_postbyte
      ldb #STB_TM1638      ; strobe=1, dt=0, ck=0
      stb PORT_TM1638
      pulu a,b
      rts



Procedurka tm1638_writeat to odrobinę bardziej skomplikowany potworek, rozpoczyna transfer SPI, poczym do kostki tm1638 wysyła wyliczony z danej wejściowej adres w pamięci wyświetlacza, następnie wysyła daną, którą kostka zapisze sobie pod wskazany adres. Specyfika aplikacji układu definiuje adresy pól odczytowych kolejno: 0xC0, 0xC2,.. 0xCE czyli co 2, parzyste. Dla garstki diodek LED luzem, zapiętych jako segmenty numer 9 kolejnych pól odczytowych adresy będą wynosiły odpowiednio 0xC1, 0xC3,…0xCF i takimi właśnie wartościami operuje bliźniacza procedurka tm1638_led. Po szczegóły odnośnie adresacji odsyłam do tabelki chart(2) na stronie 3 wskazanego datasheet, a poniżej procedurki do pisania po wyświetlaczu oraz zapalania wybranego LED-a. Pozycje cyfry/diodki określa wartość 0..7 podawana via rejestr B, kod siedmiosegmentowy budowany w sposób tradycyjny (bit 0 – segment a, bit 1 – b i tak dalej) podajemy jako parametr do rejestru A.

tm1638-1.asm pisze:

Kod: Zaznacz cały

      ; A - 7-seg code to set
      ; B - display position (left 0..7 right)
tm1638_writeat:
      pshu a,b,x
      tfr d,x      ; save a,b in x
      lslb         ; << 1
      addb   #$C0   ; digits
      lda #0   ; strobe=0, dt=0, ck=0
      sta PORT_TM1638
      tfr b,a         ; put add. in B and send
      jsr tm1638_postbyte
      tfr x,d         ; restore input
      jsr tm1638_postbyte
      ldb #STB_TM1638      ; strobe=1, dt=0, ck=0
      stb PORT_TM1638
      pulu a,b,x
      rts


tm1638-1.asm pisze:

Kod: Zaznacz cały

      ; A - 1/0 to set
      ; B - LED position (left 0..7 right)
tm1638_led:
      pshu a,b,x
      tfr d,x      ; save a,b in x
      lslb         ; << 1
      addb   #$C1   ; free leds
      lda #0   ; strobe=0, dt=0, ck=0
      sta PORT_TM1638
      tfr b,a         ; put add. in B and send
      jsr tm1638_postbyte
      tfr x,d         ; restore input
      jsr tm1638_postbyte
      ldb #STB_TM1638      ; strobe=1, dt=0, ck=0
      stb PORT_TM1638
      pulu a,b,x
      rts


Zerknijmy jeszcze na przebiegi czasowe złapane przy pomocy Analog Discovery 2 – widać wysłanie pojedynczej komendy (brightness) jak i dwubajtowy transfer polecenie+dana, to działanie writeat.

Obrazek
Obrazek
Obrazek

Cukierek też potrafi pokazać zdekodowane na żywca SPI, o proszę:

Obrazek

Nie zmienia to faktu, że poustawianie wszystkiego tymi jego gałeczkami może doprowadzić do rozstroju nerwowego, stanowoczo muszę to oskryptować w wolnej chwili.

Działanie przykładowej aplikacji pokazuje filmik:

https://youtu.be/gpRgG1qZ5JE

a jej pętlę główną fragment poniżej – dwa komplety cyferek na zmianę i biegający led plus zmiana jasności:

tm1638-1.asm pisze:

Kod: Zaznacz cały

.here:

      ldb #0
      ldx   #digits
.loop
      lda ,x+
      jsr tm1638_writeat
      incb
      cmpb #8
      bne .loop

      ldb #0
.loop1
      lda #1
      jsr tm1638_led
      jsr delay
      incb
      cmpb #8
      bne .loop1


      ldb #7
.bright
      tfr b,a
      adda #$88
      jsr tm1638_command
      jsr delay
      decb
      bne .bright

      ldb #0
.bright1
      tfr b,a
      adda #$88
      jsr tm1638_command
      jsr delay
      incb
      cmpb #8
      bne .bright1



      ldb #0
      ldx   #digits+8
.loop3
      lda ,x+
      jsr tm1638_writeat
      incb
      cmpb #8
      bne .loop3


      ldb #0
.loop2
      lda #0
      jsr tm1638_led
      jsr delay
      incb
      cmpb #8
      bne .loop2


      jmp .here

digits:   .db DIG_0,DIG_1,DIG_2,DIG_3
      .db DIG_4,DIG_5,DIG_6,DIG_7
      .db DIG_8,DIG_9,DIG_A,DIG_B
      .db DIG_C,DIG_D,DIG_E,DIG_F



Kolejny film daje pojęcie o zmianach w poborze prądu przy różnych poziomach jasności wyświetlacza, widać zmiany w zakresie od praktycznie zera do 160mA.

Obrazek

https://youtu.be/XGOrtF-PhPU

Tu powstaje pytanie - dlaczego na filmiku występuje UM-4B a nie V640 lub UM-111? I dlaczego 160mA powyżej jest pogrubione? Przypadek? Nie sądzę...

Fragment kodu tak ładnie machający wskazówką amperomierza:

Kod: Zaznacz cały

.forever:
      ldx #bright
.fade
      lda   ,x+
      jsr tm1638_command
      jsr delay
      cmpx #brightEnd
      bne .fade
      jmp .forever

bright:   .db $80
      .db $88+0
      .db $88+1
      .db $88+2
      .db $88+3
      .db $88+4
      .db $88+5
      .db $88+6
      .db $88+7
      .db $88+6
      .db $88+5
      .db $88+4
      .db $88+3
      .db $88+2
      .db $88+1
      .db $88+0
      .db $80
brightEnd:



Stos

Stos to świetna sprawa, aczkolwiek żywię uzasadnione obawy, że moje poprzedniczki sprzed kilkuset lat raczej nie podzielałyby tej opinii. Niemniej jednak w ochronie czy chwilowym przechowywaniu zmiennych podczas pracy programu stos jest narzędziem wręcz niezastąpionym. Równie łatwo może stać się narzędziem destrukcji generującym naprawdę trudne do identyfikacji anomalie w działaniu aplikacji, proszę zerknąć na filmik:

https://youtu.be/uyWvtKZlgKA

Programik testowy (wczesna, mocno rozwojowa wersja gdy walczyłam z kolejnymi procedurkami) jak widać działa sobie całkiem ładnie, ale tylko przez chwilę. Potem dzieje się coś dziwnego z wyświetlaczem, wizualnie zachowanie nie jest deterministyczne i prowadzi do tak zwanej zwiechy. Podejrzenia miałam różne – a może coś chińskie kabelki nie stykają? a może to domowa płytka-przelotka przy Motorolce nie kontaktuje? Toć tam fura drucików lutowanych przecież. No bo przecież niemożliwe jest abym to ja gdzieś dała ciała w programie! A tu proszę, sucharek ukryty siedział w procedurce tm1638_postbyte, czyli tej wywoływanej przy każdej atomowej operacji na wyświetlaczu. Polegał na niezbilansowanym stosie, inna ilość danych chomikowana rozkazem pshu a inna zdejmowana przez pulu, jakby klasyczny memory leak. Późniejszy eksperyment z wyświetlaniem wierzchołka stosu na terminalu wykazał, że owy systematycznie przesuwał się w kierunku dolnych adresów aż zawinąwszy się przez 0 wjechał w obszar ROM (wysokie adresu, od 0xE000) . Ponieważ Księżniczka Motorola ma na bogato 58kB pamięci RAM to taki rajd po kolejnych bankach pamięci trwał dłuższą chwilę, stąd złudne i mylne wrażenie, że aplikacja pada na wskutek czynników fizycznych.

Kod: Zaznacz cały

F000-                 29      tm1638_postbyte:
F000-                 30                      ; b - byte 2 send
F000-8E 00 08         31 ( 3)                 ldx             #8
F003-                 32      .pb:
F003-                 33                      ; dt=0; ck=0, stb - bez zmian
F003-36 04            34 ( 6)                 pshu    b               ; save on stack
F005-C4 01            35 ( 2)                 andb    #%0000.0001
F007-27 05            36 ( 3)                 beq             .skipIfZero
F009-                 37                      ;set data pin H
F009-86 01            38 ( 2)                 lda             #DAT_TM1638
F00B-B7 E0 01         39 ( 5)                 sta             VIA1+ORA
F00E-                 40      .skipIfZero:
F00E-                 41                      ; ck pulse
F00E-                 42                      ; __/--
F00E-86 02            43 ( 2)                 lda             #CLK_TM1638
F010-BA E0 01         44 ( 5)                 ora             VIA1+ORA
F013-B7 E0 01         45 ( 5)                 sta             VIA1+ORA
F016-                 46                      ; --\__
F016-86 00            47 ( 2)                 lda             #0
F018-B7 E0 01         48 ( 5)                 sta             VIA1+ORA
F01B-                 49
F01B-37 04            50 ( 6)                 pulu    b               ; restore for a moment
F01D-54               51 ( 2)                 lsrb                    ; >> next incoming bit
F01E-36 04            52 ( 6)                 pshu    b               ; save back
F020-                 53
F020-30 1F            54 ( 5)                 dex
F022-26 DF            55 ( 3)                 bne             .pb
F024-                 56
F024-37 04            57 ( 6)                 pulu    b               ; just for stack balance
F026-39               58 ( 5)                 rts


Jak to mawiamy
Obrazek
program coraz bardziej
Obrazek
nie działa.
Obrazek

Okiem konsumentki

Jakieś wielkie rozwodzenie się nad tym czy warto to kupować czy nie jest chyba niecelowe. Jak ktoś może poczekać te trzy tygodnie to jak za piątak taki modułek jest całkiem fajnym urozmaiceniem zabaw z Ardu czy innymi platformami uC. Lokalnie też można nabyć tego typu płytki, cena jest jednak w okolicy kilkunastu złotych, za to dostępne są praktycznie od ręki, kwestia wyboru. Zwracam uwagę, że istnieje też wariant z większą klawiaturką oraz taki ze złączkami IDC10, do wyboru do koloru. Odnośnie jakości wykonania, narzekać raczej nie mogę.

Obrazek
Obrazek

No fakt, te wyświetlacze jakoś deczko krzywo ktoś wlutował, minimalnie ale jednak pod linijką widać.

Obrazek

Złączka do SPI też mogłaby być albo kątowa albo wrzucona jako luzem grzebyk 5-pin do samodzielnego wlutowania. W takiej konfiguracji nie da się modułku wmontować na front urządzenia, będzie problem właśnie o wysokość igiełek i skuwek z kabelkami, zostaje wtenczas albo wyciąć to zupełnie, albo przylutować się bezpośrednio do wyprowadzeń.

Obrazek
Obrazek

Płytka ma otworki montażowe M3, da się dorobić nóżki ze śrubek czy słupków dystansowych, moduł jest mały gabarytowo i całość nie wygina się przy naciskaniu guzików. Odnośnie dokumentacji modułku już pisałam, jest momentami przezabawna ale summa summarum na jej podstawie idzie tę płytkę w miarę szybko oswoić, czego wszystkim na koniec życzę.

Ukryta zawartość
To forum wymaga zarejestrowania i zalogowania się, aby zobaczyć ukrytą zawartość.
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [TM1638] Chiński Moduł LED & Key z układem TM1638 | Nocne przygody Księżniczki Motoroli

Postautor: gaweł » czwartek 19 kwie 2018, 15:07

tasza pisze:Dla wielbicieli kwaśnych jabłuszek polecam wersję w oryginale, wydruk pozostawiony na stoliku to gwarant szacunku na dzielnicy czy też innym biurowym open-space.

:arrow: http://www.titanmec.com/index.php/en/pr ... d/303.html

No właśnie, hard core.
page1.PNG
Ale jak jak się zaprzeć, to wszystkie problemy da się pokonać
page2.PNG
Język, jak język. Cokolwiek zostanie napisane, powiedziane, sens można odczytać właściwie.
Nie masz wymaganych uprawnień, aby zobaczyć pliki załączone do tego posta.

Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse

Awatar użytkownika
tasza
Geek
Geek
Posty: 1082
Rejestracja: czwartek 12 sty 2017, 10:24
Kontaktowanie:

Re: [TM1638] Chiński Moduł LED & Key z układem TM1638 | Nocne przygody Księżniczki Motoroli

Postautor: tasza » wtorek 24 kwie 2018, 22:58

#slowanawiatr

♬ ☘ Moja muzyka do kodowania ♬ ♬ ♬ ☘
♫ ♩ ♪ Collage ⚡ ☘ ⚡ Baśnie ♪ ♩ ♫
https://youtu.be/uQQbij47LPE


Złe oblicza dobrej zmiany

Może zacytuje sama siebie:
tasza pisze:Tu powstaje pytanie - dlaczego na filmiku występuje UM-4B a nie V640 lub UM-111? I dlaczego 160mA powyżej jest pogrubione? Przypadek? Nie sądzę...


Jakoś nie doczekałam się podjęcia tematu, no trudno, a wyjaśnienie takie:
to pomiar przy pomocy UM-4B zapewni w tym przypadku najmniejszy błąd bezwzględny i względny. Najpierw tabelka oraz garść liczb:

Kod: Zaznacz cały

przyrząd   klasa      zakres    błąd bezwzględny   błąd względny
----------------------------------------------------------------
                      1.5A      ±22.5mA            ~14%
V640       1.5
                      0.15A     ±2.25mA            przekroczenie
----------------------------------------------------------------
                      1A        ±15mA              ~9%
UM-4B      1.5
                      0.3A      ±4.5mA             ~3% (♥)
----------------------------------------------------------------
                      1A        ±15mA              ~9%
UM-111     1.5
                      0.1A      ±1.5mA             przekroczenie
----------------------------------------------------------------


Widać od razu, że dla prądu rzędu 160mA najlepsze wyniki uzyskamy na zakresie 0.3A miernika UM-4B. Mamy trzy urządzenia tej samej klasy, ale z zakresami różnie pokrywającymi interesujący nas obszar. W przypadku V640 i UM-111 albo przekraczamy zakres albo pracujemy na małych wartościach wychylenia wskazówki. W tym przypadku tylko UM-4B da się ustawić tak, aby odczyt był w połowie (i więcej) skali, co jest zalecane ponieważ minimalizuje błąd względny, który jak wiemy zależy od wartości mierzonej.
Tu fajnie napisane jak kto ciekaw: :arrow: http://www.kmet.agh.edu.pl/wp-content/u ... teoria.pdf
I drugie co widać, to że nie zawsze dobiera się zakres do pomiaru, czasem trzeba zmienić także przyrząd na bardziej dopasowany do danej sytuacji, na przykład o innym podziale na zakresy.
No i w sumie tyle odnośnie zagadki. Ja wiem, że w dobie wszechobecnej cyfryzacji przyrządów wybór zakresów pomiarowych to są jakieś niedzisiejsze gusła, ale czasem warto sobie potrenować, choćby na kartce, a nuż się przyda kiedyś.

Odczyt klawiatury z TM1638

Aby już definitywnie zakończyć temat tego modułku - parę zdań o obsłudze klawiatury.
Matryca klawiszy zapięta jest do portu wyświetlacza - pierwszy wymiar matrycy, szyny zbiorcze K1..K3 to drugi wymiar. Można wykorzystać pełne 24 bity (3x8) albo tylko wybrane, to już zależy od wymagań dla naszej aplikacji.
W opisywanym tu module jest tylko osiem przycisków, do prostych manipulacji z powodzeniem to wystarcza. Skanowaniem klawiaturki układ zajmuje się samodzielnie, czy tego chcemy czy nie zawsze przemiata linie matrycy klawiatury zbierając dane w komórkach własnej pamięci. Tylko od użytkownika zależy, kiedy odczyta zawartość tej pamięci, ale należy mieć na uwadze, że dane te odzwierciedlają bieżący (chwilowy) stan przycisków, zbyt rzadko odpytując układzik o klawisze mamy spore szanse przegapić aktywność klawiatury.

Odczyt danych klawiatury zgodnie z firmową dokumentacją:

Obrazek
Obrazek

I widać, że sprawa wcale nie jest skomplikowana, po wysłaniu komendy 0x42 należy zebrać 32 bity danych nadsyłane przez TM1638 i poukładać w czterobajtowy bufor, na koniec zamknąć transakcję SPI.

Jedyna upierdliwość jaka może nas spotkać, to konieczność zmiany trybu pracy portu niejako w locie i to precyzyjnie - dla jednego bitu I/O. O ile współczesne kontrolery nie mają z tym większego problemu, to taka sztuczka w przypadku niektórych układów peryferyjnych np. 8255 nie jest taka prosta. Szczęściem, układ VIA (6522) który eksploatuje Księżniczka Motorola ma podobne jak w AVR i reszcie rejestry DDR (Data Direction Register) konfigurujące I/O per bit, to mega ułatwienie i nie wymaga dodatkowych sprzętowych sztuczek.

Obsługa klawiaturki z programowego punktu widzenia to dwie podstawowe procedurki - tm1638_getrawkey ogarniająca kompleksowo transakcję SPI i zbierającą dane z klawiaturki do bufora oraz taką pomocniczą tm1638_getbyte zapewniającą synchroniczny odczyt ośmiu bitów z kostki.

tm1638-3.asm pisze:

Kod: Zaznacz cały

      ; X - 4-bytes buff for kbd data   
tm1638_getrawkey:
      pshu a,b,x
      lda #0   ; strobe=0, dt=0, ck=0
      sta PORT_TM1638
      lda #$42         ; read data command
      jsr tm1638_postbyte
      ; data pin as input
      lda VIA2+DDRB
      ; clear bit, DATA as IN
      anda #$FE
      sta   VIA2+DDRB      
      ldb #4
.continue
      jsr tm1638_getbyte
      sta   ,x+
      decb
      bne .continue
      lda #$ff      
      sta   VIA2+DDRB      ; all out as before
      ldb #STB_TM1638      ; strobe=1, dt=0, ck=0
      stb PORT_TM1638
      pulu a,b,x
      rts


tm1638-3.asm pisze:

Kod: Zaznacz cały

      ; returns scanned bits in A
tm1638_getbyte:
      pshu x,y,d
      lda #0
      sta temp
      ldx      #8
.loop:   ; get data bit
      lda   VIA2+IRB
      ; ck pulse
      ; __/--
      ldb      #CLK_TM1638
      orb      PORT_TM1638
      stb      PORT_TM1638
      ; --\__
      ldb      #0
      stb      PORT_TM1638
      ; process bit
      anda #$01
      ora   temp
      rora
      sta temp      
      dex            ; next bit
      bne      .loop
      pulu x,y,d
      lda   temp
      rora
      rts


Smuteczek drobny polega tylko na tym, że dane w czterobajtowym buforze są jak gdyby rozproszone i poskładanie stanu ośmiu przycisków z jeden wynikowy bajt wymaga odrobiny gimnastyki.

Dla opisywanego modułku stan przycisków odzwierciedlany jest w buforze w następujący sposób:

Kod: Zaznacz cały

        kbdBuff
key.    +0   +1   +2   +3
-----------------------
S1      01   00   00   00
S2      00   01   00   00
S3      00   00   01   00
S4      00   00   00   01
-----------------------
S5      10   00   00   00
S6      00   10   00   00
S7      00   00   10   00
S8      00   00   00   10
-----------------------


Aby ułatwić sobie wykrywanie co zostało naciśnięte dopisałam małą procedurkę tm1638_getkey, która na podstawie tych zerojedynkowych płotków i przy pomocy operacji przesunięć bitowych układa bity klawiszy w jeden bajt, oto ona:

tm1638-3.asm pisze:

Kod: Zaznacz cały

      ; X - raw kb data, destroyed!
      ; A - converted key code
tm1638_getkey:
      ; +1   << 1
      lda   1,x
      rola
      sta   1,x
      ; +2  <<  2
      lda   2,x
      rola
      rola
      sta   2,x
      ; +3  <<  3
      lda   3,x
      rola
      rola
      rola
      sta   3,x
      ; put all together
      lda #0
      ora   0,x
      ora   1,x
      ora   2,x
      ora   3,x
      rts


Zwracane wartości niekoniecznie oddają kolejność przycisków S1..S8, ale są unikalne i co ważne - rozpoznawane jest symultaniczne wciśnięcie kilku z nich, to się czasem przydaję (np. klawisze shift/ctrl/alt)

Cały programik tutaj :arrow: https://github.com/bienata/monoboard9/b ... 1638-3.asm

A poniżej zawartość bufora klawiatury oraz zdekodowanego przycisku dla dwóch przykładowych guzików:

Obrazek
Obrazek

Bardziej na żywo wygląda to tak:

https://youtu.be/3zAk0ispPC8

Na koniec kilka spostrzeżeń natury praktycznej, pierwsza sprawa to gdzie umieścić obsługę klawiatury. W przykładowym, prostackim programiku tm1638-3.asm zrobiłam to w pętli głównej aplikacji, ale to tylko demo. Takie rozwiązanie jest dość ryzykowne, ponieważ zależnie od aktualnie wykonywanych przez program czynności mamy jednak spore szanse przespać naciśnięcie jakiegoś klawisza. Drugie rozwiązanie, w światku mikroprocesorowym wręcz naturalne - odpytywanie klawiatury w przerwaniach. Oczywiście kłopocik taki mamy, że kostka TM1638 nie potrafi zgłosić żądania przerwania, trzeba zatem odpytywać ją cyklicznie (polling) i analizować w locie stan bufora klawiatury. Jest to do zrobienia, ale trzeba mieć na uwadze czasowy koszt procedurek do komunikacji z kostką. Ze zrzutek ekranu powyżej łatwo rozpoznać, że transakcja SPI trwa jakieś 2.3ms przy zegarze Motki 1MHz. Kolejna sprawa, która spotka nas przy odpytywaniu TM1638 w przerwaniach to konieczność zapewnienia wyłączności dostępu do układu, tak aby jedna transakcja (np. z pętli głównej obsługującej wyświetlacz) nie została przerwana tą skanującą klawiszki, choćby z uwagi, że tam zmienia się kierunek I/O dla linii DIO. Jak widać główkowania nieco będzie, ale chyba z tych twórczych. Niestety siermiężność sprzętu trzeba będzie nadrobić sprytem w kodzie. Takie życie - tanio, dobrze, szybko – wybierz dwa.
______________________________________________ ____ ___ __ _ _ _ _
Kończysz tworzyć dopiero, gdy umierasz. (Marina Abramović)

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [TM1638] Chiński Moduł LED & Key z układem TM1638 | Nocne przygody Księżniczki Motoroli

Postautor: gaweł » wtorek 24 kwie 2018, 23:15

tasza pisze:Jak widać główkowania nieco będzie, ale chyba z tych twórczych. Niestety siermiężność sprzętu trzeba będzie nadrobić sprytem w kodzie. Takie życie - tanio, dobrze, szybko – wybierz dwa.

Jak zawsze, główkowanie ma przyszłość. Wszystko da się poczarować z klawiatury w asemblerze, wiedźmy są sprytne i znajdą drogę do celu.

Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse

Awatar użytkownika
gaweł
Geek
Geek
Posty: 1259
Rejestracja: wtorek 24 sty 2017, 22:05
Lokalizacja: Białystok

Re: [TM1638] Chiński Moduł LED & Key z układem TM1638 | Nocne przygody Księżniczki Motoroli

Postautor: gaweł » czwartek 26 kwie 2018, 23:58

Jak widać, nawet chińskiego można się naumieć :D , odrobina chęci i nie nie ma problemów, których nie da się pokonać. Znikają bariery nawet językowe.
tasza pisze:Jakoś nie doczekałam się podjęcia tematu, no trudno, a wyjaśnienie takie:

Troszkę ostatnio byłem zajęty (nawet więcej niż troszkę), ale ważne działania zawsze mam na uwadze.
Tak po prawdzie to niektóre działania czasami są poza zasięgiem. Przykładowo ja nie miałem możliwości zabadania czegoś takiego, bo nie mam takiego sprzętu. To istotna przeszkoda, jednak w sytuacji, gdy będzie dostęp do takich sprzętów, to z pewnością będzie to ciekawy eksperyment.
Wracając do górniczo-hutniczych rozważań, to ... jak zwykle jest kwestią punktu widzenia. Cytując dokument: "Wartość rzeczywista jest pojęciem abstrakcyjnym i nie jest znana eksperymentatorowi (gdyby była znana to pomiar byłby niepotrzebny)." Tu mi w głowie pojawiło się: zasada Heisenberga (a to jest czystą fizyką kwantową). Dalej, cyt.: "a więc każdy wynik pomiaru obarczony jest niepewnością,...". Tu można dyskutować i roztaczać różne koncepcje filozoficzne, historia zna tego całe mnóstwo. Przykładowo w starożytności nie istniał taki problem, zapewne wynikało to z precyzji pomiaru. Bo cóż to jest pomiar. Pomiar to porównanie z wzorcem. Im lepszy wzorzec, tym lepszy pomiar. Z resztą jest dalej to opisane, cyt.: "niedokładności wzorcowania". A, cyt.: "Niedoskonałość  zmysłów obserwatora" jest wręcz sednem sprawy.
Dalsze rozważania ogniskują się wokół statystyki i oceny niepewności. W moim przekonaniu statystyka, to takie oszustwo. Za pomocą statystyki można wszystko udowodnić, a konkretny wynik zależy jedynie od zleceniodawcy. Jeżeli statystyka jest jaka jest, to jaki sens ma ocenianie?

Tak myślę.

Prawdziwe słowa nie są przyjemne. Przyjemne słowa nie są prawdziwe.
Lao Tse


Wróć do „Inne mikroklocki, również peryferyjne”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 3 gości