@SpiderKenny Yes fastgpio is better but I showed code that uses the file system instead as I'm not sure of your level of experience and this method is easy to implement.

Hi all, As a follow up to this, the Omega2 LTE has been working well utilizing power through the GPIO pins. We have discovered an issue however with using a LiPo battery as a back up. The LiPo happily runs the board as expected, but the charging circuit is not working. Is there a way we can power the charging circuit from the 5V GPIO pins?

Can you profile digitalWrite function only? Like this, while(1) { digitalWrite(PWM_LEFT_PIN,0); digitalWrite(PWM_LEFT_PIN,1); } With this code, what's the wavelength of output signal on LEFT_PIN ?

This might help, https://github.com/dumtux/agpio-switch-mt7688 I wrote this for enabling all 5 ethernet ports for Ethernet switch. But I think you can modify this for disabling all of them to use digital I/O, by modifying AGPIO_CFG.

@Antony The easiest method is to just use subprocess function to call the command from within your python code. I think many people will just add the the command to their /etc/rc.local so the pin is set to gpio when the device boots.

@Antony I think you answered your own question with the follow up related to gpiomux.

@crispyoz Thanks for all your help!

@Antony The most common way people achieve this is by adding the command to /etc/rc.local so it is executed at boot time.

@dixit I just noticed this post after answering the other one in the p44-ledchain thread Hearing that you had similiar problems with the ws2812-draiveris driver as with my p44-ledchain, I can conclude that the problem is most likely not the timing, but the hardware (missing level shifter?). Because ws2812-draiveris always meets the timing for the WS28xx - as you might have seen when porting it, it simply locks all interrupts and then bit-bangs the data. While this is good for meeting the LED chip timing (and simple to code), locking interrupts for dozens of milliseconds is a cardinal sin in a Linux driver. On the original AR9331 CPU (Omega1), where ws2812-draiveris originates from, this was the only way to get such SmartLEDs working at all, so ws2812-draiveris is as good as it can get on that chip. However, on the MT7688/Omega2 with its PWM units, the p44-ledchain way to do it, without locking interrupts, is the way to go. And that works easily, at least with WS2813 or WS2815, with all 4 PWMs running in parallel with 1000 LEDs each.

@Nagarjuna-Reddy Doesn't look like you're writing the correct value to the GPIO1_MODE register. Take a look at the GPIO1_MODE register definition, you're probably interested in the SD_MODE bit fields.

I think I'm closer to the answer. It seems to lie in the register AGPIO_CFG at address 0x1000003C. It switches the GPIOs 14 through 29 between the digital pins and the analog ethernet counterparts. Would this modification to AGPIO be done in the DTSI file, some bootloader/kernel parameter or do I need to make a patch to something somewhere? I'm aware I could use something like devmem to directly set this register from userspace but I assume there is something a bit cleaner?

If you want to interface a lot of devices, you would typically adopt mux/demux technique, with a middle-level "device aggregator". See this: https://www.instructables.com/id/Tims-PCA9685-Controller One side (the micro-controller -uC- facing side) is I2C, while the "physical device" facing side is PWM. The micro-controller talks to 9685 (device aggregator), which in turn would talk to the devices connected to its 16 channels. Note that the above URL has Atmel 8-bit uC/Arduino as the "controlling platform". The point is that, we are making use of the I2C interface which is present in almost any uC . Further, the data sheet of the 9685 provided in the above link: https://cdn-shop.adafruit.com/datasheets/PCA9685.pdf says that, "The PCA9685 operates with a supply voltage range of 2.3 V to 5.5 V and the inputs and outputs are 5.5 V tolerant". So, you can drive it using 3.3v. Picking the the right hardware to meet a "specific requirement" is an art, that takes time to get anywhere near the mastery. Getting used to the "datasheet" is the basic requirement. Luckily, the Internet has tons of resources providing implementation details of various project.

@Moonshiner Yes, it's not in the DTS If you want to make the change when the device boots, you can use omega2-ctrl to change the pin multiplexing. See the ephy group here http://docs.onion.io/omega2-docs/using-gpios.html#using-gpios-multiplexing However, if you're using a more recent version of the bootloader, GPIO43 should be set to act as a GPIO by default. Learn more about checking your bootloader version, the bootloader changelog, and updating it here: http://docs.onion.io/omega2-docs/Web-Recovery-flash-bootloader.html

@Radek said in How can I pass one GPIO pin to an other?: Yes, this is what I actually tried to ask: how can i programmatically pass GND to those two pins. I don't think connecting pins from Omega would do the trick as I need to pass GND. For the moment the only idea I have is to buy relays but I would rather try to avoid it of possible Instead of relays, try making a switch with a transistor. That way, you can use the Omega's GPIO as the control signal (set the logic level), but don't have to depend on the Omega to provide the current. We used this method for the Omega-controlled MCU reset on the Arduino Dock 2:

@jose-r said in Problem with GPIO18/19: So when a GPIO is set to HIGH or LOW, is an internal pullup / down performed? No. I'm afraid my post was not clear enough or you fully misunderstood something.