Problems Reconfiguring GPIO's

[P B]

Greetings,

I am working on developing a new piece of equipment using the BBB as the controller.

One aspect of the project is control of an inlet and outlet pump from a tank.  Time sensitivity is not critical.

I am looking to use

P8-11 (GPIO 45) as pulldown input - Program man/auto

P8-12 (GPIO 44) as pulldown input - Pump 1 - man on/off

P8-14 (GPIO 26) as pulldown input - Pump 2 - man on/off

P8-15 (GPIO 47) as pulldown input - Pump 2 start switch

P8-16 (GPIO 46) as pulldown input - Pump 1 Stop switch

P8-17 (GPIO 27) as pulldown input - Pump 2 Stop switch

P8-18 (GPIO 65) as pulldown input - Pump 1 Start switch

Fortunately, pulldown input is the default state of each of those pins.

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.  

But I have not impacted this default state.

I am using Kenerl r.19.94-ti-r42.

I have captured my boot sequence using a serial cable through putty:

uboot_overlays: [uboot-base-dtb = am335x-boneblack-uboot-univ.dtb]...

the seqeunce confirms it switched to the above, then loads with 162266 bytes read

am335x-boneblack-uboot-univ.dtb includes 

1) am33xx.dtsi, which appears to set on chip GPIO's,

2) am335x-bone-common.dtsi, which appears to only interact with P9-19 & P9-20 in terms of GPIO, and

3) am335x-bone-common-univ.dtsi

So looking at P9-12 in am335x-bone-common-univ.dtsi:

Line 713 of am335x-bone-common-univ.dtsi begins the definitions of Gpio on P9-12

/* P9_12 (ZCZ ball U18) gpio1_28 */

P9_12_default_pin: pinmux_P9_12_default_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

P9_12_gpio_pin: pinmux_P9_12_gpio_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_OUTPUT | INPUT_EN | MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

P9_12_gpio_pu_pin: pinmux_P9_12_gpio_pu_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

P9_12_gpio_pd_pin: pinmux_P9_12_gpio_pd_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_OUTPUT_PULLDOWN | INPUT_EN | MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

P9_12_gpio_input_pin: pinmux_P9_12_gpio_input_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_INPUT | MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

I have tried modifying the lines above with no success

1)

P9_12_gpio_pd_pin: pinmux_P9_12_gpio_pd_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_OUTPUT_PULLDOWN_EN | INPUT | MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

and

2)

P9_12_gpio_pd_pin: pinmux_P9_12_gpio_pd_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_OUTPUT_PULLDOWN_EN | MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

and

3)

P9_12_gpio_pd_pin: pinmux_P9_12_gpio_pd_pin { pinctrl-single,pins = <

AM33XX_IOPAD(0x0878, PIN_OUTPUT_PULLDOWN| MUX_MODE7) >; }; /* gpmc_be1n.gpio1_28 */

Line 2049 starts the next section which appears to only define the pinctrl states

/* P9_12 (ZCZ ball U18) */

P9_12_pinmux {

compatible = "bone-pinmux-helper";

status = "okay";

pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "gpio_input";

pinctrl-0 = <&P9_12_default_pin>;

pinctrl-1 = <&P9_12_gpio_pin>;

pinctrl-2 = <&P9_12_gpio_pu_pin>;

pinctrl-3 = <&P9_12_gpio_pd_pin>;

pinctrl-4 = <&P9_12_gpio_input_pin>;

};

I have not played with these.

Finally, the last place it appears to configure P9-15 starts on Line 2777

P9_12 {

gpio-name = "P9_12";

gpio = <&gpio1 28 0>;

input;

dir-changeable;

};

I have tried a few modification here with no success such as

P9_12 {

gpio-name = "P9_12";

gpio = <&gpio1 28 3>;

output;

pulldown;

};

I nano'ed, modified and saved the am335x-bone-common-univ.dtsi file, used the dtb-rebuilder make all command, backed up the old binary file am335x-boneblack-uboot-univ.dtb_BACKUP and replaced it with the new am335x-boneblack-uboot-univ.dtb.

And yes I messed it up a couple times and had to completely rebuild the BBB's loaded image, updates, upgrades, etc...  Lots of fun.

I have not seen any change in the default state of P9-12 from pullup input as checked using config-pin query.

Can anyone redirect me to some examples, or provide a some tips, or simply tell me I'm off my rocker and nowhere close to where I need to be?  

I'm a little stuck here.

[Dennis Lee Bieber]

On Mon, 15 Jun 2020 15:08:18 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user P B

<mmmbarley-Re5JQE...@public.gmane.org> 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 <filename>
config-pin -l <pin>
config-pin -q <pin>
config-pin <pin> <mode>

debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -h
config-pin [-a] <pin> <mode>
Set <pin> to <mode>, configuring pin multiplexing and optionally
configuring the gpio. Valid <mode> strings vary based on <pin>,
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 <mode> 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 <pin>
list valid <mode> values for <pin>

config-pin -i <pin>
show information to <pin>

config-pin -q <pin>
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:~$
-=-=-=- <snipping irrelevant>
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 script config-pin help:
"""
While the pull-down resistor will be enabled, it will not do
much
until application software changes the pin direction to input.
"""


{config-pin, either version, are not available if using the BB AI -- that
board must use device tree edits}


--
Dennis L Bieber

[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

[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

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f5d00e94-c939-437b-8179-cdb6a2525229o%40googlegroups.com.

[Dennis Lee Bieber]

On Thu, 18 Jun 2020 09:11:39 -0700, in gmane.comp.hardware.beagleboard.user
P B <mmmbarley-Re5JQE...@public.gmane.org> 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 <G>

>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

[Dennis Lee Bieber]

On Thu, 18 Jun 2020 13:10:59 -0400, in gmane.comp.hardware.beagleboard.user
Dennis Lee Bieber <dennis.l.bieber-Re5...@public.gmane.org>
wrote:

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

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

[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

[Dennis Lee Bieber]

On Thu, 18 Jun 2020 12:11:23 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user TJF

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

[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

[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

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

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

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

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

[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