Skip to content

Conversation

@kiarie404
Copy link
Contributor

@kiarie404 kiarie404 commented Jan 10, 2024

Description :
This repo will act as a reception for other related things eg Embedded-Resources-Repo and Driver-Development-Repo

To this effect, all development files were removed EXCEPT the read_me and Licence. This was done in the 1st commit

In the 2nd commit, I have added a link to the driver-development-book repo

Description :
This repo will act as a reception for other related things eg Embedded-Resources-Repo and Driver-Development-Repo

To this effect, all development files were removed EXCEPT the read_me and Licence
@448-OG
Copy link
Member

448-OG commented Jan 11, 2024

I think we should create a Book within this repository with the chapters on resources and a chapter for each driver since these are unofficial drivers and embedded resources for learning.

Then each driver would be it's own crate within this repository as a Cargo workspace. That way we can have shared resources like a traits and common data structures crate that is generic over all drivers or boards and then have a seperate crate for each specific board target within the same workspace.

For example, we can have a common trait crate that have methods for lighting up LEDs, connecting to WIFI and Bluetooth and communicating with GPIO pins and then within the same workspace we have a crate for ESP32 board which implements the common traits but extends them based on eg the layout of the GPIO pins specific to the ESP32 board.
We can also have a raspberry pi crate within the same workspace that extends the same trait methods but for raspberry pi.

You see both the esp32 and raspberry pi would re-use the same code and only add code for the parts that are specific to each board.

That way:

  1. We reuse the common code for all boards
  2. We reduce code boilerplate since we are not duplicating the same code in different repositories
  3. Someone can just read the book within the cargo workspace and find all crates within the workspace making it easier
  4. We reduce compile times since all crates under the same workspace and therefore share the same build cache in the same target directory where cargo store all the cache
  5. Easier to maintain since we reuse the same workflows for github actions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants