Library to work with displays based on TM1637 (Oshonsoft Pic Basic Compiler).

[DogFlu66]

I am attaching the library to work with the TM1637 based on the library written in C from the datasheets.
I have had several problems because the displays with TM1637 do not all work at the same speed and this is not taken into account in the examples in the datasheets. There is also a big problem with the datasheet example and that is that it does not configure the DIO line as an open collector, if this is not corrected it will be impossible to read the keyboard. After all these adventures I have been able to create a functional library. I just need to perform the keyboard reading test because I do not have any module with a keyboard until I receive the one I ordered.
Another important problem that I have had to implement is that in the "While" loop of the "I2CAskTM1637()" function (in the original I2CAsk) an exit had not been implemented due to lack of response from the DIO line, if this is not available Take into account that in the case of a breakdown or lack of response from the module, an infinite loop would be generated in the function.

Notice: Finish the library to work with a 4-digit display and a 6-digit display with a keyboard. So update to the new files (2024/04/10).

 

[tumbleweed]

When you say that works with both "fast and slow displays", note that the modules I used had a ridiculously long rise-time since they were using much larger caps than the 100pF shown in the datasheet example circuit.

If you do bit operations on the PORT register then you can run afoul of RMW effects.
That's one of the nice feature of Swordfish... if you do a PORT output operation (ie 'PORTB.1 = 1') it actual uses the LAT register for you automatically.

 

[DogFlu66]

True, using C I did suffer from that problem until I realized it, however with this language I have not had that problem, I suppose I would do it internally with Swordfish.
Regarding the "NOPs" when placing those fixed values on the slow displays, the times were reduced to a delay of 30uSec. for the DIO line and a fixed delay for all (slow and fast) of 1uSec. for the CLK.

Therefore I use a fixed delay2 of 1uSec for the CLK line for slow and fast displays.
For the DIO line I use a delay1 of 1uSec for fast displays and a Delay1 = 30uSec for slow displays.

 

[MaxHeadRoom78]

Most come with 10nf on the two control lines, they should actually be 100pf.
Or even removed altogether usually works also.

 

[DogFlu66]

When I finish modifying the library with more peace of mind, I perform some more tests with the capacitors, just to clear up any doubts.

At the moment I classify them into slow and fast displays, as I said before I apply a delay of 30uSec to the DIO line for the slow ones and a delay of 1uSec for the fast ones, and for the CLK line I always apply a delay of 1uSec for fast and slow ones.

 

[DogFlu66]

Complete the library to work with a 4-digit display and a 6-digit display with keyboard. So update to the new files at the beginning of the thread.

 

[DogFlu66]

When you say that works with both "fast and slow displays", note that the modules I used had a ridiculously long rise-time since they were using much larger caps than the 100pF shown in the datasheet example circuit.

If you do bit operations on the PORT register then you can run afoul of RMW effects.
That's one of the nice feature of Swordfish... if you do a PORT output operation (ie 'PORTB.1 = 1') it actual uses the LAT register for you automatically.

The effect that occurs when using the PORTx register instead of the LATx register to control outputs on a PIC18 microcontroller is commonly known as the "read-modify-write" issue. This effect can cause the pins not to achieve the correct state.

This issue indeed happened to me with this language. When a port is used as an output, you must use LATx, and PORTx should be used when it’s an input. My mistake was due to carelessness. It's crucial to use the ports correctly out of habit. The error lies in the fact that sometimes, when the wrong register is used and not many pins from the same port are involved, it may seem to work fine, leading you to overlook the issue. However, to ensure it won't fail, you must use PORTx and LATx appropriately.