-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add very basic support for FlexPRET platform #29
base: main
Are you sure you want to change the base?
Conversation
I think this should be ready for review now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the effort Magnus! Just a couple of suggestions. Would be great if you could create a FlexPRET example under examples/flexpret
and quickly document how to get it running. (No need to document the whole process of installing FlexPRET, just state the assumptions or refer to documentation).
A bigger question is this: How to correctly implement critical_section_enter/leave?
The purpose of that is to allow scheduling of physical actions. There are three types of programs we must handle:
- Programs where another FP thread is scheduling physical actions
- PRograms where an ISR within the same FP thread is scheduling physical actions.
- Both (1) and (2).
For (1) we need to acquire a lock in order to ensure mutual exclusion. In (2) it is enough to disable interrupts on the FP thread. For (3) I guess we must do both.
I think the best solution might be:
In enter_critical_section
we do one of two things:
if in ISR: Then do nothing
if not in ISR: acquire lock and disable interrupts
In leave_critical_section
:
if in ISR: Do nothing
if not in ISR: release lock and enable interrupts.
Also, currently we treat it as an error if there are nested critical sections. Lets try and keep it like this if we can
src/platform/flexpret.c
Outdated
* One variable per hardware thread so each thread knows whether an async | ||
* event occurred | ||
*/ | ||
static volatile bool _async_event_occurred[FP_THREADS] = THREAD_ARRAY_INITIALIZER(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only support single-threaded operation, so putting a single variable on the PlatformFlexpret
struct seems better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm okay, now I'm a bit confused between the comment you left and what you're saying here. You say we need to handle "Programs where another FP thread is scheduling physical actions", but here we only support single-threaded operation. Can these two statements be true at the same time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that currently we only support the reactor-uc runtime managing a single thread. However, we can have other FP threads running asynchronous to the reactor-uc runtime. E.g. running a networking stack, and scheduling events into the reactor-uc runtime through a physical actin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this is probably OK for a networking stack, it is exactly this pattern that I'm trying to avoid having LF programmers use. Our goal should be that the LF programmer never explicitly starts a thread or acquires a mutex.
src/platform/flexpret.c
Outdated
* leave (disable ints) -> leave -> enter (enable ints) -> leave (disable ints) -> | ||
* enter (enable ints) -> enter | ||
*/ | ||
static volatile int _critical_section_num_nested[FP_THREADS] = THREAD_ARRAY_INITIALIZER(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would go for a single variable on the platform struct. BTW I am trying to avoid nested critical sections. If it is possible
Give me a ping when you want me to do another review, Magnus :) |
Current status: Can run with the following output. Seems to hang when it should print hello world - could be lots of reasons for that.
See branch
reactor-uc-flexpret-support
for the LF compiler changes too