• AVR Freaks

Hot!Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display

Page: < 123 > Showing page 2 of 3
Author
jack@kksound
code tags!
  • Total Posts : 3198
  • Reward points : 0
  • Joined: 2014/05/14 10:03:19
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/08 10:30:48 (permalink)
+1 (1)
 I have been quite unlucky getting it operational.

What does that mean? You should tell us what you expect the program to do, what it does do, what it does not do or do correctly. Without some idea of what you see not working the way you expect, the job of finding your problems becomes mostly a guessing game.
#21
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 01:07:23 (permalink)
0
Well, for instance, I have uploaded my program on my PIC and for some strange reason, I cannot get any signal on RB1 and RB2 pins with my oscilloscope  - the DIO and CLK pins for serial communication.
 
On the other hand, in Proteus, the booting goes smoothly, shows test values 123456 for 2 seconds, then 0 for 500 ms. Then my program goes to while loop, in which it must collect the RA4 frequency count in 1 second intervals. The frequency count is done by counting T0IF interrupts and the remainder of pulses within 1 s. Then this result must be displayed on the screen, but my test signal in there is for example 171042 Hz, but the screen shows something like 41389 Hz. So the calculus gets a very wrong result. Yet, when I inspect the CPU memory, the frequency value is quite correct. The display number function loses some information. Perhaps it is due to data type conversion: I have declared my freq as long, but when I send my number for the function I use:

 
 
 
display_number((unsigned int)freq);   // display frequency
 
 
 

 
Now, another matter is that the assembled PCB version does not work at all. I still need to debug and see how and why this problem occurs.
 
My PIC clocking crystal part of the schematics is also attached.
 
 
Edit: For some reason, there is an old remnant in the schematics - the D4 diode is not supposed to be there, I think.
post edited by citizen3942 - 2019/04/09 01:31:00

Attached Image(s)

#22
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 01:28:35 (permalink)
+2 (2)
On 8-bit PICs unsigned int (or signed int) is 16-bit.
171,042 exceeds the maximum allowable value of 65,535 for a 16 bit integer.
Although according to my calculations should display 39,940.
So not exactly what you are getting (41,389), but you did say “something like”.

My advice:
Include stdint.h, and then you have access to:
int8_t
int16_t
int24_t
int32_t
uint8_t
uint16_t
uint24_t
uint32_t

Use these and you will always know what size integers you are dealing with.
#23
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 03:06:22 (permalink)
0
I have tried setting uint32_t:

void display_number(uint32_t);

And the same in the main cycle:

void main(){
    uint32_t freq = 0;
    OPTION_REG = 0b10101000; // Set T0CKl as clock source, rising edge
                                                 // and WDT prescale 1:1
    display_init((uint8_t)7);
    display_number(123456);
    __delay_ms(2000);
    display_number(0);
    __delay_ms(500);
    while(1){
        ...
       // calculating frequency
       freq = (uint32_t)f1; // get # of TMR0 overflows
       freq <<= 8; // multiply by 256
       freq += (uint32_t)f2; // add the remainder of TMR0 count
       //freq <<= 1; // multiply by 2

       display_number(freq); // display frequency
    }
}

 
But still proteus outputs 40824, instead of 171896.
#24
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 03:46:55 (permalink)
+2 (2)
citizen3942
I have tried setting uint32_t:

 
void display_number(uint32_t);
 

And you have changed the actual function code to accept and process a uint32_t, and not just the prototype?
 
Just changing the prototype (as you have above) will not work.  Even changing the function definition also may not work if it is only processing 16-bits internally.
 
What did...
display_number(123456);

...give you?
 
Post all your source, including the code for display_number.
#25
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 03:58:32 (permalink)
+1 (1)
Note the code you posted earlier takes an unsigned 24 bit "number" (range 0 through 16,777,215) and produces a 6 digit result (valid in range 0 through 999,999 as far as I can see):
void display_number(uint24_t number) {
//    uint8_t digit6 = digitToSegment[number & 0x0F];
//    uint8_t digit5 = digitToSegment[(number >> 4) & 0x0F];
//    uint8_t digit4 = digitToSegment[(number >> 8) & 0x0F];
//    uint8_t digit3 = digitToSegment[(number >> 12) & 0x0F];
//    uint8_t digit2 = digitToSegment[(number >> 16) & 0x0F];
//    uint8_t digit1 = digitToSegment[(number >> 20) & 0x0F];
    // if someone figures out bitwise operation for 6 digit in base 10, would be
    // much faster operation here
    uint8_t digit6 = digitToSegment[number % 10];
    number /= 10;
    uint8_t digit5 = digitToSegment[number % 10];
    number /= 10;
    uint8_t digit4 = digitToSegment[number % 10];
    number /= 10;
    uint8_t digit3 = digitToSegment[number % 10];
    number /= 10;
    uint8_t digit2 = digitToSegment[number % 10];
    number /= 10;
    uint8_t digit1 = digitToSegment[number % 10];
    
    display_values(digit1, digit2, digit3, digit4, digit5, digit6);
}


Is this still what you are using?
Please post entire current code and actual example values of input and output "not working".
 
Edit:
This code...
freq = (uint32_t)f1; // get # of TMR0 overflows
freq <<= 8; // multiply by 256
freq += (uint32_t)f2; // add the remainder of TMR0 count

 
f1 and f2 are being updated in your ISR (Interrupt Service Routine) - correct?
What type are f1 and f2?
You are running the risk of f1 and f2 being read at different times and an interrupt occuring between them. Or worse for multi-byte variables - part of the variable being read and then an interrupt and then the remainder being read (after being modified by the ISR).
 
GIE = 0; //disable interrupts while reading
freq = (uint32_t)f1; // get # of TMR0 overflows
freq <<= 8; // multiply by 256
freq += (uint32_t)f2; // add the remainder of TMR0 count
GIE = 1; // re-enable interrupts

post edited by pcbbc - 2019/04/09 04:10:24
#26
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 04:19:53 (permalink)
0
pcbbc
And you have changed the actual function code to accept and process a uint32_t, and not just the prototype?

Yes I did change the acual function as well:

 
void display_number(uint32_t number) {
 

Following call:

 
display_number(123456);
 

outputs the number correctly on the simulated display.
 
main.c is attached.
 
PS! I disassembled PLJ-6LED-R5 display, it has PIC16F648A and TM1637. The CLK pin is at RB3 and DIO is at RB0 for some reason. But I believe its due to USART RX and TX pins. I want to believe that there should not be any difference which kind of PORB pins I use for TM1637 IC communication.
post edited by citizen3942 - 2019/04/09 04:23:08
#27
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 05:53:00 (permalink)
+1 (1)
    INTCONbits.T0IF = 0;   // clear the interrupt flag
 
// Why are you cleraring this here, when you clear it again 2 lines later by setting INTCON?
        f1 = 0;                // zero the frequency # of overflows count
        INTCON = 0b10101000;   // Enable interrupt at Timer0
 
// Why are you enabling RB port change interrupt?  You do not appear to be using it?
        TMR0 = 0;              // start counting input signal
        __delay_ms(1000);       // tweaking this will enhance gate time
// This is a very poor inaccurate way to delay for 1 second.  For one it does not account for time in the ISR.
// Much better would be to user TIMER1 to time 1 second, and have the ISR calcualte the frequency and set a flag.
        INTCON = 0;             // Disable interrupts
 
// You realise TMR0 is still counting?  It might now rollover from 0xFF to 0x00 and NOT increment the high byte.
        f2 = TMR0;              // Store the remainder of Timer0 count
        
        // calculating frequency
        freq = (uint32_t)f1;        // get # of overflows
 
// f1 may now be out by one because the interrupt hasn't fired to increment it.
 
// indeally you would be checking INTCONbits.T0IF here, and other stuff, to account for this.
        freq <<= 8;             // multiply by 256
        freq += (uint32_t)f2;       // add the remainder of Timer0 count
        //freq <<= 1;             // multiply by 2
 
      
        display_number(freq);   // display frequency

You are getting 40824, instead of 171896, because:
40824 = 0x00009F78
171896 = 0x00029F78
 
Somewhere there is a truncate to 16 bits and you are losing the high word (0x0002____).
But I cannot see where from the code you have posted, sorry.
It is odd, because the 123456 = 0x0001E240, you say isn't getting truncated.
post edited by pcbbc - 2019/04/09 05:59:31
#28
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 08:13:40 (permalink)
0
Somehow the Proteus was acting up. I redid everything with those type definitions modifications and the simulaed display shows the number correctly, even in this while loop.
 
Another step is to replace this supposedly inaccurate delay:

__delay_ms(1000); 

Does someone have a good example of using TMR1, while the system clock is at 16.3676 MHz. It may sound a bit uneducated - I am a bit unfamiliar, if I need an external crystal on pins RB6 and RB 7 to use TMR1?
 
And another matter is figuring out, why I don't have any pulses on RB1 and RB2 on my circuit board, whereas simulation works fine?
I tried using internal oscillator as well, for debugging, by setting:

   #define _XTAL_FREQ 4000000
    #pragma config FOSC = INTOSCIO 

But now I get garbled characters and odd pulses on DIO pin with my PCB. So there must be something wrong with this VC-TCXO I have put together.
https://1drv.ms/u/s!ApzdPwNRjFJK137mEFX6j6hR-Gjh
#29
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 09:12:32 (permalink)
+1 (1)
No, TIMER1 can run from the instruction clock Fosc/4.
So you would set a value of 16367600 / 4 = 4,091,900 = 0x3E6FFC
But as it is only a 16 bit timer, you need to count overflows of that as well.
 
Something like (I don't claim this is 100%):
volatile bit isr_done;
volatile uint8_t T1ticks;
volatile uint24_t freq;

// interrupt procedure
void interrupt tc_int (void) {
    if(INTCONbits.T0IE && INTCONbits.T0IF) {    // make sure the interrupt came from T0IF/RA4 pin
        INTCONbits.T0IF = 0;                    // clear T0IF bit
        freq += 0x100;                          // increment # of overflows
    }
    if (PIE1bits.TMR1IE && PIR1bits.TMR1IF) {   // timer1 timeout
        if (T1ticks == 0) {
            uint8_t tmr0 = TMR0;                    // get low byte of count
            if (INTCONbits.T0IF) {                  // rollover post read of TMR0?
                INTCONbits.T0IF = 0;                // clear T0IF
                tmr0 = 0xFF;                        // assume max value on rollover
            }
            freq |= tmr0;               // or in low order bits to frequency
            INTCONbits.T0IE = 0;        // disable T0 IRQ
            PIE1bits.TMR1IE = 0;        // disable T1 IRQ
            isr_done = 1;
        } else {
            T1ticks--;                  // one less timer1 timeout to go
        }
        PIR1bits.TMR1IF = 0;        // clear TMR1IF
    }
}

int main()
{
    // USING EXTERNAL CLOCK (16.3676 MHz) on OSC1
    CMCON = 0b00000111;   // comparator off
    TRISA = 0b10110000;   //Set A register I/O bits
    TRISB = 0b11000000;   //Set B register I/O bits
    OPTION_REG = 0b10101000;    // Set T0CKl as clock source, rising edge
                                // and WDT prescale 1:1
 
    // Try counting the signal frequency for 1 second intervals
    while(1){
        freq = 0;               // zero the frequency # of overflows count
        T1ticks = 0x3E;         // 16367600 / 4 = 0x3E6FFC
        TMR1 = ~0x6FFC;
        PIR1bits.TMR1IF = 0;    // Clear T1 interrupt
        PIE1bits.TMR1IE = 1;    // Enable T1 interrupt
        isr_done = 0;           // flag ISR as incomplete
        TMR0 = 0;               // start counting input signal
        T1CON  = 0b00000001;    // Enable Timer1
        INTCON = 0b11100000;    // Enable interrupt at Timer0 and PEIE
        while (isr_done == 0);  // wait for T1 timeout T1ticks
      
        display_number(freq);   // display frequency
    }
}

 
Some other observations:
1. You have WDT enabled, but aren't resetting the watchdog anywhere.  Turn it off:
#pragma config WDTE = OFF
2. You do not need return statements at the end of void functions.  Remove them.
#30
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 09:27:05 (permalink)
+1 (1)
And another matter is figuring out, why I don't have any pulses on RB1 and RB2 on my circuit board, whereas simulation works fine?
I tried using internal oscillator as well, for debugging, by setting:
   #define _XTAL_FREQ 4000000
    #pragma config FOSC = INTOSCIO 

Internal oscillator appears on RA6.  No idea where you got the idea it is on RB1/RB2?
101 = INTRC oscillator: CLKOUT function on RA6/OSC2/CLKOUT pin, I/O function on RA7/OSC1/CLKIN.
RB1/RB2 are the serial RX/TX pins.
 
Are you expecting to see the serial data (you aren't sending anything in your code) or the internal oscillator clock out?
 
 
#31
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/09 23:52:03 (permalink)
0
pcbbc
Internal oscillator appears on RA6.  No idea where you got the idea it is on RB1/RB2?
101 = INTRC oscillator: CLKOUT function on RA6/OSC2/CLKOUT pin, I/O function on RA7/OSC1/CLKIN.
RB1/RB2 are the serial RX/TX pins.
 
Are you expecting to see the serial data (you aren't sending anything in your code) or the internal oscillator clock out?
 

Yes, I meant RB1/RB2 must show me the TM1637 compatible serial data.
The external clock is on RA7/OSC1.
 
I will test the main sequence you have proposed with this TIMER1 and optimized interrupt in a few hours, and see if I can get it working in simulation and on PCB as well.
post edited by citizen3942 - 2019/04/10 00:12:00
#32
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 00:12:54 (permalink)
0
I have tested the proposed code in simulation, and it works perfectly (+- 1Hz). On PCB the display does not show, nor there is any serial data in RB1/RB2. I have reason to believe that there is some sort of a problem with my external clock generator. Either there is a faulty crystal, or it is not correct for the PIC16F628SO I am using.
 
EDIT1: I measured on my oscilloscope that RA7 receives ca 570 mV Pk-Pk oscillation at ca 16.3 MHz.
 
EDIT2: I measured clock signals on PLJ-6LED-R5 and its offset was at 0.75 V (Pk-Pk 0.5 V), oscillating at 13 MHz. On my PCB, the oscillation is at 90 mV offset (600 mV Pk-Pk) at 16 MHz. Do I have my FOSC bits set up correctly?
 
EDIT3: I have set FOSC = HS, and now the oscillation is 600 mV Pk-Pk (600 mV offset). Yet there is no serial data bits RB1/RB2 thus no display.
post edited by citizen3942 - 2019/04/10 01:45:21
#33
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 02:13:00 (permalink)
0
UPDATE1: THE FOSC=HS is the correct oscillator mode, since I did get serial data when I disconnected the display. I believe that it has to do something with those pull-up resistors, so I probably need to configure RBPU.
 
UPDATE2: I replaced C3 and C4 capacitors (10 nF) with much smaller value (500 pF) and now the serial data is working well. Although the digit addressing is wrong.  In display_number function I had to change the order of digits:
display_values(digit3, digit2, digit1, digit6, digit5, digit4);

In boot sequence, it shows 654321 as supposed to, but next test value 0 shows as ---0--, though it should have -----0 (- as blank). Also in serial data, everything seems in the correct order - the 0 is indeed the last byte. What explains such behavior?
post edited by citizen3942 - 2019/04/10 03:40:16
#34
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 03:55:16 (permalink)
+1 (1)
citizen3942UPDATE2: I replaced C3 and C4 capacitors (10 nF) with much smaller value (500 pF) and now the serial data is working well. Although the digit addressing is wrong.
Where are C3 and C4?  On RB1/RB2?
 
 
As your PIC is of and old design, and you do not have PORT LAT registers, it will suffer RMW (Read Modify Write) effects when writing to single output bits.  Use a backing variable to get around this and always write the entire variable to the output port.
 
Also, what is with all the do while loops in your #defines?
#define CLK_SetDigitalInput()    do { TRISBbits.TRISB1 = 1; } while(0)

 
In display_number function I had to change the order of digits:
display_values(digit3, digit2, digit1, digit6, digit5, digit4);

In boot sequence, it shows 654321 as supposed to, but next test value 0 shows as ---0--, though it should have -----0 (- as blank). Also in serial data, everything seems in the correct order - the 0 is indeed the last byte. What explains such behavior?
Sorry - Having to change the order of the digits in obviously working code is nonsense.


This is the result of some other effect.  Perhaps a result of errors sending data, and only some of the data being sent/arriving.  I would suggest you start by accounting for the RMW issue.
#35
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 04:04:50 (permalink)
0
I forgot to include the link to the display schematics:
https://robotdyn.com/pub/media/0G-00005561==Mod-LED-Display-6D-TM1637-76x19mm/DOCS/Schematic==0G-00005561==Mod-LED-Display-6D-TM1637-76x19mm.pdf
In that schematics, I replaced the C3 and C4.
 
Also, what is with all the do while loops in your #defines?

These are the remnants of the original library code by Jarrett Rainier.
Perhaps, yes these do/while can be omitted in there.
 
I will look into that RMW issue...
#36
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 04:47:33 (permalink)
0

https://robotdyn.com/pub/media/0G-00005561==Mod-LED-Display-6D-TM1637-76x19mm/DOCS/Schematic==0G-00005561==Mod-LED-Display-6D-TM1637-76x19mm.pdf

 
RobotDyn TM1637 pins are defined incorrectly, thus the data must be in sequence: digit3, digit2, digit1, digit6, digit5, digit1.
 
I updated the library functions to accomodate for that:

void display_number(uint24_t number) {
// uint8_t digit6 = digitToSegment[number & 0x0F];
// uint8_t digit5 = digitToSegment[(number >> 4) & 0x0F];
// uint8_t digit4 = digitToSegment[(number >> 8) & 0x0F];
// uint8_t digit3 = digitToSegment[(number >> 12) & 0x0F];
// uint8_t digit2 = digitToSegment[(number >> 16) & 0x0F];
// uint8_t digit1 = digitToSegment[(number >> 20) & 0x0F];
// if someone figures out bitwise operation for 6 digit in base 10, would be
// much faster operation here
uint8_t digit6 = digitToSegment[number % 10];
number /= 10;
uint8_t digit5 = digitToSegment[number % 10];
number /= 10;
uint8_t digit4 = digitToSegment[number % 10];
number /= 10;
uint8_t digit3 = digitToSegment[number % 10];
number /= 10;
uint8_t digit2 = digitToSegment[number % 10];
number /= 10;
uint8_t digit1 = digitToSegment[number % 10];

//decide leading zero blanking
if(digit1==digitToSegment[0]){
digit1=digitToSegment[16]; //blank digit byte
if(digit2==digitToSegment[0]){
digit2=digitToSegment[16];//blank digit byte
if(digit3==digitToSegment[0]){
digit3=digitToSegment[16];//blank digit byte
if(digit4==digitToSegment[0]){
digit4=digitToSegment[16];//blank digit byte
if(digit5==digitToSegment[0]){
digit5=digitToSegment[16];//blank digit byte

}
}
}
}

display_values(digit3, digit2, digit1, digit6, digit5, digit4);

}
//...........
void display_values(uint8_t data1, uint8_t data2, uint8_t data3, uint8_t data4, uint8_t data5, uint8_t data6) {

// First version of leading zeroes elimination code 

display_sof();
write_byte(0x40);
display_eof();

display_sof();

write_byte(0xC0);

write_byte(data1);
write_byte(data2);
write_byte(data3);
write_byte(data4);
write_byte(data5);
write_byte(data6);

display_eof();

display_sof();
write_byte(0x8F); //write command 3
display_eof();

}

 
#37
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 04:58:40 (permalink)
0
citizen3942RobotDyn TM1637 pins are defined incorrectly, thus the data must be in sequence: digit3, digit2, digit1, digit6, digit5, digit1.
Then how come 654321 "displays correctly"?
At least you fixed the hideous leading zero blanking code in the original library grin: grin
#38
citizen3942
New Member
  • Total Posts : 11
  • Reward points : 0
  • Joined: 2019/04/02 04:37:33
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 05:09:44 (permalink)
0
pcbbc
citizen3942RobotDyn TM1637 pins are defined incorrectly, thus the data must be in sequence: digit3, digit2, digit1, digit6, digit5, digit1.
Then how come 654321 "displays correctly"?
At least you fixed the hideous leading zero blanking code in the original library grin: grin


I have set up the test number to be "654321", so this is most definitely correct. Indeed I used 123456 previously, so that might have caused some misunderstanding grin: grin
 
#39
pcbbc
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2014/03/27 07:04:41
  • Location: 0
  • Status: offline
Re: Interfacing the PIC16F628A with a TM1637 (Chinese) Multiplexed LED Display 2019/04/10 05:32:08 (permalink)
+1 (1)
citizen3942In boot sequence, it shows 654321 as supposed to, but next test value 0 shows as ---0--, though it should have -----0 (- as blank). Also in serial data, everything seems in the correct order - the 0 is indeed the last byte. What explains such behavior?
So if display_number(654321) displays "654321", then there is no conceivable reason for display_number(0) to display "---0--"!
 
 
But if your modified code is working for you, no problem.  It just doesn't comport with the observations you posted earlier.  Unless of course display_number(654321) actually displayed "456123" - but that's not what you said. wink: wink
#40
Page: < 123 > Showing page 2 of 3
Jump to:
© 2019 APG vNext Commercial Version 4.5