Giter Site home page Giter Site logo

esp-32-tm1637's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

esp-32-tm1637's Issues

Invalid handling of ACK signal: short?

Hi,

I was toying with a new logic analyzer, and noticed something strange looking at the signal coming out of this library.
Here is what sending the TM1637_ADDR_FIXED byte (the first byte sent by tm1637_set_segment_raw()) looks like:

scrn-2020-09-07-13-55-30

So basically: start condition (S), the 8 individual bits, ACK, and stop condition (P).

What struck me is what happens when CLK goes down at the end of the 8th bit.
Looking at the code, after sending the 8th bit, the library pulls CLK down, and DIO up: https://github.com/petrows/esp-32-tm1637/blob/master/tm1637.c#L89-L90
But looking at the capture above, it appears that DIO stays down.
The most logical explanation is that while we pull DIO up, the TM1637 itself pulls it down (and "wins the fight", according to the logic analyzer).

So I looked at the TM1637 spec, and it actually makes sense:

TM1637 data transfer carries with answering signal ACK. For a right data transfer, an answering signal ACK is
generated inside the chip to lower the DIO pin at the failing edge of the 8th clock. DIO interface wire is released at the
end of the 9th clock. (Interface interpretation - page 3)

The TM1637 actually pulls DIO low as soon as CLK goes low after the 8th bit.
So pulling it up in the code is a mistake, and generates a short-circuit for a few microseconds after each and every byte.
Probably not very good for the chips...

To my understanding, the code would need to be modified to follow these steps right after sending the 8th bit, basically making sure DIO is set as input for the whole duration of the ACK, to prevent any shorts:

  • set DIO as input
  • pull CLK down (TM1637 ACK starts, pulling DIO low)
  • delay
  • pull CLK up
  • wait for DIO to be low (it should be low since we pulled CLK down above)
  • delay
  • pull CLK low (TM1637 ACK stops, "releasing" DIO)
  • delay
  • set DIO as output
  • pull DIO low

Then, as CLK is already low, we don't need to pull it low again in tm1637_stop() so line 69 could be removed.

These are just initial findings. I'll play with the code, and see if I can come up with a PR.

Cheers!

Huge blocking time

Hi,

I'd like to start by thanking you for this library, I'm using it regularly :-)
However I noticed some unexpectedly high blocking times when updating the display: about 20ms to update all 4 digits (using 4 calls to tm1637_set_segment_raw()). This is huge!
It all boils down to the tm1637_delay() function, which blocks for 50us by calling ets_delay_us(50).
A 50us delay between clock pin changes gives a 100us clock period, which means a 10kHz clock frequency (this is ignoring CPU time to process data and toggle GPIOs, which brings the frequency even lower in real life).
10kHz is waaaaay below the maximum clock frequency of the TM1637: 250kHz as per the datasheet.
As an experiment, I reduced the delay to 1us (which would give a 500kHz frequency, ignoring CPU time) and my display was still working perfectly fine, even on 3.3V, while blocking time was reduced from 20ms to about 1.1ms.
However this was on ESP8266 RTOS SDK v3 (which mimicks the ESP-IDF APIs) so YMMV. The ESP32, being much faster, might actually reach the frequency limit.
But I guess a delay of 5us (100kHz) or 4us (125kHz, or half the max frequency) would probably be safe in most cases, while still speeding up the communications process considerably.

What do you think?

Problem with tm1637_set_number_lead_dot

Hi, looking for some help here... I am using the example code and its working for the most part. I am having a problem speicfically with:

tm1637_set_number_lead_dot(lcd, time_number, true, z%2 ? 0xFF : 0x00);

Two issues....

  1. Not displaying leading zeros when time is using 24hr clock
  2. Not understanding how the mask is working for the dot.

with regards to the dot, I am calling the display to change every 1 second based on an interrupt. I would like the dot to change every other cycle. If I use the code as above, I get a faint blip, but not consistantly. If I change the %2 to %4, I get a consistant blip every second, but it only stays on for what is probably 1/4 of a second.

Any help is appreciated!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.