Faster analog sampling « LeafLabs Garden

LeafLabs Garden » Support » Maple IDE Support

Faster analog sampling

(32 posts) (7 voices)

Started 4 years ago by bart_dood
Latest reply from bart_dood

12 3 Next »

bart_dood
Member

Hi Folks, I am working on a 3 phase motor control with a fast control loop. My loop currently takes 106 microseconds (probably a little less with USB disabled).

I need to get it down, don't have a hard stop right now. Altering the analog sampling time seems an easy way to shave off time, my voltage source is an op-amp voltage follower for all the analog channels.

Is there a simple way of sampling over a smaller time period during an analogRead()

Thanks for the help, I searched but could not find anything address this specifically.

Posted 4 years ago #
robodude666
Member

You can enable DMA to sample the ADC port and store the samples into a RAM buffer.

I am unsure what the sample rate used by the DMA controller is for ADC, but you can take X amount of samples and use only every other one, for example to get a specific sample rate.

Posted 4 years ago #
bart_dood
Member

Well I have a list of functions that run on a timed interrupt. The first function samples two analog channels. So my sampling rate is already defined so to speak.

Posted 4 years ago #
mbolivar
LeafLabs
hey bart_dood,

i saw the other thread where you were posting questions about adc_smp_rate. you can lower the sample rate of an ADC device using the libmaple function adc_set_sample_rate(), which is documented here:

http://leaflabs.com/docs/libmaple/api/adc.html#functions

we picked the sample rate we did in order to allow for fairly high impedance inputs. since you've got an op-amp follower in between the signal and the analog pin, you should be able to lower it without breaking anything.

you can set the sample rate for all ADC devices on the board to its lowest possible value with this (untested):
```
void set_rate(const adc_dev *d) {
    adc_set_sample_rate(d, ADC_SMPR_1_5);
}

void setup() {
    adc_foreach(set_rate);
}
```
if you find that that sample rate is too low, try the other adc_smp_rate values until you find one that works. fyi, the one used by default is ADC_SMPR_55_5.

let us know how it goes!
Posted 4 years ago #
bart_dood
Member

Thanks mbolivar,

The code you gave me works and seems to reduce my total cycle time (which includes 2 analog reads) from 106 microseconds to 96 microseconds.

I have some other functions I can reduce, I've timed them all and I'm going to work on speeding them up.

Thanks again!

Posted 4 years ago #
gbulmer
Moderator

I replied in the other thread http://forums.leaflabs.com/topic.php?id=739&page=5#post-6654
It would have been nice of you had posted a link to this threade there.
Pretty much the same as poslathian.

I timed the ADC read a while ago, and I think it took well under 10microseconds (maybe 150K samples/second, but I'd need to check to be sure)

I'd recommend you test the rest of the code, and time that before spending any more time on analogRead.
What are you doing in the control loop? Is it floating point arithmetic?

Posted 4 years ago #
bart_dood
Member

Hi gbulmer,

I think I will leave the analogRead alone now, there is other lower hanging fruit for reducing the function times.
I am doing floating point math for clarke/park transforms for 3 phase motor control, however after timing the various functions I have discovered the two longest functions are the PI and SVM functions.
The PI is basically a PID loop with the derivative part absent and the SVM is the space vector modulation which creates the times for the PWM periods.

At the moment my code seems to have errors in it, so I am re-writing these parts and trying to make them simpler. I think I can use a lot of integer math instead of floating point which should speed things up.
I'm going to search the forum for references to PID code, I think there are some native dsp functions in the M3 for PID but I'm not sure how easy it is to access/use them with the Maple compiler.

Once I have working code that is tested and functioning I plan on posting it in the public domain.

Posted 4 years ago #
bart_dood
Member

I am wondering if long long math is faster than floating point. In some of my functions the values are essentially dimensionless, so I could use long long data types instead. Are basic subtraction/multiplication/addition math functions faster for long long's or floating points? or does it make any difference?

Posted 4 years ago #
mbolivar
LeafLabs

since there's no FPU on the cortex m3, doing integer operations on 64 bit types should be significantly, significantly faster.

edit 1: you should also consider fixed point math. crenn has gotten libfixmath working on the maple, with significant performance improvements:

http://forums.leaflabs.com/topic.php?id=266&page=2#post-4700

edit 2: by the way, the "maple compiler" is just GCC. more information here:

http://leaflabs.com/docs/arm-gcc.html

Posted 4 years ago #
bart_dood
Member

It looks like long long math is the way to go, I will simply re-scale my values at the end after all the math is finished.

I just did a quick test substituting a few floats for integers and long long's and I dropped another 30 microseconds. So my loop has gone from 106 microseconds to 66 now. I can still remove further floats and tidy some other stuff up, so I expect to drop about another 10-20 microseconds!

Posted 4 years ago #
gbulmer
Moderator

bart_dood

So my loop has gone from 106 microseconds to 66 now. I can still remove further floats and tidy some other stuff up, so I expect to drop about another 10-20 microseconds!

Very good progress. Will 50us be quick enough?

Well I have a list of functions that run on a timed interrupt. The first function samples two analog channels. So my sampling rate is already defined so to speak.

Maple has two ADC's (RET6 three), so two different analogue channels can be sampled simultaneously (if that is useful)
Maples library doesn't support dual ADC sampling, but this post might help http://forums.leaflabs.com/topic.php?id=739&page=4#post-6095

If you used robodude666 suggestion to use DMA, then you might be able to 'pipeline' (i.e. overlap in time) your calculation with sampling, though, if it is only two samples, and you use dual smapling ADCs, it might actually be 'a wash', i.e. a tiny difference.

Posted 4 years ago #
bart_dood
Member

Well in my haste I overlooked something...I can't substitute too many long long's for floats as if some numbers get multiplied together I won't know what to divide by at the end to get them back. I think I can still get rid of some floating point math but I'll have to keep some.
60-70 microseconds might be fast enough, so I'm still optimistic I can achieve this, even leaving in floating point operations.

Posted 4 years ago #
bart_dood
Member

Well its been one step forward and two steps back on this project. I finally got my code sorted to the point where its putting out numbers that make sense for the three PWM output pins.

However speed wise I've taken a major step backwards, its seems the time it takes really depends on the values going through there, and earlier I didn't have things fixed enough to have representative figures.

I'm back to floating point numbers at the moment and a cycle is taking 157 microseconds, it needs to be half this....

I guess I got a lot of work to do now to try and speed it up again...

Posted 4 years ago #
bart_dood
Member

Ok, after some analysis of the code and what is hogging all the microprocessor time I've narrowed it down to the sin and cos math.

I have this in my code:

parksin = sin(theta);
parkcos = cos(theta);

These two lines are slowing my code down a lot. I'm guessing the only way to speed it up is to use a lookup table? Anyway I can avoid a lookup table?

Posted 4 years ago #
crenn
Moderator

Do you actually need double precision?

Posted 4 years ago #

RSS feed for this topic

12 3 Next »

Reply »

You must log in to post.