Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision
  • master
1 result

Target

Select target project
  • d7018e-special-studies-embedded-systems/are_we_embedded_yet
  • tmplt/are_we_embedded_yet
  • shawnshank/are_we_embedded_yet
  • CuriouslyCurious/are_we_embedded_yet
  • nevvi/are_we_embedded_yet
  • williameriksson/are_we_embedded_yet
  • nannap/are_we_embedded_yet
  • ironedde/are_we_embedded_yet
8 results
Select Git revision
  • master
  • patch-1
2 results
Show changes
Commits on Source (43)
Expand all Show whitespace changes
Inline Side-by-side
README.md
View file @ 931a7705
...@@ -4,7 +4,7 @@ Are We Embedded Yet ...@@ -4,7 +4,7 @@ Are We Embedded Yet
## D7018E - Special Studies in Embedded Systems ## D7018E - Special Studies in Embedded Systems
Disclaimer: This document is in beta state!!!!! Just to give a hint how the course will look like. Disclaimer: This document is in beta state!!!!! Just to give a hint how the course will look like.
The course will be given as a self study course with a set of introductional seminars and accompanying mandatory assignments, followed by a larger assignment (project). The project can be carried out individually or in groups depending on size. Grading will be individual, based on agreed requirements between the student and the teacher, showing understanding and abilities regarding: The course will be given as a self study course with a set of introduction seminars and accompanying mandatory assignments, followed by a larger assignment (project). The project can be carried out individually or in groups depending on size. Grading will be individual, based on agreed requirements between the student and the teacher, showing understanding and abilities regarding:
1. The Rust ecosystem. [ecosystem](doc/Ecosystem.md) 1. The Rust ecosystem. [ecosystem](doc/Ecosystem.md)
...@@ -32,7 +32,7 @@ The course will be given as a self study course with a set of introductional sem ...@@ -32,7 +32,7 @@ The course will be given as a self study course with a set of introductional sem
8. Building and debugging embedded code in Rust 8. Building and debugging embedded code in Rust
Hardware abstractions using svd2rust (autogenerated from vendor-provided SVD specifications). Compiling using xargo. Setting up openocd and gdb. Hardware abstractions using svd2rust (auto-generated from vendor-provided SVD specifications). Compiling using xargo. Setting up openocd and gdb.
9. Pre-processing 9. Pre-processing
Custom build.rs build scripts, and the RTFM Concurrent Reactive Component model. Custom build.rs build scripts, and the RTFM Concurrent Reactive Component model.
...@@ -50,7 +50,7 @@ Each project should be reported in terms of a git Rust crate, with sufficient do ...@@ -50,7 +50,7 @@ Each project should be reported in terms of a git Rust crate, with sufficient do
There will be two presentation rounds (at end of LP2 and LP3). Students taking (too many other) courses during LP2 may choose to present their project at end of LP3 (instead of LP2). Presentations will be oral, where the student(s), will present and demonstrate their work. There will be two presentation rounds (at end of LP2 and LP3). Students taking (too many other) courses during LP2 may choose to present their project at end of LP3 (instead of LP2). Presentations will be oral, where the student(s), will present and demonstrate their work.
Projects should be related to embedded programming, either on the target side (some application using the RTFM-core or CRC model), or on the host side, communicating with an embedded target running Rust RTFM. E.g., two groups can work together with building a system, e.g., with back-end processing of data collected by the embedded system, or by providing a front-end to the embedded system. Alternatively, host side project could relate the development of the RTFM-core/ RTFM-CRC frameworks or related tools (e.g. LLWM-KLEE as a backend for analysis of Rust code). Projects should be related to embedded programming, either on the target side (some application using the RTFM-core or CRC model), or on the host side, communicating with an embedded target running Rust RTFM. E.g., two groups can work together with building a system, e.g., with back-end processing of data collected by the embedded system, or by providing a front-end to the embedded system. Alternatively, host side project could relate the development of the RTFM-core/ RTFM-CRC frameworks or related tools (e.g. LLVM-KLEE as a back-end for analysis of Rust code).
## Resources ## Resources
Students will carry out the assignments on their personal laptops (in case you don't have a working laptop we will try to lend you one). Tools used are available for Linux and OSX, but with a bit of trickery windows based installations should be possible (but you are on your own here). In case you don't run OSX/Linux native, virtual box or VMware is possible, though debugging of target MCUs are feasible it is a bit more tricky. Students will carry out the assignments on their personal laptops (in case you don't have a working laptop we will try to lend you one). Tools used are available for Linux and OSX, but with a bit of trickery windows based installations should be possible (but you are on your own here). In case you don't run OSX/Linux native, virtual box or VMware is possible, though debugging of target MCUs are feasible it is a bit more tricky.
...@@ -138,7 +138,7 @@ Seminars ...@@ -138,7 +138,7 @@ Seminars
* Topic [Memory](doc/Memory.md) * Topic [Memory](doc/Memory.md)
In-depth discussion of underlying theory, linear types (relation to functional programming). The *Affine* type system of Rust, requirements on the programmer, and guarantees offered by the compiler. Lifetimes, of stack allocated and global variables. Relation to C++ `unique pointers`. In-depth discussion of underlying theory, linear types (relation to functional programming). The *Affine* type system of Rust, requirements on the programmer, and guarantees offered by the compiler. Lifetimes, of stack allocated and global variables. Relation to C++ `unique pointers`.
* Assignment * Assignment 3
a. Recall the D0013E course lab2/4, where you decrypted a message in assembler (lab2) and C (lab 4). Now, let's re-implement the lab in Rust (base your development on group number [1's](http://www.sm.luth.se/csee/courses/smd/D0013E/labs/lab1underlag/grupp_01.lab1_underlag.s ) lab assignment). a. Recall the D0013E course lab2/4, where you decrypted a message in assembler (lab2) and C (lab 4). Now, let's re-implement the lab in Rust (base your development on group number [1's](http://www.sm.luth.se/csee/courses/smd/D0013E/labs/lab1underlag/grupp_01.lab1_underlag.s ) lab assignment).
...@@ -148,7 +148,7 @@ Seminars ...@@ -148,7 +148,7 @@ Seminars
The `seed`, `abc`,`coded` and `plain` should be stack allocated. The decoded string should be printed when decryption is finished. The `seed`, `abc`,`coded` and `plain` should be stack allocated. The decoded string should be printed when decryption is finished.
b. Make the `seed`, `abc`,`coded` and `plain` static (heap) allocated (i.e., as global varibles). Accessing those will require some `unsafe` code. (Keep the unsafe blocks as local as possible.) b. Make the `seed`, `abc`,`coded` and `plain` static (heap) allocated (i.e., as global variables). Accessing those will require some `unsafe` code. (Keep the unsafe blocks as local as possible.)
c. Safety analysis. Provoke the implementation, by omitting the `'\0'` (null termination). Observe the result and motivate the behavior in terms of your understanding of the Rust memory model. Under which circumstances do you consider 3a and 3b to have same/different memory safety. c. Safety analysis. Provoke the implementation, by omitting the `'\0'` (null termination). Observe the result and motivate the behavior in terms of your understanding of the Rust memory model. Under which circumstances do you consider 3a and 3b to have same/different memory safety.
...@@ -169,21 +169,21 @@ Seminars ...@@ -169,21 +169,21 @@ Seminars
* `blue-pill` and `nucleo` board support crates * `blue-pill` and `nucleo` board support crates
* Building and debugging your first application. * Building and debugging your first application.
* Assignment * Assignment 4
a. Backport assignment `3b` to your chosen target. Use semihosting in order to `write` the resulting string to the host. You may need to use `--release` for decoding the long (`coded`) message, as being deeply recursive unoptimized code may run out of stack memory. a. Backport assignment `3b` to your chosen target. Use semi-hosting in order to `write` the resulting string to the host. You may need to use `--release` for decoding the long (`coded`) message, as being deeply recursive unoptimized code may run out of stack memory.
b. Discuss from a memory safety perspective the outcome. b. Discuss from a memory safety perspective the outcome.
c. Compare for the short message (`abc`), the number of cycles required for `decode` in debug (standard) vs. `--release`. As a comparison my straightforword C implementation took 2200 cycles in best optimized mode using `gcc` (-o3), while my (translation) to Rust code took 1780 cycles (--release). (Both executed on a bluepill board at 8MHz without (flash) memory wait states). c. Compare for the short message (`abc`), the number of cycles required for `decode` in debug (standard) vs. `--release`. As a comparison my straightforward C implementation took 2200 cycles in best optimized mode using `gcc` (-o3), while my (translation) to Rust code took 1780 cycles (--release). (Both executed on a bluepill board at 8MHz without (flash) memory wait states).
Make a new git for your embedded development. Make three branches (`3a, 3b, 3c`) with updated documentation according to the above. Make a new git for your embedded development. Make three branches (`4a, 4b, 4c`) with updated documentation according to the above.
5. Advanced Rust Concepts 5. Advanced Rust Concepts
* Preparation * Preparation
Be prepared to present the progress on assignment 3. Be prepared to present the progress on assignment 4.
* Topic * Topic
Advanced Rust features, trait system and closures. Advanced Rust features, trait system and closures.
...@@ -192,12 +192,12 @@ Seminars ...@@ -192,12 +192,12 @@ Seminars
* [13 - Functional Language Features in Rust](https://doc.rust-lang.org/book/second-edition/ch13-00-functional-features.html). * [13 - Functional Language Features in Rust](https://doc.rust-lang.org/book/second-edition/ch13-00-functional-features.html).
* Assignment * Assignment
Continue working on assignment 3. Continue working on assignment 4.
6. Memory Safe Concurrency 6. Memory Safe Concurrency
* Preparation * Preparation
* Finish lab 3 and be prepared to show your solution. * Finish assignment 4 and be prepared to show your solution.
* Topic * Topic
* UnsafeCell, and synchronization in the RTFM model. * UnsafeCell, and synchronization in the RTFM model.
...@@ -207,55 +207,54 @@ Seminars ...@@ -207,55 +207,54 @@ Seminars
* [cortex-m-rtfm](https://github.com/japaric/cortex-m-rtfm) The RTFM-core (task and resource model) in Rust for the Cortex-M family * [cortex-m-rtfm](https://github.com/japaric/cortex-m-rtfm) The RTFM-core (task and resource model) in Rust for the Cortex-M family
* [svd2rust](https://github.com/japaric/svd2rust) Generating * [svd2rust](https://github.com/japaric/svd2rust) Generating
* Assignment 4 * Assignment 5
Implement a simple system with two tasks Implement a simple system with 3 tasks
* a periodic task executing each 10ms, that blinks the onboard LED, and * A periodic task executing each Xms (free of accumulated drift, and with minimal jitter), that blinks the on-board LED, and
* USART task receiving commands (pause, start, period) * A USART task receiving commands (pause, start, period 1-1000ms), received commands should be parsed and corresponding responses generated and sent over the USART. (Come up with a nice and simple user interface.)
* a shared resource (data structure) protecting the command and period * A a logging task, run each second (period 1s), that prints statistics of CPU usage over the ITM port
* Idle should gather statics on sleep/up time, (there is a sleep counter in the cortex core)
* Use shared resources (data structures) to ensure race free execution
You may use the core systic timer (relative) and the dwt cycle counter (absolute) in combination to achieve drift free timing. Alternative you look into the stm32f4xx timer peripheral. There is a support crate for the [STM32F3DISCOVERY](https://github.com/japaric/f3) board. Peripherals are similar so you may "borrow" code from there.
Make a new git with the development and documentation. Make a new git with the development and documentation.
7. Macros Optional:
* Preparation Find a way to measure the power consumption. A possible solution is to power the board externally and use a power cube with current measuring capability. Alternative use an external power source with known charge (e.g., a "capacitor"), and measure the discharge time (start and residue charge at brown-out voltage), at least a precise relative measure is possible to obtain.
Be prepared to present the progress on assignment 4. Operation without being connected to the USB port: in this case the serial IO and ITM needs to be connected externally (e.g., using some ftdi serial-USB).
* Topic
We will cover the implementation of the RTFM-core crate. Super optional:
Try to minimize power consumption while maintaining desired operation. Lowering supply voltage and using aggressive power modes of the processor might be applied. (Not sure how USART/ITM communication can be made possible at sub 3.3v voltages. Also you have to make sure not to source the board over the communication interfaces.)
Special focus to `macro_rules` and `procedural macros`.
8. Concurrent Reactive Objects
7. Macros and Projects (Monday Nov. 20th)
* Preparation * Preparation
Be prepared to present assignment 4. Be prepared to present the progress on assignment 5.
* Topic * Topic
A component model for reactive real-time programming. - We will cover the implementation of the rtfm-core and the cortex-m-rtfm crates. For details see [RTFM](doc/RTFM.md).
We will cover the programming model and the implementation, including the `build.rs`, parsing of model files and generation of Rust code.
* Assignment 5
* port the assignment 4 to the RTFM-CRC model.
Make a new git for the development and documentation. Special focus to `macro_rules` and `procedural macros`.
- RTFM-CRC A component model for reactive real-time programming.
9. Presentation of project ideas We will cover the programming model and the implementation, including the `build.rs`, parsing of model files and generation of Rust code.
* Preparation
Be prepared to present progress of assignment 5.
* Topic
Discussion of projects - Discussion of project ideas
* Assignment * Assignment
Write a project specification including individual grading assessment criteria. Write a project specification including individual grading assessment criteria.
10. Wrap-up 8. Wrap-up (Monday Dec. 4th)
* Preparation * Preparation
* Be prepared to present assignment 5. * Be prepared to present assignment 5.
* Be prepared to present your project. * Be prepared to present your project, 10 minutes per project.
* A good idea is to prepare a git for the project with a `README.md` and use that as supporting material for your presentation. Its advicable to have a section (or in a doc sub folder) where you collect references to the material you will use, i.e., links to data sheets, links to other related crates and projects of importance to your project.
This type of reference section will be largely helpful to both you (during the project and afterwards maintaining it, but also to other users and people interested in your work). Moreover, from a "course" perspective it shows that you have done the necessary background studies BEFORE you "hack away". Of corse this will be a living document, updated throughout the project, but its a very good thing to start out NOW, then it can be used for your 10 minutes of fame!
doc/Ecosystem.md
View file @ 931a7705
...@@ -29,16 +29,16 @@ We suggest a Linux or OSX development environment, though Rust related tools are ...@@ -29,16 +29,16 @@ We suggest a Linux or OSX development environment, though Rust related tools are
The [rustup](https://www.rustup.rs/), tool manager allows you to manage multiple tool chain installations. Rust is distributed in three channels (`stable`, `beta` and `nightly`). You may set the default toolchain: The [rustup](https://www.rustup.rs/), tool manager allows you to manage multiple tool chain installations. Rust is distributed in three channels (`stable`, `beta` and `nightly`). You may set the default toolchain:
``` ```
rustup default nightly-2017-10-22-x86_64-unknown-linux-gnu rustup default nightly-2018-01-10-x86_64-unknown-linux-gnu
``` ```
and get information on the status of `rustup` and get information on the status of `rustup`
``` ```
rustup show rustup show
``` ```
Nightly tool chains allow for the development of libraries and applications including `unsafe` code using features not available on the `stable channel` (which will be necessary for the later exercises). For some tools to work (`rls/rustfmt`), you need to install additional components. For this to work, you should use a nightly toolchain for which all tools and components work (currently `nightly-2017-10-30` is the latest). Here is an example: Nightly tool chains allow for the development of libraries and applications including `unsafe` code using features not available on the `stable channel` (which will be necessary for the later exercises). For some tools to work (`rls/rustfmt`), you need to install additional components. For this to work, you should use a nightly toolchain for which all tools and components work (currently `nightly-2018-01-10` is the latest). Here is an example:
``` ```
rustup default nightly-2017-10-30 rustup default nightly-2018-01-10
rustup component add rls-preview rustup component add rls-preview
rustup component add rust-analysis rustup component add rust-analysis
rustup component add rust-src rustup component add rust-src
...@@ -71,7 +71,7 @@ Dependencies (may) include a minimal version, following the [semver](http://semv ...@@ -71,7 +71,7 @@ Dependencies (may) include a minimal version, following the [semver](http://semv
See [rls](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust) for installing the RLS extension. See [rls](https://marketplace.visualstudio.com/items?itemName=rust-lang.rust) for installing the RLS extension.
You will need to pin the specific toolchain version used, by setting the `"rust-client.channel": "nightly-2017-10-30"` in your `vscode` *user* settings (this will be stored in a file `~/.config/Code/User/settings.json` and used for all your `vscode` projects. Settings may be set individually for each *workspace*, overriding the defaults. Regarding the `"rust-client.channel"` setting, a *workspace* setting would force the specific version (overriding the default), and may not work when the code is distributed (as other developers may be on other toolchains). You will need to pin the specific toolchain version used, by setting the `"rust-client.channel": "nightly-2018-01-10"` in your `vscode` *user* settings (this will be stored in a file `~/.config/Code/User/settings.json` and used for all your `vscode` projects. Settings may be set individually for each *workspace*, overriding the defaults. Regarding the `"rust-client.channel"` setting, a *workspace* setting would force the specific version (overriding the default), and may not work when the code is distributed (as other developers may be on other toolchains).
For RLS to work, `vscode` need a path to the `rls-preview` library (using the environment variable `LD_LIBRARY_PATH` (Linux), `DYLD_LIBRARY_PATH` (OSX ?)). For RLS to work, `vscode` need a path to the `rls-preview` library (using the environment variable `LD_LIBRARY_PATH` (Linux), `DYLD_LIBRARY_PATH` (OSX ?)).
``` ```
......
doc/Nucleo_64.md
View file @ 931a7705
# Nucleo 64 # STM32 Nucleo-64 Board
A collection of documentation, tricks and tips regarding the ST Nucleo 64 development kit. A collection of documentation, tricks and tips regarding the STM32 Nucleo-64 Board (development kit).
We will mainly cover the `stm32f401re` and `stm32f411re` as these models. We will mainly cover the `stm32f401re` and `stm32f411re` as these models (main difference is the higher maximum clock frequency of the `stm32f411re`).
---
## Stlink inteface
The nucleo-64 platform has an onboard `stlink-v2.1` SWD interface (programmer) supported by `openocd`. By default the programmer is connected to the target (`stm32f401re` or similar).
---
### Programming external targets
You may use the board as a programmer (connector `CN4` SWD), in that case you should remove the `CN3` jumpers, and optionally desolder `SB15` (SWO) and `SB12` (NRST). See board documentation for details.
## Links ## Links
* [Nucleo-64 board](http://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf)
Board documentation.
* [Firmware Upgrade](http://www.st.com/en/development-tools/stsw-link007.html)
Standalone java program.
# Clocking # Clocking
* [Note on Overclocking](https://stm32f4-discovery.net/2014/11/overclock-stm32f4-device-up-to-250mhz/) * [Note on Overclocking](https://stm32f4-discovery.net/2014/11/overclock-stm32f4-device-up-to-250mhz/)
......
doc/Project_and_grading.md 0 → 100644
View file @ 931a7705
# Course description
In order to be officially enrolled for the course each student need to write (and submit) an individual course plan including grading goals and assessments based on this document.
Assignments are mandatory (as detailed in the README.md).
- Each student should for each assigment 2, .., 5 comment (make an `issue` and/or `pull request` to one other `git`). Comments should be meaningful and constructive. For the assigment 2, .., 5 you should comment on different groups. Strive to spread comments so that each group will get at least one comment for each assignment.
- Each student/group should attend `issues`/`pull request`
Projects should aim to further cover the learning goals as stated in the README.md.
## Blooms taxonomy
Blooms taxonomy assess the (increasing) level of understanding as:
- Remember
- Understand
- Apply
- Evaluate
- Create.
(In the original taxonomy Evaluate was set at a higher level than Create.)
Well its not the only one.
## The SOLO taxonomy
The SOLO taxonomy can be summarised:
- Prestructural - Incompetence: fail, incompetent, missing the point
- Unistructural - One relevant aspect: identify, name, follow simple procedure
- Multistructural - Several relevant inedendent aspects: combine, describe, enumerate, perform serial skills, list
- Relational - Aspects integrated into a structure: analyze, apply, argue, compare/contrast, critisze, explain causes, relate, justify,
- Extended Abstract - Asprects generalized to new domain: create, formulate, generate, hypothesize, reflect, theorize
The advantage of the SOLO taxonomy is that you have progression towards generalization (while the Bloom taxonomy allows progression in isolation).
How can such "mumbo jumbo" be useful towards setting the goals and assessment criteria for Your project? Project assessment is not an easy task and there is no single correct answer to it, so let's study an example.
---
## Example HW AES Support for cortex-m.
- Grade 5. The project aims to `create` an API and library allowing end user memory safe access to the underlying AES hardware of the target platform. The API will provide the features A, B, C, and D, with correcness argued from the evaluation.
- Grade 4. The API/library will be based on an `evalution` (analysis) or requirements and possible solutions based on the Rust Memory model and the `cortex-m-rtfm` task/resource model.
- Grade 3. Low level access to the AES hardware, by `applying`, provided primitives by the Rust language and the `cortex-m-rtfm` library.
---
## Grading
So basically for grade 3 you show that you understand and can apply known methods and provided material. For grade 4, you show that you can make judgements on designs choices. And for grade 5, you put it all together, practical understaning and theoretical judgements. For the example for grade 5, you will show to combine knowledge and understanding of both software and hardware architecture and the theoretical concerns of a sound implementation.
Assessment/evalutation is individual. If you work together in a group, you should detail the description, e.g., student X will focus on the features A and B, while studen Y will focucs C and D.
## Amount versus quality.
The amount of work required to make a complete solution is VERY hard to predict (even industry stuggles with such questions). However in industry a track record of previous projects serves as a baseline, here we face a much harder problem, You are likely new to the topic.
Thus, if you along the project see that covering a complete solution (in this case features A-D) is out of reach (or that when doing the grade 3 you find that B and D is not possible for some reason) you are free to make restrictions (meaning that its ok to drop features provided a motivation). However quality is not to be compromised. Shortcutting the design/evaluation in favour of more features is NOT getting you a higher grade. Ultimatetely, you can still get a grade 5, even if the project fails to meet its goals (provided that the quality of the work done holds up). This is where industry and academia largly differs!
## Engineering
You are becoming engineers, to that end I believe Bloom's taxonomy to a good fit (simle to apply), you will become experts at engineering in your field. Of course this does not prohibit generalization, but the point here is NOT to show the socioeconamical impact and political issues of AES encryption, but rather to engineer a solution. (Actually, we are subject to political issues regarding AES - due to US export restrictions the Nucleo boards are shipped without HW AES, but thats another story.)
# Instructions, what to turn in
For each student
Create a git with a README.md with
- Course name : "d7018e - special studies in embedded systems"
- name, mail address and personal number
- title of your project
- project description (here you may share text with your partner) and grading goals (individual)
I will give feedback to the git (an issue). When we have an agreement you will print the READE.md as a `pdf` and send to edusrt@ltu.se (with the title "d7018e - special studies in embedded systems", so you can be officially admitted and enrolled.
doc/Project_suggestions.md 0 → 100644
View file @ 931a7705
# Suggested projects
---
## Printing device (William)
- Rotating stick with LEDs at the end of the stick that can "print" text by switching the LEDs on and off with the right timings.
---
## Seer (Nils)
Symbolic execution engine for MIR internal format
- Study and understand the Z3 API
- Study and understand the user API (maybe add more functionalty)
- Study outsets for program verification based on seer
---
## LED Audio (John)
- Modulate LED colors and intensity according to audio input
---
## Drivers for NXP (Axel)
---
## WCET analysis for RTFM models using KLEE (Henrik)
- Automated testebed, integrated as cargo sub-command
---
## USB-Hid (Johannes)
---
## ETM Tracing
- Develop an API for setting up ETM trace
[ARM](https://www.arm.com/files/pdf/AT_-_Advanced_Debug_of_Cortex-M_Systems.pdf)
---
## AES Encryption in hardware (Viktor)
- Develop on API for hardware supported AES encryption
---
## CAN bus API and Wheel Sensor implementation
- Develop a CAN bus API for cortex-m0
- Implement a wheel sensor for existing model car
---
## Stack Memory Analysis
- Seer or KLEE based path/call graph extraction
- Target code analysis, per function stack usage
- Static worst case stack analysis for RTFM and/or RTFM-TTA
---
## Ethernet driver for TCP/UDP/IP stack (Jonas)
- Develop driver and integrate to existing TCP/UDP/IP stack
---
## Nucleo 64 support crate
- Drivers for the Nucleo 64, stm32f401re/stm32f411re, similar to the f3/bluepill support crates
---
## Time Triggered Architecture (RTFM-TTA)
- Periodic timers
- Communication channels/message buffers
- Static analysis (for safely bound buffers)
- Static analysis for data aging (opitmal ordering?)
---
## Your ideas...
\ No newline at end of file
doc/Quickstart.md
View file @ 931a7705
...@@ -23,7 +23,7 @@ ...@@ -23,7 +23,7 @@
## Dependencies for development ## Dependencies for development
- `arm-none-eabi-ld`, linker - `arm-none-eabi-binutils`, linker
- `arm-none-eabi-gdb`, debugger - `arm-none-eabi-gdb`, debugger
...@@ -39,7 +39,18 @@ ...@@ -39,7 +39,18 @@
- Arch Linux - Arch Linux
``` console ``` console
$ sudo pacman -Sy arm-none-eabi-{ld,gdb} openocd $ sudo pacman -Sy arm-none-eabi-{binutils,gdb}
```
OpenOCD is in AUR:
```
$ yaourt -S openocd
```
For hardware-association and pre-packaged UDEV-rules also install:
```
$ sudo pacman -S stlink
``` ```
### macOS ### macOS
...@@ -70,6 +81,9 @@ $ rustup default nightly ...@@ -70,6 +81,9 @@ $ rustup default nightly
$ cargo install cargo-clone xargo $ cargo install cargo-clone xargo
``` ```
> **NOTE** If the `cargo install` fails you may need to install `pkg-config`. In Arch this can be
> accomplished with the `pacman -S pkg-config` command.
## Demo ## Demo
In the first part of the demo we'll use command line tools in the terminal then we'll transition to In the first part of the demo we'll use command line tools in the terminal then we'll transition to
...@@ -336,6 +350,25 @@ $ # for the NUCLE-F401RE ...@@ -336,6 +350,25 @@ $ # for the NUCLE-F401RE
$ openocd -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg $ openocd -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg
``` ```
> **NOTE(Linux)** If you get a permission error when running OpenOCD then you'll need to change the
> udev rules for the SWD programmer you are using. To do that create the following file at
> `/etc/udev/rules.d`.
>
> ``` console
> $ cat /etc/udev/rules.d/99-st-link.rules
> # ST-LINK v2
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE:="0666"
>
> # ST-LINK v2-1
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", MODE:="0666"
>
> # NUCLEO-F401RE
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", MODE:="0666"
> ```
>
> With that file in place call the command `sudo udevadm control --reload-rules`. Then unplug and
> re-plug your SWD programmer. That should fix the permission problem.
You should see some output like this: You should see some output like this:
``` console ``` console
...@@ -619,7 +652,7 @@ write: ...@@ -619,7 +652,7 @@ write:
Now pick from the menu: `Tasks > Configure Default Build Task...` and pick `xargo build`. Now pick from the menu: `Tasks > Configure Default Build Task...` and pick `xargo build`.
Now you should be able to build your project by picking `Tasks > Run Build Task...` from the menu or Now you should be able to build your project by picking `Tasks > Run Build Task...` from the menu or
by hitting the shorcut `Ctrl + Shift + B`. by hitting the shortcut `Ctrl + Shift + B`.
![Build task](/assets/vscode-build.png) ![Build task](/assets/vscode-build.png)
......
doc/RTFM.md 0 → 100644
View file @ 931a7705
This diff is collapsed.