Fix serial hang when scheduler work

[mlouielu]

This is relate to #12. When typing in minishell, user may hang their shell.

The problem cause this is because a re-schedule inside the loop. When sched_elect
work, it will hang out. The root cause maybe inside the scheduler, but for now, this patch
will help for user to not hang by the shell.

[jserv]

Cc. @yenwu for review.

[mlouielu]

@yenwu I'm not sure for this, should it be async or sync when reading? But in current sched, async will hang the cur_thread.

[iankuan]

@mlouielu , I can answer the question first. it's synchronize reading.

In order to achieve synchronize reading without wasting CPU resource, we attempt to block the thread not spin it if the resource isn't available. In detail, user threads using read system call would change state to blocking and dequeue itself from the runqueue if the resource isn't available. However, in this case, UART receive RX and trigger the interrupt. In corresponding ISR, we would do what I should do and trigger the serial callback function in the end of ISR. That would enqueue the blocking threads into runqueue. Moreover, I extract pieces of code to show what really happens.

• https://github.com/Piko-RT/pikoRT/blob/master/drivers/serial/stm32f1xx.c#L59
  • https://github.com/Piko-RT/pikoRT/blob/master/drivers/serial/serialcore.c#L8
    • https://github.com/Piko-RT/pikoRT/blob/master/drivers/serial/serialchar.c#L7

The flow seems really work, right? It would work if all program works expectably. As you reported that, it would hang on this situation. However, I suspect that there are some unexpected conditions in operations of serial. Thank for your report. We seem to see more clearly about #12 .

By the way, if we did this change, it will cause multiple enqueue. And that would make runqueue fulfill with this thread and cause other threads starving.

[mlouielu]

Proposing #24 for better fixed.