| Age | Commit message (Collapse) | Author |
|
502: book/resources: highlight that `#[lock_free]` includes a compile-time check r=AfoHT a=japaric
for the "same priority requirement"; this prevents data races
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
|
|
500: migration/0.5: cover #[lock_free] r=AfoHT a=japaric
I think this completes #488
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
|
|
for the "same priority requirement"; this prevents data races
|
|
I think this completes #488
|
|
the #[task_local] attribute was removed
|
|
it no longer exists. all resources are now late resources
|
|
instead stick to `#[local]` resources
|
|
|
|
to use the new resources syntax
I also reordered the sections to cover all the resource API first before covering the spawn API
I've also added a section about the old `static mut` variable transform
|
|
|
|
|
|
|
|
479: book: detail import resolving for 0.6 migration r=korken89 a=tmplt
That is, answering the question of why imports are no longer resolving during compilation.
Co-authored-by: Viktor Sonesten <v@tmplt.dev>
|
|
The example now migrates from v5 to v6 instead of an incorrect v6 syntax
to a another incorrect v6 syntax.
|
|
|
|
|
|
you -> your
|
|
|
|
|
|
|
|
|
|
|
|
411: Add section about task_local and lock_free r=perlindgren a=AfoHT
Co-authored-by: Henrik Tjäder <henrik@tjaders.com>
|
|
408: Fixup app/new r=perlindgren a=AfoHT
Reference the current example
Co-authored-by: Henrik Tjäder <henrik@tjaders.com>
|
|
|
|
410: resources r=AfoHT a=perlindgren
resources
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
|
|
|
|
|
|
|
|
409: Updated send/sync docs r=AfoHT a=korken89
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
|
|
|
|
|
|
|
|
405: Updated migration guide with symmetric locks and new spawn r=AfoHT a=korken89
406: book.toml/by-example/app r=korken89 a=perlindgren
Book update
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
Co-authored-by: Per Lindgren <per.lindgren@ltu.se>
|
|
|
|
|
|
|
|
|
|
|
|
When quickly reading through the priorities chapter, I couldn't find in which order the priorities were, so I assumed it was the same as in the hardware.
In the cortex-m hardware, interrupts with the **lower** priority number will preempt the other interrupts.
RTIC does the reverse, so I think it's good to be more explicit about it.
|
|
|
|
|
|
of https://github.com/rtic-rs/cortex-m-rtic
|
|
173: add sandbox example r=AfoHT a=etrombly
Added a real world example for my sandbox project.
Co-authored-by: Eric Trombly <etrombly@yahoo.com>
|
|
|
|
368: Mod over const r=korken89 a=AfoHT
Related [RFC](https://github.com/rtic-rs/rfcs/pull/34)
Dependent on [rtic-syntax-PR30](https://github.com/rtic-rs/rtic-syntax/pull/30)
~~Currently using my own dev-branch~~
Co-authored-by: Henrik Tjäder <henrik@tjaders.com>
|
|
|
|
|
|
375: close console text blocks on a new line r=AfoHT a=dcarosone
fixes #369
Co-authored-by: Daniel Carosone <Daniel.Carosone@gmail.com>
|
|
|