Reading ADC after exactly 1.56 us

[sanjib]

Posted on January 09, 2014 at 13:20

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[waclawek.jan]

Posted on January 09, 2014 at 14:05

This is why ADC can be triggered from timers.

JW

[Tesla DeLorean]

Posted on January 09, 2014 at 14:22

Per your [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Discovery/Timer%20value%20calculation&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/AllItems.aspx&currentviews=871]earlier thread, what part about the fact you can't interrupt at these sorts of rates can't you get your head around?

[Tesla DeLorean]

Posted on January 09, 2014 at 15:57

The timer is not set up the way the comments suggest, please fix that so we don't have to guess what your system/attentions are.

You have TIM2 basically interrupting every 100 cycles, of 84 MHz?, or 200 machine cycles. You can't do a lot with that, but you need to be very conscious about what you're doing, and how long that takes, or could take.

You need to let the HARDWARE manage high rate tasks.

You make the TIM trigger the ADC

You make the DMA copy the data at EOC

You make the ADC sequence the channels

And you service interrupt when you have dozens, or hundreds of samples to process.

You'll need to evaluate the resources you have, the documented function, and if that's sufficient to do what you want, in the way that you want.

If there aren't the resources, then you'll need to consider how you might address, mitigate,  or adapt what you're doing so you can.

[sanjib]

Posted on January 10, 2014 at 06:09

[sanjib]

Posted on January 10, 2014 at 06:30

[Tesla DeLorean]

Posted on January 10, 2014 at 13:25

I'm not annoyed as much as I'm frustrated. I don't want to own your project, I have my degree already.

As you need to read 4 different pins in a cascade style, your option really is to program the list into the ADC and use sequence/continuous mode, and play games with the sample time, and inter-sample space setting, and bus clocks, to get the exact pacing you are looking for.

You could confirm the pacing via a GPIO toggled on DMA HT and TC interrupts, and measured on a scope.

[Tesla DeLorean]

Posted on January 10, 2014 at 16:05

Ok, let's try playing this a different way.

Draw a system diagram for your sonar system, illustrating where these 4 analogue signals come from, what they are measuring, and what you expect the signals to look like.

Are they from a delay line?

[sanjib]

Posted on January 13, 2014 at 06:28

[Tesla DeLorean]

Posted on January 13, 2014 at 16:10

Ok, but why four separate analogue signals? Please DIAGRAM this system.

Again going to suggest to tune the clocking source, and sample time, and inter-sample time to meet your periodicity goals.

Or if you don't need multiple analogue sources sample one aggressively and process the data.

[Tesla DeLorean]

Posted on January 14, 2014 at 04:24

Ok so working the numbers

HSE 5.12 MHz

PLL_M 4

PLL_N 160

PLL_P 2

PLL Comparison Frequency 1.28 MHz

PLL Frequency 204.8 MHz

CPU Frequency 102.4 MHz

APB1 Frequency 25.6 MHz

APB2 Frequency 51.2 MHz

ADC Prescaler /2 (25.6 MHz)

Sample Cycles 28

25.6 MHz / (28 + 12) = 640 KHz [1.5625 us]

QED

While it techically violates the PLL requirements you could perhaps use the 16 MHz HSI

HSI 16.0 MHz

PLL_M 25

PLL_N 320

PLL_P 2

PLL Comparison Frequency 640 KHz [should be 1-2 MHz range]

PLL Frequency 204.8 MHz