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.

uSec precise timing in RTOS

Dear Community.

I am implementing oneWire timing in RTOS environment. My problem is how to implement precise timing? The board I am using is TivaC launchpad. You know in 1Wire the uC needs to issue different timing slots for reading and writing bits.

// Delay values in usec unit
#define OW_A_DELAY 6
#define OW_B_DELAY 64
#define OW_C_DELAY 60
#define OW_D_DELAY 10
#define OW_E_DELAY 9
#define OW_F_DELAY 55
#define OW_G_DELAY 0
#define OW_H_DELAY 480
#define OW_I_DELAY 70
#define OW_J_DELAY 410

Seaching for reliable answer and tried most of them without success. 

This answer is quite good: 

but I need a little help to get my code more efficient:

Here is my code:

static void DELAY_us(uint32_t usec)
{
	uint32_t end;
	uint32_t start = Timestamp_get32();

	Float target = (Float)usec / OW_USEC_PER_CYCLE;
	Float result;

	while(1)
	{
		end = Timestamp_get32();
		result = end-start;
		if( result >= target )
		{
			result = result;
			break;

		}
	}

}

Sometimes the function provides accurate timing but sometimes doesn't. The result is much more greater than target.

However I have a much more bigger problem this one. 

There are my function for 1Wire:

//--------------------------------------------------------------------------
// Setting this bit to 0 drives the 1-Wire line low
static void OW_SetLineLow()
{

	GPIOPinTypeGPIOOutput(OW_PORT,OW_PIN);
	GPIOPinWrite(OW_PORT,OW_PIN,false);

	//GPIO_setAsOutputPin(OW_PORT,OW_PIN);
	//GPIO_setOutputLowOnPin(OW_PORT,OW_PIN);
}

//--------------------------------------------------------------------------
// Setting the bit to 1 releases the 1-Wire to be pulled up by resistor or pulled down by a 1-Wire device
static void OW_SetLineRelease()
{
	GPIOPinTypeGPIOInput(OW_PORT,OW_PIN);
}

The commented statements were used in MSP430, and works very fast. The issue with above function is the execution time. Changing the GPIO direction takes so long. About 5usec or more. I did not realize such long execution with MSP430.

Is there any more efficient way in RTOS?

Update: For precise timing I have create a Timer in RTOS and toggled a LED in SWI to measure the accuracy of the timer. It was very accurate as I expected, however when I post a Semaphore to start the execution of the blocked task, ( and toggle the LED in the task)  it was very very inaccurate. This timing advice was found in the forum.

I think I am using something wrong. Please point me to the right direction to solve this timing problem.

Thank you very much.

  • Hey,

    It seems nobody read this forum or thread. :( I would be very grateful if  someone reply to me.

    I have searched for ROM_SysCtlDealy() but this function is not accessible in the RTOS  project. I found this call in a pure TivaWare lib, but it doesn't help. I made a trial with SysCtlDelay() but the outcome is the same as here: 

    I found the MAP_SysCtlDelay() function - not accurate!!!! 

    Could someone tell me how to make a precise timing in RTOS? or why I can not find the ROM_SysCtlDelay() function?

  • Hi Daniel,

    Which version of TI-RTOS are you using?  I am guessing you started by modifying an example/empty project? Which?  

    TI-RTOS Driver example projects have access to TivaWare (our drives require it).  You can use the ROM_SysCtlDelay() API by adding the following to your source files:

    #include <driverlib/rom.h>
    #include <driverlib/rom_map.h>

    You will also have to add "TARGET_IS_TM4C123_RA1" to the compiler symbols.  Please see the "Using the ROM" section of the DriverLib User's Guide for more details about using ROM APIs.

    As for switching a GPIO to input/output, I am surprised it is taking 5us to make the change.  Unfortunately, there is no means in TI-RTOS to do this besides TivaWare APIs.  You may want to try writing directly to the HW registers.

    Regards,

    -- Emmanuel

  • Dear Emmanuel,

    Sorry for my late reply.  As you suggested I made the following includes and defines:

    #define TARGET_IS_TM4C123_RA1
    #include <driverlib/rom.h>
    #include <driverlib/rom_map.h>
    #include <driverlib/sysctl.h>
    

    And I had to set the XDCToolsVersion to 3.31.1.33. Now I can make the ROM call. 

    I have not tested the precision yet but I hope it works as expected. ( Precision: I read some threads about the ROM version is much more precise than the non ROM version. 

    Well, Thank you for your help!