TM1637 Raspbery PI pico

[aodintsov87]

It seems like TM1637 driver doesn't work on RaspberyPi pico.

I've used the same example provide in the examples folder here just replaced the pins like
tm := tm1637.New(machine.GP21, machine.GP20, 7) // clk, dio, brightness

I've tested the same TM1637 module on Arduino (with C++ tho) and it works fine.
Also tested on 3 different Picos the result is the same.
Any hints? :)

[deadprogram]

I've never tried it, I do not have that HW. Anyone else have a device?

[bxparks]

Are you using the 4-digit or 6-digit seven-segment TM1637 modules commonly found on Amazon or eBay (originally made by robotdyn.com, now cloned by many others)? If so, try increasing the TM1637_DELAY from 10 to 100 microseconds. If that works, I can explain the reason in subsequent posts..

[aodintsov87]

@bxparks I'm using 4-digit seven-segment TM1637 module. I've tried to increase TM1637_DELAY variable but it had no effect. I was also wondering is there away how to properly debug stuff like this? :)

[bxparks]

@aodintsov87 : Are you using the black 4-digit LED modules? There is also the blue 4-digit module which has different timing characteristics. If you are using the black ones, I recall that changing the TM1637_DELAY is not sufficient. You also have to tweak the code to add symmetric delays in the bit twiddling loop. Can you patch this commit and see if it works for you?
bxparks@3caaa7a

I've tested this patch with a Seeed XIAO (SAMD21) and an ESP32. I did not test the PI Pico, I have them laying around, but been too busy with other things to play with them.

With regards to debugging such things, a logic analyzer is what you are looking for. For something like the TM1637, max speed of 400-500 kHz, the cheap 24MHz 8CH USB logic analyzer going for $12-13 on Amazon will be sufficient.

[aodintsov87]

@bxparks thanks a lot your change also works for my module and RPPico. I've also tried 2 other RPPicoW it works for them too :) I'm not sure what you mean by blue and black, my module looks like this. And thanks for the tip regarding debugging I'll try that :)

[bxparks]

You have the blue TM1637 modules, looking like this:

The black ones look like this:

So your blue modules should work with TM1637_DELAY set to the original 10. I'm guessing that the Pico is so fast that it triggers the latent bug in the tm1637 driver code, which is fixed by the extra delaytm() in my patch.

The black TM1637 modules need TM1637_DELAY set to 100, unless you take a soldering iron and remove 2 capacitors on those modules. I have the gory details here: https://github.com/bxparks/AceSegment/blob/develop/docs/tm1637/capacitor_removal.md

[aodintsov87]

Hey @bxparks thanks a lot for all the explanation and additional materials :) I've also checked and indeed it also works with TM1647_DELAY=10. So I'm wondering will you create a pull request with your changes or what's the plan? :)

[pavelanni]

Thanks @bxparks! It works now!
For those who are going to repeat this customization, here is what I did:

1. Create a directory tm1637) at the same level with my current project (cd .. ; mkdir tm1637)
2. Create a Go module in that directory (cd tm1637; go mod init tm1637)
3. Copy the files tm1637.go and registers.go from this commit: https://github.com/bxparks/tinygo-drivers/tree/3caaa7af6250b51d222108fd2c953e98f4e4b784/tm1637
4. In your main project's directory change the go.mod file to include:

require tinygo.org/x/drivers/tm1637 v0.25.0

replace tinygo.org/x/drivers/tm1637 => ../tm1637

5. Flash the board as usual.

I hope I didn't forget anything.

PS. I almost turned on my soldering iron to remove the capacitors but remembered that I needed 8 such displays for my project and decided it's easier to fix it in software ;-)

[tonygilkerson]

FWIW - I just followed the steps described by @pavelanni on my pico and it worked perfectly