ΣSigmaStudio Ask AI Русский Log in

Continuous READBACK polling over I2C is it safe for the sigma core?

SigmaDSP & SigmaStudio bnemo Nov 2, 2025 00:00 1 replies Original on forum ↗
Thread Summary

Thread Summary

The user is concerned about continuously and sequentially reading values from six READBACK blocks on an ADAU1701 DSP via I2C at 400 kHz. The final answer confirms that this is safe but suggests adding a 0.6 μs delay between transactions and possibly reducing the I2C clock speed to 100 kHz to ensure stability. The data from meter objects is integrated over time, making periodic reads sufficient for displaying audio levels on LED bars.
AI Generated Content
Subscribe
bnemo Question
Nov 2, 2025 00:00

Hi,
I’m using an ADAU1701 controlled by an ESP32 via the I2C interface (currently set to 400 kHz).
The ESP32 loads the full program into the DSP and communicates with it in real time, reading data from READBACK and occasionally sending new parameters via Safeload.
I’d like to continuously and sequentially read values from six READBACK blocks (2 inputs and 4 outputs) in order to display the current audio levels on an LED bars controlled by the ESP32.

Is such continuous sequential READBACK polling over I2C safe for the ADAU1701?
Will the DSP handle this without issues, or would it be better to add a short delay between reads or reduce the I2C clock speed (for example, to 100 kHz)?

Best regards,

Bartek

Audio Signal Processors

hardware

i2c

SigmaDSP Audio Processors

adau1701

DaveThib Reply
Nov 3, 2025 00:00

Hello Bartek,

Thanks for asking. Fortunately there is good guidance on this in the datasheet. I will add a few of my "real-world" comments afterwards.

The max speed is 400kHZ.

When pushing the speed to the max then the other specs become more important. The setup times, the hold times, the rise and fall times, all of those should be looked at carefully. The pull-up resistors affect some of these parameters but a lot of it is stray capacitance which will come from the PCB layout of course but also, capacitance of other devices on the bus.

There is one little typo of the spec sheet,... there is no unit to the Buss-Free Time. I am fairly certain this is in us. (microseconds) So you should wait 0.6us min between comms transactions. (short delay between reads)

I would consider possibly slowing it down a little. Keep in mind that the data you read from the meter objects are integrated over time so this will be plenty fast enough. A readback cell will not be integrated unless you put in an envelope generator before it.

I would just use a meter object in the program and then do exactly what SigmaStudio does which is read it periodically to get the audio level. Then it displays it on the screen. We do suppress this traffic in the SigmaStudio Capture screen because it would be too much data but if you have a buss monitor you will see how it works and which addresses it is reading.

You can see the addresses in the Parameter window.

Dave T

pastedimage1762188447695v1.png
pastedimage1762188447695v1.png