GPIO pulse in nanoseconds

[DuBBox]

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?

[Idahowalker]

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.

[DuBBox]

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++;
    }
}

[rzusman]

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.

[DuBBox]

@rzusman

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

[rzusman]

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

[Idahowalker]

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.

[drgeoff]

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.