I’m working with a Beaglebone Black to do some signal acquisition using a laser as a light source.
The sampling/acquisition system is driven through the PRU since I need pretty tight timing - including pulsing a laser to illuminate a sample.
A problem that we just noticed is that as soon as I load the Device Tree overlay that maps my PRU lines, several of the outputs go HIGH instantly - including the one that drives the laser - until the software spins up and initializes everything back to LOW.
I’m specifically looking at pin P8-46 mapped as pr1_pru1_pru_r30_1, but a number of pins have the same behavior. I’ve tried asserting the pulldowns in the DeviceTree, but they don’t have any effect, so I’m pretty sure it’s not just the signal floating up, but rather being driven high.
With a laser the time it takes my software to come up and clear everything out is a safety liability.
What can I do at the Beaglebone to ensure / enforce outputs staying LOW when the Device Tree overlay is mapped?
The default state of P8-46 is LOW, but I can stick a scope on it and see it go HIGH as soon as the Device Tree overlay loads.
Several web searches come up with suggestions to “rebuild uBoot to get the pin state you want”, but there’s not a lot of detail on that and nobody ever comes back to the discussions with “Yes - that did the trick!”.
I’m also not convinced that’d solve the problem since the state of the pin post-boot is LOW - it’s only when the DTree overlay loads that the pin jumps HIGH.
Board spins eat up weeks of project - software / firmware changes are “free”.
…so the powers that be would rather see this solved at the Beaglebone rather than on our outboard hardware. And that’s kind of a legitimate request, too - nobody in their right mind would design a system where Outputs go HOT without any interaction to request that state.
I can clearly see how gpio-hog works to define pins that are going to be used as GPIOs. Is gpio-hog applicable to pins that need to get their MUX switched over to be used as PRU pins ?
One of the tests I’ve done was delaying loading the device tree until after we’re well past the boot sequence (run a script that echoes our cape name into capemgr.9/slots and then immediately executes code to activate the PRU and clear the outputs) and see the same behavior of the pin - it’s pleasantly low through the boot sequence where the HDMI overlays are commented out to free up the pins but as soon as my cape overlay is loaded the PRU outputs go high. Since we’re well past the u-boot/kernel handoff and well past any initialization at that point, how applicable is gpio-hog (assuming it can be used on PRU pins) at that moment?
