On 4/1/2023 12:07 PM, Fotis Panagiotopoulos wrote:
Is there any limitation anywhere that dictates the relationship between
these two priorities?
Since they run synchronously and generally don't overlap in time, I
would say that the answer is no
I think this answers my question, thank you.
So,
>> Is there any limitation anywhere that dictates the relationship between
>> these two priorities?
> Since they run synchronously and generally don't overlap in time, I
> would say that the answer is no
I think this answers my question, thank you.
So, It doesn't really matter what the priority o
The network API (sockets etc) will be called by the user's task.
The network driver will run on the LP worker.
The socket calls run at the user priority, but no not actually do the
transfers. The just set up to do the transfer then wait for the
transfer to complete.
The transfer itself i
Thank you very much for this explanation.
> This is really outside of the scope of the OS. There is no OS imposed
> rule about what priorities you should use for your applications or for
> the low priority work queue. So I don't think there is a rule or a
> correct answer. You just need to expe
You said one other thing that caught my attentioni:
For example, I have several tasks (that use the network) running at a
priority of 100.
In a properly turned real time system, you should never have two tasks
with the same priority. That breaks some of the fundamental assumptions
that supp
As far as I know, the network must use the low-priority workers.
I can see a comment in arch/arm/src/stm32/stm32_eth.c line 88.
But I also remember reading somewhere that the high priority workers may
cause dead-locks.
But I think that the difference between the two workers is only the...
prio
