Validate that the Control Task Doesn't interfere with PWM Signals

[davinbirdi]

Talking about how we utilized RTT to stop the printf delay that was causing the beat sounds while running DPR Solenoid tests.

RTT solves the problem by removing that delay, but I do not remember testing if the delay is still there if the control task takes a long time.

How to test:

• Use a very large delay in the control loop and monitor if the PWM frequency changes

Things to investigate:

• How I am controlling the PWM task, am I using a Task Start & Stop? Which delays am I using, an absolute delay (xTaskDelayUntil() vs. vTaskDelayUntil())

[davinbirdi]

@Amarantheum I mentioned this today and we try to figure out a systematic way of testing the timing.

[davinbirdi]

https://www.freertos.org/vtaskdelayuntil.html

This is the FreeRTOS API Reference/Documentation, I save this as a bookmark as I come back to it a lot: https://www.freertos.org/a00106.html

[Esouder]

This should ultimately not be an issue (I guess at least in this specific case) though since once we have SPI working we can make the high-side switches handle all the PWM, right?

[Amarantheum]

I was thinking that maybe a way we could test this is by writing to a buffer every time a task executes. Assuming getting a timestamp takes a small number of cpu cycles, writing to a buffer and updating a pointer into the buffer to write the next task completed and time stamp should take only a few cpu cycles. This is because writing is not like read where the cpu has to wait for slower cache performance for the value to be in the cpu register and the C compiler should optimize a counter in a while loop to just use a register and not read/write to a location in memory every time (unless you use the volatile keyword).