Re: [beagleboard] Re: GPIO, libpruio & dtbo Question

[Don Pancoe]

I don't mean to start a fight here. You are all providing helpful
information. I think I will proceed on one of the following paths.

   1. Dig in and understand the GPIO registers. I have seen those in the
   libpruio docs, but just haven't groked them yet.
   2. Failing that, I can use libpruio to read the button during the
   *customSleep()* function, where it will both call a *break* right there
   as well as set an *abort* flag to notify any subsequent tests that they
   should also not execute.
   3. And lastly, really dive into the device tree more long-term per
   Seth's info, because I think that would be useful knowledge for future
   projects.

Thanks,
Don

--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com <http://donpancoe.com/>


On Fri, Mar 5, 2021 at 3:48 AM TJF  wrote:

>
> Dennis Bieber schrieb am Donnerstag, 4. März 2021 um 23:41:22 UTC+1:
>
>> libpruio
>> does not seem to support such -- cf:
>> https://groups.google.com/g/beagleboard/c/3wphAPs9Uws (which is the
>> underlying C level, I doubt the Python interface adds any features)
>>
> Nonsens! Use
>
> io.IntcInit
>
> to configure the interrupt table (IRQ[0-4,6,7]). And mask your event in
> the GPIO registers
>
> LEVELDETECT[0,1]
> RISINGDETECT
> FALLINGDETECT
>
> If need be also set the GPIO registers
>
> DEBOUNCENABLE
> DEBOUNCINGTIME
>
> and then catch (and reset) the new IRQ in a thread. But this isn't worth
> the effort!
>
> As mentioned above, the while loop should get placed in a custom sleep
> function. And since the app does nothing in that sleep function, the
> abortPIN can get polled fast enough (20 to 100 Hz).
>
> Dennis Bieber schrieb am Donnerstag, 4. März 2021 um 23:41:22 UTC+1:
>
>> Non Sequitur: "TJF" is, as I recall, the author of that libpruio package,
>> and pushes it as the only solution for everything related to Beaglebone
>> GPIO.
>>
> Nonsens! You can find hundreds of threads here without any pushing. Since
> the OP already implemented libpruio for the eCAP feature, why shouldn't he
> use further features?
>
>
> --
> 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/bd3d4e00-58e8-4e6d-86df-004e5305b0a2n%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/bd3d4e00-58e8-4e6d-86df-004e5305b0a2n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAP3tSUPDKm2gnhiTH0d5PuutpRBa1TaHhjMQNBJ5-q83GJ6V4A%40mail.gmail.com.

Re: [beagleboard] Re: GPIO, libpruio & dtbo Question

[Don Pancoe]

But if I used the following, would it not evaluate only at the start of the
while loop? The main loop of the whole test lasts on the order of minutes
even if all sub-tests pass, so how would that capture a <1sec button press?
Or is Python an event-driven language, where a change in the evaluated
condition will break the loop at any point?

while pruio_gpio_Value(io, abortPIN)

Thanks,
--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com <http://donpancoe.com/>


On Thu, Mar 4, 2021 at 6:35 AM TJF  wrote:

> Why so complicated?
>
> Dennis Bieber schrieb am Donnerstag, 4. März 2021 um 05:03:54 UTC+1:
>
>> Your sleep() and loops would then include something like "while not
>> abortFlag".
>>
>
> Replace
>
> while not abortFlag
>
> by
>
> while pruio_gpio_Value(io, abortPIN)
>
> and drop all that IRQ magic (which only makes sense when you can use the
> hardware debounce feature).
>
> And drop all that device tree magic. Instead configure the abortPIN by
> libpruio as GPIO with pull-up resistor (PRUIO_GPIO_IN_1) and wire the other
> end of the button to ground.
>
> Focus on your major target. Don't waste your time by reading and testing a
> bunch of documentations, which are too modern (or outdated) for your
> current system.
>
> 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/a1ab4004-4871-46c2-8fd3-be8fcb160206n%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/a1ab4004-4871-46c2-8fd3-be8fcb160206n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAP3tSUPh_tSjC2BBbxHkPkGZ%3Dqb_j7M%3DJbKu1bR8arFDYNjW9A%40mail.gmail.com.

Re: [beagleboard] Re: GPIO, libpruio & dtbo Question

[Don Pancoe]

Hello everyone,

Thank you for all the input. It's been a busy few days so I'm just getting
back to it.

First, I was talking about AdafruitBB_IO. I was just being lazy and/or
confused in typing BBB_IO, but I now see that BBBIO
<https://github.com/tomtzook/BBBIO> is a different C library for the
Beaglebone Black. I do write C code for microcontrollers, so I don't know
why I felt like a program on an SBC should be in Python, but I don't want
to start over from scratch now.

The PCBA test program is a long series of while loops, if statements and
timeout counters that wait for inputs and evaluate them, or move on if
they're taking too long. I was thinking of using an AdafruitBB_IO edge
detect to watch for an abort button press, then having that trigger a
function that handles any wrap-up tasks and calls a *break* function to pop
out of the main test loop to another outer loop so that it returns to the
top of the test. I'm actually doing this now to halt the test if the
in-circuit programmer reports a flashing failure. The difference is: the
programmer failure happens at a known point where I know to look for it,
but the abort button should be able to be used at any time.

One idea I've had but not tested yet is to replace the *sleep()* functions
I judiciously use for timing throughout the test with a custom function
that breaks the sleep period (anywhere from 10 ms to 10 s) into smaller
chunks interspersed with checking of the abort button GPIO. This I could do
just with libpruio as suggested by TJF. Theoretically, I could wait for
every subsequent while loop to time out at 60 seconds each, but that's not
practical for test throughput, or when you are billed for testing by the
minute.

Somewhat separate from all this, though: I've been finding the device tree,
overlays and pinmuxes to be some of the more difficult BBB/Linux topics to
wrap my head around, so I would appreciate any recommended tutorials on the
subject. There are tutorials that come up in Google searches, but with the
changes to both Linux and Beaglebone over the years, it's hard to know if
they are pertinent to the state of my system right now (I've not updated to
the latest kernel etc. because I don't want to break any of my past work).

Thanks,
--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com <http://donpancoe.com/>


On Wed, Mar 3, 2021 at 4:09 AM TJF  wrote:

> Hello Don Pancoe!
>
> Why do you think you'll need an IRQ for the "abort" button?
>
> Drop Adafruit_BBIO! Just setup the GPIO in libpruio and poll the state in
> your main loop (or in a timered thread).
>
> Regards
> donp...@gmail.com schrieb am Montag, 1. März 2021 um 19:27:01 UTC+1:
>
>> Hello all,
>>
>> I have a BBB Python application (PCBA test fixture) where I am using
>> libpruio, specifically for access to the eCAP pins. Libpruio requires that
>> the universal cape be disabled, but when I needed a UART and I2C, I was
>> able to add those back in using the existing dtbo files from /lib/firmware
>> (shown below) in my uEnv.txt.
>>
>> uboot_overlay_addr0=/lib/firmware/BB-I2C1-00A0.dtbo
>> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
>> uboot_overlay_addr2=/lib/firmware/DP-GPIO-PCBATest-00A0.dtbo (I talk
>> about this below)
>>
>>
>> Now I want to add an "abort" button to the test fixture since the
>> technicians have reported it takes a lot of time to reset if the board
>> under test locks up. I expect that wiring a pushbutton to a GPIO with an
>> interrupt is the way to handle this, and I've been thinking that there are
>> two ways to get there.
>>
>>1. Include another dtbo file to add a single GPIO that I can then
>>access with Adafruit_BBIO (this is where my efforts have focused so far), 
>> or
>>2. Figure out how to work with the hardware-based IRQ of the PRU
>>with libpruio (which I've been avoiding because it looks even more scary)
>>
>> I've tried to make a custom dtbo by following an example from Derek
>> Molloy (github.com/derekmolloy/boneDeviceTree) and while it compiled and
>> booted OK, I still get the following error when I run a simple test
>> program. The same error as when I tried running the program before I
>> created the dtbo.
>>
>> kapsul@beaglebone:~/pyDev$ sudo python3 abortTest.py
>> Traceback (most recent call last):
>>   File "abortTest.py", line 6, in 
>> GPIO.setup("P9_12", GPIO.IN)
>> ValueError: Set gpio mode failed, missing file or invalid permissions.
>>
>>
>> Further, when I do the following (with or without the dtbo), I get the
>> following...
>>
>> kapsul@beaglebone:~/pyDev$ config-pin -q p9.12
>> P9_12 pinmux file not found!
>> Cannot read

Re: [beagleboard] Re: GPIO, libpruio & dtbo Question

[Don Pancoe]

You prompted me to recheck how I'm accessing the two peripherals I did get
to install, the UART and the I2C. I'm only sending messages out over the
UART using pyserial, although I do also use minicom to bi-directionally
communicate with the board under test from the BBB Ubuntu command line. For
the I2C I'm using the Adafruit char LCD library, which relies on busio from
Circuit Python. Still an Adafruit product, but not technically the BBB_IO
library, I guess.

If anyone can give tips on how to do a button-based interrupt (abort)
without BBB_IO, I'm all ears. I guess I could just start programming the
BBB in C. I already program embedded microcontrollers in that language, so
why not SBC?

--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com <http://donpancoe.com/>


On Mon, Mar 1, 2021 at 4:27 PM set_  wrote:

> Hello,
>
> I literally am havin' the same issue as you right now w/ a GPS module
> working w/ BB-UART2-00A0.dtbo and a grove connector. This is my error:
>
> *py_setup_uart(UART2): set_pin_mode() failed for pin=P9_22Traceback (most
> recent call last):*
> *  File "FirstGPS.py", line 5, in *
> *UART.setup("UART2")*
> *ValueError: Set pin mode failed for uart channel.*
>
> I think things are changing at some point in some way at some level.
> Vague...yes. I can set up my source w/out the .dtbo and use config-pin to
> set my uart2 pins to have my source 'work.'
>
> Anyway, I will be following along to see how far you get b/c right now, I
> am a  little stumped as to why what has worked no longer is viable.
>
> Seth
>
> On Monday, March 1, 2021 at 12:27:01 PM UTC-6 donp...@gmail.com wrote:
>
>> Hello all,
>>
>> I have a BBB Python application (PCBA test fixture) where I am using
>> libpruio, specifically for access to the eCAP pins. Libpruio requires that
>> the universal cape be disabled, but when I needed a UART and I2C, I was
>> able to add those back in using the existing dtbo files from /lib/firmware
>> (shown below) in my uEnv.txt.
>>
>> uboot_overlay_addr0=/lib/firmware/BB-I2C1-00A0.dtbo
>> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
>> uboot_overlay_addr2=/lib/firmware/DP-GPIO-PCBATest-00A0.dtbo (I talk
>> about this below)
>>
>>
>> Now I want to add an "abort" button to the test fixture since the
>> technicians have reported it takes a lot of time to reset if the board
>> under test locks up. I expect that wiring a pushbutton to a GPIO with an
>> interrupt is the way to handle this, and I've been thinking that there are
>> two ways to get there.
>>
>>1. Include another dtbo file to add a single GPIO that I can then
>>access with Adafruit_BBIO (this is where my efforts have focused so far), 
>> or
>>2. Figure out how to work with the hardware-based IRQ of the PRU
>>with libpruio (which I've been avoiding because it looks even more scary)
>>
>> I've tried to make a custom dtbo by following an example from Derek
>> Molloy (github.com/derekmolloy/boneDeviceTree) and while it compiled and
>> booted OK, I still get the following error when I run a simple test
>> program. The same error as when I tried running the program before I
>> created the dtbo.
>>
>> kapsul@beaglebone:~/pyDev$ sudo python3 abortTest.py
>> Traceback (most recent call last):
>>   File "abortTest.py", line 6, in 
>> GPIO.setup("P9_12", GPIO.IN)
>> ValueError: Set gpio mode failed, missing file or invalid permissions.
>>
>>
>> Further, when I do the following (with or without the dtbo), I get the
>> following...
>>
>> kapsul@beaglebone:~/pyDev$ config-pin -q p9.12
>> P9_12 pinmux file not found!
>> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_12_pinmux/state
>>
>>
>> Any input would be appreciated, whether it is correcting me on path 1 or
>> steering me towards path 2. I will happily provide any additional info, but
>> I didn't want to start uploading stuff until I know what, exactly, will be
>> helpful.
>>
>> Thanks,
>> --
>> Don Pancoe, P.E.
>> Industrial Designer, Electrical Engineer
>> DonPancoe.com <http://donpancoe.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/58e45b18-f019-49e7-92ce-95015cbc0e63n%40googlegrou

[beagleboard] GPIO, libpruio & dtbo Question

[Don Pancoe]

Hello all,

I have a BBB Python application (PCBA test fixture) where I am using
libpruio, specifically for access to the eCAP pins. Libpruio requires that
the universal cape be disabled, but when I needed a UART and I2C, I was
able to add those back in using the existing dtbo files from /lib/firmware
(shown below) in my uEnv.txt.

uboot_overlay_addr0=/lib/firmware/BB-I2C1-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr2=/lib/firmware/DP-GPIO-PCBATest-00A0.dtbo (I talk about
this below)


Now I want to add an "abort" button to the test fixture since the
technicians have reported it takes a lot of time to reset if the board
under test locks up. I expect that wiring a pushbutton to a GPIO with an
interrupt is the way to handle this, and I've been thinking that there are
two ways to get there.

   1. Include another dtbo file to add a single GPIO that I can then access
   with Adafruit_BBIO (this is where my efforts have focused so far), or
   2. Figure out how to work with the hardware-based IRQ of the PRU  with
   libpruio (which I've been avoiding because it looks even more scary)

I've tried to make a custom dtbo by following an example from Derek Molloy (
github.com/derekmolloy/boneDeviceTree) and while it compiled and booted OK,
I still get the following error when I run a simple test program. The same
error as when I tried running the program before I created the dtbo.

kapsul@beaglebone:~/pyDev$ sudo python3 abortTest.py
Traceback (most recent call last):
  File "abortTest.py", line 6, in 
GPIO.setup("P9_12", GPIO.IN)
ValueError: Set gpio mode failed, missing file or invalid permissions.


Further, when I do the following (with or without the dtbo), I get the
following...

kapsul@beaglebone:~/pyDev$ config-pin -q p9.12
P9_12 pinmux file not found!
Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_12_pinmux/state


Any input would be appreciated, whether it is correcting me on path 1 or
steering me towards path 2. I will happily provide any additional info, but
I didn't want to start uploading stuff until I know what, exactly, will be
helpful.

Thanks,
--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com <http://donpancoe.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/CAP3tSUMe396gTjaGsjq9Ucy1w_3zephaq%2BCaprGYdydx-tO0AQ%40mail.gmail.com.

Re: [beagleboard] BBBW Operating Temperature

[Don Pancoe]

If you have a need for extended temperature range, check out the BeagleBone
Black Industrial from element14. -40 to +85 C

https://beagleboard.org/e14-bbbi

Don

On Thu, May 7, 2020, 5:20 PM Claude Sammut  wrote:

>
> Hello!
> I was trying to find the operating temperatures for the BBBW but I could
> not find any official documentation other than that of the octavo
> processor. can perhaps someone shed some light or point me to the right
> 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/ecaae75d-8315-4526-b1f0-ca8c74dcfe28%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/CAP3tSUNsVie%3DcHGpCisYsKP-p_kq7qxUqG%2BU8x1V5Bi8BQf%3DvQ%40mail.gmail.com.

Re: [beagleboard] Barcode Scanner/Keyboard on BBB with Crontab

[Don Pancoe]

Thank you for this information. I will have to do some reading and
experimenting with udev and symlinks over the next few days.

Interesting that you mention this in the context of a BBB self-test,
because a PCBA factory functional test fixture is exactly the application
I'm working on right now.

--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com <http://donpancoe.com/>


On Tue, Apr 21, 2020 at 10:14 AM Jason Kridner 
wrote:

>
>
> On Tue, Apr 21, 2020 at 9:02 AM Don Pancoe  wrote:
>
>> Hello all,
>>
>> I have been successfully using a barcode scanner / keyboard emulator with
>> python on a BBB thanks to the evdev library (
>> https://python-evdev.readthedocs.io/en/latest/) recommended by Drew
>> Fustini.
>>
>> However, when I run the main program with crontab instead of from a
>> console (I want to eliminate the need to have a laptop at the workstation),
>> the barcode scanner no longer works. I suspect it has something to do with
>> with the /dev/input path to the device being different in that
>> environment, but I'm not entirely sure.
>>
>> I've done some searching and reading into this but haven't found the
>> magic answer yet. I've not yet even been able to connect a console to the
>> instance that was spawned by crontab to see what's going on inside of it.
>>
>> Any guidance appreciated, including pointing me to resources to work
>> through myself.
>>
>
> I've been using C, not Python, but I do launch my program from a udev
> rule, which should be comparable to being launched from crontab. I do a bit
> more in the udev rules (
> https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.rules)
> to actually create a symlink for the barcode scanner that I then use in my
> C program:
>
> KERNEL=="event*", ATTRS{idVendor}=="05fe", ATTRS{idProduct}=="1010",\
> SYMLINK+="input/beagle-barcode", TAG+="systemd",\
> ENV{SYSTEMD_WANTS}="beagle-tester.service"
> KERNEL=="event*", ATTRS{idVendor}=="05f9", ATTRS{idProduct}=="2204",\
> SYMLINK+="input/beagle-barcode", TAG+="systemd",\
> ENV{SYSTEMD_WANTS}="beagle-tester.service"
> KERNEL=="event*", ATTRS{idVendor}=="067e", ATTRS{idProduct}=="0801",\
> SYMLINK+="input/beagle-barcode", TAG+="systemd",\
> ENV{SYSTEMD_WANTS}="beagle-tester.service"
> KERNEL=="event*", ATTRS{idVendor}=="0c2e", ATTRS{idProduct}=="0901",\
> SYMLINK+="input/beagle-barcode", TAG+="systemd",\
> ENV{SYSTEMD_WANTS}="beagle-tester.service"
> KERNEL=="event*", ATTRS{idVendor}=="05f9", ATTRS{idProduct}=="2206",\
> SYMLINK+="input/beagle-barcode", TAG+="systemd",\
> ENV{SYSTEMD_WANTS}="beagle-tester.service"
> KERNEL=="event*", ATTRS{idVendor}=="24ea", ATTRS{idProduct}=="0197",\
> SYMLINK+="input/beagle-barcode", TAG+="systemd",\
> ENV{SYSTEMD_WANTS}="beagle-tester.service"
>
>
> You can see I also use the insertion of the barcode scanner to startup the
> beagle-tester.service (
> https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.service
> ):
>
> [Unit]
> Description=Beagle Self-test
> Requires=dev-input-beagle\x2dbarcode.device
> BindsTo=dev-input-beagle\x2dbarcode.device
> [Service]
> ExecStart=/usr/sbin/beagle-tester
>
> In my C program (
> https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.c#L3119),
> I just open up the symlink:
>
> int barcode = open("/dev/input/beagle-barcode", O_RDONLY);
> The path shouldn't change based on if you invoke the program from the
> console or by a crontab, but it could change due to adding/removing input
> devices. I suggest you look at my udev-rule + systemd method of invocation
> and see if that makes it more stable. The VID/PID entries in the udev rules
> are based on which barcode scanners I've used/tested. You can make a more
> generic rule to try to catch more input devices.
>
> Note, these rules come pre-installed on the Debian images, so they might
> actually be getting in your way already! We use these in production tests
> of the boards.
>
>
>
>> --
>> Don Pancoe, P.E.
>> Industrial Designer, Electrical Engineer
>> DonPancoe.com <http://donpancoe.com/>
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To u

[beagleboard] Barcode Scanner/Keyboard on BBB with Crontab

[Don Pancoe]

Hello all,

I have been successfully using a barcode scanner / keyboard emulator with
python on a BBB thanks to the evdev library (
https://python-evdev.readthedocs.io/en/latest/) recommended by Drew Fustini.

However, when I run the main program with crontab instead of from a console
(I want to eliminate the need to have a laptop at the workstation), the
barcode scanner no longer works. I suspect it has something to do with with
the /dev/input path to the device being different in that environment, but
I'm not entirely sure.

I've done some searching and reading into this but haven't found the magic
answer yet. I've not yet even been able to connect a console to the
instance that was spawned by crontab to see what's going on inside of it.

Any guidance appreciated, including pointing me to resources to work
through myself.

--
Don Pancoe, P.E.
Industrial Designer, Electrical Engineer
DonPancoe.com <http://donpancoe.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/CAP3tSUPTTQn7bZ_M53vRGzbdKgeSzefu_%2BDvTT4gDLE5rSp14A%40mail.gmail.com.

Re: [beagleboard] Re: libpruio: How to Turn Off PWM?

[Don Pancoe]

Thank you for the reply! So far,* pruio_pwm_setValue()* with a non-zero
frequency and zero duty cycle definitely seems like the most stable way to
stop a PWM signal.

Don

On Thu, Mar 14, 2019 at 12:42 PM TJF  wrote:

> Hi Don!
>
> Am Mittwoch, 13. März 2019 21:49:06 UTC+1 schrieb Don Pancoe:
>>
>> Using *pruio_gpio_setValue()* to set a value of zero seems to do the
>> trick, but I'd still be curious to know if there is an "official" way to do
>> this.
>>
>
> Setting the duty cycle to zero is the official way to switch off PWM
> output. (Note: switching off by setting the frequency to zero would be
> dangerous, since it will set the frequency for both outputs A and B in case
> of output generated by a PWMSS subsystem. That's why such a feature isn't
> implement.)
>
> 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/b33823ba-e93b-494e-8a5d-f814def919d2%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/b33823ba-e93b-494e-8a5d-f814def919d2%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAP3tSUN2Qn7nr-k4TyMpwfLbf%2BdxeWWRUZkEP8LmLgXJp0hYgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: libpruio: How to Turn Off PWM?

[Don Pancoe]

Using *pruio_gpio_setValue()* to set a value of zero seems to do the trick, 
but I'd still be curious to know if there is an "official" way to do this.

Don


On Wednesday, March 13, 2019 at 10:39:43 AM UTC-4, Don Pancoe wrote:
>
> I have been making good progress with learning and using libpruio 
> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/>, but 
> I've hit a question I've been unable to work out for myself.
>
> I've successfully started PWM signals using *pruio_pwm_setValue()*, but 
> I'm having an issue turning those same PWM signals off when I'm done with 
> them. I've tried using *setValue()* again with zero values for frequency 
> and/or duty cycle, and my DMM (which can measure such things) is reporting 
> zero frequency and duty cycle, but it is also measuring a constant 3v3 
> output on that header pin. Effectively a 100% duty cycle, which my DMM 
> would actually report as zero frequency and duty cycle.
>
> Is there anything I'm missing here, or are there better ways to turn off 
> the PWM signal in libpruio?
>
> FYI, I have a Beaglebone Black, Linux 4.14, Debian 6.3, but I've noticed 
> more libpruio discussion on his board. I can also post any additional 
> information needed.
>
> Thanks,
> Don
>

-- 
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/b548637c-931d-44cf-ab8b-d21066fbe18a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] libpruio: How to Turn Off PWM?

[Don Pancoe]

I have been making good progress with learning and using libpruio 
, but 
I've hit a question I've been unable to work out for myself.

I've successfully started PWM signals using *pruio_pwm_setValue()*, but I'm 
having an issue turning those same PWM signals off when I'm done with them. 
I've tried using *setValue()* again with zero values for frequency and/or 
duty cycle, and my DMM (which can measure such things) is reporting zero 
frequency and duty cycle, but it is also measuring a constant 3v3 output on 
that header pin. Effectively a 100% duty cycle, which my DMM would actually 
report as zero frequency and duty cycle.

Is there anything I'm missing here, or are there better ways to turn off 
the PWM signal in libpruio?

FYI, I have a Beaglebone Black, Linux 4.14, Debian 6.3, but I've noticed 
more libpruio discussion on his board. I can also post any additional 
information needed.

Thanks,
Don

-- 
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/59134dc8-972a-439a-a132-b2a1bbee277c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.