From aea542b019911fb82f729fbd3e2e473ceb0d80ab Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 20:09:28 -0800 Subject: [PATCH 01/12] No newline at end of file? --- src/static-guarantees/state-machines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/static-guarantees/state-machines.md b/src/static-guarantees/state-machines.md index 0d5a5ba..da8adc3 100644 --- a/src/static-guarantees/state-machines.md +++ b/src/static-guarantees/state-machines.md @@ -95,4 +95,4 @@ However, this could allow us to modify certain registers that do not make sense. This would allow us to reach states not defined by our state machine above: An output that is pulled low, or an input that was set high! -Although this interface is convenient to write, it doesn't enforce the design contracts set out by our hardware implementation. \ No newline at end of file +Although this interface is convenient to write, it doesn't enforce the design contracts set out by our hardware implementation. From b8f78902b15717ea3ee3725e9465894616bf0c22 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 20:17:48 -0800 Subject: [PATCH 02/12] Add emphasis, fix grammar --- src/static-guarantees/state-machines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/static-guarantees/state-machines.md b/src/static-guarantees/state-machines.md index da8adc3..c890b35 100644 --- a/src/static-guarantees/state-machines.md +++ b/src/static-guarantees/state-machines.md @@ -51,7 +51,7 @@ Typically the states listed above are set by writing values to given registers m | | | 1 | set-high | Output pin is driven high | | input_status | 5 | x | in-val | 0 if input is < 1.5v, 1 if input >= 1.5v | -We could simple expose the following structure in Rust to control this GPIO: +We _could_ expose the following structure in Rust to control this GPIO: ```rust,ignore /// GPIO interface From 6a37fe713eba517ac69494d6444841d2b70ba322 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 20:20:51 -0800 Subject: [PATCH 03/12] Fix set_output_status -> set_output_mode --- src/static-guarantees/state-machines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/static-guarantees/state-machines.md b/src/static-guarantees/state-machines.md index c890b35..d86f4f7 100644 --- a/src/static-guarantees/state-machines.md +++ b/src/static-guarantees/state-machines.md @@ -79,7 +79,7 @@ impl Gpio { }); } - pub fn set_output_status(&mut self, is_high: bool) { + pub fn set_output_mode(&mut self, is_high: bool) { self.periph.modify(|_r, w| { w.output_mode.set_bit(is_high) }); From 290fb34964b7135e993a23c7893ab953a40b6d71 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 20:25:23 -0800 Subject: [PATCH 04/12] Refactor a sentence. --- src/static-guarantees/state-machines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/static-guarantees/state-machines.md b/src/static-guarantees/state-machines.md index d86f4f7..0cae514 100644 --- a/src/static-guarantees/state-machines.md +++ b/src/static-guarantees/state-machines.md @@ -91,7 +91,7 @@ impl Gpio { } ``` -However, this could allow us to modify certain registers that do not make sense. For example, what happens if we set the `output_mode` field when our GPIO is configured as an input? For some hardware, this may not matter, but on some hardware, it could cause unexpected or undefined behavior. +However, this could allow us to modify certain registers that do not make sense. For example, what happens if we set the `output_mode` field when our GPIO is configured as an input? For some hardware, this may not matter. On other hardware, it could cause unexpected or undefined behavior. This would allow us to reach states not defined by our state machine above: An output that is pulled low, or an input that was set high! From 4fe0ff4ec10c9b2884ca0edce5705afdf8ceaec4 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 20:57:00 -0800 Subject: [PATCH 05/12] Refactor and generalize - to avoid repetitive statements --- src/static-guarantees/state-machines.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/static-guarantees/state-machines.md b/src/static-guarantees/state-machines.md index 0cae514..b7c24f1 100644 --- a/src/static-guarantees/state-machines.md +++ b/src/static-guarantees/state-machines.md @@ -91,8 +91,8 @@ impl Gpio { } ``` -However, this could allow us to modify certain registers that do not make sense. For example, what happens if we set the `output_mode` field when our GPIO is configured as an input? For some hardware, this may not matter. On other hardware, it could cause unexpected or undefined behavior. +However, this would allow us to modify certain registers that do not make sense. For example, what happens if we set the `output_mode` field when our GPIO is configured as an input? -This would allow us to reach states not defined by our state machine above: An output that is pulled low, or an input that was set high! +In general, use of this structure would allow us to reach states not defined by our state machine above: e.g. an output that is pulled low, or an input that is set high. For some hardware, this may not matter. On other hardware, it could cause unexpected or undefined behavior! Although this interface is convenient to write, it doesn't enforce the design contracts set out by our hardware implementation. From 68fb2ba5b5880e6573ba41255b23b2d12f179ccd Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 21:16:54 -0800 Subject: [PATCH 06/12] Typo whch->which --- src/static-guarantees/design-contracts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/static-guarantees/design-contracts.md b/src/static-guarantees/design-contracts.md index ea3eae6..f0df219 100644 --- a/src/static-guarantees/design-contracts.md +++ b/src/static-guarantees/design-contracts.md @@ -97,7 +97,7 @@ impl Gpio { } ``` -Because we need to enforce the restrictions on the hardware, we end up doing a lot of runtime checking whch wastes time and resources, and this code will be much less pleasant for the developer to use. +Because we need to enforce the restrictions on the hardware, we end up doing a lot of runtime checking which wastes time and resources, and this code will be much less pleasant for the developer to use. ## Type States From bf13a6db6832da9c8f796f3f2f864d19640d34a6 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 21:19:15 -0800 Subject: [PATCH 07/12] Typo: defintely->definitely --- src/static-guarantees/design-contracts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/static-guarantees/design-contracts.md b/src/static-guarantees/design-contracts.md index f0df219..4a243be 100644 --- a/src/static-guarantees/design-contracts.md +++ b/src/static-guarantees/design-contracts.md @@ -245,7 +245,7 @@ output_pin.set_bit(false); // output_pin.into_input_pull_down(); ``` -This is defintely a convenient way to store the state of the pin, but why do it this way? Why is this better than storing the state as an `enum` inside of our `GpioConfig` structure? +This is definitely a convenient way to store the state of the pin, but why do it this way? Why is this better than storing the state as an `enum` inside of our `GpioConfig` structure? ## Compile Time Functional Safety From 20d9a21d138701e4ea232f18d2808ef932b5e5d5 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 21:56:54 -0800 Subject: [PATCH 08/12] Typo intialise->initialize --- src/portability/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/portability/index.md b/src/portability/index.md index 754ef63..77a2191 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -42,7 +42,7 @@ As said above there are three main users of the HAL: A HAL implementation provides the interfacing between the hardware and and the users of the HAL traits. Typical implementations consist of three parts: * One or more hardware specific types -* Functions to create and intialise such a type, often providing various configuration options (speed, operation mode, use pins, etc.) +* Functions to create and initialize such a type, often providing various configuration options (speed, operation mode, use pins, etc.) * one or more `trait` `impl` of **embedded-hal** traits for that type Such a **HAL implementation** can come in various flavours: From f85a8df4fa62aabb843ccc799d22228f62b7bc83 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 22:00:53 -0800 Subject: [PATCH 09/12] Typos: temperatur, arays, actors, relais -> temperature, arrays, actuators, relays --- src/portability/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/portability/index.md b/src/portability/index.md index 77a2191..e55000b 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -53,7 +53,7 @@ Such a **HAL implementation** can come in various flavours: ### Driver -A driver implements a set of custom functionality for an internal or external component, connected to a peripheral implementing the embedded-hal traits. Typical examples for such drivers include various sensors (temperature, magnetometer, accelerometer, light), display devices (LED arrays, LCD displays) and actors (motors, transmitters). +A driver implements a set of custom functionality for an internal or external component, connected to a peripheral implementing the embedded-hal traits. Typical examples for such drivers include various sensors (temperature, magnetometer, accelerometer, light), display devices (LED arrays, LCD displays) and actuators (motors, transmitters). A driver has to be initialised with an instance of type that implements a certain `trait` of the embedded-hal which is ensured via trait bound and provides its own type instance with a custom set of methods allowing to interact with the driven device. From 169f59eb7c2237b379146ee41f5e150ef00e4c35 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 22:02:32 -0800 Subject: [PATCH 10/12] Typo intialise->initialize --- src/portability/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/portability/index.md b/src/portability/index.md index e55000b..a5e24aa 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -59,4 +59,4 @@ A driver has to be initialised with an instance of type that implements a certai ### Application -The application binds the various parts together and ensures that the desired functionality is achieved. When porting between different systems, this is the part which requires the most adaptation efforts, since the application needs to correctly intialise the real hardware via the HAL implementation and the initialisation of different hardware differs, sometimes drastically so. Also the user choice often plays a big role, since components can be physically connected to different terminals, hardware buses sometimes need external hardware to match the configuration or there are different trade-offs to be made in the use of internal peripherals (e.g. multiple timers with different capabilities are available or peripherals conflict with others). +The application binds the various parts together and ensures that the desired functionality is achieved. When porting between different systems, this is the part which requires the most adaptation efforts, since the application needs to correctly initialize the real hardware via the HAL implementation and the initialisation of different hardware differs, sometimes drastically so. Also the user choice often plays a big role, since components can be physically connected to different terminals, hardware buses sometimes need external hardware to match the configuration or there are different trade-offs to be made in the use of internal peripherals (e.g. multiple timers with different capabilities are available or peripherals conflict with others). From 84e5976fed82ef68da6446f6d48fbb2d51b03d24 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 22:03:59 -0800 Subject: [PATCH 11/12] Consistency: initialised->initialized --- src/portability/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/portability/index.md b/src/portability/index.md index a5e24aa..cfbd1d7 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -55,7 +55,7 @@ Such a **HAL implementation** can come in various flavours: A driver implements a set of custom functionality for an internal or external component, connected to a peripheral implementing the embedded-hal traits. Typical examples for such drivers include various sensors (temperature, magnetometer, accelerometer, light), display devices (LED arrays, LCD displays) and actuators (motors, transmitters). -A driver has to be initialised with an instance of type that implements a certain `trait` of the embedded-hal which is ensured via trait bound and provides its own type instance with a custom set of methods allowing to interact with the driven device. +A driver has to be initialized with an instance of type that implements a certain `trait` of the embedded-hal which is ensured via trait bound and provides its own type instance with a custom set of methods allowing to interact with the driven device. ### Application From d2bc7a695199eb94531e1bc96b87fea53c9304a1 Mon Sep 17 00:00:00 2001 From: Nathan <2266858+njmartin10@users.noreply.github.com> Date: Tue, 6 Nov 2018 22:05:38 -0800 Subject: [PATCH 12/12] Remove duplicate "and" --- src/portability/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/portability/index.md b/src/portability/index.md index cfbd1d7..1e1f03b 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -40,7 +40,7 @@ As said above there are three main users of the HAL: ### HAL implementation -A HAL implementation provides the interfacing between the hardware and and the users of the HAL traits. Typical implementations consist of three parts: +A HAL implementation provides the interfacing between the hardware and the users of the HAL traits. Typical implementations consist of three parts: * One or more hardware specific types * Functions to create and initialize such a type, often providing various configuration options (speed, operation mode, use pins, etc.) * one or more `trait` `impl` of **embedded-hal** traits for that type