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.
This commit is contained in:
Adam Green
2018-11-19 01:25:04 -08:00
parent 6a7b4037ed
commit a1c7244548
2 changed files with 5 additions and 5 deletions

View File

@@ -58,7 +58,7 @@ pub x: cty::c_int,
pub y: 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 ```rust
pub extern "C" fn cool_function( ... ); pub extern "C" fn cool_function( ... );

View File

@@ -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**. 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. > 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]* > *Wikipedia: [Hardware Abstraction Layer]*
@@ -18,7 +18,7 @@ How do we do this in Rust? Enter **embedded-hal**...
## What is 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: A typical layering might look like this:
@@ -53,7 +53,7 @@ Such a **HAL implementation** can come in various flavours:
### Driver ### 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. 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.