ESP32 DevkitC1 interrupt (TX0) causing unwanted delay

[Brian_Chapman]

At the moment I have a simple program using 1 of the DACs on ESP32 Devkit C, different values running in a continuous loop.
The problem is a momentary delay every 4 or so seconds, which appears to occur at the same time TX0 transmits data.
Is there away to disable or workaround this? Thanks
Attached

ESP32__DAC_STEP.fcfx

(12.58 KiB) Downloaded 408 times

[mnfisher]

It's probably the watch-dog timer triggering an error - which will output a message to the UART (try connecting using PUTTY or similar to check this)

Try FeedTheDog - see viewtopic.php?p=4447#p4447

This is happening because the esp32 is running a multi-tasking operating system (RTOS) and expects tasks to cooperate by yielding to allow other tasks to run.

A better way to do this might be too move the output to a timer
Interrupt running every 4ms.

Martin

[Brian_Chapman]

Thank you Martin.
As you mentioned WDT is triggered. I have a lot to add, but wanted to test the DAC first.
However I do this I need to keep the DAC step a constant rate.

Brian

[mnfisher]

Hi Brian,

Output to the DAC in a timer interrupt (running every 4ms in the example) - the accuracy is very good (remarkably good) - just output the next value and return (no delay) - try using an array of values and increment the index to this on each interrupt - use the mod (%) operator to loop.

Martin

[mnfisher]

As a simple example.

Note I output 12 values (I think this is how many your sample had - but the number can be varied to suit) - and I just output the values 1..12 (too lazy to copy your data)

DAC.fcfx

(10.74 KiB) Downloaded 266 times

As an aside - this demonstrates an issue with simulation. Simulate the program (debug-run) at a fast rate (say 10Hz) and FC becomes unresponsive as it tries to display the steps from the timer interrupt. It looks like it is running the interrupt at a simulated 'rate' that is faster that the display update - and this is 'buffered' - so that clicking on any control (stop, pause, change speed etc) - takes a long time for the command to reach the top of the message queue? Or it might be that the interrupt is taking longer than the 4ms (simulated) time - (it tries to update the 2d display) and the interrupt isn't blocked when simulating?

Martin

[Brian_Chapman]

Thank you for the example. Much appreciated.

Brian

[mnfisher]

Hi Brian,

No problem.
I've just got it up and running on hardware - and seems to run AOK. With a couple of issues - mainly it won't work under v5 (lots of 'timer not defined errors) - if you are using the (recommended) v4 no problems.
You'll also need to call 'Enable' on the DAC channel.
The DAC only allows 8 bit resolution (in the component) - I'm not sure if it should allow 12 bits?

Martin

[Brian_Chapman]

Hi Martin,
Got it running from the example, thanks again. I had already enabled the DAC. I recalled from previous Flowcode versions, the simulation was quite sympathetic and would run without it!
8 bits is fine for my application. Previously used 16F886 with SPI DAC (MCP4921).

Brian