Just a tip that may help you a bit. It’s useful to separate the abstraction (embedded-hal) from the implementation (device-hal) in your mind. The abstraction can not possibly know how to instantiate a peripheral because that is device specific and, therefore, depends on the implementation crate. Because every MCU has different peripherals and registers, each impl crate will necessarily have different ways of instantiating peripherals. I would recommend writing a driver crate that only relies on the embedded-hal abstraction then pulling it in and using it in your board specific application to get a feel for the benefits and why it’s done this way.
Also, did you find the Discovery Book? It was written with embedded beginners in mind.
That said, there are definitely some problems with the embedded-hal abstraction and you hit on one of them, the lack of interrupt/async support. Not that it’s an easy problem to solve, it’s not.
Great tip! I'll keep that in mind. Thanks Christopher! Actually the Discovery Book with the F3 board was the first one I chose to read as I embarked on my Journey and it helped me a great deal. If I recall properly though, the Discovery book was closer to the PAC level with some abstractions introduced from an auxiliary crate. The PAC I actually didn't have much of an issue dealing with. The auxiliary crate at the beginning was a bit confusing though as I didn't know what to make of it, meaning was it a HAL following the embedded-hal approach or something else.
As for the Discovery book with the micro::bit, I found very useful but I really felt various areas lacked depth. Although there was no PAC level, there was sort of a mishmash of Board level and HAL level code. Several things in the book I could not comprehend until later when I got more acquainted with embedded Rust..
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Just a tip that may help you a bit. It’s useful to separate the abstraction (embedded-hal) from the implementation (device-hal) in your mind. The abstraction can not possibly know how to instantiate a peripheral because that is device specific and, therefore, depends on the implementation crate. Because every MCU has different peripherals and registers, each impl crate will necessarily have different ways of instantiating peripherals. I would recommend writing a driver crate that only relies on the embedded-hal abstraction then pulling it in and using it in your board specific application to get a feel for the benefits and why it’s done this way.
Also, did you find the Discovery Book? It was written with embedded beginners in mind.
That said, there are definitely some problems with the embedded-hal abstraction and you hit on one of them, the lack of interrupt/async support. Not that it’s an easy problem to solve, it’s not.
Great tip! I'll keep that in mind. Thanks Christopher! Actually the Discovery Book with the F3 board was the first one I chose to read as I embarked on my Journey and it helped me a great deal. If I recall properly though, the Discovery book was closer to the PAC level with some abstractions introduced from an auxiliary crate. The PAC I actually didn't have much of an issue dealing with. The auxiliary crate at the beginning was a bit confusing though as I didn't know what to make of it, meaning was it a HAL following the embedded-hal approach or something else.
As for the Discovery book with the micro::bit, I found very useful but I really felt various areas lacked depth. Although there was no PAC level, there was sort of a mishmash of Board level and HAL level code. Several things in the book I could not comprehend until later when I got more acquainted with embedded Rust..