Siebensegment und Tasten ansteuern mit TM1651 \ TM1637

[Ralph S. (jjflash)]

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

[Karl M. (Gast)]

Hallo Ralph,

ich finde in deinem Quellcode:

"I2C Bus-Datentransfer" aber der Baustein macht laut Datenblatt:
 "Two - wire serial interface"

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

Ein Schreibfehler?

[Ralph S. (jjflash)]

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"

[Ralph S. (jjflash)]

so, jetzt hab ich mich schlau gemacht:

https://de.wikipedia.org/wiki/i2c

Zitat aus Wikipediaartikel:

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:

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 !

[Axel S. (a-za-z0-9)]

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.

[Ralph S. (jjflash)]

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...

[Axel S. (a-za-z0-9)]

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.

[Ralph S. (jjflash)]

... 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.

[Axel S. (a-za-z0-9)]

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.

[Juan A. (juan_a)]

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

[Juan carlos A. (Firma: juan_c) (juan_carlos_a)]

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