Hello everyone. A typical work week. Let’s go over everything.
PocketBeagle 2 Examples
Continuing the work from last week, I finished adding Python examples for all the prior Rust examples. I have also added a lot of new examples, mostly centered around the hardware available in TechLab cape for PocketBeagle 2.
EEPROM
I already had a Rust example to parse Beagle EEPROM contents. A python version for the example has also been added. I have also introduced BeagleEeprom type in both the Rust and Python helper libraries to make it easier for other people to extend. I also ended up learning about struct module in python, which ended up being better than I expected. I still prefer Rust and C for packed structs, but at least python has something.
Here is the Python example running:
debian@pocketbeagle2:~/vsx-examples/PocketBeagle-2/eeprom/python$ python main.py
BeagleEeprom(magic_number=(170, 85, 51, 238),
hdr1=Header(hdr_id=1, length=55),
hdr2=Header(hdr_id=16, length=46),
board_info=BoardInfo(name='POCKETBEAGL2A00G',
version='A0',
proc_number='0000',
variant='0G',
pcb_revision='A0',
schematic_bom_revision='A0',
software_revision='00',
vendor_id='01',
build_week='02',
build_year='25',
serial='PB20000183'),
hdr3=Header(hdr_id=17, length=2),
ddr_info=4776,
termination=254)Photo Diode
TechLab cape has a Photo Diode attached to pin P1.19. I have added Python and Rust examples to use the Photo Diode to detect whether it is dark or light, based on a threshold. The helper library also contains LightSensor for general usage. The full details can be found in the following PR.
It would be nice to write a Photo Diode kernel driver at some point, since currently the examples are directly reading ADC values.
Seven Segments
TechLab cape has two 7-segment displays. The displays are connected to MCP23S18, an IO extender, which is connected to PocketBeagle 2 over SPI. After a bit of grepping, I found that the upstream kernel already has a driver for seven segment displays, so I am using it instead of driving the GPIOs from userspace. The full details can be found in the following PR.
Currently, both the 7-segment displays are driven by separate drivers, since there does not exist a 14-segment GPIO driver for now. The subsystem seems to have support for 14 segment, so maybe it would be useful to write one.
Tonal Buzzer
TechLab cape has a buzzer connected to pin P2.30. Since the pin does not have hardware PWM, and producing notes only really needs 50% duty cycle at comparatively low frequencies, I am using the pwm-gpio driver. The full details can be found in the following PR.
The example currently plays Hedwig’s theme from the Harry Potter Movies, which is ported from an Arduino example. I might end up adding the buzzer as an alsa device in the future, but let’s see how that goes.
RGB LED
TechLab cape has an RGB LED. I am using the led-pwm-multicolor driver. The full details can be found in the following PR.
The example cycles through different hues.
TechLab Cape Devicetree Overlay
The PocketBeagle 2 examples, specially when using TechLab Cape need a devicetree overlay for some specific pinmux and devices such 7-segments, RGB Led, etc. The overlay can be found in the following PR. This overlay will be present in new distro images going forward.
Devicetree Compiler support for /./
Normally, node properties in devicetree can only be replaced with new ones. A lot of hardware devicetrees actually include base devicetrees for SOCs, etc. However, to add some new values to properties, such as adding some extra clocks, pinumx, etc. would require copying all the values from the included devicetree. This could become inconvenient and can allow things to go out of sync.
A few months ago, I sent a patch series a few months ago to add capability to append properties instead of overriding them. In that patch series, there was discussion regarding something more flexible, with a popular option being able to use the old value to construct the new property value. This will allow a lot of usecases such as appending, pre-appending, duplicating, etc.
In practice, it looks as follows:
dts-v1/;
/ {
str-prop = "0";
};
/ {
/* append */
str-prop = /./, "1";
};
/ {
/* pre-append */
str-prop = "1", /./;
};
/ {
/* duplicate */
str-prop = /./, /./;
};The full patch series can be found here.
Devicetree Specification export-symbols
I have been pursuing various possible methods to allow upstream drivers for connector add-on-board setups such as MikroBUS, Beagle Capes, etc. The current favorite seems to be export-symbols.
It was initially proposed by Herve Codina and seems to be quite useful even outside add-on-board setups. At the basic level, export-symbols provide a way to define symbols local to the node, and can be used by any overlay or devicetree include that uses the node as target.
This in turn allows creating overlays for add-on-boards using generic names for the nodes such SPI, I2C, etc. instead of knowing about the device it is being applied to. Thus, the same overlay can be used across multiple connectors in different devices.
The initial proposal was for Linux kernel, but since I would like to use the same setup in ZephyrRTOS as well, I have been trying to make export-symbols a standard devicetree node. I already had patch series to add support to dtc and fdtoverlay as a proof of concept.
The full patch for adding it to the devicetree secification can be found here. Feel free to chime in if the topic interests you.
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.