355: Multi-core removal r=korken89 a=AfoHT
Dependent on https://github.com/rtic-rs/rtic-syntax/pull/27
With the same reasoning as ^^
For now the testing is done against my rtic-syntax/multiremove-branch, but before we merge it should corrected.
Co-authored-by: Henrik Tjäder <henrik@tjaders.com>
344: Added badges to 'README.md' file r=AfoHT a=regexident
Badges for quick access to the corresponding pages on **crates.io**, **docs.rs**, the **book** (aka **rtic.rs**), as well as a badge for showing the **minimum required rustc version**.
Co-authored-by: Vincent Esche <regexident@gmail.com>
343: Updated URL for example 'init.rs' file r=AfoHT a=regexident
(the file at tag '0.5.0' still uses `rtfm`, rather than `rtic` from tag '0.5.3' or later)
Co-authored-by: Vincent Esche <regexident@gmail.com>
337: Examples: Clarify extern section r=korken89 a=dbrgn
Some beginners are confused about the "extern" section, so I added an explanation comment to all examples.
![image](https://user-images.githubusercontent.com/105168/85903840-9ad2a780-b807-11ea-943d-3f37b814c23f.png)
Furthermore, using the UARTx interrupts when UART is actually being used in the same example may be confusing, so I changed them all to SSI0/QEI0.
Co-authored-by: Danilo Bargen <mail@dbrgn.ch>
338: Fixes an issue where one could double take the cortex_m Peripheral r=japaric a=korken89
Closes#321
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
Some beginners are confused about the "extern" section, so I added an
explanation comment to all examples. Furthermore, using the UARTx
interrupts when UART is actually being used in the same example may be
confusing, so I changed them all to SSI0/QEI0.
330: Combine publish, docs and build into one workflow, do not test on nightly r=korken89 a=AfoHT
Streamline the Github Actions workflow a bit, currently it does not play well with multiple workflows since dependencies needs to be within the same workflow.
This combines the previous docs and publish workflows into one larger build workflow.
If pushing to master branch, and all jobs succeed, then the deploy is also done.
No testing on nightly except for multi-core which requires nightly.
Co-authored-by: Henrik Tjäder <henrik@tjaders.com>