search

petrows / esp-32-tm1637

ESP-32 IDF library for control TM1637 LCD 7-Segment display
MIT License
21 stars 19 forks source link

Huge blocking time #3

Closed malinges closed 7 months ago

malinges commented 4 years ago

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?

petrows commented 4 years ago

Hey,

Thank you for your feedback!

I really don't remember why i selected this exact timeout. Probably i had some not best hardware or reversed this timeouts from another library using protocol sniffer.

I am agree with you, this timeout is far from optimal! It can be configured by some #define option. Can you implement it and make pull request?

hayschan commented 1 year ago

To address this issue, I just added a Kconfig so that user can change the delay time of ets_delay_us() through sdkconfig. https://github.com/petrows/esp-32-tm1637/pull/8

IMHO, using Kconfig is more user friendly than #define. Usually there is a UI for Kconfig operation, with search feature. (such as in VS Code)

petrows commented 7 months ago

Thanks a lot, PR was merged some time ago, will close this issue