Hi Mark, On 6/9/2011 8:41 AM, Mark Borgerson wrote: [much elided]> It certainly helps that the engineer who designed the board put all > the FIFO and LCD clocking bits on pins from the same peripheral > port. If they were on different ports, it would take a separate > instruction for each clock bit---doubling the number of instructions.This is where having someone comfortable in software and hardware really pays off. A pure hardware dweeb would connect things "wherever" without concern for how they are going to be used/accessed. E.g., "make the schematic look pretty" (signal names in numerical order -- even if REVERSE numerical order would have made more sense!) or "make the layout easy". I recall the sound output (CVSD) on some old arcade hardware required the processor to shift the data byte (in an accumulator) and write *one* bit of it into the CVSD, generate a clock, lather, rinse, repeat. As a result, the quality of the speech generated on those machines was piss poor -- with the processor spending 100.0% of its time doing this! A bit more forethought on the part of the hardware designer would have made the software easier *and* more capable. I.e., write a routine to move data and see how clumsy it REALLY is!
pulse counter using LPC1768 proving to very challenging
Started by ●June 7, 2011
Reply by ●June 9, 20112011-06-09
Reply by ●June 9, 20112011-06-09
Just to update my findings, the LPC1768 **is** running at 100MHz as confirmed by the CLKOUT pin. I'll have to check the disassembly and see where the problem is. But I'm still very much surprised to see 150ns pulses to toggle a pin. An 8 bit AVR on 16MHz clock can do about the same and maybe faster! --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●June 9, 20112011-06-09
On 9.6.11 8:30 , navman wrote:> Just to update my findings, the LPC1768 **is** running at 100MHz as > confirmed by the CLKOUT pin. I'll have to check the disassembly and see > where the problem is. But I'm still very much surprised to see 150ns pulses > to toggle a pin. An 8 bit AVR on 16MHz clock can do about the same and > maybe faster! > > --------------------------------------- > Posted through http://www.EmbeddedRelated.comThere's something fishy in the interrupt code. I'm running 200 kHz data capture (10 bit SPI A/D) and a 12800 bits/s software UART simultaneously on a 50 MHz Cortex-M3 (TI/Stellaris LM3S818). There is still plenty of processor time left for other chores. -- Tauno Voipio
Reply by ●June 9, 20112011-06-09
In article <to2dnb9SyPnenmzQnZ2dnUVZ_uSdnZ2d@giganews.com>, naveen_pn@n_o_s_p_a_m.yahoo.com says...> > Just to update my findings, the LPC1768 **is** running at 100MHz as > confirmed by the CLKOUT pin. I'll have to check the disassembly and see > where the problem is. But I'm still very much surprised to see 150ns pulses > to toggle a pin. An 8 bit AVR on 16MHz clock can do about the same and > maybe faster! > > --------------------------------------- > Posted through http://www.EmbeddedRelated.comThis definitely sounds like a code generation issue. At 10nSec per instruction, I would expect you to be able to toggle a bit in 20nSec. The GPIO ports go directly to the CPU, according to the block diagram in the LPC1768 data sheet, so I wouldn't expect and AHB slowdown. 160nSec is about what I would expect to get into an interrupt service routine or a function call that saved a few registers. Mark Borgerson
Reply by ●June 9, 20112011-06-09
On Thu, 9 Jun 2011 12:16:08 -0700, Mark Borgerson <mborgerson@comcast.net> wrote:>In article <to2dnb9SyPnenmzQnZ2dnUVZ_uSdnZ2d@giganews.com>, >naveen_pn@n_o_s_p_a_m.yahoo.com says... >> >> Just to update my findings, the LPC1768 **is** running at 100MHz as >> confirmed by the CLKOUT pin. I'll have to check the disassembly and see >> where the problem is. But I'm still very much surprised to see 150ns pulses >> to toggle a pin. An 8 bit AVR on 16MHz clock can do about the same and >> maybe faster! >> >> --------------------------------------- >> Posted through http://www.EmbeddedRelated.com > >This definitely sounds like a code generation issue. At 10nSec >per instruction, I would expect you to be able to toggle a >bit in 20nSec. The GPIO ports go directly to the CPU, >according to the block diagram in the LPC1768 data sheet, >so I wouldn't expect and AHB slowdown. > >160nSec is about what I would expect to get into an interrupt >service routine or a function call that saved a few >registers.For a datapoint, I dragged out an old devboard & tossed a few lines of test code into a scratch project. Running at 96 MHz on a "Blueboard LPC1768-H" devboard with Rowley's CrossWorks set for "Flash Release" mode and -O1 optimizations, the output pin toggles at just over 20 nsec for an entire period (one uppie, one downie) (nothing fancy; just a series of FIO0SETs and CLRs wrapped in a (shudder) goto). Unoptimized ("Flash Debug" mode) the period is about 94 nsec overall. So it *can* do it. The issue is probably just finding that one line in the user's manual or that one register bit that has been overlooked. Bloody processors are so damned *literal* sometimes... -- Rich Webb Norfolk, VA
Reply by ●June 10, 20112011-06-10
On Jun 9, 10:30=A0am, "navman" <naveen_pn@n_o_s_p_a_m.yahoo.com> wrote:> Just to update my findings, the LPC1768 **is** running at 100MHz as > confirmed by the CLKOUT pin. I'll have to check the disassembly and see > where the problem is. But I'm still very much surprised to see 150ns puls=es> to toggle a pin. An 8 bit AVR on 16MHz clock can do about the same and > maybe faster! =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.EmbeddedRelated.comSome older LPCs had "slow" GPIO and "fast" GPIO methods. Might this be the case for your 1768?
Reply by ●June 12, 20112011-06-12
In article <rMadnYYXWcwzuXPQnZ2dnUVZ_oydnZ2d@giganews.com>, 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 >=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?This shows the limits of interrupt processing. The GA144 with asynchronous waits for input change (up-going and down-going) should be able to switch between the two in a matter of nS. (Burning one processor for the input and a couple to do the processing, such as reading out a timer when signalled by the input processor.)>--------------------------------------- >Posted through http://www.EmbeddedRelated.comGroetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reply by ●June 12, 20112011-06-12
In article <3cWdnfMeAJr0rHLQnZ2dnUVZ8iqdnZ2d@lyse.net>, David Brown <david@westcontrol.removethisbit.com> wrote:>On 07/06/2011 21:45, Tim Wescott wrote: >> >> 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. >> > >Yes, there is always someone that thinks the UART receive interrupt >routine is the best place to interpret incoming telegrams, act on them, >and build up a reply...With decent handling of interrupt levels and UART at the lowest priority, this may well be the cleanest design ...>Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reply by ●June 12, 20112011-06-12
On 06/12/2011 02:43 PM, Albert van der Horst wrote:>> 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? > > This shows the limits of interrupt processing. The GA144 with > asynchronous waits for input change (up-going and down-going) > should be able to switch between the two in a matter of nS. > (Burning one processor for the input and a couple to do the processing, > such as reading out a timer when signalled by the input processor.)Not quite. The interrupt latency of the Cortex-M3 is only 12 cycles in normal circumstances, or 120 ns when running at 100 MHz, using fast memory. The fact that the ISR takes 6-8 us in the OP's case, doesn't mean there's a problem with the interrupt mechanism itself.
Reply by ●June 12, 20112011-06-12
On Jun 8, 1: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 >I see in http://ics.nxp.com/literature/other/microcontrollers/pdf/line.card.cortex-m= .pdf that the LPC18xx series, has a Timer State engine, which could be ideal for this type of pre-qualify. Of course, the LPC18xx seems to only come in big packages.. so it might not be a easy shift to make. Depends how important this count+Filter is ?
