LPC MicrocontrollersのトピックRe: mrt 1us resolution

mrt 1us resolution

lpcware — Wed, 15 Jun 2016 20:13:39 GMT

Content originally posted in LPCWare by Spock on Wed Jun 12 13:24:48 MST 2013

Hi,

I just got my LPC800 mini kit and started evaluation.

My target is wireless OneWire fish tank enviromental monitor.

For support OneWire protocol I need 1us timing resolution

I've tried to perform this in following way using mrt following function:

void mrtInit(uint32_t delay)
{
/* Enable clock to MRT and reset the MRT peripheral */
LPC_SYSCON->SYSAHBCLKCTRL |= (0x1<<10);
LPC_SYSCON->PRESETCTRL &= ~(0x1<<7);
LPC_SYSCON->PRESETCTRL |= (0x1<<7);

mrt_counter = 0;
LPC_MRT->Channel[0].INTVAL = delay;
LPC_MRT->Channel[0].INTVAL |= 0x1UL<<31;

LPC_MRT->Channel[0].CTRL = MRT_REPEATED_MODE|MRT_INT_ENA;

/* Enable the MRT Interrupt */

NVIC_EnableIRQ(MRT_IRQn);
return;
}

However passing values less than 60 as a function parameter gives result in not working system.

Above thise value timer works properly and I can see test quare wave on my oscilloscope.

What might be a problem ?

Re: mrt 1us resolution

lpcware — Wed, 15 Jun 2016 20:13:40 GMT

Content originally posted in LPCWare by wmues on Wed Jun 12 14:39:05 MST 2013

The problem is that the interrupt service function is using all available time, if it is called so often.

Trying to get 1us Resolution with Interrupts is hopeless.

You should use the SCT of the LPC800 for the OneWire protocol.

Re: mrt 1us resolution

lpcware — Wed, 15 Jun 2016 20:13:41 GMT

Content originally posted in LPCWare by Spock on Thu Jun 13 06:56:55 MST 2013

Thanks,

I will try with SCT with match configuration.

Re: mrt 1us resolution

lpcware — Wed, 15 Jun 2016 20:13:41 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Tue Aug 20 05:20:18 MST 2013
On all LPCs prior to LPC800 one could simply run one of the 32bit timers with a prescaler of PCLK/1000/1000.
That way, I had a clock with 1us resolution. Each read of the TC got the current time (with a wraparoung of 1.5hours).
When using a 32-bit processor and a 32-bit timer, you simply ignore all carries or overflows if you don't measure differences/delays of hours. t1-t0 is always positive and the time between t1 and t0 in us, provided t1 is later than t0.
For very tight timings, you will have to use busy waits.

But the great engineers at NXP removed such simple timers. Now we have a 31-bit counter (how odd is that), down counters (I can live with that, but why?), and special timer 1, and timer 2, and... special timer xy.
I seem to be the only person on this planet who used to run nearly all timing from T0, free running at 1MHz. Because nobody complained so far.
The MRT is the one I like most after skimming the manual and the SCT is the ONLY timer that can provide me with a full 32-bit but not at a configurable tick period. I can't change clock frequency without changing the meaning of 'time'. Poor design that needs to be compensated for in software.
Please don't get me wrong. I'm not insisting on a huge number of timer bits, I'm insisting on timers having the same number of bits (for counting) as the ALU of the processor.

If I were you I would use MRT with 1024*1024*1024 reload value, free running and implementing 30bit overflow handling logic (sign extending bit 29). That gives you better than us resolution at register read speed.

When I was new to ARM processors, I chose NXP (Philips at that time) because I realized, the engineers have understood that a 32-bit processor works excellently with 32-bit peripherals. Atmel and ST at that time provided 16-bit timers. How stupid was that? A 32-bit processor can read (atomically) a 32-bit timer and they provided 16-bits? Hilarious!
But now I had a closer look at LPC800 and that thing reminds me of Atmel and ST 6 years ago, honestly.

SCT is a big leap forward, the other timers mostly

Re: mrt 1us resolution

lpcware — Wed, 15 Jun 2016 20:13:42 GMT

Content originally posted in LPCWare by MarcVonWindscooting on Sat Dec 28 04:56:15 MST 2013
Not sorry for bringing up this thread again :p

It took some time until I actually implemented my suggestion for a current project. "hr" stands for high resolution. However, instead of sign extending I did a shift left by 2. If I can't get my beloved 1us timer tick then I don't care if its 4*(something else) rather than 1*(something else). htTimer uses MRT channel 3. Delays/time measurements up to 17.5s at least are possible. I prefered to invert hrTimer()'s direction with respect to MRT (counting downwards) because that makes it easier to understand. That inversion costs on instruction, however.
I assume you provide the MRT structure and symbolic constants MEGA,PCLK, with their obvious meanings. And of course switch on the AHB clock and so on...

EDIT: failed to inline the code. Now as an attachment.

Any comments are welcome.

BTW: In my post above, the last word and the full stop got missing. Here they are: " NOT ."

Re: mrt 1us resolution

lpcware — Wed, 15 Jun 2016 20:13:42 GMT

Content originally posted in LPCWare by onkel.jack@t-online.de on Sun Dec 29 03:53:05 MST 2013
Spock,

your problem indeed is you dont have enough CPU cycles to process interrups in 1 us resolution.
I dont know our one wire protocol, but maybe you could "abuse" SPI to generate the required puses at 1 MHz SPI speed.
Use either SCLK to get 8/16 pulses or use MOSI and send the number of bits. i.e. send a 0x07 would give you 3 pulses.