API command Vs Direct Registry command

Ant Scranney

Hi all,

Firstly I know the direct registry command will be faster, this question probably has no practical usage other than being something I was curious about. I have tried in the past to measure code speed on the C2000 Launchpad, only to find it has 2 hardware break points and this is not enough to use CCS to calculate the clock cycles, see the below post as reference to this:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/330128/1151351.aspx#1151351

So I have used a GPIO pin in the past to turn on and off between code execution points, then used a scope to gauge a rough idea of the code execution time. This has worked quite well for me, and I was then curious if I could measure the difference between a GPIO pin being switched high and low using the API and the direct registry commands (I know what your saying...why?).

So basically I have the clock set-up to run at 60MHz and a timer set to trigger every ~100uS and free run. I have not pasted all the code, just the bits I see as relevant to the test results:

   void main(void)
{
	/***  All my setup code is here before the while loop and just sets-up the timer, interrupt etc ***/
	
	while(1)
    {
	/*** Set the pin low using the direct registry command ***/
	//	EALLOW;
    //	GpioDataRegs.GPACLEAR.bit.GPIO19 = 1;
	//	EDIS;
	
	/*** Set the pin low using the TI API ***/
    GPIO_setLow (myGpio, GPIO_Number_19);
    }
}

interrupt void cpu_timer0_isr(void)
{	
	/*** Set the pin high using the direct registry command ***/
	//	EALLOW;
	//	GpioDataRegs.GPASET.bit.GPIO19       = 1;
	//	EDIS;

	/*** Set the pin high using the TI API ***/
    GPIO_setHigh (myGpio, GPIO_Number_19);

	/*** Clear the interrupt flag ***/
    PIE_clearInt(myPie, PIE_GroupNumber_1);
}

So I then basically just commented out the API command and then the direct registry command and recorded the traces on the scope. I thought I would get a cleaner trace but there seems to be some pulse width fluctuation on the oscilloscope traces, which at this time I am not sure why?

I have tried the GPIO setup with and without the internal pull-ups, and also a combination of nothing connected to the GPIO19, and a 3k3 resistor to ground. All the combinations of which produce the same result, so is this drift in timing expected or is my set-up in error?

Direct Registry Oscilloscope Traces - Lowest pulse width first and highest pulse width second

API Oscilloscope Traces - Lowest pulse width first and highest pulse width second

Cheers,

Ant

over 11 years ago

0 Devin Cottier over 11 years ago

TI__Guru 60865 points

Hi Ant,

My understanding:

The setLow function takes multiple instructions (some read-modify-write or bit packing to GPIO registers and function call overhead). One of those cycles is the actual write to the HW registers which causes the GPIO to go low. There are also some overhead instructions in the looping itself.

When the interrupt returns, it could be at any of those instructions. If it is the one right before the HW write, the GPIO will go low right away. If it is the one right afterwards, it will have to return from the function, check the loop conditions and branch to loop start, re-enter the function, do the bit-packing, and then do the write. You can also have everything in-between, which is why you get the spread of low going times.

0 Ant Scranney over 11 years ago in reply to Devin Cottier

Expert 1275 points

Hi Devin,

Thanks and makes sense, also explains why you see a lesser effect in the direct registry command.

I guess for timing I can use the mean value as a good approximation.

Cheers,

Ant

C2000™︎ microcontrollers

C2000 microcontrollers forum

API command Vs Direct Registry command