From 268a76be638908c6b4d206f2839a641c96303d95 Mon Sep 17 00:00:00 2001 From: Daniel Egger Date: Wed, 14 Nov 2018 23:26:14 +0100 Subject: [PATCH 1/2] Mention complexity benefits by using embedded-hal --- src/portability/index.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/portability/index.md b/src/portability/index.md index 615c397..2378e4a 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -28,6 +28,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 reusablility 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 sticking to the *API* provided by the **embedded-hal** traits will reduce the implementation complexity to **M+N**. Of course there're additional benefits to be had like 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: From 38188af8fad1545697e70267982a29ec2cab6457 Mon Sep 17 00:00:00 2001 From: Emil Fresk Date: Sun, 18 Nov 2018 18:07:39 +0100 Subject: [PATCH 2/2] Update src/portability/index.md Co-Authored-By: therealprof --- 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 2378e4a..8d681c9 100644 --- a/src/portability/index.md +++ b/src/portability/index.md @@ -28,7 +28,7 @@ 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 reusablility 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 sticking to the *API* provided by the **embedded-hal** traits will reduce the implementation complexity to **M+N**. Of course there're additional benefits to be had like less trial-and-error due to a well-defined and ready-to-use APIs. +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