I've been trying for hours to make a 4-digit display work with the TM1637 controller. On Arduino Nano it works well. When trying to port the Arduino library to the PIC, MPLAB-X XC8, the signal generated by the PIC is different from the Arduino.

  • MPLAB X IDE v6.00
  • XC8 2.36

So after trying to do bitbang on the XC8, and not getting satisfactory results, I decided to compare it with the operation of the program made in MikroBasic.

With MikroBasic the PIC seems to make the signal correctly, as occurs with Arduino.

But in MPLAB-X there is a lack of power at the PIC pin, it seems that the internal resistance of the pin is lower when the program is done in MPLAB-X.

On the oscilloscope it is easy to notice that the PIC cannot immediately lower the pin when using MPLAB-X:


enter image description here


enter image description here

I tried everything I know:

  • Different ports (PORT, PORTB), Different port pins, Different PIC models (PIC16F876A, PIC16F1938)
  • PORTAbits.RA3 = 0;
  • PORTA &= 0b11110111;
  • Disabled the modules related to the pins, comparator, ADC, voltage reference, etc.
  • With the XC8's delay, with the FOR(), WHILE() loop, nothing worked.

MPLAB-X main:

void main(void) {

    PORTA = 0;
    PORTB = 0;
    PORTC = 0;

    TRISA = 0b00000011;
    TRISB = 0;

    //ADCON0 = 0b11000000; //bit 0 ADON: A/D On bit = off
    ADCON1 = 0b11000110; //all pins as digital

    CCP1CON = 0; //module off
    CCP2CON = 0;

    CMCON = 7; //comparator off
    //CVRCON = 0;


    //TM1637_setBrightness(0x0F, true);
    const uint8_t const1 = 70;

    while (1) {
        //TM1637_setSegments(TM1637_test, 1, 0);
        PORTB = 0; // PORTAbits.RA2 = 0; // DIO_low(); // pinMode(m_pinDIO, OUTPUT)
        //__delay_us(100); // bitDelay();
        delay1 = const1;


        PORTB = 0; // PORTAbits.RA2 = 0; // DIO_low(); // pinMode(m_pinDIO, OUTPUT);
         //__delay_us(100); // bitDelay();
        delay1 = const1;

        PORTB |= 0b00010000; // PORTAbits.RA3 = 1; // CLK_high(); // pinMode(m_pinClk, INPUT);
//         __delay_us(100); // bitDelay();
        delay1 = const1;

        PORTB = 255; // PORTAbits.RA2 = 1; // DIO_high(); // pinMode(m_pinDIO, INPUT);
//         __delay_us(100); // bitDelay();
        delay1 = const1;




MikroBasic main:

'   Main program

  PORTA = 0
  PORTB = 0
  PORTC = 0
  TRISB = 0

  CMCON = 7
  ADCON0 = %11000000
  ADCON1 = %11000110
  CCP1CON = 0
  CCP2CON = 0

    PORTB.B5 = 0
    PORTB.B5 = 1



  • Edit 1:
    • I didn't mention that I'm using Linux, I haven't tested it on Windows yet.
  • \$\begingroup\$ The differences in how the compilers optimize and handle code might also affect the timing and the behaviour of your program. \$\endgroup\$
    – liaifat85
    Commented Apr 2 at 6:07
  • 2
    \$\begingroup\$ have you looked at the assembly that gets generated? \$\endgroup\$
    – BeB00
    Commented Apr 2 at 6:11
  • \$\begingroup\$ ADCON1 = %11000110: bit 3-0 PCFG3:PCFG0: A/D Port Configuration Control bits, All digital: 011x. \$\endgroup\$ Commented Apr 2 at 15:48

2 Answers 2


There should not be any difference in pin behaviour between compilers. XC8 emits a BSF PORTB, 0x4 and I assume Mikro would do the same if you used PORTB.B4 rather than PORTB.B5. The delays you have inserted should be adequate to avoid RMW issues.

You mention different PIC models, pin and port numbers, and compilers, but not different TM1637s. The TM1637 modules have capacitors on the CLK and DIO, that are supposed to be 100pF. If one or more of them was mistakenly populated with a much larger value capacitor such then the waveforms you are seeing would make a lot more sense.

Missing or intermittent power supply connections can cause similar weird effects because things get powered through the data lines.

  • \$\begingroup\$ Yes, I have 2 TM1637, I also removed the CLK and DIO capacitors but it remains the same. But what is the question regarding TM1637, if the code generated by MikroBasic is functional and the code generated by MPLABX is not? \$\endgroup\$ Commented Apr 2 at 15:43
  • 1
    \$\begingroup\$ You did not specify exactly how you did the tests, whether the physical setup was identical, and differences in the functionality of the two programs lead to doubt that everything was identical. In any case, I suggest looking at the emitted code in the simulator. Depending on the version you have you might see something different than I did. \$\endgroup\$ Commented Apr 2 at 16:03
  • \$\begingroup\$ In fact, when the pin is free, the descent time is perfect, only when the pin is connected to the CLK or DIO of the TM1637 does this occur. And it is on either the CLK or DIO pins. And on different ports, so there's no point in putting it in a simulator, I'm already doing tests with the microcontroller on the bench. But thanks for the help. \$\endgroup\$ Commented Apr 2 at 16:11
  • 1
    \$\begingroup\$ The point of the simulator is to set a breakpoint and see exactly what machine instructions are generated. \$\endgroup\$ Commented Apr 2 at 16:13
  • \$\begingroup\$ Yes, I understand the point, debug the instruction that the compiler left in the HEX file. Unfortunately I don't have much time right now. It's easier for me to exchange the PIC16F876A for an ATmega328p, which I'm more certain will be working without having to debug the IDE or compiler itself, port the project to the Arduino platform and compile with VScode. Thanks. \$\endgroup\$ Commented Apr 2 at 16:28

The problem was the lack of GND on the TM1637. Before removing the PIC16F876A to place the ATmega328P, I reconnected the TM1637. Then the PIC was programmed with MPLABX and the pin signal was as in the oscilloscope image running the code generated by MikroBasic. As for why MikroBasic can output the signal correctly even with a problem with the TM1367's GND, I still don't know what happens. Thank you to everyone who tried to help.

I forced the lack of GND on the TM1637 with Arduino Nano, and the symptom is similar, the display only lights up when the update command is performed. Although the wave on the oscilloscope is not as deformed as on the PIC, demonstrating the superiority of the ATmega328P over the PIC16F876A. (It was not without reason that Microchip bought ATMEL)

  • 2
    \$\begingroup\$ Ah, "Missing or intermittent power supply connections" strikes again. Thanks for closing the loop. \$\endgroup\$ Commented Apr 2 at 17:18
  • \$\begingroup\$ @SpehroPefhany In fact, I later saw that your answer was suggesting problems with poor contact in the power supply, so I added an answer, instead of accepting your answer. Maybe if the answer didn't have other things along with it, I would have been able to make better use of the information. It's harder for me to work with Software than working with Hardware, that's why I paid more attention to the tips on Software. But thanks anyway. \$\endgroup\$ Commented Apr 3 at 15:03
  • \$\begingroup\$ You can accept your own answer. \$\endgroup\$ Commented Apr 3 at 15:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.