task + async misc #67
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'd like to start getting this ready for review. But, there is a question of how much this should be split apart. There are a few cherry-picked changes that are to be merged, so we'll at least wait for those to go in. |
d3zd3z
force-pushed
the
tasks
branch
2 times, most recently
from
2657f67 to
f90442b
Compare
These are macros in Zephyr, so write explicit wrappers for them, that bindgen will be able to directly use. Signed-off-by: David Brown <[email protected]>
There is a fairly fundamental incompatibility between Zephyr spin locks and the Critical Section specification. Zephyr spin locks do not allow nesting from within a single spin lock. The critical section API only has an `acquire` and `release` entry, and provides no way (such as a stack frame) to have a unique context for different invocation places. Unfortunately, this means we cannot use spin locks for critical sections. Instead, this change implements critical sections using irq locking. The implementation of these macros on Zephyr does try to make them SMP safe, with a simple atomic lock, but there is still something preventing the riscv SMP from working. Also, these entries cannot be called from user mode. There are various other reasons we don't support usermode, so at this time, just have a compile time assertion that usermode is not enabled in the build. If it is needed, we will have to come up with another way to implement this. Signed-off-by: David Brown <[email protected]>
Implement a proc macro that allows a declaration like:
```rust
fn mythread(arg: usize, arg2: &'static Thing) { .. }
```
With this change, creation of threads, with arbitrary "Send" arguments
can be done without needing allocation. The macros reserves a static
area alongside the `k_thread` structure to use for handing the threads
over.
This creates a function `mythread` with the given args that returns a
ReadyThread. This has a `start()` method which will begin execution of
the thread. This results in a RunningThread, which has a join method
that can be used to wait for termination.
Signed-off-by: David Brown <[email protected]>
Move away from the `kobj_define` task declaration to use the new `#[zephyr::thread]` to define these. This allows for a more natural declaration where the thread just looks like an attribute added to a regular function declaration. This also eliminates the static Mutex, as the Mutex now has a constructor that avoids allocation (it is still put in an Arc, though). Signed-off-by: David Brown <[email protected]>
To help with debugging, try to give created Zephyr threads a readable name. Currently, this is based off of the name of the function used in the declaration of the thread. Signed-off-by: David Brown <[email protected]>
d3zd3z
force-pushed
the
tasks
branch
3 times, most recently
from
c0b5b21 to
cef1d3a
Compare
Don't require that the two time bases be the same. This allows applications to work using the default embassy-time base of 1MHz. There is a performance cost to the conversion (which depends on the exact ratios). If the time bases are the same (which would be common for an application build for a single target), then no conversion is needed. Signed-off-by: David Brown <[email protected]>
Don't generate instance access code for DT nodes that aren't actually enabled. Signed-off-by: David Brown <[email protected]>
Add a short readme to explain some of the difficulties with level triggered interrupts (notably, most STM32 devices do not support level triggered interrupts). Signed-off-by: David Brown <[email protected]>
Make some small changes to try testing this on stm32. This change can be discarded. Signed-off-by: David Brown <[email protected]>
A version mismatch here causes compilation errors due to other crates depending on this specific version. Signed-off-by: David Brown <[email protected]>
Instead of allocating work queues, and hoping they don't get freed, instead move to a static declaration. This is facilitated by a macro `define_work_queue` that makes it easy to declare these at the top level. Signed-off-by: David Brown <[email protected]>
The docgen target seems to try building the docs before the generated headers are present. Work around this by making a full build first, and then generating the docs. Signed-off-by: David Brown <[email protected]>
The work-queue-based Future has been removed, so also removed the documentation that was describing it. Signed-off-by: David Brown <[email protected]>
Fix various broken links in documentation comments. Signed-off-by: David Brown <[email protected]>
The Serde "tag" rules was being used for enums, which results in enums
being generated in a somewhat awkward format. Remove this, and change
the syntax of the dt-rust.yaml file to match. This typically results in
changes like:
- type: instance
value:
raw:
type: myself
to be simplified to just:
- !Instance
raw: !Myself
Signed-off-by: David Brown <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Create a new proc-macro-based way of declaring threads in Zephyr. Instead of the weird
kobj_definemacro, provide azephyr::threadmacro that can decorate an ordinary Rust function to become a builder for aReadyThreadthat can just be started. Threads can also now be reused after they exit.This allows something like:
and somewhere in the code, you just call it, which returns a handle that can be used to start the thread.
There is still some things to clean up, hence the draft, but I wanted to get some exposure.