diff --git a/README.md b/README.md
index 8f986c422a5f612cfb4255f2c3663df30e634856..22621f380f4827471db3ba572a8bb41dad144bc7 100644
--- a/README.md
+++ b/README.md
@@ -4,7 +4,7 @@ Are We Embedded Yet
## D7018E - Special Studies in Embedded Systems
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)
@@ -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
- 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
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
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. LLVM-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
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.
@@ -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.
- 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.
@@ -171,11 +171,11 @@ Seminars
* Building and debugging your first application.
* 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.
- 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 (`4a, 4b, 4c`) with updated documentation according to the above.
@@ -211,23 +211,23 @@ Seminars
Implement a simple system with 3 tasks
- * A periodic task executing each Xms (free of accumulated drift, and with minimal jitter), 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
* 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 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 (absoulte) in combination to achieve drift free timing. Alternative you look inte the stm32f4xx timer peripheral. There is a support crate for the [STM32F3DISCOVERY](https://github.com/japaric/f3) board. Periherals are similar so you may "borrow" code from there.
+ 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.
Optional:
- Find a way to measure the power consumpion. 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.
+ 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.
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).
- Superoptional:
- Try to minimize power consumption while maintaining desired operatotion. 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.)
+ 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.)