Vor einiger Zeit hatte ich Software für ein 4 stelliges
7-Segmentanzeigemodul (China) gepostet der die Segmentanzeigen mittels
eines TM1637 ansteuert.
Für ein bestimmtes Projekt brauchte ich wieder 7-Segmentanzeigen, aber
auch Taster.
Ich wußte noch, dass der TM1637 eben auch Taster scannt, und hab mir
(dummerweise) TM1651 bestellt (weil der kleiner ist), aber dabei
übersehen, dass dieser nur 7 Segmente ansteuern kann (und somit ein
Ansteuern eines Dezimalpunktes nicht möglich ist).
Also wurde der Versuch mit TM1637 realisiert (nachdem einzelne Chips
dann endlich da waren) und ich hab mein altes Softwaremodul erweitert,
sodass dieses nun die Chips TM1637 UND TM1651 für die Anzeige UND das
Tastenauslesen angesprochen werden können.
TM1651:
------------------------------------
4 * 7 LEDs ansteuerbar (gemeinsame Anode)
7 Inputs lesbar
TM1637
------------------------------------
6 * 8 LEDs ansteuerbar (gemeinsame Anode)
16 Inputs lesbar
Desweiteren kann nun bestimmt werden, ob am TM1637 4 oder 6 Stück
7-Segmentanzeigen angeschlossen sind.
Wenn die nächste Chinabestellung da ist, wird dieses Softwaremodul hier
noch um den Chip TM1638 erweitert (kann 8 Stück 7-Segmentanzeige und 16
Tasten bedienen).
Beschreibung ebenfalls hier im Anhang
--
Ich habe mir die Freiheit genommen, den etwas kryptischen Titel
anzupassen
-rufus
Die Antwort ob es ein Schreibfehler ist beantworte ich jetzt mal mit
"nein", die Frage ob man das hätte anderst bezeichnen können, könnte man
mit " ja und nein" beantworten.
Die TMxx Bausteine SIND TWI (two wire interface),
aaaaaaaaaber:
Ein I2C Baustein ist auch ein TWI !!!
Atmel spricht bspw. bei seinen internen Funktionalitäten auch von einem
TWI (und ich glaube mich erinnern zu können, dass es schlicht deswegen
TWI - und nicht I2C - heißt, weil es Namensstreitigkeiten bezgl. des I2C
Buses hätte geben können).
Wenn du dir die Funktionen von tm16_read und tm16_write anschaust
(Bitbanging), dann wirst du dort sehen, dass das nichts weiteres als ein
serielles Ausschieben der Bits ist. Dieses allerdings mit LSB zuerst.
Alle meine I2C Bausteine schieben MSB zuerst aus, und ich weiß nicht aus
dem Handgelenk, ob das in den I2C Spezifikationen so sein muß.
Betrachtest du dir das Datenblatt der TM16xx Bausteine genauer, dann
wirst du feststellen, dass sie dieselbe Startkondition und dieselbe Stop
Kondition besitzen.
Desweiteren quittiert ein TM16xx Baustein ein Datentransfer zu ihm mit
einem Acknowledge genauso, wie es ein I2C Baustein auch macht.
Wenn man sich den "Spaß" macht, und einen TM16XX Baustein als einzigen
Chip an einen I2C Bus hängt, und für das Versenden und Lesen eines Bytes
die "normalen" Funktionen des Buses verwendet, bei der Ausgabe des
einzelnen Datums die Bits reversiert (d.h. Bit7 <=> Bit 0, Bit6 <=>
Bit1, Bit5 <=>Bit2, Bit4 <=> Bit3 tauscht), dann kannst du den TM16XX
auch mit regulären I2C - Funkionen ansprechen.
Das "ärgerlichste" an den TM16XX Chips ist, dass sie KEINE Busadresse
besitzen und man sie deshalb nicht an einen I2C Bus mit anderen
Bausteinen hängen kann weil der TM16XX immer antwortet.
Die Übertragungsfunktionen zum TM16XX sind also I2C Funktionen. Der
TM16XX hat aber kein I2C Busprotokoll (wie zuerst Deviceadresse mit r/w
Flag in Bit0).
Für mich entspricht deshalb der Transfer von / zum TM16XX einem I2C
Busdatentransfer.
Der geneigte Benutzer kann logischerweise diese Bezeichnung im Kommentar
gerne seinen einen Betrachtungsweise anpassen...
Vielleicht als "serieller Busdatentransfer"
Atmel führte aus lizenzrechtlichen Gründen die heute auch von einigen anderen Herstellern verwendete Bezeichnung TWI (Two-Wire-Interface) ein, technisch sind TWI und I²C identisch.
Allerdings steht dort auch:
1
Alle Bytes werden dabei „Most Significant Bit First“ übertragen.
Somit ist ein Frame für den TM16XX kompatibel zum I2C-Bus, aber nicht
wie oben beschrieben das Protokoll !
Danke für den Hinweis auf diese interessanten IC. Habe mir gleich mal je
10 vom Chinesen geordert. Die 1651er sind jetzt da und funktionieren auf
Anhieb mit deiner Software.
Freut mich, dass das gleich funktioniert hat. Ich habe soeeben einen
weiteren Chip von TM beackert von dem ich annahm dass er ähnlich wie die
beiden anderen funktioniert: Ich hätte ins Datenblatt sehen sollen.
Das ist der TM1638... und statt 2 oder 3 Stunden habe ich jetzt 2 Abende
daran verbracht (inklusive Doku). Leider willl youtube ein Video davon
nicht so hochladen wie ich das mag.... Und ohne Video will ich nicht.
Wird die Tage hochgeladen und vllt. findest du einen Spaß an dem
(Chinaboard) mit 8 Stck. 7-Segmentanzeigen und 16 Tasten...
Ralph S. schrieb:> ... TM1638>> Wird die Tage hochgeladen und vllt. findest du einen Spaß an dem> (Chinaboard) mit 8 Stck. 7-Segmentanzeigen und 16 Tasten...
So groß brauch ich eigentlich gar nicht.
Der TM1651 hat einen Bruder, der sogar noch interessanter ist. Der
TM1650 verwendet das gleiche Interface und kommt auch in DIP/SOP-16.
Kann aber 4 Stellen mit je 8 Segmenten ansteuern. Und bis zu 28 Tasten
abfragen. 10 Stück für ~ €1,- bei Ali.
Das Datenblatt gibt es nur chinesisch, aber hier:
https://os.mbed.com/components/TM1637-LED-controller-32-LEDs-max-Keyboa/
gibt es schon Code dafür.
... hab ich mir jetzt angeguckt und gleich mal bestellt. Wird sich wohl
integrieren lassen.
Code von mbed guck ich mir höchstens mal an, der Resourcenverbrauch ist
ähnlich hoch wie bei Arduino und ich mag an sich keine Onlinecompiler.
Für STM32 nutz ich libopencm3 und eigene Erweiterungen.
Aber Danke für den Tip mit TM1650.
Ralph S. schrieb:> ... hab ich mir jetzt angeguckt und gleich mal bestellt. Wird sich wohl> integrieren lassen.
Gern geschehen ;)
> Code von mbed guck ich mir höchstens mal an
Klar. Dito. Aber bevor ich Chinesisch lerne, um das Datenblatt zu lesen,
schau ich doch lieber in eine Handvoll Zeilen C Code.
Hallo und zuallererst vergebe ich für mein schlechtes Deutsch
Freund Ralph S. (jjflash) seine Lib. Ich war sehr hilfsbereit
Ich habe costruido ein Modul auf der Grundlage seines Beitrags.,
beigefügt das Schema verwendet
Ich habe mit vier KEY-Botons gebaut, weil ich MENU handhaben muss
funktioniert perfekt so, aber DELAYS erzeugt eine unerwünschte
Verzögerung beim USART-Empfang
Ich werde es überprüfen, wenn Sie eine Möglichkeit haben, eine TIMER1 zu
verwenden
speziell in der Funktion
#define puls_us 5
#define puls_len() _delay_us(puls_us)
Ich befestige den Link an ein Video, das ich von Ihrem Projekt gemacht
habe, damit sie sehen, dass es funktioniert
Platzieren Sie auch vier LEDs für süchtig machende Funktionen
Erweitern der Funktion auf sechs Ziffern, damit sie funktionieren
https://youtu.be/H00rQ2vM0gY
ATTE: juan
Hallo, danke, dass du mich gelesen hast, vergib mein schlechtes Deutsch
Ich habe das folgende Problem
Ich muss vier Ports des Mikrocontrollers freigeben
Sie machen nur einen Blink für die Funktion einer Flagge
If (Indflags & (1 << function_1))
{
Indflags & = ~ (1 << function_1);
PortD ^ = (1 << PD3); // Grüner LED-Zustand ändern
}
Sonst portD | = (1 << PD3); // Deaktivieren Sie LED, wenn sich nichts
geändert hat
If (blink & (1 << 0)) portD & = ~ (1 << PD4); // Rote LED aktivieren,
wenn das erste Bit eingestellt ist
Sonst portD | = (1 << PD4);
Blink = (blink >> 1); // SCHALTSCHEMA.
Wenn (blink == 1)
{
Blink = 0b10000000;
Die Funktionen des erweiterten TM1637 sind
// LED TM16_SETSEG (4.0); Blau
// LED TM16_SETSEG (4.1); Grün
// LED TM16_SETSEG (4.2); Gelb
// LED tm16_setseg (4,3); rot
In dem vorherigen Fall wird es verwendet (4.1) und (4.3)
Der andere Fall ist gleich dem vorherigen (PD5 und PD6) und (4,0) und
(4,2), die jeweils
tm1637_demo_kl.jpg
(180 KB)
tm1637_schematic.jpg
(160 KB)
tm1651_schematic.png
(21 KB)
