ADC_CONVERSION_SPEED question: why would you choose a slow conversion?

MarcusS

Member
I am working on a new project, and it is the first time I have really used the ADC. This project is for an amateur radio amplifier controller, and speed is an issue as I need to read the transmit control signal and flip some relays quickly from receive transmit before the input to the amplifier becomes active. If this does not happen regularly, the relay will eventually fail because the relay will arc.

The controller is also reading a number of thermistors, controlling fan PWM, monitoring voltage, current, input power, output power, and VSWR. I expect to read and process two or four of these each time through the loop (dual ADC) to keep the total loop time low, while trying to catch bad events (input power too high, high VSWR, high input current, etc.).

I would like to use the HIGH_SPEED setting, versus whatever the default is, but I expect that there are tradeoffs and I do not see these discussed anywhere. Can someone tell me what the effect of choosing HIGH_SPEED on the converted data is?

A second separate question: I see that the ADCs do a compare function, but I have not seen a tutorial. Is a compare something that I call regularly which just checks whether the value is above a threshold and that is incredibly fast. If so, that would be ideal for me. I could check on all these values to see if any of them are out of tolerance and immediately shut down, and if nothing is out of tolerance read the values of two analog inputs for display.

A final question, how expensive are floating point operations in the Teensy 4.1? Is it good practice to do all my calculations in fixed point and handle the conversion when I send an update to the display?

Thanks in advance for your help

Marcus
 
Sorry not sure if I can give you a complete answer, hopefully others will also chime in.

Slower speed conversions, I believe give you a better resolution on the results. There is some more information up on the thread about ADC.
https://forum.pjrc.com/threads/25532-ADC-library-update-now-with-support-for-Teensy-3-1

I have never used the ACMP (Chpater 64 on IMXRT). So not sure

Using the compare features of ADC (chapter 65) I also have not tried. Don't see any obvious example sketches, so not sure if library supports it or not.

Floating point - There is hardware support for it, so you might try it to see if it is fast enough.
 
Looks like you're taking a deep dive into the ADC hardware.

High speed mode consumes more power. But it's only a tiny amount compared to the power for the CPU and everything else. There's really no reason not to use it.

I have not used the threshold compare feature. It might be nice in certain usage cases, like extremely low power uses where you wish to keep the CPU in sleep mode. Probably not a big deal for most applications.

32 bit float is almost the same speed as integers. 64 bit double is half the speed. If floating point is convenient, I'd recommend putting your effort into keeping the compiler from automatically promoting to 64 bits, rather than trying to shoehorn into much more difficult fixed point. So write constants like "1.0f" (32 bits) rather than "1.0" (64 bits) and use library functions like logf() rather than log().

But if the math you need naturally works with integers, at least in theory the CPU can sometimes execute 2 instructions at once. In practice, this rarely gives you a 2X speedup. Likewise for the very difficult DSP extension instructions for packing two 16 bit numbers into 32 bit registers. Extreme effort is needed to get more than only a modest speedup, or even just to avoid a net loss as your code becomes more complicated.
 
Thank you Kurt and Paul. That is very helpful information. I will use the high speed, and ignore the compare functions for now. Don't need to be doing any bleeding edge work. Good to know about single precision being built in. I will be careful to use float for everything, including constants.

Marcus
 
When using the ADC, by far the most important factor for good results is having a low impedance signal. 5K or less is good, and under 1K is really getting into diminishing returns. Just know if you have a high source impedance, like 100K, you'll get terrible results. Even if you configure for longer sample times to allow the signal to settle, the other major problem with high impedance is the ADC is on the same chip with a lot of high speed digital circuitry that tends to couple to the ADC input. You need a strong low impedance drive to overcome that stuff.

If you use an opamp to buffer your signal, add a resistor between the opamp output and Teensy ADC pin, because the pin acts like a capacitor which has rapid switching. Most opamps can't handle that if connected directly.
 
Back
Top