Raspberry Pi Forums

Posted: **Wed Nov 21, 2018 3:38 pm**

Hey,
I try to interact with a TLC5940 via C. I use Rapsbian as OS and I am not sure how I can realize something like

pulse(int nanoseconds){
setPinOutHigh
sleep(nanoseconds)
setPinOutLow
sleep(nanoseconds)
}

The timing diagram requires for example a period of at least 3ns for some signals. So is nanosleep() the way to go, even if it may take länger. Or is there a more consistent way to interact with so precise Timing?

Posted: **Wed Nov 21, 2018 4:59 pm**

DuBBox wrote: ↑
Wed Nov 21, 2018 3:38 pm
Hey,
I try to interact with a TLC5940 via C. I use Rapsbian as OS and I am not sure how I can realize something like

pulse(int nanoseconds){
setPinOutHigh
sleep(nanoseconds)
setPinOutLow
sleep(nanoseconds)
}

The timing diagram requires for example a period of at least 3ns for some signals. So is nanosleep() the way to go, even if it may take länger. Or is there a more consistent way to interact with so precise Timing?

Which data sheet are you referring to? When I look at the data sheet http://www.ti.com/lit/ds/symlink/tlc5940.pdf... Never mind. If a 16Mhz 8 bit Arduino can run one of these devices then the RPI can as well.

A simple search with your favorite search enginge using the words " +c TLC5940 library" will give you a number of results you can view to see how 'they' did it.

But if you really really need to generate a 3nS pulse use a ESP32 and the internal hardware timer.

Posted: **Wed Nov 21, 2018 5:21 pm**

Thank you for your quick response!

I took a closer look to https://github.com/lrvdijk/tlc5940-raspberry but here, I may miss something, is no sleep or something similar used.

The pulse just works like

pulse(){
setPinOutHigh
setPinOutLow
}

No sleeps are used.

My current implementation is not working and my guess was, that my pulse method is simply "too fast".
I am very new to all those "hardware"-things, I did also not see any implementation AVR/Arduino which used sleep for a pulse method, https://sites.google.com/site/artcfox/d ... he-tlc5940 also does not mention it in the code. I used this and translated it to the usage for a raspberry pi using wiringPi.

**The reason for the idea of using a sleep is because http://www.ti.com/lit/ds/symlink/tlc5940.pdf 6.3, but I may get something wrong here? There are some times listed, which are needed to accept a signal. Since the Pi could propably be faster? I thought I may need to reglement this.

The method I am cycling is

Code: Select all

//
void TLC5940_SetGS_And_GS_PWM(void) {
    uint8_t firstCycleFlag = 0;
    if (outputState(VPRG_PIN)) {
        setLow(VPRG_PIN);
        firstCycleFlag = 1;
    }
    uint16_t GSCLK_Counter = 0;
    uint8_t Data_Counter = 0;
    setLow(BLANK_PIN);
    for (;;) {
        if (GSCLK_Counter > 4095) {
            setHigh(BLANK_PIN);
            pulse(XLAT_PIN);
            if (firstCycleFlag) {
                pulse(SCLK_PIN);
                firstCycleFlag = 0;
            }
            break;
        } else {
            if (!(Data_Counter > TLC5940_N * 192 - 1)) {
                if (gsData[Data_Counter])
                    setHigh(SIN_PIN);
                else
                    setLow(SIN_PIN);
                pulse(SCLK_PIN);
                Data_Counter++;
            }
        }
        pulse(GSCLK_PIN);
        GSCLK_Counter++;
    }
}

Posted: **Wed Nov 21, 2018 5:44 pm**

I’d be willing to bet that it’s impossible to generate a pulse that’s narrower than 3nS with a user-space program on the Pi.
Even at 1.4 GHz, that’s only around 4.2 clocks, and there’s going to be way more cycles than that with the function call overhead.

Posted: **Wed Nov 21, 2018 6:02 pm**

@rzusman

That is what I thought, so the problem is not the implementation of pulse I guess?

Posted: **Wed Nov 21, 2018 6:06 pm**

Have you ‘scoped the output? That’s the only way to be sure of the pulse rise time, width, and fall time.

Posted: **Wed Nov 21, 2018 6:08 pm**

At that frequency the latency of the code to change the state of the GPIO pin and the overhead of other taskings should be sufficient delay. I've only ran a GPIO interrupt at 400kHz using Python. The only code in the ISR was an evet trigger, to some code being run on another core and I used semaphores to control traffic.

I, using a Arduino DUE (80MHz) send interrupts to the RPI by setting changing state, without any time delay between state changes. The RPi has no problem with handeling such state changes.

I do not use sleep as a matter of course, that sleep suspends operations is, by me, unacceptable. In your case, if you really really feel you need a delay send out two successive setPinOutHigh and allow code latency to be your delay.

Posted: **Wed Nov 21, 2018 8:55 pm**

rzusman wrote: ↑
Wed Nov 21, 2018 6:06 pm
Have you ‘scoped the output? That’s the only way to be sure of the pulse rise time, width, and fall time.

You'll need a good 'scope to get anywhere near seeing the true shape of a 3 nS pulse.

Raspberry Pi Forums

GPIO pulse in nanoseconds

GPIO pulse in nanoseconds

Re: GPIO pulse in nanoseconds

Re: GPIO pulse in nanoseconds

Re: GPIO pulse in nanoseconds

Re: GPIO pulse in nanoseconds

Re: GPIO pulse in nanoseconds

Re: GPIO pulse in nanoseconds

Re: GPIO pulse in nanoseconds