LeafLabs Garden

A place to share, learn, and grow...

1. 

   IIIIIIIIII
   Member

   Does anybody know the overhead on the external interrupt feature? I'm looking for a microcontroller for a research project, and I need accurate timing on the order of microseconds.

   What I essentially need is to be able to record the exact time an interrupt occurs relative to other interrupts. Basically there will be a half dozen events or so happening potentially within a 30us time frame, and I need to know when they happened relative to each other.

   What I'm thinking is when an external interrupt occurs, have the microcontroller disable interrupts, record the value in one of the timers to memory, then re-enable interrupts. This couldn't take too many clock cycles so I think it would work, especially since the overhead before it records the timer's value should be exactly the same for each interrupt. With the timer prescaler set to have it tick once a microsecond I should be able to get fairly accurate measurements. At least I think so.

   I know I could do this on a hardware level, I've done similar things in assembly code on different boards, however I'd much rather use C in a user friendly environment like on the maple. If I use an external interrupt will it immediately execute my code? Are there any automatic maintenance routines that would delay only one interrupt? Any other issues you can think of off-hand?

   Thanks in advance.

   Posted 5 years ago #
2. 

   gbulmer
   Moderator

   Does anybody know the overhead on the external interrupt feature? I'm looking for a microcontroller for a research project, and I need accurate timing on the order of microseconds.

   The STM32F manuals at http://www.st.com/mcu/familiesdocs-110.html
   will give these answers in loving detail.

   Essentially, the ARM Cortex-M3 has been designed to give deterministic interrupt response times, so, in the absence of multiple interrupts, the times should be very predictable.

   know I could do this on a hardware level, I've done similar things in assembly code on different boards, however I'd much rather use C in a user friendly environment like on the maple.

   Pretty much everything on a Maple (ARM Cortex-M3) is programmed in C, no assembler required. All peripherals and I/O pins are accessed in C. (This is a key advantage of ARM Cortex-M3 over some earlier generations of ARM)

   What I essentially need is to be able to record the exact time an interrupt occurs relative to other interrupts. Basically there will be a half dozen events or so happening potentially within a 30us time frame, and I need to know when they happened relative to each other.

   Is it just one set of 6 interrupts, or are there many sets of 6 interrupts?
   That may have a bearing on the approach.

   You said there are only half a dozen signals.
   In that case you could use timers configured to use their input capture pins.

   The Maple has four timers, each timer has 4 channels, and each channel has an input capture pin which controls a 'capture register'. So up to 16 input pins can be used to time 16 external signals (I'd need to go check how many of those are available on the Maples 64 pin part, but many more than 6)

   When an input capture pin gets a signal, it copies the timer's current counter value into its 'capture register'.
   The timer can run at upto 72MHz, so you'd get significantly better resolution than 1uS.

   The timer's capture event can simultaneously trigger interrupts, but this is a bit easier than dealing with getting the time in your interrupt handler, as the code just needs to copy the value from the capture register to memory.

   (It is possible to have the DMA system put the values into memory, so there is only one interrupt to worry about, i.e. when all 6 values have been captured, but one thing at a time :-)

   If you switch off interrupts, the processor could miss one, and an event would be lost. Is this okay?

   If I use an external interrupt will it immediately execute my code?

   That depends on whether or not interrupts are disabled, and if there is a higher priority interrupt running. If interrupts are disabled, no, it won't execute your code. If there is a higher priority interrupt the lower priority must wait until the higher priority interrupt handler exits.

   Are there any automatic maintenance routines that would delay only one interrupt?

   Yes, there is a millisecond timer which would have to be switched off, which you can do in software.

   There is also a USB connection. I'm not sure if there is anything that needs to be done about this. Maybe a LeafLabs person can answer.

   Any other issues you can think of off-hand?

   Certainly start by doing it in software, to get the feel of the system. But be prepared to dig into timers if it is important that it is very accurate and predicable.

   Other than suggesting you don't do this in software, but instead let the hardware timers do the job for you, I can't think of any other issues.

   Posted 5 years ago #
3. 

   mbolivar
   LeafLabs

   There is also a USB connection. I'm not sure if there is anything that needs to be done about this. Maybe a LeafLabs person can answer.

   Yup, USB will fire a high-priority interrupt every 5ms by default. You can disable it in software. We had to do this (along with disabling SysTick) in a project to get the Maple to drive VGA smoothly; without this, the timing was nondeterministic enough to cause display artifacts. Here's some example code:

   http://github.com/leaflabs/projects/blob/14b624b6ac961887d8dfa07b9d8b6be840c9c82d/vga-colors/main.cpp#L298

   Posted 5 years ago #
4. 

   IIIIIIIIII
   Member

   Thank you so much, this is exactly what I needed to know. I didn't see that each pin had a capture register when I looked through the processor datasheet, and that makes what I want to do so much easier. I was thinking there was a single register that I'd have to get the data from before the next event. Also, what is this DMA you mentioned, I don't think I'm familiar with the term.

   Looks like I need to go order a Maple board. I've been looking to get one for a while and now I finally have a good reason. Thanks so much you guys!

   Posted 5 years ago #
5. 

   gbulmer
   Moderator

   DMA - Wikipedia says: Direct memory access

   Quick quote from Wikipedia:
   "Direct memory access (DMA) is a feature of modern computers and microprocessors that allows certain hardware subsystems within the computer to access system memory for reading and/or writing independently of the central processing unit."

   As a concrete example, lets imagine that you'd like to get the value from a peripheral register, and put it into memory, every time an interrupt fires. This is a very straightforward job, and doesn't really need all the power of the processor.

   Lets write some pseudo-code (almost C, but I might skip some details) to do that

   int32 *peripheral_register_src = 0x...;
     int32 memory[10];
     int32 *memory_dest = &memory[0];
     attachDMAinterrupt(peripheral_register_interrupt, move_peripheral_register);
     ....
   
   void move_peripheral_register() {
     *memory_dest++ = *peripheral_register_src;
     if (memory_dest >= &memory[10]) {
       raise an interrupt for the processor
     }
   }

   A DMA controller does the piece in the move_peripheral_register interrupt handler, without involving the processor unless it runs beyond the end of its allocated memory block.

   I hope that makes sense.

   Posted 5 years ago #
6. 

   mbolivar
   LeafLabs

   on the subject of DMA: right now, you'll have to do it yourself; i.e., there's no libmaple support for it, so you'll need to take a look at ST's manuals and set the registers by hand. it's being actively worked on, however.

   Posted 5 years ago #
7. 

   gbulmer
   Moderator

   mbolivar - is there any DMA code in github yet?

   Posted 5 years ago #
8. 

   mbolivar
   LeafLabs

   gbulmer - not yet. i'll ping the relevant people to see if they have anything worth putting in a branch.

   Posted 5 years ago #
9. 

   larryang
   Member

   For more juicy goodness on the ARM Cortex M-3 interrupts, check out http://www.drdobbs.com/blog/archives/2010/10/arm_cortex_m3_p_1.html

   It supports 255 interrupts. It looks like you won't need to disable interrupts, as you can prioritize and nest them. But if you really need to deal with multiple interrupts, I would suggest an RTOS.

   Latency snippet below:

   "[...] (12 cycles or less from normal code to interrupt handler). The worst case latency is when a low priority interrupt occurs while a higher priority interrupt is preparing to return to the main program. In this case the latency could be as high as 18 cycles. However, if the lower priority interrupt occurs during the high priority interrupts handle, the NVIC adds the new interrupt to the end of the original interrupt so there is only a 6 cycle gap between the two handlers. Of course, when using nested interrupts, the latency will probably largely be determined by the length of your interrupt handlers (except, of course, for the highest priority interrupt)."

   Posted 5 years ago #
10. 

    gbulmer
    Moderator

    For more juicy goodness on the ARM Cortex M-3 interrupts, check out http://www.drdobbs.com/blog/archives/2010/10/arm_cortex_m3_p_1.html

    The author seems to misunderstand M0 to M4
    Also

    With Thumb-2, everything can be done in 16-bit instruction mode.

    Thumb-2 has both 16 bit and 32 bit instructions.

    There are also statements which I read as contradictory:

    there is a very small and deterministic interrupt latency (12 cycles or less from normal code to interrupt handler)

    For interrupt latency to be deterministic if must be the same number of cycles, i.e. "12 cycles from normal code to interrupt handler".
    It is either deterministic interrupt latency, or it is "12 cycles or less", but I don't see how it can be both.

    ST divides the STM32 into Performance and Access lines

    No, they divide STM32F into five lines Connectivity, Performance, USB Access, Access, Value
    and STM32 into even more under the three families STM32F - 32-bit ARM Cortex MCUs , STM32L - 32-bit ultra-low-power MCUs, STM32W - 32-bit ARM Cortex RF MCUs

    I wouldn't recommend folks read the article, unless you have the energy to help the author clarify statements and correct the errors.

    Posted 5 years ago #

RSS feed for this topic

Reply

You must log in to post.