Single channel configuration

[PurpleLobster]

Does anybody know how to force a reconfiguration of the GPIO? I am facing the issue that multiple GPIO pins are driven when I launch bin/led-udp-rx , despite the fact that I configured leds.config to a single channel ( 1,20,3 ) and adjusted scripts/pin-layout.txt to a a single line '0,gpio2[3],P8_08,67', representing the pin I would like to use.

My goal is to have only one GPIO pin (P8_08) driven by the PRU. Currently other pins are driven as well, for example P8_10.

I tried to rerun scripts/provision and scripts/pin-config without successful outcome.

cat leds.config 1,20,3

cat scripts/pin_layout.txt 0,gpio2[3],P8_08,67

sudo scripts/pin-config GPIO Already configured

sudo bin/led-udp-rx read 6 bytes '1,20,3' parsed 3 entries... Launching with 1 strips, each 20 LEDs long, and 3 bytes per LED Launching on port 9999, with 1 channels and 20 pixels per channel.

I think scripts/pin_layout.txt is somehow not loaded. How do I force a reconfiguration of the GPIO?

[RemyPorter]

So, the launcher script touches a few files in /tmp to prevent doing some expensive setup work when restarting the service. rm /tmp/pins_hot and it should reload the GPIO pins- but that won't clear out the configuration that was already set. You can either use config-pin (a CLI tool which is called by that pin-config script) to clear them, or probably easier: just reboot the device.

That might not solve your problem, though. The PRU is going to try and write to those pins no matter what though, so if you're hoping to use those pins for other IO operations, you'll still end up fighting the PRU. If you look at the assembly, you can see that it's just writing to entire GPIO banks, via OCP. You'd need to change the pin_map.asm and probably futz around in ledscape.asm as well.

ThrowingBagels is very much designed around the idea that it's the only user of those 32 GPIO pins.

[PurpleLobster]

Thanks for your explanation! I have very little assembly experience but I will give it at try. My approach was to commend out all the commands in ledscape.asm related to GPIO banks not being gpio2. My assumption is that this will free up gpio0, 1 and 3 for other applications. I can live with that.

e.g.:

;set low for all the pins we control ; SBBO &gpio0_mask, t0, 0, 4 ; SBBO &gpio1_mask, t1, 0, 4 SBBO &gpio2_mask, t2, 0, 4 ; SBBO &gpio3_mask, t3, 0, 4

... and so on for other blocks...

I recompiled ledscape.asm by running make in the ThrowingBagels folder. I rebooted and deployed the firmware:

sudo ./launcher Starting GPIO setup Stopping any running PRU firmware Deploying LEDScape firmware Starting LEDScape firmware

followed by

sudo bin/led-udp-rx

Unfortunately the LED colors are all over the place, I assume this is due to a timing issue in the pulses.

I figured removing assembly instructions impacts the timing and replaced all gpio0,1,3 commands by a gpio2 command:

;set low for all the pins we control SBBO &gpio2_mask, t2, 0, 4 SBBO &gpio2_mask, t2, 0, 4 SBBO &gpio2_mask, t2, 0, 4, SBBO &gpio2_mask, t2, 0, 4

I redeployed the firmware and restarted everything. No success. Colors are still all over the place. I will try tomorrow with a single LED configuration to check the timings. Unless someone has a brilliant idea..

[PurpleLobster]

It turned out the pulse timings where out of spec of the LEDs I used. By tweaking the delays I managed to adjust it :)

[RemyPorter]

Ah, fantastic to hear. I was figuring that the timings were probably off. This definitely drives the WS protocol, which also works for most SKs, but other LED varieties can definitely have different timings.