This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/LAUNCHXL-CC1350: PIN driver transition timing

Part Number: LAUNCHXL-CC1350

Tool/software: TI-RTOS

Hello:

I have a phototransistor measuring the output of an IR LED at 5 second intervals. The instruction sequence for this process is as follows:

1) Open Pin driver

2) raise pin high that drives the IRLED

3) Task_sleep ( 500 );//clock interval is set to 10 uS

4) Open ADC driver

5) Take measurement

6) Lower Pin driving LED

7) close ADC driver

8) close Pin driver

The reason for the Task_sleep() is that I don't get a reasonable reading without the delay (this value was determine through trial and error experimentation). Does the PIN driver have a slow transition time, perhaps to minimize any ringing that could interfere with the RF? Unfortunately, I do not have a scope to measure this and the datasheet did not mention any pin transition timing.

I don't view this as a deal breaker for my application, but I an curious as to what might be driving the requirement to include the delay.

Thank you,

Michael

  • Hi Michael

    There is no direct transition time related to the PIN driver itself, there is a small amount of checking if you use the PIN_setOutputValue() API but that is nothing that should be noticeable in this case as opening the ADC driver also takes a while. You could try using PINCC26XX_setOutputValue() API straight away, this is basically a direct hardware register write and is more efficient then the first one.

    What is the configuration of the PIN you are using to drive the IRLED?
  • Here is the code in question:

        const PIN_Config LEDs[] =
        {
             Board_DIO22 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,       /* LED initially off             */
             PIN_TERMINATE
        };

    //    PIN_open( &ledGroup1, LEDs );



        while(1)
        {

            Semaphore_pend( flashLEDSem, BIOS_WAIT_FOREVER );

            PIN_open( &ledGroup1, LEDs );

            //Turn IR LED on
            PIN_setOutputValue( &ledGroup1, Board_DIO22, 0x01 );

            //Give the LED a chance to turn on
            Task_sleep(500);


            //Perform conversion
            adc = ADC_open( Board_ADC0, &params );

            if (adc == NULL)
            {
                sendMessage( &uart, "ADC error", 9 );
                while (1);
            }

            res = ADC_convert( adc, &adcValue0 );

            //Turn IR LED off
            PIN_setOutputValue( &ledGroup1, Board_DIO22, 0x00 );

            ADC_close(adc);
            PIN_close( &ledGroup1 );

    .

    .

    .

    .

  • Two things:
    - The LED is connected to a IO with normal driver strength (4 mA). How much does the LED source?
    - Does the LED itself have any turn on time?
  • I have torn that circuit apart now but might be revisiting it in a bit. If so, I'll check the current is within spec. But, I believe the IRLED was wired so that the port was the current sink, not the source. I couldn't find any spec in the datasheet for maximum current sink per pin, so I assumed it would be ok for the LED load. I *think* the LED resistors were 2 x 100 Ohm for a series resistance of 9.5 mA. This is all speculation (from memory) though.

    With respect to LED turn on time, this is an old Radio Shack part I had lying around from a couple of years ago. I don't have a datasheet for it. However, I did Google it at the time and one of the sources at the top mention that (generically speaking) IR LEDs should have single digit nanosecond turn on time due to their physics. Even the phospher driven LEDs were much less than delay mentioned above.

    So, I don't know...like I said, it's not an issue for me since the circuit that this issue is associated with is an alarm circuit...so timing isn't critical. Let's close this issue and file it under "huh...that's odd." since I no longer have that circuit constructed.

  • It would have been interesting to look at this with a scope. If you get the chance when revisiting this again to scope the signals that would have been perfect.

    I'll mark this as "TI thinks resolved" for now to put the thread to rest as a ""huh...that's odd." case.