[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-22 Thread TJF
@Andrew P. Lentvorski You came in to point to your tri-state solutions. I also use a tri-state GPIO in my one-wire driver libpruw1 . But it isn't the topic in this thread. Am Montag, 22. Juni 2020 09:23:35 UTC+2 schrieb Andrew P. Lentvorski: > > 1) While I'm

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-22 Thread Andrew P. Lentvorski
1) While I'm always grateful for your responses, TJF, you need to understand that your answers almost always come across a bit ... abrupt. I presume it's a language thing as I couldn't possibly convey nuance in German. 2) You know the libpruio architecture cold, but none of your documentation

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-22 Thread TJF
Am Montag, 22. Juni 2020 07:45:44 UTC+2 schrieb Andrew P. Lentvorski: > > Pinmuxing *must* be done from privileged mode (effectively: Linux > kernel/kernel module only). > Correct. Neither userspace nor PRU can change a pinmux. > Not correct. In a libpruio configuration all members of

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-21 Thread Andrew P. Lentvorski
On Thursday, June 18, 2020 at 10:11:20 AM UTC-7, Dennis Bieber wrote: > > > OTOH -- if the author could get it to work on a > BB AI (which has two /pairs/ of PRUs, and currently has nothing for > run-time pin-muxing -- requiring device tree edits for any thing that is > not a default)... > As

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-21 Thread Andrew P. Lentvorski
On Sunday, June 21, 2020 at 10:45:44 PM UTC-7, Andrew P. Lentvorski wrote: > > > If you must have a pin that changes direction and you need to control it > from the PRU, you can use the digital I/O's on the IEP (industrial ethernet > peripheral). I can confirm that this works. > I probably

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-21 Thread Andrew P. Lentvorski
On Thursday, June 18, 2020 at 1:50:03 PM UTC-7, Dennis Bieber wrote: > > I can only state then, that a quick perusal of the online > documentation > (in particular, the github readme) gives this one the impression that the > package provides a specific program running on a PRU which

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-19 Thread TJF
@ P B: > I want to ensure the pump is not triggered from any noise. Perhaps I > misunderstood this feature. > You should also consider to implement an external pulldown. The weak internal resistance isn't present in the early boot phase (it comes up 7-10 seconds after power-on). @ Dennis

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-18 Thread Dennis Lee Bieber
On Thu, 18 Jun 2020 12:11:23 -0700 (PDT), in gmane.comp.hardware.beagleboard.user TJF wrote: >Am Donnerstag, 18. Juni 2020 19:11:20 UTC+2 schrieb Dennis Bieber: >> >> -- Linux app sending command to PRU application to modify pin-mux so Linux >> app can make use of new state >> > >How do you

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-18 Thread TJF
Am Donnerstag, 18. Juni 2020 19:11:20 UTC+2 schrieb Dennis Bieber: > > -- Linux app sending command to PRU application to modify pin-mux so Linux > app can make use of new state > How do you make the PRU modify pinmuxing? You have no idea what you're talking about! Regards -- For more

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-18 Thread Dennis Lee Bieber
On Thu, 18 Jun 2020 13:10:59 -0400, in gmane.comp.hardware.beagleboard.user Dennis Lee Bieber wrote: > > Or managing to read the config-pin /script/ source and figuring out how >to invoke the equivalent directly ... which appears to be sysfs writes... Note -- there appears to be

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-18 Thread Dennis Lee Bieber
On Thu, 18 Jun 2020 09:11:39 -0700, in gmane.comp.hardware.beagleboard.user P B wrote: > >I've used config-pin in the ways you've described from the IDE, but have >not incorporated it into C++ program. Will look for examples > Well, there is always the old C-lib system() call

Re: [beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-18 Thread P B
Thank you for the responses, gentlemen. *Dennis:* 2nd addition... ran it to those problems last spring... edition matters for certain. 1st addition uses only an outdated device tree method. I've used config-pin in the ways you've described from the IDE, but have not incorporated it into C++

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-16 Thread TJF
Hi! Am Dienstag, 16. Juni 2020 00:08:18 UTC+2 schrieb P B: > I'm a little stuck here. > Drop all than device tree and config-pin stuff. Instead use libpruio for pinmuxing. Once installed you can configure the pins from user space in your source code,

[beagleboard] Re: Problems Reconfiguring GPIO's

2020-06-16 Thread Dennis Lee Bieber
On Mon, 15 Jun 2020 15:08:18 -0700 (PDT), in gmane.comp.hardware.beagleboard.user P B wrote: >Unfortunately, I also want >P9-12 (GPIO 60) as pulldown output to turn on pump 1 using a relay, where >P9-12's default state is pullup input, and >P9-15 (GPIO 48) as pulldown output to turn on pump 2