This click uses two GPIO, mapped to CS and PWM.
using gpioinfo gpiochip3 the mikrobus pins all show used due to mikrobus driver.
line 7: "MIKROBUS_GPIO1_7" "mikrobus" output active-high [used]
line 8: "MIKROBUS_GPIO1_8" "mikrobus" output active-high [used]
line 9: "MIKROBUS_GPIO1_9" "mikrobus" output active-high [used]
line 10: "MIKROBUS_GPIO1_10" "mikrobus" output active-high [used]
line 11: "MIKROBUS_GPIO1_11" "mikrobus" output active-high [used]
line 12: "MIKROBUS_GPIO1_12" "mikrobus" output active-high [used]
line 13: "MIKROBUS_W1_GPIO0" "w1-gpio.0" output active-high [used open-drain]
line 14: "MIKROBUS_GPIO1_14" "mikrobus" output active-high [used]
line 15: unnamed unused input active-high
line 16: unnamed unused input active-high
line 17: unnamed unused input active-high
line 18: unnamed unused input active-high
line 19: "VDD_3V3_SD" "regulator-4" output active-high [used]
line 20: unnamed unused input active-high
line 21: unnamed unused input active-high
line 22: "MIKROBUS_GPIO1_22" "mikrobus" output active-high [used]
line 23: "MIKROBUS_GPIO1_23" "mikrobus" output active-high [used]
line 24: "MIKROBUS_GPIO1_24" "mikrobus" output active-high [used]
line 25: "MIKROBUS_GPIO1_25" "mikrobus" output active-high [used]
What is the idiomatic way to access these GPIO with the mikrobus driver present?
My preference for this use case would be to use libgpiod after disabling the mikrobus driver.
I don’t recall the BP board having that many gpio pins on the mikro board click connector. That might be pins on the din connector??
Have not tried it however you should be able to control with gpioset with gpiochip and line. Might look over the .dts and see what they have going on. Hard to guess without looking it over, if they are fanning it out with a i2c and mux just delete the overlay and use your own overlay, this is all a guess on this end.
gpio pins marked as used can’t be set using gpioset; hence the question.
debian@BeaglePlay:~$ gpioset gpiochip3 7=1
gpioset: error setting the GPIO line values: Device or resource busy
debian@BeaglePlay:~$ gpioset gpiochip3 7=0
gpioset: error setting the GPIO line values: Device or resource busy
debian@BeaglePlay:~$ gpioget gpiochip3 7
gpioget: error reading GPIO values: Device or resource busy
Click RELAY pinout:
Pretty sure you can just rip out their device tree and make your own. Don’t remember why, that board is just not a good fit for us so not much was done for it. Did you try
$sudo gpioset gpiochip3 7=1
$sudo gpioset gpiochip3 7=0
Looks like you are user not root so that will also give you resource busy.
What is showing is more than likely just node labels, and the actual port is more than likely not turned on so sudo will not matter much.
You will have to poke around in the .dtsi and .dts and the HAL to find out what is going on. If memory is correct you will have to sift out the real data needed since it has a couple of HAL (Hardware abstraction layers).
If you clone the beagleboard device tree it will be in one location. If you need to compile a new device tree you will need to do that in the tree. Find the base .dtsi, it will be the one you see when on the debug port as FDT. And all the includes are in the bbdt clone, just follow the trail…
Looking at the example code
void applicationTask()
{
relay_relay2Control ( 1 );
relay_relay1Control( 1 );
mikrobus_logWrite("Relays turned on", _LOG_LINE);
Delay_ms(1000);
relay_relay2Control ( 0 );
relay_relay1Control( 0 );
mikrobus_logWrite("Relays turned off", _LOG_LINE);
Delay_ms(1000);
}
If you don’t have really tight timing for the gpio you would be better in the long run spending the $22. Looks like the driver they have provided is very clean based upon their example. Just a proof of concept, just buy the board and get it up and running.
I believe what you’re looking for is those 2 overlays:
k3-am625-beagleplay-release-mikrobus-set-gpios-all.dtbo sets all the pins to GPIO
k3-am625-beagleplay-release-mikrobus-set-native.dtbo sets them to PWM, I2C, SPI etc.
Once you load that and make sure the driver is unloaded you should be able to use libgpiod fine.
/boot/firmware/overlays$ ls | grep "k3-am625"
k3-am625-beagleplay-bcfserial-no-firmware.dtbo
k3-am625-beagleplay-csi2-ov5640.dtbo
k3-am625-beagleplay-lt-lcd185.dtbo
k3-am625-beagleplay-release-mikrobus.dtbo
k3-am625-beagleplay-release-mikrobus-set-gpios-all.dtbo
k3-am625-beagleplay-release-mikrobus-set-native.dtbo
1 Like
Do you recall the name of the driver for the microbus?
Looks like OP is ready to go, that is nice having those overlays.
It should be greybus something or another… that’s what underlying tech spun from Google’s Project Ara.
Exactly what I was looking for. Thank you!
If you don’t mind sharing, where did you find those overlays. They are not in the latest factory image, this all that is included:
fred@bp1:/boot/firmware/overlays$ ls | grep "k3-am625"
k3-am625-beagleplay-csi2-ov5640.dtbo
k3-am625-beagleplay-csi2-tevi-ov5640.dtbo
k3-am625-beagleplay-grove-connector0.dtbo
k3-am625-beagleplay-grove-connector1.dtbo
k3-am625-beagleplay-lincolntech-lcd185-panel.dtbo
k3-am625-sk-dmtimer-pwm.dtbo
k3-am625-sk-ecap-capture.dtbo
k3-am625-sk-lincolntech-lcd185-panel.dtbo
k3-am625-sk-m2-cc3301.dtbo
k3-am625-sk-mcspi-loopback.dtbo
k3-am625-sk-microtips-mf101hie-panel.dtbo
k3-am625-sk-pwm.dtbo
k3-am625-sk-rpi-hdr-ehrpwm.dtbo
He’s referencing 5.10.x based kernel… For 6.6.x which you have, i’m moving to just use libgpiod to talk to the pins directly…
So, as the connector is marked, that should be out of the box as identified on the connector. Then if mux’d to gpio that would require an overlay. I/O is the next way point, been working on setting up weston on the minimal image so the I/O is next.
That seems way more confusing. Myself, the old fashioned way of the simple uEnv.txt is the best. Its simple and straightforward. If the base devicetree is fully defined then overlays are simple to do.
Have you tried trixie RT on the BP? Got it on the 625evm and so far it looks good.
