[beagleboard] Re: Problems Reconfiguring GPIO's

[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 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.
>

I'm sorry if you're not fast enough.

2) You know the libpruio architecture cold, but none of your documentation 
> explains it, at all.  So, the relationship between kernel module, system 
> groups, PRU, and user mode is not at all clear to newcomers who actually 
> try to look at your libpruio library.
>

I do my very best not just develping a unique solution, but also 
documenting it in a forein language. The docu may not be perfect, but it 
explains that relaionship. It's OK when you don't read that. But don't tell 
other that it isn't present.
 

> 3) The reliance on FreeBASIC is an absolute non-starter for a *LOT* of 
> people.  While I'm sure you find it to be a superior tool, most people 
> already find the BeagleBone forbidding enough.  Adding another unfamiliar 
> tool to the mix is not something most people are willing to do.
>

The library also includes bindings and examples for C and Python 
programming languages. Why do you see a reliance on FreeBASIC?
 

> Thanks.
>
> On Sunday, June 21, 2020 at 11:22:48 PM UTC-7, TJF wrote:
>>
>>
>>
>> Am Montag, 22. Juni 2020 07:45:44 UTC+2 schrieb Andrew P. Lentvorski:
>>>
>>> Neither userspace nor PRU can change a pinmux.
>>>
>>
>> Not correct. In a libpruio configuration all members of system-group 
>> 'pruio' can pinmux from user space. That's why libpruio development is as 
>> easy as Arduino development, but much more powerful.
>>
>
> *Because* you shunt the request through the custom kernel module. Telling 
> people that they can pinmux from userspace simply confuses people further 
> who are already probably plenty confused.
>

Yes, the library shunts requests. And that's why (only) libpruio users can 
do pinmuxing from user space single source in their code. There's nothing 
wrong with that statement.

You're right, one of us is confusing people.

Regards

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0d14d536-6c54-4140-980c-b7c43c26deb5o%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 
explains it, at all.  So, the relationship between kernel module, system 
groups, PRU, and user mode is not at all clear to newcomers who actually 
try to look at your libpruio library.

3) The reliance on FreeBASIC is an absolute non-starter for a *LOT* of 
people.  While I'm sure you find it to be a superior tool, most people 
already find the BeagleBone forbidding enough.  Adding another unfamiliar 
tool to the mix is not something most people are willing to do.

Thanks.

On Sunday, June 21, 2020 at 11:22:48 PM UTC-7, TJF wrote:
>
>
>
> Am Montag, 22. Juni 2020 07:45:44 UTC+2 schrieb Andrew P. Lentvorski:
>>
>> Neither userspace nor PRU can change a pinmux.
>>
>
> Not correct. In a libpruio configuration all members of system-group 
> 'pruio' can pinmux from user space. That's why libpruio development is as 
> easy as Arduino development, but much more powerful.
>

*Because* you shunt the request through the custom kernel module. Telling 
people that they can pinmux from userspace simply confuses people further 
who are already probably plenty confused.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9e313800-286e-41fa-b20f-cee927ab9d1co%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 system-group 
'pruio' can pinmux from user space. That's why libpruio development is as 
easy as Arduino development, but much more powerful.
 

> 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.
>

Off-topic.


@ P B

You asked for GPIO. In order to control the flow rate, you could also 
control the pumps by PWM signals.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3cf28356-82c5-4843-a33d-6de389f5117do%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 I understand it, most of the pinmux issues on the AM57xx are due to a 
*chip* bug.  I don't think anybody can work around them.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c2399ece-0e90-4c8b-9062-8522617e91e1o%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 need to clarify.  I can confirm that you can *tri-state* an IEP 
output pin from the PRU.  I actually used an input and output pin wired 
together so I could dodge the whole question of changing *direction*. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cabf9bf0-228e-458b-a1d6-dd9c44924ab1o%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 must be used, 
> and that a host application, via a library, talks to that PRU to perform 
> I/O. If setting the configuration and subsequent I/O performed without 
> involving a PRU, it is not readily apparent. The presence of that warning 
> about the PRU being able to access any memory reinforces this, as it 
> implies that a PRU could write to the pin-mux registers to change 
> configuration. 
>

Pinmuxing *must* be done from privileged mode (effectively: Linux 
kernel/kernel module only).  Neither userspace nor PRU can change a pinmux.

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.

See:
https://groups.google.com/forum/#!msg/beagleboard/AcQ3lY03UD0/glUL7Rc-CgAJ
https://e2e.ti.com/support/processors/f/791/t/445028


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f52441e9-53d3-435b-b1a6-d716c172e55fo%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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

Am Donnerstag, 18. Juni 2020 22:50:03 UTC+2 schrieb Dennis Bieber:
>
> On Thu, 18 Jun 2020 12:11:23 -0700 (PDT),
>
> >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! 
> > 
>
> 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 must be used, 
> and that a host application, via a library, talks to that PRU to perform 
> I/O. If setting the configuration and subsequent I/O performed without 
> involving a PRU, it is not readily apparent. The presence of that warning 
> about the PRU being able to access any memory reinforces this, as it 
> implies that a PRU could write to the pin-mux registers to change 
> configuration.
>

The warning applies to all PRU deployment. The only difference: libpruio 
users get informed.

IMHO you shouldn't try to create the impression that you're an expert with 
years of experience before you misread the short introduction of a project.

Regards

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0c96b3fe-a70f-4eb7-973c-f41fa85b48cbo%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 make the PRU modify pinmuxing? You have no idea what you're 
>talking about!
>

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 must be used,
and that a host application, via a library, talks to that PRU to perform
I/O. If setting the configuration and subsequent I/O performed without
involving a PRU, it is not readily apparent. The presence of that warning
about the PRU being able to access any memory reinforces this, as it
implies that a PRU could write to the pin-mux registers to change
configuration.



-- 
Dennis L Bieber

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/82kneflb5c2o2vl2rqu3tn9oeqdg2lcm5j%404ax.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/69a2faf4-cf66-4f4f-91d6-f3ec363e46eco%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 an error at line 1446 of the script
version... It is setting PULL-DOWN, but is in a block of code that is
supposed to be setting PULL-UP. Looks like a cut of lines 1414-1430
(setting pull-down), to 1432-1448, in which three of the four _pd where
changed to _pu.

# GPIO with pull-up enabled

[iI][nN]+|[iI][nN][pP][uU][tT]+|[iI][nN][-_][pP][uU]|[iI][nN][pP][uU][tT][-_][pP][uU])
MODE=gpio_pu;
DIR=in
;;

[oO][uU][tT]+|[oO][uU][tT][pP][uU][tT]+|[oO][uU][tT][-_][pP][uU]|[oO][uU][tT][pP][uU][tT][-_][pP][uU])
MODE=gpio_pu;
DIR=out
;;

[lL][oO]+|[lL][oO][wW]+|0+|[lL][oO][-_][pP][uU]|[lL][oO][wW][-_][pP][uU]|0[-_][pP][uU])
MODE=gpio_pu;
DIR=low
;;

[hH][iI]+|[hH][iI][gG][hH]+|1+|[hH][iI][-_][pP][uU]|[hH][iI][gG][hH][-_][pP][uU]|1[-_][pP][uU])
MODE=gpio_pd;   < line 1446, compare to 
previous three
DIR=high
;;


Direction is written via (trimmed)(line 1470)

if [ -n "$DIR" ] ; then
eval GPIO="\$${PIN}_GPIO"
FILE="$GPIODIR/gpio$GPIO/direction"
if [ -e $FILE ] ; then
if [ -w $FILE ] ; then
echo $DIR > $FILE || (echo_err "Cannot 
write gpio
direction file: $FILE" && exit 1)

and mode is written (line 1484 -- note that I think I only showed the post
3.8 kernel)

if [ ! "x${SLOTS_LOCATION}" = "xold38kernel" ] ; then
# Expand filename using shell globbing
for FILE in $OCPDIR${PIN}_pinmux/state ; do
echo_dbg "echo $MODE > $FILE"
if [ -w $FILE ] ; then
echo $MODE > $FILE || (echo_err "Cannot 
write pinmux
file: $FILE" && exit 1)



So... from C/C++ determining the sysfs file names for the pins, and
writing the direction and mode strings to the proper files would be the
direct way. I believe most newer images have put the "debian" user into a
group with GPIO write access (I snipped the "else" branch which invokes the
write using sudo -- I'm presuming [-w ...] is a test for "is file
writable")


-- 
Dennis L Bieber

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/lp9nefhu5qt1gl0ketlfn4lcchocrl91vj%404ax.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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
https://www.tutorialspoint.com/c_standard_library/c_function_system.htm

Or managing to read the config-pin /script/ source and figuring out how
to invoke the equivalent directly 

>I want to ensure the pump is not triggered from any noise.  Perhaps I
>misunderstood this feature.
>

If you need to prevent the pump for doing anything during system
start-up, you likely need to put the pull-up/-down resistors on the pump
inputs themselves, where they won't be affected by changes in the pin-mux
settings. However, take into consideration that recommendations are that
/no/ voltages be applied to I/O pins before the board itself is powered --
which implies having some sort switched buffer between the I/O pin and the
pump control with its pull-up/-down if it uses an external power-supply
rather than one controlled by the Beagle itself.



The heavily promoted libpruio bothers me for some reason -- among them
being that it requires one of the two PRUs to be dedicated to it, so not of
use if one has an application that needs both PRUs; and that control chain
-- Linux app sending command to PRU application to modify pin-mux so Linux
app can make use of new state [Does this mean the kernel may have a
disconnect in what /it/ thought the pin-mux state was, or does the PRU
somehow update the kernel]. 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)...



-- 
Dennis L Bieber

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/nt7nef1urdtkk98g68vc0oni4di3sft1e8%404ax.com.

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

[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++ program. Will look for examples

 As an aside -- setting an output to pull-up/pull-down seems to me
rather perverse. My understanding of circuits is that pull-up/-down is
meant to ensure one reads a particular state when external devices are
/not/ driving a line to either rail, or are tri-stated (floating) when the
line is shared among devices. Once your application is running, your
outputs should be driven to one or the other state, they won't be
floating.

I want to ensure the pump is not triggered from any noise.  Perhaps I
misunderstood this feature.

TJF
I will review this method.

Best Regards





On Tue, Jun 16, 2020 at 10:29 AM TJF  wrote:

> 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, compiled against
> libpruio. (This also safes boot-time and kernel memory.)
>
> Example:
> ...
> // Input
> if (pruio_gpio_config
> 
> (io, P8_11
> 
> , PRUIO_GPIO_IN_0
> 
> )) {
>   printf("GPIO P8_11 configuration failed (%s)\n", io->Errr); break;}
> // Output
> if (pruio_gpio_setValue
> 
> (io, P9_12
> 
> , 0
> 
> )) {
>   printf("GPIO P9_12 configuration failed (%s)\n", io->Errr); break;}
>
> Check the examples
> 
> for complete code. By default an output pin gets configured without
> restistor, but you can override by function pruio_setPin(io, P9_12, 7 +
> PRUIO_PULL_UP).
>
> Regards
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/S3UoBNP6kjg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/f5d00e94-c939-437b-8179-cdb6a2525229o%40googlegroups.com
> 
> .
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BWcFtNQnDEJt7tR5_mFDAs4237HHLbYxkKU_Ebx07j9UsuPgw%40mail.gmail.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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, compiled against 
libpruio. (This also safes boot-time and kernel memory.)

Example:
...
// Input
if (pruio_gpio_config 

(io, P8_11 

, PRUIO_GPIO_IN_0 

)) {
  printf("GPIO P8_11 configuration failed (%s)\n", io->Errr); break;}
// Output
if (pruio_gpio_setValue 

(io, P9_12 

, 0 

)) {
  printf("GPIO P9_12 configuration failed (%s)\n", io->Errr); break;}

Check the examples 

 
for complete code. By default an output pin gets configured without 
restistor, but you can override by function pruio_setPin(io, P9_12, 7 + 
PRUIO_PULL_UP).

Regards

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f5d00e94-c939-437b-8179-cdb6a2525229o%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[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 using a relay, where 
>P9-15's default state is pulldown input.
>
>I have been trying to work through RCN's dtb-rebuilder with Derek Molloy's 
>book to accomplish this.  

First or second edition? It may be pertinent.

>
>But I have not impacted this default state.
>

OTOH, I note you mentioned checking using config-pin, but not trying to
set using it. Have you tried using config-pin at run time instead of all
this DTB hassle? {the /old/ config-pin script, not the less-capable binary
that is now in the path} 

-=-=-=-
debian@beaglebone:~$ config-pin -h

GPIO Pin Configurator

Usage: config-pin -c 
   config-pin -l 
   config-pin -q 
   config-pin  

debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -h
config-pin [-a]  
Set  to , configuring pin multiplexing and optionally
configuring the gpio.  Valid  strings vary based on ,
however all pins have a default and gpio mode.  The default mode is
the reset state of the pin, with the pin mux set to gpio, the pull
up/down resistor set to it's reset value, and the pin receive buffer
enabled.  To setup gpio, the following  strings are all valid:

gpio :
Set pinmux to gpio, existing direction and value unchanged
in | input:
Set pinmux to gpio and set gpio direction to input
out | output :
Set pinmux to gpio and set gpio direction to output
hi | high | 1 :
Set pinmux to gpio and set gpio direction to output driving
high
lo | low | 0 :
Set pinmux to gpio and set gpio direction to output driving low

To enable pull-up or pull-down resistors, a suffex may be appended to
any of the above gpio modes.  Use + or _pu to enable the pull-up
resistor
and - or _pd to enable the pull-down resistor.  Examples:

in+ | in_pu:
Enable pull-up resistor and setup pin as per input, above.
hi- | hi_pd:
Enable pull-down resistor and setup pin as per high, above.
While the pull-down resistor will be enabled, it will not do
much
until application software changes the pin direction to input.

config-pin -l 
list valid  values for 

config-pin -i 
show information to 

config-pin -q 
query pin and report configuration details

config-pin -f [file]
Read list of pin configurations from file, one per line
Comments and white-space are allowed
With no file, or when file is -, read standard input.
config-pin -h
Display this help text

debian@beaglebone:~$
-=-=-=- 
debian@beaglebone:~$ /opt/scripts/device/bone/show-pins.pl


P9.15 16 R13 fast rx down 7 gpio 1.16
ocp/P9_15_pinmux (pinmux_P9_15_default_pin)

P9.12 30 U18 fast rx  up  7 gpio 1.28
ocp/P9_12_pinmux (pinmux_P9_12_default_pin)

debian@beaglebone:~$ config-pin -q p9.12

Current mode for P9_12 is: default

debian@beaglebone:~$ config-pin -q p9.15

Current mode for P9_15 is: default

debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q
p9.12
P9_12 Mode: default Direction: in Value: 1
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q
p9.15
P9_15 Mode: default Direction: in Value: 1
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin p9.12
out_pd
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin p9.15
out_pd
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q
p9.12
P9_12 Mode: gpio_pd Direction: out Value: 0
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q
p9.15
P9_15 Mode: gpio_pd Direction: out Value: 0
debian@beaglebone:~$ config-pin -q p9.12

Current mode for P9_12 is: gpio_pd

debian@beaglebone:~$ config-pin -q p9.15

Current mode for P9_15 is: gpio_pd

debian@beaglebone:~$
-=-=-=-

{the "modern" config-pin binary seems to lack an ability to set direction,
but does have gpio_pd/gpio_pu; the old script version has direction and
option to set _pu/_pd on the direction: out, out_pu, out_pd, in, in_pu,
in_pd}

As an aside -- setting an output to pull-up/pull-down seems to me
rather perverse. My understanding of circuits is that pull-up/-down is
meant to ensure one reads a particular state when external devices are
/not/ driving a line to either rail, or are tri-stated (floating) when the
line is shared among devices. Once your application is running, your
outputs should be driven to one or the other state, they won't be floating.
>From the