From a1c72445483fd86bb6bf0e305c63d8d9b737d706 Mon Sep 17 00:00:00 2001 From: Adam Green Date: Mon, 19 Nov 2018 01:25:04 -0800 Subject: [PATCH] Few typo fixes I fixed a few more typos I noticed as I finished my first read through of the Embedded Rust Book. My editor also deleted some trailing white space from a few lines when I saved out my typo fixes. --- src/interoperability/c-with-rust.md | 2 +- src/portability/index.md | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/interoperability/c-with-rust.md b/src/interoperability/c-with-rust.md index 2eadfdb..e0da5e7 100644 --- a/src/interoperability/c-with-rust.md +++ b/src/interoperability/c-with-rust.md @@ -58,7 +58,7 @@ pub x: cty::c_int, pub y: cty::c_int, ``` -Due to the flexibility of how C or C++ defines an `int` or `char`, it is recommended to use primative data types defined in `cty`, which will map types from C to types in Rust +Due to the flexibility of how C or C++ defines an `int` or `char`, it is recommended to use primitive data types defined in `cty`, which will map types from C to types in Rust ```rust pub extern "C" fn cool_function( ... ); diff --git a/src/portability/index.md b/src/portability/index.md index 6451f40..626987d 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -5,8 +5,8 @@ In embedded environments portability is a very important topic: Every vendor and A common way to equalize such differences is via a layer called Hardware Abstraction layer or **HAL**. > Hardware abstractions are sets of routines in software that emulate some platform-specific details, giving programs direct access to the hardware resources. -> -> They often allow programmers to write device-independent, high performance applications by providing standard operating system (OS) calls to hardware. +> +> They often allow programmers to write device-independent, high performance applications by providing standard operating system (OS) calls to hardware. > > *Wikipedia: [Hardware Abstraction Layer]* @@ -18,7 +18,7 @@ How do we do this in Rust? Enter **embedded-hal**... ## What is embedded-hal? -In a nutshell it is a set of traits which define implementation contracts between **HAL implementations**, **drivers** and **applications (or firmwares)**. Those contracts include both capabilities (i.e. if a trait is implemented for a certain type, the **HAL implementation** provides a certain capability) and methods (i.e. if you can construct a type implementing a trait it is guarenteed that you have the methods specified in the trait available). +In a nutshell it is a set of traits which define implementation contracts between **HAL implementations**, **drivers** and **applications (or firmwares)**. Those contracts include both capabilities (i.e. if a trait is implemented for a certain type, the **HAL implementation** provides a certain capability) and methods (i.e. if you can construct a type implementing a trait it is guaranteed that you have the methods specified in the trait available). A typical layering might look like this: @@ -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 (temperatur, magnetometer, accelerometer, light), display devices (LED arays, LCD displays) and actors (motors, relais). +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, transmitter). 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.