superfuous delay

[nerdralph]

Only one delay per clock phase is needed, so the one on line 538 can be deleted.
https://github.com/jasonacox/TM1637TinyDisplay/blob/master/TM1637TinyDisplay.cpp#L538
Keep the delay on line 546.

Also the default of 100us seems excessive. The datasheet v2.4 lists 500kHz for Fmax, which means 1us per clock phase. I'd suggest a default bit delay value of around 5us, which would still leave a large safety margin.

[jasonacox]

That makes sense, but when I drop the bitdelay to 5 or 10us, the Arduino Uno is unable to drive the display. When I have more time, I'll investigate.

[nerdralph]

Earlier today I hooked my scope up and found the rise time to 3V is nearly 10us with my module. It has 10k pullups. The datasheet example circuit has 100pF caps, but the module must be using 1n. I have been modifying my TM1638 library for the 1637. I've avoided using delays by polling the clk and dio lines when they get pulled high.

…

On Thu, Nov 19, 2020, 00:55 Jason Cox ***@***.***> wrote: That makes sense, but when I drop the bitdelay to 5 or 10us, the Arduino Uno is unable to drive the display. When I have more time, I'll investigate. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKNZ6XVN7DGQGTSFKN5CCDSQSQL3ANCNFSM4TYSZCCQ> .

[jasonacox]

I'm impressed! Makes sense. I've seen a few other TM1637 libraries that use aggressive timing that caused stability issues over time for my project on some modules I use. I may have over engineered the delays, but they are stable. I'll revisit when I get time. Thanks for all the feedback and PRs!