Libre Computer Wiring Tool

Following line is a bit misleading, I would add # before temporarily.

sudo ldto enable OVERLAY temporarily
1 Like

Fixed the typo on that line.

I am getting some weird results while running these commands (on a potato running ubuntu 22.04.1 server). I have a setup with an LED hooked up to the main GPIO header pins to see the results. The set commands work as expected, I am able to set the pin to high and low and observe the expected on and off of the LED. So setting the pin level manually seems to be fine.

However, when I try to get the status of the pin after changing it (since I want to read button presses using the GPIO pins), the status always comes back as high (1), even when I have just set it to be low (0).
So I get results like this:

$ sudo lgpio set 40=0
$ sudo lgpio get 40
1

The other interesting thing is that when I do this with my LED that is hooked up to the GPIO pin whose state I am changing, when I set the pin to 0 the LED goes completely off, but when I do the get on the pin the LED comes on just ever so faintly. So it seems like the get does actually change the state of the pin (I had no idea this was a quantum computer!) which might be why it always returns high.

I have tried this with both lgpio and gpioset and get the same results. Any idea how to properly read the state?

GPIO set is output mode. GPIO get is input mode. Your understanding of GPIOs is incorrect.

You keep track of your own pin state.

@librecomputer I have two probably very basic questions about the device tree on a ROC-RK3328-CC, which I didn’t think deserved their own thread, but happy to make one.

  1. The Raspian image for ROC-RK3328-CC (as best I can tell) ships with all of the PWM nodes disabled. What’s the purpose/benefit of having available hardware disabled by default? For example, does it save power or resources? Increase security? I’ve been reading a lot about device trees over the last couple of days, and haven’t found a good explanation for this, even though it seems fairly common across many boards and devices.

  2. Ultimately (I think), the DT nodes need to get very specific about actual hardware characteristics of the SOC or board; something like a memory address. Having read through the datasheets for the ROC-RK3328-CC, the RK3328, etc, I see a lot of useful information about the hardware, but I haven’t been able to find the specific hardware values present in the DTB. How would someone creating the device tree for a chip or board from scratch know or find those values, if they aren’t provided in the reference material?

  1. A single pin can have multiple hardware functions outside of a simple GPIO. The hardware functions must be enabled and disabled according to the application needs for that GPIO.
  2. Reference existing overlays. This is covered in kernel documentation. Each board vendor can have different implementation.

Hello, is there a simple guide somewhere on how to set outputs or query inputs in NODE-RED on the AML-905X-CC?
I tried to install “node-red-contrib-libgpiod” or “node-red-contrib-roadrunner” without success. I can’t find any “gpio-in” or “gpio_out” nodes. Please help

Does this tool have any sort of mechanism for driving the GPIOCLK_0 through one of the SoC’s PLLs? On the Pi this can be done with the WiringPi tool, as follows:

gpio mode 7 clock ; gpio clock 7 1000000

To output a roughtly 1MHz clock. Reading through the S905X datasheet I see that there are registers for driving this pin. At the very least I would like to be able to set gpioCLK_0_xtal to 1 on the HHI_XTAL_DIVN_CNTL register in order to measure overall system clock performance via an external frequency counter.

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?

It says it in the original post @Nicholas_Ferrara

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.