Lpc2000

Hi everyone,
I'm searching for solve a big problem in one of my projects.
We use FreeRTOS in LPC ARM microcontroller and scheduler is called 
by a tick made with Timer0 Compare0.
Unfortunately, Timer0 is configured, by FreeRTOS sources, as reset 
on match Compare0.
Our board has a capture pin on P0.22 (CAP0.0) used to detect level 
duration and we have not to reset Timer0. So we configured Timer0 as 
continuously running and, on Timer0 Match0 interrupt, we reloaded 
new match value on register permitting us to have a periodic tick of 
100 microseconds.
To set the new match value I use following code:

T0MR0 += L_COMPAREMATCH;

where L_COMPAREMATCH is equal to 6000. Doing so, our next tick is
after 71 seconds (that is about 0xFFFFFFFF clock at 60MHz)
If I substitute previous code with:

T0MR0 = T0TC + L_COMPAREMATCH;

our next tick is about after 100 microseconds.
But I cannot use this code, as I will lost tick between match on 
T0MR0-T0TC and recalculation-setting of next compare.

How can I do? I cannot use Timer1 for O.S. tick as it is used for 
other purposes...
Is it possible that between match on Compare0 and write of next 
Compare0, T0TC counts as many ticks as my match value? I tried to 
increment tick value of compare, but nothing, it doesn't work! My 
LPC works at 60MHz as Timer0, so I don't think that it executes about
20 instructions (corresponding to flag check and T0MR0 += 
L_COMPAREMATCH;) in 100 microseconds!!!!

Thank you for your attention
Enrico D.M.
Vicenza - Italy

Quoting gvnn77 <paynet@...>:

> where L_COMPAREMATCH is equal to 6000. Doing so, our next tick is
> after 71 seconds (that is about 0xFFFFFFFF clock at 60MHz)
> If I substitute previous code with:
>
> T0MR0 = T0TC + L_COMPAREMATCH;
>
> our next tick is about after 100 microseconds.
> But I cannot use this code, as I will lost tick between match on
> T0MR0-T0TC and recalculation-setting of next compare.
>
> How can I do? I cannot use Timer1 for O.S. tick as it is used for
> other purposes...
> Is it possible that between match on Compare0 and write of next
> Compare0, T0TC counts as many ticks as my match value? I tried to
> increment tick value of compare, but nothing, it doesn't work! My
> LPC works at 60MHz as Timer0, so I don't think that it executes about
> 20 instructions (corresponding to flag check and T0MR0 +=
> L_COMPAREMATCH;) in 100 microseconds!!!!

Depending on what else you are doing you may be surprised.  Divides are a
particular issue.

Take a look at the timer performance application note at
http://www.aeolusdevelopment.com/Articles/docandapp.html It goes through some
of the things I did to get preditable performance and what the barriers 
to high
speed timing were.

It would be very worthwhile to measure how long both of your routines are
actually taking.  Note that I/O takes multiple cycles.

Robert

> How can I do? I cannot use Timer1 for O.S. tick as it is used for
> other purposes...

Is using the PWM timer a possibility?  It has identical features as the
other timers, just a different base address.


Joel

Sorry, but also PWM timer is used...
I am not able to understand why

T0MR0 += L_COMPAREMATCH;

doesn't work!!! I use other micro, such as Texas MSP430, and this 
implementation work well! Is there a bug in micro or I have to do 
something before read/write T0MR0???
Thank you
Enrico
--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@...> wrote:
>
> > How can I do? I cannot use Timer1 for O.S. tick as it is used for
> > other purposes...
> 
> Is using the PWM timer a possibility?  It has identical features as 
the

> other timers, just a different base address.
> 
> 
> Joel
>

> I am not able to understand why
> 
> T0MR0 += L_COMPAREMATCH;
> 
> doesn't work!!! I use other micro, such as Texas MSP430, and this
> implementation work well! Is there a bug in micro or I have to do
> something before read/write T0MR0???

Hmm, I'm doing this on a LPC2148 with no problem:

T0MR0 += SAMPLE_INTERVAL;

Did you check the assembler output?


Joel

At 09:53 AM 2/21/2006 +0000, gvnn77 wrote:
>Sorry, but also PWM timer is used...
>I am not able to understand why
>
>T0MR0 += L_COMPAREMATCH;
>
>doesn't work!!! I use other micro, such as Texas MSP430, and this
>implementation work well! Is there a bug in micro or I have to do
>something before read/write T0MR0???

It seems more likely to me that you have got an unexpected source of 
latency in your system somewhere (another interrupt perhaps?).  Can you set 
it up to toggle a pin on match using one of the EMR registers?  If you do 
that and toggle a pin on entry to your ISR you can get a direct measurement 
of your latency.  This is where a DSO or logic analyzer really pays off, 
you can get easy measurements of the range of latencies and even trigger on 
the difference between the edges.  However, even an analog 'scope should 
give you a start, it just won't help you with the rare event nearly as much.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@...> wrote:
>
> > I am not able to understand why
> > 
> > T0MR0 += L_COMPAREMATCH;
> > 
> > doesn't work!!! I use other micro, such as Texas MSP430, and this
> > implementation work well! Is there a bug in micro or I have to do
> > something before read/write T0MR0???
> 
> Hmm, I'm doing this on a LPC2148 with no problem:
> 
> T0MR0 += SAMPLE_INTERVAL;
> 
> Did you check the assembler output?
> 
> 
> Joel
>

Source code is:
void vPortPreemptiveTick( void )
{
	#if portPRESCALE_VALUE != 0
		#define L_COMPAREMATCH (configCPU_CLOCK_HZ / 
configTICK_RATE_HZ) / portPRESCALE_VALUE
	#else
		#define L_COMPAREMATCH (configCPU_CLOCK_HZ / 
configTICK_RATE_HZ)
	#endif

	if (T0IR & BIT(0))
	{

    T0MR0 += L_COMPAREMATCH;

		/* Increment the tick counter. */
		vTaskIncrementTick();

		/* The new tick value might unblock a task.  Ensure 
the highest task that
		is ready to execute is the task that will execute 
when the tick ISR
		exits. */
		vTaskSwitchContext();

		/* Ready for the next interrupt. */
		T0IR = portTIMER_MATCH_ISR_BIT;
	}
	extern void vTmr0Cr0_Isr(void);
	if (T0IR & BIT(4))
	{
		vTmr0Cr0_Isr();
		T0IR = BIT(4);
	}
	VICVectAddr = portCLEAR_VIC_INTERRUPT;
}

L_COMPAREMATCH is equal to 0x1770. Checking assembler code, it seems 
correct.

Assembler generated code is:
vPortPreemptiveTick:
        PUSH        {LR}
        CFI ?RET Frame(CFA, -4)
        CFI CFA R13+4
        LDR         R0,??vPortPreemptiveTick_0  ;; 0xe0004000
        LDR         R0,[R0, #+0]
        LSL         R0,R0,#+0x1F
        BPL         ??vPortPreemptiveTick_1
        LDR         R0,??DataTable4    ;; 0xe0004018
        LDR         R1,??DataTable4    ;; 0xe0004018
        LDR         R1,[R1, #+0]
        LDR         R2,??DataTable3    ;; 0x1770
        ADD         R1,R1,R2
        STR         R1,[R0, #+0]
        _BLF        vTaskIncrementTick,vTaskIncrementTick??rT
        _BLF        vTaskSwitchContext,vTaskSwitchContext??rT
        LDR         R0,??vPortPreemptiveTick_0  ;; 0xe0004000
        MOV         R1,#+0x1
        STR         R1,[R0, #+0]
??vPortPreemptiveTick_1:
        LDR         R0,??vPortPreemptiveTick_0  ;; 0xe0004000
        LDR         R0,[R0, #+0]
        LSL         R0,R0,#+0x1B
        BPL         ??vPortPreemptiveTick_2
        _BLF        vTmr0Cr0_Isr,vTmr0Cr0_Isr??rT
        LDR         R0,??vPortPreemptiveTick_0  ;; 0xe0004000
        MOV         R1,#+0x10
        STR         R1,[R0, #+0]
??vPortPreemptiveTick_2:
        LDR         R0,??vPortPreemptiveTick_0+0x4  ;; 0xfffff030
        MOV         R1,#+0
        STR         R1,[R0, #+0]
        POP         {R0}
        BX          R0                 ;; return
        DATA
??vPortPreemptiveTick_0:
        DC32        0xe0004000
        DC32        0xfffff030
        CFI EndBlock cfiBlock7

Have you checked if interval tick is regular and corrected? Can you 
give me Timer0 settings??? Thank you in advance!
Enrico

At 08:05 AM 2/23/06 +0000, gvnn77 wrote:
>--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@...> wrote:
> >
> > > I am not able to understand why
> > >
> > > T0MR0 += L_COMPAREMATCH;
> > >
> > > doesn't work!!! I use other micro, such as Texas MSP430, and this
> > > implementation work well! Is there a bug in micro or I have to do
> > > something before read/write T0MR0???
> >
> > Hmm, I'm doing this on a LPC2148 with no problem:
> >
> > T0MR0 += SAMPLE_INTERVAL;
> >
> > Did you check the assembler output?
> >
> >
> > Joel
> >
>
>Source code is:

Have you verified your interrupt latency yet? See my earlier post if not.

Like Joel I'm using similar code w/o any issues.  I really think you need 
to verify that your interrupt latency is reasonable.  If you latency is 
longer than you expect then you will see exactly the behaviour you have 
described.

If you do find out it is unexpectedly long you can determine why but you do 
need to find out if it could be an issue first.  Running off after other 
issues without verifying may just cause you to burn a lot of time to no 
good purpose.  Unless of course you enjoy the frustration ;) but then I 
guess you wouldn't be asking for suggestions.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> 
wrote:
>
> At 08:05 AM 2/23/06 +0000, gvnn77 wrote:
> >--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@> wrote:
> > >
> > > > I am not able to understand why
> > > >
> > > > T0MR0 += L_COMPAREMATCH;
> > > >
> > > > doesn't work!!! I use other micro, such as Texas MSP430, and 
this
> > > > implementation work well! Is there a bug in micro or I have 
to do
> > > > something before read/write T0MR0???
> > >
> > > Hmm, I'm doing this on a LPC2148 with no problem:
> > >
> > > T0MR0 += SAMPLE_INTERVAL;
> > >
> > > Did you check the assembler output?
> > >
> > >
> > > Joel
> > >
> >
> >Source code is:
> 
> Have you verified your interrupt latency yet? See my earlier post 
if not.
> 
> Like Joel I'm using similar code w/o any issues.  I really think 
you need 
> to verify that your interrupt latency is reasonable.  If you 
latency is 
> longer than you expect then you will see exactly the behaviour you 
have 
> described.
> 
> If you do find out it is unexpectedly long you can determine why 
but you do 
> need to find out if it could be an issue first.  Running off after 
other 
> issues without verifying may just cause you to burn a lot of time 
to no 
> good purpose.  Unless of course you enjoy the frustration ;) but 
then I 
> guess you wouldn't be asking for suggestions.
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,   be 
> they legal, genetic, or physical.  If you don't believe me, try to 
chew a 
> radio signal. "  -- Kelvin Throop, III
> http://www.aeolusdevelopment.com/
>

Hi,
about interrupt latency, I tried to set L_COMPAREMATCH as big as my 
tick will be greater than 1 millisecond without interesting result. 
And I think that my interrupt latency is smaller than 1 millsecond...
What do you think?
Thank you
Enrico

At 08:10 AM 2/27/06 +0000, gvnn77 wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...>
>wrote:
> >
> > At 08:05 AM 2/23/06 +0000, gvnn77 wrote:
> > >--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@> wrote:
> > > >
> > > > > I am not able to understand why
> > > > >
> > > > > T0MR0 += L_COMPAREMATCH;
> > > > >
> >
> > Have you verified your interrupt latency yet? See my earlier post
>if not.
> >
> > Like Joel I'm using similar code w/o any issues.  I really think
>you need
> > to verify that your interrupt latency is reasonable.  If you
>latency is
> >
>
>Hi,
>about interrupt latency, I tried to set L_COMPAREMATCH as big as my
>tick will be greater than 1 millisecond without interesting result.
>And I think that my interrupt latency is smaller than 1 millsecond...
>What do you think?

I think you need to measure it if possible.  It's quite possible to get 
latencies all the way up to infinity.  You can get an infinite latency by 
ending up in an infinite loop with interrupts disabled or by turning off 
the interrupt source.  I can certainly imagine errors that could give you a 
latency > 1mS. Even if you end up not having an latency issue knowing what 
your latency is and how it varies is useful.  A few minutes looking at the 
waveforms from such a measurement can yield a lot of insight into what's 
going on.

In the really hard cases tracking this sort of thing down you want to use 
the waveforms used to measure latency to trigger a trace unit of some sort 
so that you can look at the last ms or so worth on instructions.  Hopefully 
you don't need that kind of horsepower.

Latency might not be the issue but without doing some sort of measurement 
of it you just don't know.

BTW a simple check in your interrupt to raise a flag if the timer is beyond 
your match point would give you some check on this as well.  It's not 
foolproof but it's something.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/