Hello everyone. This was a light week since I had college exams. Let’s go over everything.
PocketBeagle 2 Examples
I have been working on Rust examples for PocketBeagle 2 as evident from my past posts. However, a lot of examples ended up being more complicated than they should be, specially for new users. Additionally, Rust being a compiled language might not be suitable for fast prototyping. Maybe cranelift, can solve this problem, but I have not explored it enough to say yet. Additionally, it seems to require nightly, which I do not want to impose right now.
So, following the industry, I have also started adding examples in Python. Being probably one of the most popular scripting language, it seemed like the safe choice.
Additionally, I have started working on beagle_linux_sdk libraries for both Rust and Python. They are inspired by gpiozero for Raspberry Pi. Since beagle_linux_sdk is intentionally designed to be as high level and easy to use as possible, it allows making both the Rust and Python examples a lot more simple and readable. The plan is to push the libraries to PYPI and crates.io once things are bit more stable.
As of writing this post, the updated examples are still in open PR. But they should be merged quite soon.
Dynamic Devicetree overlays from userspace
While working on PocketBeagle 2 examples, I have started to realize how useful userspace application for devicetree overlays can be for single board computers. Some of the z that I envision are as follows:
- Dynamic Pin muxing: A lot of SBC’s aimed for creating hardware projects expose headers, where each pin can be used for multiple things like GPIO, I2C, PWM, etc, depending on the pinmux. I think Raspberry Pi has it’s own solution to do userspace pinmux, but if userspace devicetree application was a thing, it could probably be used for this. Additionally, being able to use dynamic devicetree overlays for pin muxing would allow much easier transition to use proper device trees during production.
- Dynamic Sensors/Devices: Using devices such as sensors, external ADCs, EEPROMs, etc are also a common usecase in SBC’s. A lot of current solutions seem to be designed around using user-space drivers in such cases. This is a bit of a shame since Linux kernel already has drivers for a lot of these drivers, and they are probably going to be of higher quality than most user space drivers.
There have been attempts in the past(OF: DT-Overlay configfs interface (v3) and of/overlay: sysfs based ABI for dt overlays), but it seems like they never went anywhere.
I have started a discussion to see if I can find out what the reasons for the rejection were. Maybe things have changed by now, since the last patch series seems to be from 2017.
Ending Thoughts
This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.