FreeRTOS and TLS - task priority problem

[peter-h]

You may well be right, because I have just now verified, indirectly, by trying different baud rates, that the data loss is almost certainly a fixed time "DI" period.

[abyrvalg]

If you want to keep higher priority of debug prints to USB - you can arbitrate it in the "data mover" task instead of feeding the ISR directly. I.e. make a separate "high priority" buffer and make the mover servicing it first, ignoring the data in the "normal" buffer while HP buffer is not empty.

[gpr]

To expand this philosophy fully I would have 12 RTOS tasks servicing these

I cannot expand my philosophy so to understand why do you need 12 tasks here, probably you just misunderstood what was suggested.

[ejeffrey]

It is fine to have a loop which runs in 10us and have an osDelay(10) (10ms) at the bottom of it.

Such a program will take up 1/1000 (0.1%) of the CPU.

It is of course more "academically purist" to not have a loop at all and trigger the whole thing from some event.

It's not about being academically purist, and it's not about wasting CPU time.  It's that using delay calls to handle scheduling priorities is fragile and prone to errors, confusing behavior, and hard to track down race conditions.

If you take care to have every task marked as runnabe or waiting on a specifically enumerated event (and you mean it: not just "i'm ready to run my polling loop again or I'm waiting for an arbitrarily chosen delay) then it's much easier to take a snapshot of the system and see what is going on. 

It's not even strictly a problem of having explicit yield calls.  In a system without preemption it's totally fine to break tasks that run a long time without waiting by explicit calls to check if any higher priority tasks have become runnable, and if so to schedule them.  If you accurately track runnable tasks, this can be a very inexpensive check.  In this case you don't sleep for a fixed time, you are just checking to see if there is anything else to do.

It's a lot of work to restructure a mostly-working embedded program to behave in a more predictable fashion.  I understand if you feel it's not worth it.  But the flip side is that when you "fix" a bug by adding a delay you don't actually fix it, and you end up "fixing" the same bug over and over.

[tggzzz]

It is fine to have a loop which runs in 10us and have an osDelay(10) (10ms) at the bottom of it.

Such a program will take up 1/1000 (0.1%) of the CPU.

It is of course more "academically purist" to not have a loop at all and trigger the whole thing from some event.

It's not about being academically purist, and it's not about wasting CPU time.  It's that using delay calls to handle scheduling priorities is fragile and prone to errors, confusing behavior, and hard to track down race conditions.

Exactly.

A hardware equivalent would be to have a digital logic circuit in which monostable multivibrators are inserted to make it work not fail (yet).

[peter-h]

I appreciate all this but in this case it is fairly likely (as abyrvalg suggests) that some USB code (an ISR) is doing a "DI" for the 2ms or so, so restructuring the rest of the code won't do anything because you will still be losing 2ms's worth of UART interrupts.

It is the USB code which needs a thorough visit and I don't have the expertise for that. And it appears that neither has anybody else online... The "fix" is a hack but the issue occurred only with a debug statement which will probably never be enabled (there is a config file switch) by any customer.

[gpr]

It's a lot of work to restructure a mostly-working embedded program to behave in a more predictable fashion.  I understand if you feel it's not worth it.  But the flip side is that when you "fix" a bug by adding a delay you don't actually fix it, and you end up "fixing" the same bug over and over.

I agree with almost everything said except that it's "a lot of work". Very often it can be done incrementally. peter-h already uses FreeRTOS and already has infamous loop inside some task. What can be done here is to change osDelay to xTaskNotifyWait in the loop (one-line change) and move usart events management to interrupts together with vTaskNotifyGiveFromISR. Not rocket science at all if there is a will.

[SiliconWizard]

Agreed, but to be fair, according to peter, the root issue here seems to lie in the code handling USB, which, if it does actually do what peter says, does not play well with an RTOS. Which in itself is not so great.
Any task/ISR that can become non-preemptable by a higher-priority task/ISR leads to prioriy inversion, which is the thing you normally want to avoid. If the max time during which this can happen is below the max acceptable 'latency' for all other tasks, that works, even though you're always at the mercy of a future change that may make this requirement not met anymore.

Now surely there would be improvements to be made in how the various tasks are designed, but not sure that would solve this particular issue here (that may solve a number of potential others though.)

Fixing the USB stuff would be best, but if it can't be done, first thing to check would be to see if there's at least a way of configuring it to avoid priority issues. Was it written to play well with FreeRTOS to begin with?

Also, as I mentioned in an earlier post, I personally avoid async communication as much as I can if it's not possible to implement some kind of hardware handshaking and only resort to async comm without handshaking if I really have no other choice and I can ensure that the CPU which will handle reception will be able to handle it 100% of the time. Alternatively, of course, if you can't use hardware handshaking, you can work around that by implementing a master/slave protocol which doesn't allow any of the slave devices to transmit data unless they have been instructed to (by a command from the master), and make sure that the master is 100% available to handle the reply within the defined time-out (the rest of the time, it could even ignore whatever comes in.) Just my 2 cents, of course if all of that is not designed in from the start, it's rarely possible to add that in afterwards without making major system changes.

[peter-h]

Yes; a hardware h/s or xon/xoff could solve this issue.

The USB code comes from STM, ex Cube MX I believe, and I doubt it was written to be well-behaved. But then I did some hacks to it too like implementing flow control, which is desirable. Without flow control, USB VCP "works pretty well" until somebody tries to use it for some serious data (not just debugs). But as I wrote above flow control has its own problems; it can hang things up (well, obviously, that is how it works ).

I could actually route the offending debug via the flow-controlled route, but I don't like creating situations which could cause really weird problems in the field one day. Dumping debug strings is a lot safer. It is damn hard to revisit a project a year from now; much harder still 10 years from now. If everybody is going to be feeding debugs into Teraterm, under Windows, that is fine, but you never know...

[SiliconWizard]

Regarding source code coming from STM, yes, good luck with that. While the HAL libraries (even if many tend to despise them) are relatively sane - at least in comparison - the rest of what they have is really mediocre IMHO.
Their "middleware" libraries are not the worst though, even if they are still mediocre. (I suppose you are using STM32_USB_Device_Library?)
The worst by far being the code that ships with their application notes. You can use it as a guide to understand the app note, but never use that in anything serious!

[peter-h]

STM32_USB_Device_Library

Yes.