I’m trying to connect a wittyPi to power and control the LePotato on a set schedule. I use the command “sudo ldto enable i2c-ao” to activate the correct bus (i2c-1) for the wittyPi. Running the command “sudo i2cdetect -y 1” I get the right address of 68 and 69 for the wittyPi. I want this to be permanent, so I ran “sudo ldto merge i2c-ao” and did a reboot. However, the merge swaps the i2c-0 and i2c-1 buses. The wittyPi is now on i2c-0 and I have to change the code for the wittyPi’s software to adapt for this and I’m running into other problems because of that. Is there a reason the merge is doing this? How do I make it permanent and have the same results as the enable command? I am a relative SBC newb and any help is appreciated. Thank you!
i2c busses or any other bus added after boot are incremented. Before boot, it is detected in sequence from the DT probe. That is why the numbering is different.
Is it possible to disable the DesignWare HDMI I2C adapter? I’m working with a python library (Sparkfun Qwiic) that doesn’t appear to support selecting a specific I2C bus. It always selects the first bus which is the HDMI I2C bus. Is there an overlay specific to the HDMI I2C adapter that can be disabled, leaving only the i2c-ao overlay as active? Thanks.
You can definitely select the I2C bus. It’s part of accessing the I2C bus. Disabling the HDMI I2C is not the right way to do it.
I ran into this with Blinka and the busio module, I had to switch to adafruit_exteded_bus in order to specify a device. If Sparkfun doesn’t have a module to do that, consider Adafruit CircuitPython instead.
Also, if you merge the dto instead of enabling it, the device numbers will switch (at least it did for me). It’s still not the right way to do it, but if you need it to work immediately, it might be a quick band-aid fix. Better than disabling something anyhow.
Just make sure learn to do it the proper way too, because relying on a bug (or at least something that wasn’t intended behavior) long-term is not maintainable practice (for much the same reason as @librecomputer not wanting you to disable the HDMI adapter).
Also, if you don’t mind, what is the device you’re trying to connect? There may already be a library or diver for it.
Thanks, @angus. I also noticed the order swaps when merging and that did help me test to ensure the hardware was working. The device is a Qwiic LCD module. I’ll look into the Adafruit CircuitPython software and see if I can’t tie into that in some way.
@librecomputer I’d argue disabling the HDMI adapter is acceptable in my case since this setup will never utilize the HDMI adapter. Maybe not the best solution specific to the I2C bus problem, but it would be acceptable for me.
Yup, seems to be supported:
https://sparkfun-circuitpython-serlcd.readthedocs.io/en/latest/
Here the guide for adafruit_extended_bus:
Let me know if it works for you.
How do I permanently set my overlay so it works on boot since the ldto enable uart-a is working temporarily?
First I did sudo ldto reset and rebooted
Next after reboot I did sudo ldto merge uart-a then rebooted
After reboot sudo ldto status showed no active overlays when I would expect uart-a to be present in the list unless I am misunderstanding the use case of the merge command.
Once it’s merged, it is no longer using the dynamic device tree overlays. It becomes a static base device tree within the system and thus ldto doesn’t know about it.
Understood thank you. Can confirm it is working despite ldto status showing no active overlays after doing the merge.
Where are the overlay files located? I need to convert my gpio layout from RPi and it has been a bit challenging. I need spidev.0 as well as an output bit to reset a quad uart and an incoming interrupt request line. Is there a noob guide for building overlays?
SPI is easy: sudo ldto enable spicc-cs1
There are tons of overlays already and you can just look through them to see how they work. GitHub - libre-computer-project/libretech-wiring-tool
Does that command permanently add the SPI pins to my device tree? Where are overlays normally stored on the controller?
Read the OP, this is covered there already.
Please forgive my ignorance: What is an “OP”, where can it be had? I did attempt man ldto to no avail. Also, I noticed that after I applied the overlay I did not see the pins appear in the output of gpioinfo even though ldto status shows spicc-cs1 as active. Thanks for your kind patience.
Original post. Just scroll up using the scroll bar. It goes over ldto basics.
SPI is not GPIO. Raspberry Pi stuff is a confusing mess of ideas.
GPIO is general purpose IO. SPI bus is serial peripheral interface. SPI shows up as /dev/spidevx.y. Best not to get the concepts confused.
Roger that on the RPI being a mess. I do see line 89: “7J1 Header Pin24” “spi0 CS0” output active-low [used] appears in the output of gpioinfo thus my confusion. Regarding the UART reset and interrupt line that I need I see that they are listed as lines 85 and 95 respectively (albeit unused) which suggests that I should be able to use libgpiod to set them up. Am I to assume that once I set them up with libgpriod functions that they will transition into “used”?
The answer is that it depends.
If your device has a Linux kernel driver, the driver should handle the reservation of the pin functions. You create a device tree and provide the driver what it needs (GPIO, interrupts, pinmux, clocks, etc). Everything is done in kernel space.
If you are handling a portion of it in userspace or completely in userspace, that’s a different ball game. libgpiod is a userspace library so it really can’t reserve anything in kernel space. /dev/spidev0.0 is an userspace interface for the kernel SPI driver. You need to separately enable it via ldto enable spicc-cs1-spidev. This has 2 CS (pin 24 and pin 26). If you don’t need the CS, you can use spicc and spicc-spidev overlays. spicc/spicc-cs1 enables the SPI device. spicc/spicc-cs1 spidev enable the SPI device userspace interface (/dev/spidevx.y). Hope that makes sense.
We provide a tool called lgpio and you can use it to manually toggle pins and such. It can also convert header/pin combinations to libgpiod numberings for you to use in python or whatever userspace application you have interacting with the GPIO kernel interface. The documentation is also in the OP.