document/embbed-rust
2
0
Fork 0
mirror of https://github.com/nkbai/book.git synced 2026-09-05 22:14:54 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge #83

Browse Source 
83: Mention complexity benefits by using embedded-hal r=jamesmunns a=therealprof



Co-authored-by: Daniel Egger <daniel@eggers-club.de>
Co-authored-by: Emil Fresk <emil.fresk@gmail.com>
This commit is contained in:
bors[bot]
2018-11-18 17:14:16 +00:00
parent 863447366b 38188af8fa
commit 6a7b4037ed
1 changed files with 2 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/portability/index.md
View File

@@ -32,6 +32,8 @@ Some of the defined traits in **embedded-hal** are:
* Timers/Countdowns
* Analog Digital Conversion
The main reason for having the **embedded-hal** traits and crates implementing and using them is to keep complexity in check. If you consider that an application might have to implement the use of the peripheral in the hardware as well as the application and potentially drivers for additional hardware components, then it should be easy to see that the re-usability is very limited. Expressed mathematically, if **M** is the number of peripheral HAL implementations and **N** the number of drivers then if we were to reinvent the wheel for every application then we would end up with **M*N** implementations while by using the *API* provided by the **embedded-hal** traits will make the implementation complexity approach **M+N**. Of course there're additional benefits to be had, such as less trial-and-error due to a well-defined and ready-to-use APIs.
## Users of the embedded-hal
As said above there are three main users of the HAL: