Added support for TM1638 Seven-Segment Display

[ajithvasudevan]

Description:

This is an update of the TM1637 driver, which adds support for the TM1638 seven-segment display (+ onboard buttons +LEDs) module.
The update for the TM1638 includes all the "Display" commands of the TM1637, and additionally, has the ability to set the onboard LEDs and react to button presses.

This PR also adds a new Settings.display_type parameter, used here to switch between different display variants supported by the same (TM1637) driver. It now uses the new Settings.display_options to switch between display variants.

The DisplayType command now manipulates the Settings.display_options.data value.

Thus the TM1637 4-digit is DisplayType 0, TM1637 6-digit is DisplayType 1 and TM1638 is DisplayType 2. A future addition could be DisplayType 3 for the MAX7219.

Related issue (if applicable):
#10889

Checklist:

• The pull request is done against the latest development branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works on Tasmota core ESP8266 V.2.7.4.9
• The code change is tested and works on Tasmota core ESP32 V.1.0.5-rc6
• I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[ajithvasudevan]

@arendst,

Presently, the code is written such that proper initialization and working of the TM1637/8 driver depends on the existence of USE_SPI.

However, SPI is not really required for this driver to work, as the TM1637/8 driver now uses dedicated Pins TM1637 CLK and TM1637 DIO

Unnecessarily enabling SPI is causing the SPI pins to be assigned to 3 other GPIOs in Tasmota Configuration page, and it cannot be unset.

To this end, I have made the changes in 75699fe so that the dependency of TM1637/8 on SPI is removed.

[swampdogmash]

Hi, Thanks for adding the support for TM1638 as a display - I wonder what options you consider there are for adding back the support for the button and the LEDs? It seems like a pretty useful little board for doing control with. It's sort of mostly a redundant piece of hardware if it's connected to something running Tasmota without the buttons and LEDs. I'd love to offer my help, but I can't code to save my life... hence using Tasmota! Happy to provide additional testing / boards / etc etc though.

I saw that some time back there was some support for the buttons (I think) https://github.com/arendst/Tasmota/issues/3487 - is there a way to implement it going forward?

[mkohns]

Hi! I am also wondering how the buttons and leds could be included. Are there any concerns around this feature.

[ajithvasudevan]

I think it was an issue of separation of concerns in the driver implementation. A driver could either be an output driver (display, in this case), or an input driver (one that reads from buttons or sensors). Not both together.

…

On Sat, 4 Feb 2023, 13:49 mkohns, ***@***.***> wrote: Hi! I am also wondering how the buttons and leds could be included. Are there any concerns around this feature. — Reply to this email directly, view it on GitHub <#11031 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBUVQLCPYCTLPPFDCHNBUTWVYGHZANCNFSM4X2XAP4A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[barbudor]

While it is best to have indépendant drivers for indépendant component that can be re-usedin a different context, it happens that sometime a driver has to be done for a specific board and not for si gle components when they are tight together

How are the buttons connected?
To the esp? To an MCU?

[mkohns]

The buttons are part of the TM1638

https://www.segor.de/dokumente/tm1638.pdf

quote: TM1638 is LED driver controller with key-scan interface, MCU digital interface, data latch, LED
high pressure driver, key-scan is integrated into a single chip.

I am using the library TM1638plus in my projects.
The buttons are read by the functions readButtons()
So my answer to your question would be: The buttons are not connected directly to the GPIOs of the ESP.
Rather the chipset TM1638 is connected via SPI and retrieves the buttons over this interface.

From my point of view this is an edge case.
I understand the SoC principal - but here the controller has input and output.
Separating them would not make sense as they always come together.
On top - separation would make the code complicated - as both use the same SPI interface.

[mkohns]

Another question: I am not yet familiar with the new esp32 berry script. Just reading the docs - I have the feeling that reading the buttons could be possible with berry. What is your feeling about this?

[barbudor]

The good thing is that Tasmota driver is also based on TM1638plus
I'm looking at it

[barbudor]

There is already support for the buttons as Switches in the driver
Aren't this doing anything ?
I'm trying to understand how it's working...

[barbudor]

@mkohns
I discussed with Theo and what is done currently in the driver needs to be changed.
I'm working on it but I need to order a TM1638 to test properly

[arendst]

Try latest dev release. It introduces the keys as switches and the leds as relays. All switchmodes do apply.

Optionally compile options can change switch support to button support allowing use of button features.

#define USE_TM1638 // Add support for TM1638 switches copying Switch1 .. Switch8 (+1k code)
// #define TM1638_USE_AS_BUTTON // Add support for buttons
#define TM1638_USE_AS_SWITCH // Add support for switches (default)
#define TM1638_MAX_DISPLAYS 8 // Add support for power control 8 displays
#define TM1638_MAX_KEYS 8 // Add support for 8 keys
#define TM1638_MAX_LEDS 8 // Add support for 8 leds

[mkohns]

HI @arendst,

i compiled the current dev branch and tested the TM1638.
This all looks very good. I got a bar of 8 Web Buttons + States on top.
Pressing the hardware buttons -> turns the hardware led (relay) on + correct log in console.
Pressing the Web buttons -> turns the hardware led (relay) on + correct log in console.
Look great.

I am using a board tasmota32s2.
I now tried to get DISPLAY + your code running. To see if both is working.
I have no glue how to do this.
This only enables DISPLAY (which works)

[env:tasmota32s2-display]
extends                 = env:tasmota32_base
board                   = esp32s2
build_flags             = ${env:tasmota32_base.build_flags} -DFIRMWARE_DISPLAYS
lib_extra_dirs          = lib/libesp32, lib/lib_basic, lib/lib_display, lib/lib_ssl
lib_ignore              =
                          TTGO TWatch Library
                          NimBLE-Arduino
                          Micro-RTSP
                          epdiy

But your code seems to be in -DFIRMWARE_TASMOTA32
Apparently I can not mix them.

Can you give me a hint?

[mkohns]

I reverted this new tasmota32s2-display from above and
just added #define FIRMWARE_DISPLAYS in tasmota/my_user_config.h

By this both is now working. Looks like this

Where "9" is now the display.

[barbudor]

That's a hack, not officially supported 🙄

The proper way is to compile tasmota32s2 with all the needed defines in user_config_override.h

#define USE_DISPLAY
#define USE_DISPLAY_TM1637

#define USE_TM1638 // Add support for TM1638 switches copying Switch1 .. Switch8 (+1k code)
// #define TM1638_USE_AS_BUTTON // Add support for buttons
#define TM1638_USE_AS_SWITCH // Add support for switches (default)
#define TM1638_MAX_DISPLAYS 8 // Add support for power control 8 displays
#define TM1638_MAX_KEYS 8 // Add support for 8 keys
#define TM1638_MAX_LEDS 8 // Add support for 8 leds

[barbudor]

Just received today my 2 TM1638
Hooked one, compiled tasmota (ESP8266) with the above defines
I also tested the BUTTONS vs SWITCHES

Works like a charm !

[barbudor]

A little ruleset to enter a 8 digit code (with only digits 1 to 8)

DisplayModel 15
DisplayWidth 8

rule1 
  on system#init do event reset endon 
  on event#reset do backlog ruletimer1 0; displaymode 1; var1 1; var2 " endon
  on button1#state do event key=1 endon
  on button2#state do event key=2 endon 
  on button3#state do event key=3 endon 
  on button4#state do event key=4 endon 
  on button5#state do event key=5 endon 
  on button6#state do event key=6 endon 
  on button7#state do event key=7 endon 
  on button8#state do event key=8 endon 
  on event#key do backlog var2 %var2%%value%; displaymode 0; displaytext %var2%%value%; ruletimer1 10; add1 1 endon 
  on rules#timer=1 do event reset endon 
  on var1#state==9 do backlog ruletimer1 10; var3 The Code is %var2% endon

rule1 1

Will do a little update to the docs

[barbudor]

docs updated
https://tasmota.github.io/docs/TM163x/#tm1638-leds-and-buttons

[FraatTailscale]

Hallo, can you please add also support for the tm1638 4x4 16 button board??

https://www.amazon.de/ASHATA-Digital-LED-R%C3%B6hrenanzeigemodul-MCU-Steuermodul-8-Bit-LED-Anzeigen-default/dp/B084LFQMV4/ref=sr_1_7?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=1VPM2GPR6EJBK&keywords=tm1638&qid=1680809319&refinements=p_85%3A20943776031&rnid=20943775031&rps=1&sprefix=tm1638%2Caps%2C96&sr=8-7

[barbudor]

I have one in the AliEx mail but expected in may :(
Is there some sample code somewhere so I can have a look at the difference?

[barbudor]

@FraatTailscale I haven't received my unit yet but looking at the code, I think everything is there
When self compiling you can specifiy the number of Buttons, LEDs and 7-segment
Just add in your user_config_override.h with the proper values:

#define TM1638_MAX_DISPLAYS   8
#define TM1638_MAX_KEYS       16
#define TM1638_MAX_LEDS       0

[barbudor]

I have received my TM1638 4x4 buttons boards
Unfortunately it doesn't work as expected: neither LCDs display correct digits nor buttons works as expected

There must be some more differences between the 2 boards in trms of wiring/muxing

Does anyone knows where I can find reference/sample code that works for both model of board so I can compare ?

@Jason2866 Didn't you also ordered a 4x4 board ?

Regards

Jean-Michel

[barbudor]

Ok, I found the library and there will be some changes to do
Working on it now

[Jason2866]

@barbudor did not order the 4x4 version.

[barbudor]

I apparently burned down my 1st 4*4 board.
So I ordered and received another one but haven't much time to play with it
Before destroying the 1st one I had very partial result even by upgrading the library.
I need to find some time to work on it again