Woohoo! I really love the Nerves project. I have been slowly working on a project to build a rpi4 powered motorcycle racing timer. The goal was to use sensor fusion to get high accuracy. A friend of mine is a semi-pro motorcycle racer and didn't want to pony up for an Aim Solo device. I bit off a lot more than I could chew: learning elixir, i2c and embedded device programming simultaneously. I didn't see any libraries for interacting with Ublox GPS devices so I started writing my own. Learning how to read a datasheet, how to read/parse/construct binary messages and control the state of the various devices. I made the gradient too steep for myself and ended up kinda abandoning everything. Friend ended up buying the Aim Solo :(
I eventually did get the API to a stable enough point where I could power on the device, configure it as needed, and then read a constant stream of positioning/time data. My next steps are probably the easy part (sending the data up to an API, or collecting it internally for the sensor fusion bits), but I am kinda burned out. I am probably over thinking it - I shouldn't hold myself to such a high standard since I am learning so many new concepts at once.
I'm definitely going to grab this book. I have been in software for a long time but have never done low-level driver/device programming so I don't know the "idomatic" way to do things. For instance, a lot of devices need to warm up, then get configured to operate a certain way, and then you can read data from them. But I am used to request/response style programming, not dealing with a shared memory space that the you and the device are both reading/writing from together. I'm also completely in love with the actor model, but coming from a more traditional background struggle here with intuition on how to structure supervisors and such.
I eventually did get the API to a stable enough point where I could power on the device, configure it as needed, and then read a constant stream of positioning/time data. My next steps are probably the easy part (sending the data up to an API, or collecting it internally for the sensor fusion bits), but I am kinda burned out. I am probably over thinking it - I shouldn't hold myself to such a high standard since I am learning so many new concepts at once.
I'm definitely going to grab this book. I have been in software for a long time but have never done low-level driver/device programming so I don't know the "idomatic" way to do things. For instance, a lot of devices need to warm up, then get configured to operate a certain way, and then you can read data from them. But I am used to request/response style programming, not dealing with a shared memory space that the you and the device are both reading/writing from together. I'm also completely in love with the actor model, but coming from a more traditional background struggle here with intuition on how to structure supervisors and such.