navman wrote:> Hi, > I'm trying to counter some pulses (2-10usec width) using the LPC1768 > Cortex-M3 microcontroller. There are 2 channels on which I have count the > pulses on. I have to allow only pulses that are >=2us pulse width (so we > cannot simply use the counter function). > > But it is turning out to be an incredibly difficult feat to achieve this on > a 100MHz Cortex-M3. The problem arises when we try to measure the pulse > width to allow only pulses lasting 2us or higher. We are trying to use a > capture pin and the capture interrupt. First we set it for a falling edge > and capture the timer value, then set it to rising edge and again capture > the timer value. Then take the difference between two values to see if it >> 2usec. But the processing itself is taking over 6-8usec. We also tried > simply using a external interrupt & reading timer registers with each edge, > but with the same results. > > We cannot seem to understand how or why the processing is taking so long > there are hardly 3-4 "C" statements in the interrupt routine (change edge > of capture, take the difference in captured values and compare if it is >> =2us). Any ideas how this feat could be accomplished on a LPC1768? >I don't know this part, but timer-capture hardware I've seen usually uses the peripheral clock to "filter" out short pulses. Can you lower the peripheral clock to the 1 or 2 MHz range and let the hardware synchronizer do all the work? Obviously, if you have other peripherals that need a higher clock, this wouldn't work, but the core could continue to run at 100MHz. just an off-the-wall idea, Bob
pulse counter using LPC1768 proving to very challenging
Started by ●June 7, 2011
Reply by ●June 7, 20112011-06-07
Reply by ●June 7, 20112011-06-07
navman wrote:> Hi, > I'm trying to counter some pulses (2-10usec width) using the LPC1768 > Cortex-M3 microcontroller. There are 2 channels on which I have count the > pulses on. I have to allow only pulses that are >=2us pulse width (so we > cannot simply use the counter function).[...] Put a capacitor to the ground on the interrupt pin. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●June 7, 20112011-06-07
On Jun 7, 8:16=A0am, "navman" <naveen_pn@n_o_s_p_a_m.yahoo.com> wrote:> Hi, > I'm trying to counter some pulses (2-10usec width) using the LPC1768 > Cortex-M3 microcontroller. There are 2 channels on which I have count the > pulses on. I have to allow only pulses that are >=3D2us pulse width (so w=e> cannot simply use the counter function). =A0 > > But it is turning out to be an incredibly difficult feat to achieve this =on> a 100MHz Cortex-M3. The problem arises when we try to measure the pulse > width to allow only pulses lasting 2us or higher. We are trying to use a > capture pin and the capture interrupt. First we set it for a falling edge > and capture the timer value, then set it to rising edge and again capture > the timer value. Then take the difference between two values to see if it= >2usec. But the processing itself is taking over 6-8usec. We also tried > > simply using a external interrupt & reading timer registers with each edg=e,> but with the same results. > > We cannot seem to understand how or why the processing is taking so long > there are hardly 3-4 "C" statements in the interrupt routine (change edge > of capture, take the difference in captured values and compare if it is > > >=3D2us). Any ideas how this feat could be accomplished on a LPC1768? > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.EmbeddedRelated.comanother option might be to use a sync serial port running continuously as a sampling engine and then run filtering over the captured stream of bits.
Reply by ●June 7, 20112011-06-07
On 6/7/2011 6:16 AM, navman wrote:> Hi, > I'm trying to counter some pulses (2-10usec width) using the LPC1768 > Cortex-M3 microcontroller. There are 2 channels on which I have count the > pulses on. I have to allow only pulses that are>=2us pulse width (so we > cannot simply use the counter function). > > But it is turning out to be an incredibly difficult feat to achieve this on > a 100MHz Cortex-M3. The problem arises when we try to measure the pulse > width to allow only pulses lasting 2us or higher. We are trying to use a > capture pin and the capture interrupt. First we set it for a falling edge > and capture the timer value, then set it to rising edge and again capture > the timer value. Then take the difference between two values to see if it >> 2usec. But the processing itself is taking over 6-8usec. We also tried > simply using a external interrupt& reading timer registers with each edge, > but with the same results. > > We cannot seem to understand how or why the processing is taking so long > there are hardly 3-4 "C" statements in the interrupt routine (change edge > of capture, take the difference in captured values and compare if it is >> =2us). Any ideas how this feat could be accomplished on a LPC1768? > > > --------------------------------------- > Posted through http://www.EmbeddedRelated.comSomething seems wrong there. I've got an application where I use an LPC1758 to close a fairly complex PI loop controller. I've only got the clock turned up to 52 MHz, and I'm able to execute a printed page worth of ISR in only about 2us. A) Everyone who's told you to look at the disassembly for stupidity is right. B) Setting up all of the clocks on the LPC17s is non-trivial. Have you confirmed that you're actually running at 100 MHz, and that the peripheral clock going to the timer peripheral is too? If I recall correctly, the CMSIS code to do so doesn't actually work. If you've got access to the CLKOUT pin, setting it up and dropping a scope there might do you a world of good. Also, there's an errata note that says you've got to have the main PLL disabled while you're configuring the peripheral clocks -- Rob Gaddi, Highland Technology Email address is currently out of order
Reply by ●June 7, 20112011-06-07
On 07/06/11 17:52, Tim Wescott wrote:> On Tue, 07 Jun 2011 15:49:22 +0200, David Brown wrote: > >> On 07/06/2011 15:33, Bruce Varley wrote: >>> "navman"<naveen_pn@n_o_s_p_a_m.yahoo.com> wrote in message >>> news:rMadnYYXWcwzuXPQnZ2dnUVZ_oydnZ2d@giganews.com... >>>> Hi, >>>> I'm trying to counter some pulses (2-10usec width) using the LPC1768 >>>> Cortex-M3 microcontroller. There are 2 channels on which I have count >>>> the pulses on. I have to allow only pulses that are>=2us pulse width >>>> (so we cannot simply use the counter function). >>>> >>>> But it is turning out to be an incredibly difficult feat to achieve >>>> this on >>>> a 100MHz Cortex-M3. The problem arises when we try to measure the >>>> pulse width to allow only pulses lasting 2us or higher. We are trying >>>> to use a capture pin and the capture interrupt. First we set it for a >>>> falling edge and capture the timer value, then set it to rising edge >>>> and again capture the timer value. Then take the difference between >>>> two values to see if it >>>>> 2usec. But the processing itself is taking over 6-8usec. We also >>>>> tried >>>> simply using a external interrupt& reading timer registers with each >>>> edge, >>>> but with the same results. >>>> >>>> >> Can you connect the signal to two pins, so that one will capture times >> on a falling edge, and the other will capture times and cause an >> interrupt on the rising edge? >> >> Have you considered some analogue tricks, assuming you don't need too >> much accuracy for your measurements? A diode, a capacitor and a couple >> of resistors should let you charge up a capacitor during the pulse. >> Measure the voltage on the capacitor with the ADC when the pulse is >> complete. Or use an analogue comparator to trigger an interrupt on the >> processor once the capacitor voltage is over a certain level. >> >>>> We cannot seem to understand how or why the processing is taking so >>>> long there are hardly 3-4 "C" statements in the interrupt routine >>>> (change edge of capture, take the difference in captured values and >>>> compare if it is >>>>> =2us). Any ideas how this feat could be accomplished on a LPC1768? >>> >>> I can't help with this specific micro, but I've encountered the problem >>> on various other platforms, and solved it by using polling rather than >>> interrupts. Avoiding the context saving associated with interrupts can >>> save you a significant amount of time if your processing task is >>> otherwise reasonably trivial, as yours seems to be. This solution does >>> depend on being able to sacrifice some processing time for the polling >>> loop (interrupts disabled), that will depend on the pulse frequency and >>> what else the device has to contend with. >>> >>> You might also consider doing your time-critical coding in asm, if >>> that's possible. Have oyu checked your listings to see how many >>> removeable instructions the compiler is inserting? >>> >>> >>> >> The compiler may be generating too much code for context saving. A >> common cause of that is to call external functions from within the >> interrupt function - since the compiler doesn't know what registers it >> uses, it must save everything. >> >> And are you using appropriate flags for the compiler? Many people >> complain their compiler code is poor, when it turns out they have >> disabled optimisation... > > This is almost everything that I was going to suggest. > > Look at the assembly that your compiler is generating, and make sure that > it's really as efficient as can possibly be. If it isn't, just go to the > well and write the ISR in assembly language. >Long before you consider writing the ISR in assembly, check that the C code is decently written (if you can't write appropriate C code for an interrupt routine, you are unlikely to be able to write good assembly), and check that you are using your compiler properly (and that you have a decent compiler). Used properly (which includes studying the generated assembly), C on a processor like this should be very close to the speed of optimal assembly.> Even on a 100MHz processor, 2us is an awfully short period of time. > Doing some sort of preconditioning makes a lot of sense to me, although > Schmitt trigger logic is rarely accurate enough for any practical purpose > beyond glitch reduction. It should be possible to use a multivibrator > (74xx126??) and some gates to do this if an RC and a Schmitt isn't > accurate enough. An asynchronous clear counter would do the trick as > well -- hold it in reset when the pulse is inactive, and trigger the > micro whenever it counts to it's 'carry out' value. Then you just need > to feed it an appropriate clock to hit your "more than 2us" criterion. > > If your ISR pops off quickly enough, and if it doesn't waste too much > time, spin in the ISR until the signal goes inactive, and check the > time. If that ">2us" can mean "sometimes _much_ greater than 2us" then > this obviously won't work. > > I like the "two pins" approach, if you can make it unambiguous. Make > that microcontroller hardware work for you, if you can. >I fully agree here. Software is not good at doing things with a few microsecond timing - any processor fast enough to have plenty of instruction cycles in that time will have unpredictable latencies due to caches, pipelines, buffers, etc. But this should be fairly simple code - with enough care, it could be done.
Reply by ●June 7, 20112011-06-07
On 07/06/11 18:50, Rob Gaddi wrote:> On 6/7/2011 6:16 AM, navman wrote: >> Hi, >> I'm trying to counter some pulses (2-10usec width) using the LPC1768 >> Cortex-M3 microcontroller. There are 2 channels on which I have count the >> pulses on. I have to allow only pulses that are>=2us pulse width (so we >> cannot simply use the counter function). >> >> But it is turning out to be an incredibly difficult feat to achieve >> this on >> a 100MHz Cortex-M3. The problem arises when we try to measure the pulse >> width to allow only pulses lasting 2us or higher. We are trying to use a >> capture pin and the capture interrupt. First we set it for a falling edge >> and capture the timer value, then set it to rising edge and again capture >> the timer value. Then take the difference between two values to see if it >>> 2usec. But the processing itself is taking over 6-8usec. We also tried >> simply using a external interrupt& reading timer registers with each >> edge, >> but with the same results. >> >> We cannot seem to understand how or why the processing is taking so long >> there are hardly 3-4 "C" statements in the interrupt routine (change edge >> of capture, take the difference in captured values and compare if it is >>> =2us). Any ideas how this feat could be accomplished on a LPC1768? >> >> >> --------------------------------------- >> Posted through http://www.EmbeddedRelated.com > > Something seems wrong there. I've got an application where I use an > LPC1758 to close a fairly complex PI loop controller. I've only got the > clock turned up to 52 MHz, and I'm able to execute a printed page worth > of ISR in only about 2us. > > A) Everyone who's told you to look at the disassembly for stupidity is > right. > > B) Setting up all of the clocks on the LPC17s is non-trivial. Have you > confirmed that you're actually running at 100 MHz, and that the > peripheral clock going to the timer peripheral is too? If I recall > correctly, the CMSIS code to do so doesn't actually work. If you've got > access to the CLKOUT pin, setting it up and dropping a scope there might > do you a world of good. Also, there's an errata note that says you've > got to have the main PLL disabled while you're configuring the > peripheral clocks >An easy way to check timings is to calculate the timer delays needed for one second, and connect it up to an LED. You can quickly tell if your clocks are right, without scopes or other equipment - after all, /every/ electronics board has a blinking LED.
Reply by ●June 7, 20112011-06-07
On 06/07/2011 12:31 PM, David Brown wrote:> On 07/06/11 17:52, Tim Wescott wrote: >> On Tue, 07 Jun 2011 15:49:22 +0200, David Brown wrote: >> >>> On 07/06/2011 15:33, Bruce Varley wrote: >>>> "navman"<naveen_pn@n_o_s_p_a_m.yahoo.com> wrote in message >>>> news:rMadnYYXWcwzuXPQnZ2dnUVZ_oydnZ2d@giganews.com... >>>>> Hi, >>>>> I'm trying to counter some pulses (2-10usec width) using the LPC1768 >>>>> Cortex-M3 microcontroller. There are 2 channels on which I have count >>>>> the pulses on. I have to allow only pulses that are>=2us pulse width >>>>> (so we cannot simply use the counter function). >>>>> >>>>> But it is turning out to be an incredibly difficult feat to achieve >>>>> this on >>>>> a 100MHz Cortex-M3. The problem arises when we try to measure the >>>>> pulse width to allow only pulses lasting 2us or higher. We are trying >>>>> to use a capture pin and the capture interrupt. First we set it for a >>>>> falling edge and capture the timer value, then set it to rising edge >>>>> and again capture the timer value. Then take the difference between >>>>> two values to see if it >>>>>> 2usec. But the processing itself is taking over 6-8usec. We also >>>>>> tried >>>>> simply using a external interrupt& reading timer registers with each >>>>> edge, >>>>> but with the same results. >>>>> >>>>> >>> Can you connect the signal to two pins, so that one will capture times >>> on a falling edge, and the other will capture times and cause an >>> interrupt on the rising edge? >>> >>> Have you considered some analogue tricks, assuming you don't need too >>> much accuracy for your measurements? A diode, a capacitor and a couple >>> of resistors should let you charge up a capacitor during the pulse. >>> Measure the voltage on the capacitor with the ADC when the pulse is >>> complete. Or use an analogue comparator to trigger an interrupt on the >>> processor once the capacitor voltage is over a certain level. >>> >>>>> We cannot seem to understand how or why the processing is taking so >>>>> long there are hardly 3-4 "C" statements in the interrupt routine >>>>> (change edge of capture, take the difference in captured values and >>>>> compare if it is >>>>>> =2us). Any ideas how this feat could be accomplished on a LPC1768? >>>> >>>> I can't help with this specific micro, but I've encountered the problem >>>> on various other platforms, and solved it by using polling rather than >>>> interrupts. Avoiding the context saving associated with interrupts can >>>> save you a significant amount of time if your processing task is >>>> otherwise reasonably trivial, as yours seems to be. This solution does >>>> depend on being able to sacrifice some processing time for the polling >>>> loop (interrupts disabled), that will depend on the pulse frequency and >>>> what else the device has to contend with. >>>> >>>> You might also consider doing your time-critical coding in asm, if >>>> that's possible. Have oyu checked your listings to see how many >>>> removeable instructions the compiler is inserting? >>>> >>>> >>>> >>> The compiler may be generating too much code for context saving. A >>> common cause of that is to call external functions from within the >>> interrupt function - since the compiler doesn't know what registers it >>> uses, it must save everything. >>> >>> And are you using appropriate flags for the compiler? Many people >>> complain their compiler code is poor, when it turns out they have >>> disabled optimisation... >> >> This is almost everything that I was going to suggest. >> >> Look at the assembly that your compiler is generating, and make sure that >> it's really as efficient as can possibly be. If it isn't, just go to the >> well and write the ISR in assembly language. >> > > Long before you consider writing the ISR in assembly, check that the C > code is decently written (if you can't write appropriate C code for an > interrupt routine, you are unlikely to be able to write good assembly), > and check that you are using your compiler properly (and that you have a > decent compiler). Used properly (which includes studying the generated > assembly), C on a processor like this should be very close to the speed > of optimal assembly.The only caveat would be if the compiler wasn't very good at generating efficient code -- but I'd have a hard time believing that for a Cortex processor. Not setting up the optimization flags correctly, and inadvertently writing inefficient C code -- yes. I'm just old and suspicious, and remembering too many bad experiences with compilers that _were_ crappy.>> Even on a 100MHz processor, 2us is an awfully short period of time. >> Doing some sort of preconditioning makes a lot of sense to me, although >> Schmitt trigger logic is rarely accurate enough for any practical purpose >> beyond glitch reduction. It should be possible to use a multivibrator >> (74xx126??) and some gates to do this if an RC and a Schmitt isn't >> accurate enough. An asynchronous clear counter would do the trick as >> well -- hold it in reset when the pulse is inactive, and trigger the >> micro whenever it counts to it's 'carry out' value. Then you just need >> to feed it an appropriate clock to hit your "more than 2us" criterion. >> >> If your ISR pops off quickly enough, and if it doesn't waste too much >> time, spin in the ISR until the signal goes inactive, and check the >> time. If that ">2us" can mean "sometimes _much_ greater than 2us" then >> this obviously won't work. >> >> I like the "two pins" approach, if you can make it unambiguous. Make >> that microcontroller hardware work for you, if you can. >> > > I fully agree here. Software is not good at doing things with a few > microsecond timing - any processor fast enough to have plenty of > instruction cycles in that time will have unpredictable latencies due to > caches, pipelines, buffers, etc. But this should be fairly simple code - > with enough care, it could be done.However: you'll need to be exceedingly strict about your interrupt response time elsewhere. If you have a habit of turning off interrupts to make sure that operations are atomic, and _particularly_ if you're one of a team of programmers that do this, then you have to be Really Really Strict about just how long these intervals last. Because all it'll take is one guy turning off interrupts while he calculates pi to 100 decimal places in some bit of shared memory, and your little interval counter will fail. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●June 7, 20112011-06-07
On 06/07/2011 09:34 PM, David Brown wrote:>> A) Everyone who's told you to look at the disassembly for stupidity is >> right. >> >> B) Setting up all of the clocks on the LPC17s is non-trivial. Have you >> confirmed that you're actually running at 100 MHz, and that the >> peripheral clock going to the timer peripheral is too? If I recall >> correctly, the CMSIS code to do so doesn't actually work. If you've got >> access to the CLKOUT pin, setting it up and dropping a scope there might >> do you a world of good. Also, there's an errata note that says you've >> got to have the main PLL disabled while you're configuring the >> peripheral clocks >> > > An easy way to check timings is to calculate the timer delays needed for > one second, and connect it up to an LED. You can quickly tell if your > clocks are right, without scopes or other equipment - after all, /every/ > electronics board has a blinking LED.Another sanity check I use is to blink a LED as fast as possible in a software loop, and see if the frequency matches what I'd expect. Sometimes there's a difference of a factor 100, which usually means the PLL isn't set up correctly, or the CPU clock dividers are still at the most conservative defaults, or it's still running from an internal RC oscillator or something like that.
Reply by ●June 7, 20112011-06-07
On 06/07/2011 09:45 PM, Tim Wescott wrote:> On 06/07/2011 12:31 PM, David Brown wrote: >> On 07/06/11 17:52, Tim Wescott wrote: >>> On Tue, 07 Jun 2011 15:49:22 +0200, David Brown wrote: >>> >>>> On 07/06/2011 15:33, Bruce Varley wrote: >>>>> "navman"<naveen_pn@n_o_s_p_a_m.yahoo.com> wrote in message >>>>> news:rMadnYYXWcwzuXPQnZ2dnUVZ_oydnZ2d@giganews.com... >>>>>> Hi, >>>>>> I'm trying to counter some pulses (2-10usec width) using the LPC1768 >>>>>> Cortex-M3 microcontroller. There are 2 channels on which I have count >>>>>> the pulses on. I have to allow only pulses that are>=2us pulse width >>>>>> (so we cannot simply use the counter function). >>>>>> >>>>>> But it is turning out to be an incredibly difficult feat to achieve >>>>>> this on >>>>>> a 100MHz Cortex-M3. The problem arises when we try to measure the >>>>>> pulse width to allow only pulses lasting 2us or higher. We are trying >>>>>> to use a capture pin and the capture interrupt. First we set it for a >>>>>> falling edge and capture the timer value, then set it to rising edge >>>>>> and again capture the timer value. Then take the difference between >>>>>> two values to see if it >>>>>>> 2usec. But the processing itself is taking over 6-8usec. We also >>>>>>> tried >>>>>> simply using a external interrupt& reading timer registers with each >>>>>> edge, >>>>>> but with the same results. >>>>>> >>>>>> >>>> Can you connect the signal to two pins, so that one will capture times >>>> on a falling edge, and the other will capture times and cause an >>>> interrupt on the rising edge? >>>> >>>> Have you considered some analogue tricks, assuming you don't need too >>>> much accuracy for your measurements? A diode, a capacitor and a couple >>>> of resistors should let you charge up a capacitor during the pulse. >>>> Measure the voltage on the capacitor with the ADC when the pulse is >>>> complete. Or use an analogue comparator to trigger an interrupt on the >>>> processor once the capacitor voltage is over a certain level. >>>> >>>>>> We cannot seem to understand how or why the processing is taking so >>>>>> long there are hardly 3-4 "C" statements in the interrupt routine >>>>>> (change edge of capture, take the difference in captured values and >>>>>> compare if it is >>>>>>> =2us). Any ideas how this feat could be accomplished on a LPC1768? >>>>> >>>>> I can't help with this specific micro, but I've encountered the >>>>> problem >>>>> on various other platforms, and solved it by using polling rather than >>>>> interrupts. Avoiding the context saving associated with interrupts can >>>>> save you a significant amount of time if your processing task is >>>>> otherwise reasonably trivial, as yours seems to be. This solution does >>>>> depend on being able to sacrifice some processing time for the polling >>>>> loop (interrupts disabled), that will depend on the pulse frequency >>>>> and >>>>> what else the device has to contend with. >>>>> >>>>> You might also consider doing your time-critical coding in asm, if >>>>> that's possible. Have oyu checked your listings to see how many >>>>> removeable instructions the compiler is inserting? >>>>> >>>>> >>>>> >>>> The compiler may be generating too much code for context saving. A >>>> common cause of that is to call external functions from within the >>>> interrupt function - since the compiler doesn't know what registers it >>>> uses, it must save everything. >>>> >>>> And are you using appropriate flags for the compiler? Many people >>>> complain their compiler code is poor, when it turns out they have >>>> disabled optimisation... >>> >>> This is almost everything that I was going to suggest. >>> >>> Look at the assembly that your compiler is generating, and make sure >>> that >>> it's really as efficient as can possibly be. If it isn't, just go to the >>> well and write the ISR in assembly language. >>> >> >> Long before you consider writing the ISR in assembly, check that the C >> code is decently written (if you can't write appropriate C code for an >> interrupt routine, you are unlikely to be able to write good assembly), >> and check that you are using your compiler properly (and that you have a >> decent compiler). Used properly (which includes studying the generated >> assembly), C on a processor like this should be very close to the speed >> of optimal assembly. > > The only caveat would be if the compiler wasn't very good at generating > efficient code -- but I'd have a hard time believing that for a Cortex > processor. Not setting up the optimization flags correctly, and > inadvertently writing inefficient C code -- yes. > > I'm just old and suspicious, and remembering too many bad experiences > with compilers that _were_ crappy. > >>> Even on a 100MHz processor, 2us is an awfully short period of time. >>> Doing some sort of preconditioning makes a lot of sense to me, although >>> Schmitt trigger logic is rarely accurate enough for any practical >>> purpose >>> beyond glitch reduction. It should be possible to use a multivibrator >>> (74xx126??) and some gates to do this if an RC and a Schmitt isn't >>> accurate enough. An asynchronous clear counter would do the trick as >>> well -- hold it in reset when the pulse is inactive, and trigger the >>> micro whenever it counts to it's 'carry out' value. Then you just need >>> to feed it an appropriate clock to hit your "more than 2us" criterion. >>> >>> If your ISR pops off quickly enough, and if it doesn't waste too much >>> time, spin in the ISR until the signal goes inactive, and check the >>> time. If that ">2us" can mean "sometimes _much_ greater than 2us" then >>> this obviously won't work. >>> >>> I like the "two pins" approach, if you can make it unambiguous. Make >>> that microcontroller hardware work for you, if you can. >>> >> >> I fully agree here. Software is not good at doing things with a few >> microsecond timing - any processor fast enough to have plenty of >> instruction cycles in that time will have unpredictable latencies due to >> caches, pipelines, buffers, etc. But this should be fairly simple code - >> with enough care, it could be done. > > However: you'll need to be exceedingly strict about your interrupt > response time elsewhere. If you have a habit of turning off interrupts > to make sure that operations are atomic, and _particularly_ if you're > one of a team of programmers that do this, then you have to be Really > Really Strict about just how long these intervals last. > > Because all it'll take is one guy turning off interrupts while he > calculates pi to 100 decimal places in some bit of shared memory, and > your little interval counter will fail. >The Cortex-M3 the OP is using is actually very good for this task. There are 8 different hardware level nested interrupts, and the CPU will automatically push your registers in 12 cycles. ISRs can be written in pure C without any special pragmas/attributes, and without assembler stubs. When one ISR follows the other, the registers are not restored/saved again, but are kept in saved state, while it immediately executes the next ISR, only taking 6 cycles latency inbetween. See http://www.arm.com/files/pdf/IntroToCortex-M3.pdf for more details.
Reply by ●June 7, 20112011-06-07
On Tue, 07 Jun 2011 21:45:05 +0200, Arlet Ottens <usenet+5@c-scape.nl> wrote:>On 06/07/2011 09:34 PM, David Brown wrote: > >>> A) Everyone who's told you to look at the disassembly for stupidity is >>> right. >>> >>> B) Setting up all of the clocks on the LPC17s is non-trivial. Have you >>> confirmed that you're actually running at 100 MHz, and that the >>> peripheral clock going to the timer peripheral is too? If I recall >>> correctly, the CMSIS code to do so doesn't actually work. If you've got >>> access to the CLKOUT pin, setting it up and dropping a scope there might >>> do you a world of good. Also, there's an errata note that says you've >>> got to have the main PLL disabled while you're configuring the >>> peripheral clocks >>> >> >> An easy way to check timings is to calculate the timer delays needed for >> one second, and connect it up to an LED. You can quickly tell if your >> clocks are right, without scopes or other equipment - after all, /every/ >> electronics board has a blinking LED. > >Another sanity check I use is to blink a LED as fast as possible in a >software loop, and see if the frequency matches what I'd expect. >Sometimes there's a difference of a factor 100, which usually means the >PLL isn't set up correctly, or the CPU clock dividers are still at the >most conservative defaults, or it's still running from an internal RC >oscillator or something like that.The embedded world's version of the canonical printf("Hello, world!"); One should always, always do something like this when first approaching a new processor or a new compiler on an old processor. -- Rich Webb Norfolk, VA
