RTOS priorities messing things up?

[Børge Strand-Bergesen]

Hi guys,

While debugging the SPDIF RX code the last few days I've seen that things which work in a UAC1 context start to fail in a UAC2 context. I'm missing out on expected LED blinks and debug characters. Change one line of code in one place, and the LEDs start working again in a completely unexpected way.

My suspicion is that this is due to UAC1 and UAC2 running at different RTOS priorities. Before I start hacking away here I'd like to check if you have any experience around this block of code:

/* USB device task definitions. */
#define configTSK_USB_DEV_NAME                ((const signed portCHAR *)"USB Device")
#define configTSK_USB_DEV_STACK_SIZE          256
#define configTSK_USB_DEV_PRIORITY            (tskIDLE_PRIORITY + 3)
#define UAC1_configTSK_USB_DEV_PERIOD              10
#define UAC2_configTSK_USB_DEV_PERIOD              2
#define HPSDR_configTSK_USB_DEV_PERIOD              2

Børge

[Alex Lee]

This is the tricky parts of programming multi threaded software.  When the cpu utilization is high (higher than about 63%), some of the lower priority tasks may not get to run in time.

Generally the lower period tasks and higher priority tasks get scheduled more often.

Alex

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.
To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Børge Strand-Bergesen]

Hi Alex,

while I did have a bit of a problem-exists-between-keyboard-and-chair type of moment, there remain things which I can't quite understand.

At the moment I closely watch code related to sample rate detection in the SPDIF receiver code. It basically waits for an LRCK transition, counts during two half-periods, and returns. There's a timeout built in, and it doesn't hang. My first take on it was to disable global interrupts and run it once. (https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/wm8805.c#L605)

My next take on it is to keep global interrupts on, and rather run the darn thing repeatedly until I have N identical measurements. This is probably very good for the scheduler and a little bad for the response time of my code.

Børge

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

[Alex Lee]

Under freertos, one doesn't disable global interrupt directly, but used a freertos function.

On Mon, 6 Mar, 2017 8:41 pm Børge Strand-Bergesen, <borge....@gmail.com> wrote:

Hi Alex,

while I did have a bit of a problem-exists-between-keyboard-and-chair type of moment, there remain things which I can't quite understand.

At the moment I closely watch code related to sample rate detection in the SPDIF receiver code. It basically waits for an LRCK transition, counts during two half-periods, and returns. There's a timeout built in, and it doesn't hang. My first take on it was to disable global interrupts and run it once. (https://github.com/borgestrand/sdr-widget/blob/audio-widget-experimental/src/wm8805.c#L605)

My next take on it is to keep global interrupts on, and rather run the darn thing repeatedly until I have N identical measurements. This is probably very good for the scheduler and a little bad for the response time of my code.

Børge

On Mon, Mar 6, 2017 at 1:28 PM, Alex Lee <alexl...@gmail.com> wrote:

This is the tricky parts of programming multi threaded software.  When the cpu utilization is high (higher than about 63%), some of the lower priority tasks may not get to run in time.

Generally the lower period tasks and higher priority tasks get scheduled more often.

Alex

On Mon, 6 Mar, 2017 8:08 pm Børge Strand-Bergesen, <borge....@gmail.com> wrote:

Hi guys,

While debugging the SPDIF RX code the last few days I've seen that things which work in a UAC1 context start to fail in a UAC2 context. I'm missing out on expected LED blinks and debug characters. Change one line of code in one place, and the LEDs start working again in a completely unexpected way.

My suspicion is that this is due to UAC1 and UAC2 running at different RTOS priorities. Before I start hacking away here I'd like to check if you have any experience around this block of code:

/* USB device task definitions. */
#define configTSK_USB_DEV_NAME                ((const signed portCHAR *)"USB Device")
#define configTSK_USB_DEV_STACK_SIZE          256
#define configTSK_USB_DEV_PRIORITY            (tskIDLE_PRIORITY + 3)
#define UAC1_configTSK_USB_DEV_PERIOD              10
#define UAC2_configTSK_USB_DEV_PERIOD              2
#define HPSDR_configTSK_USB_DEV_PERIOD              2

Børge

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alex Lee]

I remember playing with the task priority and period to be able for all the tasks to work well, as the cpu utilization is close to the limit for uac2.

[Børge Strand-Bergesen]

Thanks Alex,

I had a bit of an itch in my sledge hammer arm back when I wrote that code. I'll put it through its paces the next few days with a repeated, interruptable test. That is also good for the SPDIF RX chip which does take a while to converge.

All of this is basically because the WM8805 has a fully ridiculous way of reporting sample rate. It can't be trusted at all.

Børge

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Audio-Widget" group.

To unsubscribe from this group and stop receiving emails from it, send an email to audio-widget+unsubscribe@googlegroups.com.