topic Re: Trouble in understanding function inside library in LPCXpresso IDE

Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:35 GMT

Content originally posted in LPCWare by mngeowcy on Sat Apr 04 09:02:33 MST 2015
Hi ,

I'm doing a school project where I am required to use a temperature sensor to printf out the current temperature detected by the sensor. The problem is that the function takes too long , causing an inevitable delay. I wanted to try to edit the function inside the library but I'm not able to understand the code. Was hoping to get some help here.

The function in the library is as follows :

int32_t temp_read (void)
{
    uint8_t state = 0;
    uint32_t t1 = 0;
    uint32_t t2 = 0;
    int i = 0;

    /*
     * T(C) = ( period (us) / scalar ) - 273.15 K
     *
     * 10T(C) = (period (us) / scalar_div10) - 2731 K
     */

    state = GET_TEMP_STATE;

    /* get next state change before measuring time */
    while(GET_TEMP_STATE == state);
    state = !state;

    t1 = getTicks();

    for (i = 0; i < NUM_HALF_PERIODS; i++) {
        while(GET_TEMP_STATE == state);
        state = !state;
    }

    t2 = getTicks();
    if (t2 > t1) {
        t2 = t2-t1;
    }
    else {
        t2 = (0xFFFFFFFF - t1 + 1) + t2;
    }


    return ( (2*1000*t2) / (NUM_HALF_PERIODS*TEMP_SCALAR_DIV10) - 2731 );
}

These are the definitions :

#define TEMP_TS1 0
#define TEMP_TS0 0

#if TEMP_TS1 == 0 && TEMP_TS0 == 0
#define TEMP_SCALAR_DIV10 1
#define NUM_HALF_PERIODS 340
#elif TEMP_TS1 == 0 && TEMP_TS0 == 1
#define TEMP_SCALAR_DIV10 4
#define NUM_HALF_PERIODS 100
#elif TEMP_TS1 == 1 && TEMP_TS0 == 0
#define TEMP_SCALAR_DIV10 16
#define NUM_HALF_PERIODS 32
#elif TEMP_TS1 == 1 && TEMP_TS0 == 1
#define TEMP_SCALAR_DIV10 64
#define NUM_HALF_PERIODS 10
#endif


#define P0_6_STATE ((GPIO_ReadValue(0) & (1 << 6)) != 0)
#define P0_2_STATE ((GPIO_ReadValue(0) & (1 << 2)) != 0)


#ifdef TEMP_USE_P0_6
#define    GET_TEMP_STATE P0_6_STATE
#else
#define    GET_TEMP_STATE P0_2_STATE
#endif

Note that the library does contain other functions as well , so not all the defined terms will be used.

I have also looked at the datasheet ( http://datasheets.maximintegrated.com/en/ds/MAX6576-MAX6577.pdf ) of the temperature sensor , the general descriptions of how it works is :

Quote:

Figure 3 shows a quick-look application circuit for the
MAX6576 using a universal counter measuring period.
TS1 and TS0 are both tied to ground to select a scalar
multiplier of 10μs/°K. The MAX6576 converts the ambient
temperature into a square wave with a period that is
10 times the absolute temperature of the device in μs.
At room temperature, the universal counter will display
approximately 2980μs

I understand the code up to the line " state = GET_TEMP_STATE; " , I'm lost after that point.

Thank you and sorry for the trouble.

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:37 GMT

Content originally posted in LPCWare by R2D2 on Sat Apr 04 10:22:38 MST 2015

Quote: mngeowcy
I understand the code up to the line " state = GET_TEMP_STATE; " , I'm lost after that point.

Then it's time to start the debugger and investigate :)

Obviously this code is measuring a pulse time from the sensor...

First of all find out how this pulse time is measured...

BTW: Instead using an external interrupt & timer you can use a capture timer :O

Sample: #9 of

http://www.lpcware.com/content/forum/lpc1769-capture-timer

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:37 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 01:51:29 MST 2015

Quote: R2D2

Quote: mngeowcy
I understand the code up to the line " state = GET_TEMP_STATE; " , I'm lost after that point.

Ok I've gone ahead and disected the code. I'm able to roughly get an idea of what the code is doing , it's just measuring changes in the state of the pin , when the state of the pin goes from 0 to 1 and back to 0 again , that is one pulse , or in other words half a period of a 50% duty cycle square waveform. I can also see that what causes the delay is probably the for loop that loops until NUM_HALF_PERIODS is reached. I'm still slightly unclear about this segment of the code , my guess on this segment is that it's take the average of a large sample size of many pulse times( or half periods ) to get a good estimate of the value. But why is the NUM_HALF_PERIODS defined as 320 ? Is there a reason why it should be set at this value? or is it just to get a large enough sample size. I can see under the initial definitions also that when the scalar multiplier is increased , the NUM_HALF_PERIODS defined is reduce to a smaller number. Not sure why this is so , or if there's a relation between the 2 that I'm not seeing.

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:38 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 04:29:07 MST 2015
I think the author of this code was trying to get a temperature value from his measured pulse time. Probably he was just changing NUM_HALF_PERIODS until the temperature value was halfway correct :O
And probably his time base (ticks) had also a different frequency...

Anyway, there are several options to measure a pulse with LPC1769. Of course it's not very elegant to wait until a half period is measured (in this case > 3ms) as in your sample :((

A better way is to use a capture timer which is generating an interrupt :)

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:39 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 07:17:54 MST 2015

Quote: R2D2
I think the author of this code was trying to get a temperature value from his measured pulse time. Probably he was just changing NUM_HALF_PERIODS until the temperature value was halfway correct :O
And probably his time base (ticks) had also a different frequency...

Anyway, there are several options to measure a pulse with LPC1769. Of course it's not very elegant to wait until a half period is measured (in this case > 3ms) as in your sample :((

A better way is to use a capture timer which is generating an interrupt :)

I'm still unclear , NUM_HALF_PERIODS doesn't seem to be changing , assuming that pins TS0 and TS1 are fixed connections. I'm still unsure what the for loop is doing. The time base is set to 1milisecond. So my guess is that the for loop estimates the time taken for 340 half periods , and takes the average multiplied by 2 to get the best estimate for 1 period.

Also , I've tried looking through the user guide for a capture timer but couldn't find anything.

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:39 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 07:38:47 MST 2015

Quote: mngeowcy
I'm still unclear , NUM_HALF_PERIODS doesn't seem to be changing , assuming that pins TS0 and TS1 are fixed connections. I'm still unsure what the for loop is doing. The time base is set to 1milisecond. So my guess is that the for loop estimates the time taken for 340 half periods , and takes the average multiplied by 2 to get the best estimate for 1 period.

I don't know, what 'getTicks()' is doing in detail, but probably it's reading a counter :quest:

If that counter is counting 1ms ticks, it's of course far too slow :((

Your sensor is generating a pulse around 3000 µs, with 10us/°K. So your timer should count with a time base of 1µs or 10µs ;-)

Quote: mngeowcy
Also , I've tried looking through the user guide for a capture timer but couldn't find anything.

User manual:

Quote:

21.6.9 Capture Registers (CR0 - CR1)...

Sample: #9 of http://www.lpcware.com/content/forum/lpc1769-capture-timer

should show, how Capture is working...

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:40 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 07:51:37 MST 2015

Quote: R2D2

Quote: mngeowcy
Also , I've tried looking through the user guide for a capture timer but couldn't find anything.

User manual:

Quote:

21.6.9 Capture Registers (CR0 - CR1)...

Sample: #9 of http://www.lpcware.com/content/forum/lpc1769-capture-timer

should show, how Capture is working...

getTicks() is just returning the value of a counter that increments every 1ms. Btw how did you know that my sensor is generating a pulse of 3000 µs? Also , will speeding up the clock cause the reading to be more inaccurate ?

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:41 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 08:06:51 MST 2015

Quote: mngeowcy
getTicks() is just returning the value of a counter that increments every 1ms.

:D

And do you think that's fast enough for your sensor output?

Quote: mngeowcy
Btw how did you know that my sensor is generating a pulse of 3000 µs? Also , will speeding up the clock cause the reading to be more inaccurate ?

Sensor datasheet is talking about output of 10*T in µs (TS1=0, TS0=0) :O

So at 0°C that should be 273°K * 10µs/°K = 2730 µs, right :quest:

Not sure what you are trying to measure, but with a 1ms counter your resolution isn't very high...

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:42 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 08:17:07 MST 2015

Quote: R2D2

Quote: mngeowcy
getTicks() is just returning the value of a counter that increments every 1ms.

:D

And do you think that's fast enough for your sensor output?

Quote: mngeowcy
Btw how did you know that my sensor is generating a pulse of 3000 µs? Also , will speeding up the clock cause the reading to be more inaccurate ?

Quote:
10*T in µs (TS1=0, TS0=0)

What is T referring to here?

Quote:
So at 0°C that should be 273°K * 10µs/°K = 2730 µs

I get this part , so at higher temperatures there will be a longer period which means a longer delay?

Also , the final result returns 10 times the value of the temp , by is the returned value multiplied by another 100 in the function ?

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:43 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 08:34:12 MST 2015

Quote: mngeowcy
I get this part , so at higher temperatures there will be a longer period which means a longer delay?

At 30°C = 303°K that's 3030µs, just 300µs longer.

The delay is caused because you wait until a new half period is starting before you measure it :O

So you have a delay somewhere between a half period and a full period |(

Therefore capture timers are used to measure times in interrupts without waiting for something...

Quote: mngeowcy
Also , the final result returns 10 times the value of the temp , by is the returned value multiplied by another 100 in the function ?

I dont know what the author of this code is trying to do there...
Usually I'm writing my own code and using the features of the chip :)

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:44 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 08:43:47 MST 2015

Quote: R2D2

Quote: mngeowcy
I get this part , so at higher temperatures there will be a longer period which means a longer delay?

Quote: mngeowcy
Also , the final result returns 10 times the value of the temp , by is the returned value multiplied by another 100 in the function ?

I dont know what the author of this code is trying to do there...
Usually I'm writing my own code and using the features of the chip :)

Thanks for your help so far. I feel like I'm very close to optimizing the code. Just one last question. How does the function depend on how long it takes to increment my counter? I'm unable to see any dependance on it.

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:44 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 09:09:15 MST 2015

Quote: mngeowcy
Thanks for your help so far. I feel like I'm very close to optimizing the code. Just one last question. How does the function depend on how long it takes to increment my counter? I'm unable to see any dependance on it.

How does your counter work?

If your time base is 1µs, your counter must be fast enough to count.

If your main clock is 100Mhz, there are 100 cycles to execute code.
That's not much if you try to use SysTick and an interrupt handler for every 1µs :((

So you have to use a faster counter :)

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:45 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 11:04:17 MST 2015

Quote: R2D2

For my code, my main clock is 100MHz. But I've divided it by 1000 to make it such that it enters the systick handler every 1ms. The systick handler just increments a global variable msTicks. The geticks() function defined inside the temp_read() function just retrieves the current value of msTicks. So if I were to use a faster counter I could always divide my main clock by 1000*1000 to make the code enter the systick handler every 1µs.

What I'm trying to figure out now is exactly which line of code in the temp_read() function depends on the systick timer that I've set. t1=geticks(); just retrieves the value of msTicks. I've also observed that it's mainly the for loop that causes the long delay , I've observed it to be out 500ms. So reducing that delay will ultimately make the function process faster.

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:46 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 11:25:21 MST 2015

Quote: mngeowcy
For my code, my main clock is 100MHz. But I've divided it by 1000 to make it such that it enters the systick handler every 1ms. The systick handler just increments a global variable msTicks.

And that's the weakness (or at least one weakness) of your code :(

If you are triggering an interrupt with 1MHz your chip is busy with jumping to that interrupt handler, executing this handler and returning :((

Therefore it's not useful to use this mechanism for fast counting :O

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:47 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 11:29:18 MST 2015

Quote: R2D2

Dang , my entire code is written based on that logic. I think it would be too late to change it now. So I guess to only way to reduce the delay of temp_read(); would be to use capture timers? Is it possible for you to give me a brief explanation of what capture timers are and why they would be better for the temp_read() function? Or at least drop a few hints :)

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:47 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 11:44:49 MST 2015

Quote: mngeowcy
Or at least drop a few hints :)

A capture timer is a timer which has a special cature input to trigger an interrupt.

In your case: a rising or falling edge is triggering an interrupt. Meanwhile the timer is running and counting the time between this interrupts. This time is stored in a special register, the capture register.

So this approch can measure the full period of your sensor output. The interrupt is triggered every 3ms and delivering the period time.

If you now want to read the temperature you can just use the last period time and calculate the temperature.

No delay :)

That should be doable with about 12 lines of code :O

I'm trying to find a capture sample here at the moment and I think I can post an example in a few minutes 8-)

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:48 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 11:57:24 MST 2015

Quote: R2D2

Quote: mngeowcy
Or at least drop a few hints :)

I think I get what you mean. So this timer counts the period between interrupts concurrently with the program , as such , there is no need for the code to get stuck in a for loop , resulting in no delay. So to code this, all I would have to do is program the interrupt to occur whenever there is a state change. Then inside the interrupt handler I'll just get the current value of the timer. So subtracting the 2 different times at 2 different intervals gives me the period exactly , thus giving me the exact period time of 3ms. Am I on the right track ?

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:48 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 12:03:13 MST 2015

Quote: mngeowcy
Am I on the right track ?

Yes, and if you reset the timer inside the interrupt handler, capture register is storing the period time :)

No subtraction required :O

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:49 GMT

Content originally posted in LPCWare by mngeowcy on Sun Apr 05 12:08:05 MST 2015

Quote: R2D2

Quote: mngeowcy
Am I on the right track ?

Yes, and if you reset the timer inside the interrupt handler, capture register is storing the period time :)

No subtraction required :O

Thanks alot! I'll go check it out after class tmr. You've really helped me a great deal.

Re: Trouble in understanding function inside library

lpcware — Thu, 16 Jun 2016 00:11:50 GMT

Content originally posted in LPCWare by R2D2 on Sun Apr 05 12:14:49 MST 2015
[u]Part 1:[/u]

This function is setting P1.26 as capture input. Timer 0 is runnung with default speed (100MHz / 4), so a prescaler of 25 is generating a time base of 1µs. A rising edge is triggering Timer0 interrupt....

//init CAP0.0 / P1.26 to capture with 1µs
void init_Capture(void)
{
 LPC_PINCON->PINSEL3 |= (3<<20);    //Setup P1.26 as CAP0.0
 LPC_TIM0->PR = (25-1);//1 µs at 100MHz/4
//Note: reset values of timer registers are 0, so setting them isn't necessary
 LPC_TIM0->CCR =((1<<0)|(1<<2));   //capture rising edge with interrupt
 LPC_TIM0->TCR = 1;                //start timer
 NVIC_EnableIRQ(TIMER0_IRQn);
}

Unfortunately P2.5 is no capture input, so you have to connect P1.26 to your sensor output...