| Author |
Message |
|
|
 Posted: Aug 02, 2012 - 02:07 PM |
|
Joined: Oct 20, 2011
Posts: 23
|
|
Okay, here's the deal:
We are trying to make a rather time-critical solution on AT3UC3C, which employs timer 1 compare match interrupt for ADC sample timer (external ADC with convert start pin). The problem we are facing is following: the time between consecutive conversions is as short as 1,6us (600kHz sampling freq), but it seems that our interrupt handler takes up so much time to be triggered that two consecutive interrupts will only trigger at about 53kHz. The only thing we have in the interrupt vector is direct HW pin toggle, which takes (verified with oscilloscope) the expected 30ns (two clock cycles). This means that the delay must come from interrupt handling.
Is there any way to speed up the interrupt handling of the MCU? or is it rigidly set in HW? We can get the pin triggered directly by timer, but the interrupt is still needed to trigger ADC value read (by SPI). The read is handled externally to the interrupt, and does not cause the delay.
Thanks for any insight
P.S.
We have had a lot of performance issues with this MCU and atmel ASF, so much that we have written a lot of our own code. However, I have been unable to find the ASM instruction set for this MCU. Does anyone have a clue where should I look for |
|
|
| |
|
|
|
|
|
|
Posted: Aug 03, 2012 - 08:56 AM |
|
Joined: Oct 10, 2007
Posts: 395
Location: Valls, Spain
|
|
The ASF interrupt handling mechanism uses a common ISR handler for all interrupt lines. Inside this common handler the interrupt source is checked and based o that it jumps to the correct ISR. Instead of doing that you can write your own INTC routines to make a RAM table with the handlers and jump directly to them. Check out this thread:
http://www.avrfreaks.net/index.php?name ... interrupts
This will give you some speed improvement, however, I believe that you are pushing the limits of this MCU trying to interrupt it at 600KHZ, I'd say that you have chosen the wrong MCU for this task... |
|
|
| |
|
|
|
|
|
|
Posted: Aug 03, 2012 - 01:29 PM |
|
Joined: Aug 19, 2003
Posts: 398
Location: Australia
|
|
|
|
|
|
|
|
Posted: Aug 03, 2012 - 03:08 PM |
|
Joined: Nov 06, 2008
Posts: 77
|
|
60Mhz clock. 600KHz interrupt rate. You have a few cycles to play with. Not many. The ASF INTC routine is not efficient. May even need to go deeper and use assembly; see exception.x in the INTC folder.
One wonders at this rate if interrupts are really the best way. Maybe just a tight loop? It depends a lot on your overall strategy, so speculation is not often helpful.
The idea of doing as much as possible with the hardware is a good plan. The timer's ability to pulse a line is helpful. The DMA's to collect samples also can work. A lot depends on exactly what you are trying to accomplish. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 03, 2012 - 03:25 PM |
|
Joined: Oct 20, 2011
Posts: 23
|
|
Thanks for the info thus far
Yeah, we have noticed the ASF is very generic, slow, cumbersome and plainly very poorly written for many applications. It seems Atmel simply lacks the software capabilities (there are some commercial frameworks IAR which are much better, yet very expensive).
We are aiming towards around 500kHz sampling frequency on the ADC, which requires us to read the conversion result via SPI after each conversion. Currently we are using TC1-A1 output to drive the conversion start bit on the ADC. We have extint2 monitoring "busy" signal of the ADC. once busy goes high, interrupt is triggered. the ADC conversion takes around 600ns. However, we were monitoring the entry to the ISR by setting a free I/O pin directly, and it seems to take around 3,4us for the pin to rise from interrupt condition met. Likewise, it seems that lot of time is also lost on re-entry from the ISR.
Currently we are only able to manage some 100kHz sampling frequency, which is by far too slow for our application. We are currently trying to enable NMI if it would be faster in this sense. Anyways, if something can be said about UC3C, it is definitely something I will never use again in any foreseeable solution. probably 80% of our time has been wasted on trying to figure out ASF deficiencies that have prevented our code from working on different applications. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 03, 2012 - 11:29 PM |
|
Joined: Nov 01, 2008
Posts: 191
|
|
| You are going about this the wrong way. Just about any microcontroller or microprocessor available today is going to have trouble acomplishing this in an interrupt driven way. Using DMA your UC3 will slice through this application like a hot knife through butter. Study the PDCA chapter in the datasheet. |
_________________
Letting the smoke out since 1978
|
| |
|
|
|
|
|
|
Posted: Aug 04, 2012 - 01:18 AM |
|
Joined: Aug 19, 2003
Posts: 398
Location: Australia
|
|
I think no interrupts are the way to go.
There is a system counter (AVR32_COUNT) that is driven off the main clock which you can set and read to do your sampling-rate timing. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 04, 2012 - 09:41 AM |
|
Joined: May 03, 2004
Posts: 220
Location: Cologne, Germany
|
|
I think what digitalDan is going to express, is that you could use a timer to directly trigger the pin and to trigger an event that will execute a peripheral bus DMA action to read from SPI. This way your primary action would cost you almost no CPU time.
Quote:
Yeah, we have noticed the ASF is very generic, slow, cumbersome and plainly very poorly written for many applications. It seems Atmel simply lacks the software capabilities (there are some commercial frameworks IAR which are much better, yet very expensive).
It's a nice rant, but I have seen no support routines for I2C, SPI, MAC, CAN etc on the IAR website. Either you use ASF, or write it yourself. There is a reason that you can use ASF with IAR, too. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 04, 2012 - 12:33 PM |
|
Joined: Jun 04, 2007
Posts: 490
Location: Norway
|
|
Use (an ADC that can be connected to) the SSC bus!
The SSC peripheral interface is great for interfacing ADC's and DAC's. It has its own frame sync signal driven by hardware (no interrupts). Combination of SSC and PDCA is even better, the samples will be transferred to a memory buffer without CPU intervention, and you can get an interrupt when the buffer is full.
The PDCA supports two buffers, so software can process one buffer while the other is receiving data from the ADC. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 04, 2012 - 11:05 PM |
|
Joined: Aug 19, 2003
Posts: 398
Location: Australia
|
|
| The UC3C can trigger the PDCA from a peripheral event, eg. a change in input pin, but the datasheet says
Quote:
For each peripheral event received, only one data item is transferred
|
|
|
| |
|
|
|
|
|
|
Posted: Aug 05, 2012 - 04:22 PM |
|
Joined: Nov 06, 2008
Posts: 77
|
|
It takes many bruised thumbs and bent nails before a carpenter masters all the tools in her toolbox.
The ASF is a great tool to:
a) Quickly understand some generic subset of a peripheral's programing.
b) Abstract functionality on different processors.
c) Hide, or work-around, "peculiarities" in version releases.
d) Provide a common meeting ground with Atmel tech support.
For these goals the ASF code does a good job.
I've found that any real application soon moves beyond the capability of the ASF. I think this may be what you are seeing here. My guess is you could make this work using some of the suggestions above. It also seems likely that some of the hardware in the UC3 could be better utilized. Then again, maybe it won't work.
Controlling sample-by-sample A/D conversion at a 600Ksps rate, and having time left over for non-trivial processing, is a hard problem. The software and hardware architecture must be thought through very carefully to keep everything flowing smoothly.
One solution, of course, would be to use a different processor; perhaps some family with >200MHz clock, and dedicated HW for your particular A/D converter. This may indeed be the "best" solution for your particular application. Or, it may have different ,less beneficial tradeoffs. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 05, 2012 - 04:35 PM |
|
Joined: Nov 06, 2008
Posts: 77
|
|
Also, save yourself great pain and suffering by googling "aperture jitter" in A/D converters.
The timer HW trigger should work better than a SW trigger. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 24, 2012 - 12:30 PM |
|
Joined: Oct 20, 2011
Posts: 23
|
|
Hi!
Thanks for the insight! We now have the ADC sampling running with 181kHz and a single external interrupt (extint2). The Timer1 is providing the external ADC a hardware conversion start command, and external interrupt is triggered by ADC's "BUSY" pin. However, there's still a lag of several microseconds (the ADC timing and SPI reads should take just under 2us with intermediate delays) before the interrupt vector is entered (the first command in ISR is fast (local bus interface) toggle I/O pin, which we monitor with oscilloscope). Because there's such a lag, we set the extint2 trigger to "BUSY" rising edge (the ADC does it's conversion in 600ns, drops "BUSY" and data is ready for reading via SPI).
heihopp: about your suggestion about using PDCA. There's still the inherent problem that if interrupts would give the software a trigger to read buffer, at our speeds the ASF interrupts would still be too slow to get the data before next is written (even with two buffer registers). Could you also provide more detailed info on which document should we start looking into if we try PDCA?
Anyways, thanks for the info this far. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 27, 2012 - 02:59 PM |
|
Joined: Nov 06, 2008
Posts: 77
|
|
|
Quote:
there's still a lag of several microseconds
Are you still using ASF INTC?
Quote:
at our speeds the ASF interrupts would still be too slow to get the data before next is written (even with two buffer registers).
How many samples does each of the two buffers hold per PDCA interrupt?
You may have hit the wall where you no longer have enough remaining cycles to process your buffers. What are you trying to do with all these samples? Store them? Send them to another peripheral? Do arithmetic on them? |
|
|
| |
|
|
|
|
|
|
Posted: Aug 29, 2012 - 08:38 AM |
|
Joined: Jun 04, 2007
Posts: 490
Location: Norway
|
|
If you have two buffers of, say 1MB each and fs = 600 kHz (2.4 MB/sek), the interrupt rate would be about 2.4 Hz.
Using only some the built in RAM in the MCU (for example 2*16kB), the interrupt rate would be 150 Hz
The interrupt for PDCA is not very time critical because PDCA pointers are buffered (has an extra set of pointers). What happens when one memory area is full is that hardware just copy the other set of pointers and can continue working on the other half of memory area right away. What the software need to do after an interrupt is triggered is to put new values into the extra registers some time before the next interrupt occurs (ie withinn 417ms and 13 ms for the two examples of RAM usage).
The best documentation for PDCA is probably the datasheet and ASF code itself since this is AVR32 specific information. Also search for avr32 application notes, PDCA.
The earlier UC3 software framework versions contained an USART/PDCA example, but I don't know if it is still there in the later versions.
PDCA does not have many registers to program. Actually simple to implement once you understand how it works (read datasheet, PDCA, carefully). The worst part in implementing an ADC/PDCA solution is probably setting up the SSC to run correctly with the ADC because there are several parameters for the data interface (timing, clocks, phase etc). Fortunately this part of the job can be finished first using non DMA transfer for testing (polling status bits or using interrupt for each sample), then start using the working SSC/ADC with the PDCA. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
