Re: [beagleboard] BBB GPIO pin output capability

[Steve Lentz]

Yep, be careful of things like 4-20 mA sensors, they often send 24V to the 
output when being turned on.  That’s where some capacitance across the input 
pins will really help.  For motor controllers or anything vaguely industrial, 
it’s best to use optocouplers, I’ve had good results with VO618As.  I2C devices 
are pretty tame, not a lot needed for these.

-Cheers

> On 15 Nov 2022, at 5:11 PM, Chris Green  wrote:
> 
> Stephen Lentz  wrote:
>>> On Nov 15, 2022, at 4:33 PM, Chris Green  wrote:
>>> 
>>> I can't find this anywhere in the System Reference Manual.  What is
>>> the drive capability of the BBB output pins? Also what is the best way
>>> of buffering them so they won't get any bad voltages fed back into
>>> them? 
>>> 
>> 6 mA. 
>> 
> OK, thank you, that's loads more than I need so no problem there.
> 
> 
>> Voltage dividers, 5k1 resistors going into the pin, filter capacitors and 
>> TVSS. Use more than one, better yet all of them. Or buy a crate of BBs 
>> cause you’ll burn out a few while prototyping. Don’t ask me how I know. 
>> 
> :-)  I've not killed any of my (3)  BBBs yet.  I was very careful with
> buffering on the one that is actually doing live monitoring.  It's
> outputs drive the 'outside world' through some Hobbytronics level
> converters and that seems to have kept the BBB safe.
> 
> I think I'll probably just use another of the level converters on the
> one more output I'm going to use.
> 
> -- 
> Chris Green
> ·
> 
> -- 
> 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/rcfd4j-356k2.ln1%40esprimo.zbmc.eu.

-- 
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/95904AA9-0F91-496B-90BE-774BCCEFA21B%40gmail.com.

Re: [beagleboard] Autorun Python Script can't write files

[Steve Lentz]

Dennis:

Thanks for this, I had to increase the hold off to 60 seconds but that’s fine 
for my purposes.  

I discovered that sudo systemctl status cron gives good output for debugging.

While troubleshooting, I made my script executable with chmod 777 autotest.py 
although I’m not certain this was necessary.

-Steve



> On Apr 16, 2021, at 3:28 PM, Dennis Lee Bieber  
> wrote:
> 
> On Fri, 16 Apr 2021 09:01:33 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user
> "stl...-re5jqeeqqe8avxtiumw...@public.gmane.org"
>  wrote:
> 
>> I want my autorun python script to write information into a text file. 
>> This works fine when the python file is run from the Cloud9 interface, but 
>> does not run properly when the beagleboard restarted.  
>> 
>> The command that is failing is:
>> 
>> with open("/home/debian/logs/testlog.txt",'a',encoding = 'utf-8') as f:
>>  f.write("bbb autorun test\n")
>> 
>> I am running Buster IoT Image 2020-04-06 on a beagle board black.
>> 
>> I have tried using chmod 666, chmod 755 etc, on the target file and 
>> enclosing directory with no success.
>> 
>> I see a number of older threads about using chron, but these don't seem 
>> applicable in light of having autorun.
>> 
>> Any idea what is preventing this script from writing to a file when it is 
>> autorun?  Is this a permissions issue and how would I change that?
> 
>   I have no idea what systemd does when starting Cloud9 and processing
> its "autorun" directory...
> 
>   Personally, I would move your file /out of/ Cloud9 into some location
> in your home directory...
> 
> {in Cloud9}
> debian@beaglebone:/var/lib/cloud9$ mv autorun/autotest.py ~
> 
> ... and then add it to that user's crontab...
> 
> {rest is all via SSH using PuTTY}
> debian@beaglebone:~$ crontab -e
> no crontab for debian - using an empty one
> 
> Select an editor.  To change later, run 'select-editor'.
>  1. /usr/bin/vim.nox
>  2. /bin/nano< easiest
>  3. /usr/bin/vim.basic
>  4. /usr/bin/vim.tiny
>  5. /bin/nano-tiny
> 
> Choose 1-5 [2]: 3
> crontab: installing new crontab
> 
> {the vim session is not shown} 
> 
>   Locating the actual crontab file...
> 
> debian@beaglebone:~$ sudo cat /var/spool/cron/crontabs/debian
> # DO NOT EDIT THIS FILE - edit the master and reinstall.
> # (/tmp/crontab.Wesos5/crontab installed on Fri Apr 16 15:00:39 2021)
> # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
> # Edit this file to introduce tasks to be run by cron.
> #
> # Each task to run has to be defined through a single line
> # indicating with different fields when the task will be run
> # and what command to run for the task
> #
> # To define the time you can provide concrete values for
> # minute (m), hour (h), day of month (dom), month (mon),
> # and day of week (dow) or use '*' in these fields (for 'any').
> #
> # Notice that tasks will be started based on the cron's system
> # daemon's notion of time and timezones.
> #
> # Output of the crontab jobs (including errors) is sent through
> # email to the user the crontab file belongs to (unless redirected).
> #
> # For example, you can run a backup of all your user accounts
> # at 5 a.m every week with:
> # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
> #
> # For more information see the manual pages of crontab(5) and cron(8)
> #
> # m h  dom mon dow   command
> @reboot sleep 30 && /home/debian/autotest.py
>> /home/debian/logs/unexpected.log  2>&1
> 
> debian@beaglebone:~$
>   Note: the crontab operation wrapped, the redirection is part of the
> @reboot line.
> 
>   I found I had to put in the 30 second delay to allow the system time to
> set up the GPIOs, without the job failed on 
> 
> GPIO.setup(relay3, GPIO.OUT)
> 
> with a missing file or permission error.
> 
>   I ended on 30 seconds as that is where dmesg had a major break...
> 
> [   25.949286] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
> [   26.184613] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
> [   66.991145] remoteproc remoteproc0: wkup_m3 is available
> [   67.376203] remoteproc remoteproc0: powering up wkup_m3
> 
> 
> 
> -- 
> 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/k4mj7g99ck3j9l01upctmbtuj500b3afoh%404ax.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/4BBF76CA-8C38-49C3-AA29-9

Re: [beagleboard] Is BBB a SoC FPGA

[Steve Lentz]

No, an FPGA contains programmable logic.  Flash is storage.  Yes, you can make 
look up tables in flash that emulate some simple FPGA functions, but flash is 
not an FPGA.

An example of a SoC FPGA is the Xilinx Zynq.  The ZCU104, PYNQ-Z1 or PYNQ-Z2 
are examples of boards with this type of SoC.



> On Feb 26, 2021, at 4:41 AM, S Pazouki  wrote:
> 
> Is Beagleboard Black a SoC FPGA ?
> I have hard that a system with CPU and Flash is kind of SoC FPGA, Am I right? 
> 
> -- 
> 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/f2f662f9-b72a-432e-b955-63cb55a61dbcn%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/FCE25466-DFDE-4E01-9B35-D9BB6B82B415%40gmail.com.

Re: [beagleboard] Comms Cape

[Steve Lentz]

Dwayne:

Interesting question - I built my own shunt circuits on a protoboard so I was 
able to bring out a connection to P9_34.

After looking at the BBB schematic, I see there is a ferrite bead connecting 
GNDA to GND, so there is continuity between them and you should be able to use 
the GND on positions 1 or 10 of X1.  

-Steve


> On Feb 2, 2021, at 8:47 PM, Dwayne Zimmerman  wrote:
> 
> Steve
> Thanks that helps a lot, but the agnd is not actually brought out to the 
> terminal strip only the gnd. How do I attach to agnd?
> 
> On Tuesday, February 2, 2021 at 8:27:25 PM UTC-5 stl...@gmail.com wrote:
> The comms board 4-20mA current loop input consists of a 75Ω shunt resistor 
> across one of the analog input pins.  
> 
> You need to connect an appropriate voltage source to your device and the 
> other end of your device to the comms board input.  Connect the ground of 
> your voltage source to the Analog Ground pin.  
> 
> Divide the measured voltage by 75 to obtain the current.
> 
> The cape does not provide a voltage source,  Many devices use 24V excitation, 
> but this is not universal.  Thus the choice of voltage source is left to you.
> 
> Hope this helps someone.  Schematic can be found here if you have any doubts: 
>  
> https://github.com/beagleboard/capes/blob/master/beaglebone/Comms/Comms_Cape_sch.pdf
>  
> 
> 
> 
> 
> 
> 
> 
>> On Feb 2, 2021, at 8:14 PM, evilwulfie > > wrote:
>> 
> 
>> you can use an current to voltage converter then an opamp to level shift it
>> 
>> On 2/2/2021 5:03 PM, Dwayne Zimmerman wrote:
>>> Can anyone tell me how to connect a sensor to the 4-20mA input on the comms 
>>> board.I need temperature and all 4-20mA temperature sensors I'm familiar 
>>> with are 24 VDC not 1.8
>>> 
>>> On Monday, February 1, 2021 at 7:29:46 PM UTC-5 Dennis Bieber wrote:
>>> On Mon, 1 Feb 2021 15:46:51 -0800 (PST), in 
>>> gmane.comp.hardware.beagleboard.user Dwayne Zimmerman 
>>> > wrote: 
>>> 
>>> >So the pull down is to keep the voltage under 1.8 correct? My confusion is 
>>> >I have one screw per input, 4-20mA is two wire where is the other half of 
>>> >the circut? 
>>> > 
>>> 
>>> I suspect the pull-down is only ensuring that the floating voltage is 
>>> tied to 0V; feeding anything with a voltage over 1.8V will still fry the 
>>> input. And since 0V likely also means 0mA, it indicates a fault condition 
>>> in the loop. 
>>> 
>>> https://www.fluke.com/en-us/learn/best-practices/test-tools-basics/process-tools/what-is-a-4-20-ma-current-loop
>>>  
>>> 
>>>  
>>> https://www.predig.com/indicatorpage/back-basics-fundamentals-4-20-ma-current-loops
>>>  
>>> 
>>>  
>>> {Many others| 
>>> 
>>> The input to the BBB likely needs to consist of a current->voltage 
>>> tranform, so the ADC can measure the voltage corresponding to the current. 
>>> Which might be built-into the cape (I've not looked at it). 
>>> 
>>> 
>>> -- 
>>> 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...@googlegroups.com 
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/5fd03d5f-b21f-43b8-b3d3-ae464ff8d1bdn%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...@googlegroups.com 
>> .
> 
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/9654dc5a-2d31-6f0f-a745-ae085db30859%40gmail.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/9f22b7ef-9eff-4f16-aa73-6

Re: [beagleboard] Comms Cape

[Steve Lentz]

The comms board 4-20mA current loop input consists of a 75Ω shunt resistor 
across one of the analog input pins.  

You need to connect an appropriate voltage source to your device and the other 
end of your device to the comms board input.  Connect the ground of your 
voltage source to the Analog Ground pin.  

Divide the measured voltage by 75 to obtain the current.

The cape does not provide a voltage source,  Many devices use 24V excitation, 
but this is not universal.  Thus the choice of voltage source is left to you.

Hope this helps someone.  Schematic can be found here if you have any doubts:  
https://github.com/beagleboard/capes/blob/master/beaglebone/Comms/Comms_Cape_sch.pdf
 






> On Feb 2, 2021, at 8:14 PM, evilwulfie  wrote:
> 
> you can use an current to voltage converter then an opamp to level shift it
> 
> On 2/2/2021 5:03 PM, Dwayne Zimmerman wrote:
>> Can anyone tell me how to connect a sensor to the 4-20mA input on the comms 
>> board.I need temperature and all 4-20mA temperature sensors I'm familiar 
>> with are 24 VDC not 1.8
>> 
>> On Monday, February 1, 2021 at 7:29:46 PM UTC-5 Dennis Bieber wrote:
>> On Mon, 1 Feb 2021 15:46:51 -0800 (PST), in 
>> gmane.comp.hardware.beagleboard.user Dwayne Zimmerman 
>> > > wrote: 
>> 
>> >So the pull down is to keep the voltage under 1.8 correct? My confusion is 
>> >I have one screw per input, 4-20mA is two wire where is the other half of 
>> >the circut? 
>> > 
>> 
>> I suspect the pull-down is only ensuring that the floating voltage is 
>> tied to 0V; feeding anything with a voltage over 1.8V will still fry the 
>> input. And since 0V likely also means 0mA, it indicates a fault condition 
>> in the loop. 
>> 
>> https://www.fluke.com/en-us/learn/best-practices/test-tools-basics/process-tools/what-is-a-4-20-ma-current-loop
>>  
>> 
>>  
>> https://www.predig.com/indicatorpage/back-basics-fundamentals-4-20-ma-current-loops
>>  
>> 
>>  
>> {Many others| 
>> 
>> The input to the BBB likely needs to consist of a current->voltage 
>> tranform, so the ADC can measure the voltage corresponding to the current. 
>> Which might be built-into the cape (I've not looked at it). 
>> 
>> 
>> -- 
>> 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/5fd03d5f-b21f-43b8-b3d3-ae464ff8d1bdn%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/9654dc5a-2d31-6f0f-a745-ae085db30859%40gmail.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/2C68CEE2-3A98-4D73-95E2-1851938D8C73%40gmail.com.

Re: [beagleboard] apt on BBB *very* slow, anyone else noticed?

[Steve Lentz]

Mine runs fast when there’s nothing to be found:

debian@beaglebone:/var/lib/cloud9$ time apt search abcxyz
Sorting... Done
Full Text Search... Done

real0m11.625s
user0m10.423s
sys 0m0.482s


But slower when it does get results:

debian@beaglebone:/var/lib/cloud9$ time apt search vile
Sorting... Done
Full Text Search... Done
bubblewrap/stable 0.3.1-4 armhf
  setuid wrapper for unprivileged chroot and namespace manipulation

calife/stable 1:3.0.1-5 armhf
  Provides super user privileges to specific users



real1m20.150s
user1m16.055s
sys 0m2.485s


Although no where near as long as OP.

> On Feb 2, 2021, at 7:13 AM, Chris Green  wrote:
> 
> Chris Green  wrote:
>> That's interesting, it looks as if there is some sort of bug/oddity on
>> the BBB then.  It does seem to affect some other things as well, my
>> BBB feels a lot slower in general than previous incarnations were.
>> Maybe I'll try an older Debian and see if it acts the same.
>> 
> The problem isn't unique to the BBB/Debian, I've found quite a few
> other people with similar issues where parts of apt take a very long
> time.
> 
> The time taken seems to relate to how many hits there are in the
> search!  If you search for something that doesn't exist it takes (on
> my BBB) about 30 seconds:-
> 
>chris@beaglebone$ time apt search xyzabc
>Sorting... Done
>Full Text Search... Done
> 
>real0m27.532s
>user0m26.315s
>sys 0m1.035s
> 
> Searching for something that has three hits takes longer:-
> 
>chris@beaglebone$ time apt search xvile
>Sorting... Done
>Full Text Search... Done
>vile-common/stable,now 9.8t-1 all [installed,automatic]
>  VI Like Emacs - support files for vile/xvile
> 
>vile-filters/stable,now 9.8t-1 armhf [installed]
>  VI Like Emacs - highlighting filters for vile/xvile
> 
>xvile/stable 9.8t-1 armhf
>  VI Like Emacs - vi work-alike (X11)
> 
> 
>real1m2.063s
>user0m59.874s
>sys 0m1.862s
> 
> 
> Searching for just 'vile' produces quite a lot of hits because there's quite 
> a few packages 
> with the word 'privilege' in them, so it takes around four minutes.
> 
> 
> A workaround is to use 'apt-cache search' instead:-
> 
>chris@beaglebone$ time apt-cache search vile
>bubblewrap - setuid wrapper for unprivileged chroot and namespace 
> manipulation
>calife - Provides super user privileges to specific users
>chiark-really - really - a tool for gaining privilege (simple, realistic 
> sudo)
>cups-pk-helper - PolicyKit helper to configure cups with fine-grained 
> privileges
>fakeroot - tool for simulating superuser privileges
>libfakeroot - tool for simulating superuser privileges - shared libraries
>gssproxy - Privilege separation daemon for GSSAPI
>libkf5su5 - Integration with su for elevated privileges.
>lacme - ACME client written with process isolation and minimal privileges 
> in mind
>libprivileges-drop-perl - module to make it simple to drop all privileges
>libutempter-dev - privileged helper for utmp/wtmp updates (development)
>libutempter0 - privileged helper for utmp/wtmp updates (runtime)
>policykit-1 - framework for managing administrative policies and privileges
>privbind - Allow unprivileged apps to bind to a privileged port
>libpseudo - advanced tool for simulating superuser privileges
>pseudo - advanced tool for simulating superuser privileges
>python-oslo.privsep - OpenStack library for privilege separation - Python 
> 2.7
>python-oslo.privsep-doc - OpenStack library for privilege separation - doc
>python3-oslo.privsep - OpenStack library for privilege separation - Python 
> 3.x
>slirp4netns - User-mode networking for unprivileged network namespaces
>sudo - Provide limited super user privileges to specific users
>sudo-ldap - Provide limited super user privileges to specific users
>vile - VI Like Emacs - vi work-alike
>vile-common - VI Like Emacs - support files for vile/xvile
>vile-filters - VI Like Emacs - highlighting filters for vile/xvile
>xvile - VI Like Emacs - vi work-alike (X11)
>weborf - Fast and small webserver meant to be run without root privileges
>libyubikey-udev - udev rules for unprivileged access to YubiKeys
>zulupolkit - handler the polkit privileges
> 
>real0m21.826s
>user0m20.697s
>sys 0m0.944s
>chris@beaglebone$ 
> 
> That's not affected by the number of hits:-
> 
>chris@beaglebone$ time apt-cache search xvile
>vile-common - VI Like Emacs - support files for vile/xvile
>vile-filters - VI Like Emacs - highlighting filters for vile/xvile
>xvile - VI Like Emacs - vi work-alike (X11)
> 
>real0m21.663s
>user0m20.614s
>sys 0m0.924s
> 
> 
> 
> 
> -- 
> Chris Green
> ·
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Gro

Re: [beagleboard] Comms Cape

[Steve Lentz]

I think you have to provide an external voltage source - the 4-20 mA circuits 
are sort of like the Sink-A and Sink-B circuits, they are just one end of 
something.

I connect my 4-20 mA pressure gauges to the same 24V source that supplies my 
power cape.  Then the return path from the pressure gauge goes through the 
shunt resistor across the analog input.  However, I’m not using this cape, I 
built my own shunt circuit on a protoboard.  

> On Feb 1, 2021, at 6:46 PM, Dwayne Zimmerman  wrote:
> 
> So the pull down is to keep the voltage under 1.8 correct? My confusion is I 
> have one screw per input, 4-20mA is two wire where is the other half of the 
> circut?
> 
> On Monday, February 1, 2021 at 6:40:01 PM UTC-5 RobertCNelson wrote:
> On Mon, Feb 1, 2021 at 5:24 PM Dwayne Zimmerman  > wrote: 
> > 
> > Thanks I have that. It doesn't detail the 4-20mA circut, unless I'm missing 
> > something. I'm trying to understand where power comes from and at what 
> > voltage. 
> 
> Each of those two connectors are connected to an adc pin. 
> 
> They both have a pull-down.. 
> 
> The ADC's can only take 1.8V, any more and they will fry.. 
> 
> Regards, 
> 
> -- 
> Robert Nelson 
> https://rcn-ee.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/60ff116c-040f-47cd-a34f-58e726fb88d7n%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/F0EF6982-7DA9-4F9E-B82E-0DFE21A64EC3%40gmail.com.

Re: [beagleboard] I2C problems

[Steve Lentz]

I can only speak from my experience. I have three Adafruit sensor breakouts 
connected on I2C bus 2.  Each of these has its own 10K pull-up resistors. The 
last board did not work until I added an external 1K pull up.  It is 100% 
reliable since then.  I have built this twice and experienced the same thing 
both times.  I spent a lot of time chasing software and asking questions on 
this forum.  Five minutes with an oscilloscope showed me the real problem was 
that high values on the SDA line were not reaching 3.3V before it was sampled.  
Based on this, a logical next step is to add an external 1K pull up and see 
what happens.



> On Jan 25, 2021, at 12:35 PM, Dennis Lee Bieber  
> wrote:
> 
> On Mon, 25 Jan 2021 10:42:50 -0500, in gmane.comp.hardware.beagleboard.user
> Steve Lentz  wrote:
> 
>> Here is the diagram for my i2c device.  This shows where the pull-up 
>> resistors are added.  You will need something similar.  
>> 
>> But first check the documentation for the thermo-click to see if it already 
>> has pull-up resistors.  It may have 2K, 5K, 10K already.  Don’t allow the 
>> parallel resistance to go below 500 ohms.   
>> 
> 
>   If I interpret the confusing schematic from
> https://www.mikroe.com/thermo-9-click there appear to already be a pair of
> 4.7k pull-ups on the board.
> 
> 
> -- 
> 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/e70u0g58r86qs7ct4roe7b5fjpgk6pit1f%404ax.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/F621C5DC-2FD4-4100-847E-90E367F84602%40gmail.com.

Re: [beagleboard] I2C problems

[Steve Lentz]

Then it is safe to add 1K.  My devices have 10K and did not work until I added 
the 1K resistors.

I checked in on a scope and adding 1K fixed the waveform.

-Steve



> On Jan 25, 2021, at 10:49 AM, Astrid Hochart  wrote:
> 
> I just checked and they already have pull up resistors of 4.7 kohms.
> 
> Astrid Hochart
> Product developer - QZabre LLC
> www.qzabre.com <http://www.qzabre.com/>
> 
> 
> On Mon, Jan 25, 2021 at 4:42 PM Steve Lentz  <mailto:stle...@gmail.com>> wrote:
> Here is the diagram for my i2c device.  This shows where the pull-up 
> resistors are added.  You will need something similar.  
> 
> But first check the documentation for the thermo-click to see if it already 
> has pull-up resistors.  It may have 2K, 5K, 10K already.  Don’t allow the 
> parallel resistance to go below 500 ohms.   
> 
> 
> 
>> On Jan 25, 2021, at 10:32 AM, Astrid Hochart > <mailto:ast...@qzabre.com>> wrote:
>> 
>> Hello !
>> 
>> Thank you for your reply. So I need to have a wire from Pin19 to a 
>> resistance and then another wire from the resistance to SCL pin of my sensor 
>> ? (and same for SDA and pin 20) 
>> 
>> Astrid Hochart
>> Product developer - QZabre LLC
>> www.qzabre.com <http://www.qzabre.com/>
>> 
>> 
>> On Mon, Jan 25, 2021 at 3:59 PM evilwulfie > <mailto:evilwul...@gmail.com>> wrote:
>> You also need pull up resistors on the I2C lines
>> 
>> On 1/25/2021 7:46 AM, Astrid Hochart wrote:
>>> 19 and 20 as mentioned on the pins description !
>>> 
>>> Astrid Hochart
>>> Product developer - QZabre LLC
>>> www.qzabre.com <http://www.qzabre.com/>
>>> 
>>> 
>>> On Mon, Jan 25, 2021 at 3:44 PM Vinicius Juvinski 
>>> mailto:vinicius.juvin...@gmail.com>> wrote:
>>> Hi Astrid,
>>> 
>>> where are you hooking your sensor ? What pins are you using?
>>> 
>>> Em seg., 25 de jan. de 2021 às 11:39, Astrid Hochart >> <mailto:ast...@qzabre.com>> escreveu:
>>> 
>>> Hello Vinicius,
>>> 
>>> Thank you for your email. I tried what you said but I still detect nothing. 
>>> Is it the line with addr0 or addr1 that I should change ?
>>> 
>>> Astrid Hochart
>>> Product developer - QZabre LLC
>>> www.qzabre.com <http://www.qzabre.com/>
>>> 
>>> 
>>> On Mon, Jan 25, 2021 at 3:02 PM Vinicius Juvinski 
>>> mailto:vinicius.juvin...@gmail.com>> wrote:
>>> Hi
>>> 
>>> You need to load a dtb to enable the i2c
>>> Edit uEnv.txt file and uncomment #u_boot_overlay_addr1 and add instead 
>>> .dtbo add BB-I2CX-00A0.dtb where x is the i2c 1 or 2 according the 
>>> port you are using. 
>>> 
>>> Sent from my iPhone
>>> 
>>> 
>>>> Em 25 de jan. de 2021, à(s) 10:38, Astrid Hochart >>> <mailto:ast...@qzabre.com>> escreveu:
>>>> 
>>>> Hello everyone,
>>>> 
>>>> I'm new to this subject but I'm trying to collect temperature data from 
>>>> this sensor : https://www.mikroe.com/thermo-9-click 
>>>> <https://www.mikroe.com/thermo-9-click> by using Python and a BeagleBone 
>>>> Black Rev C. The BBB is new and I don't have any SD card so I flashed 
>>>> nothing on it. My problem is that when I connect the sensor (where I moved 
>>>> the resistance to allow I2C mode) the BBB detects nothing : do you have 
>>>> any idea why ? Should I "enable" I2C pins ? 
>>>> 
>>>> I'll be grateful if someone can help me.
>>>> 
>>>> Best regards,
>>>> -- 
>>>> For more options, visit http://beagleboard.org/discuss 
>>>> <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 
>>>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/beagleboard/307d5c0a-d2ff-4f0a-a914-67ad2e4fdf92n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/307d5c0a-d2ff-4f0a-a914-67ad2e4fdf92n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>> -- 
>>> For more 

Re: [beagleboard] I2C problems

[Steve Lentz]

Astrid:

I debugged an I2C bus just recently - I had 3 devices, a DS3231 real time 
clock, a BME680 environmental sensor and a BNO055 inertial motion unit.  I had 
a lot of trouble with the last one.

Two suggestions:

First, use the i2cdetect and i2cdump utilities.  The basic commands to check 
i2C bus 2 (pins P9_19 and P9_20) are:

I2cdetect -l
I2cdetect -r 2

You can google "i2cdetect BBB” to find more info.  Using these rules out any 
problems with Python.  If your device is not showing up, check your wiring. If 
it is showing up and i2cdump works too, then you may want to check the python 
libraries.

Second, if you have access to an oscilloscope, use it to check SDA and SCL.  My 
BNO was appearing in i2cdetect and working intermittently in Python.  When I 
looked at it with the ’scope, it was clear that low to high transitions on SDA 
where taking far too long.  A 1KΩ pull-up resistor fixed this (add it close to 
the sensor between SDA and 3V3).  If you don’t have a scope, try adding the 
pull up resistor.  My devices each had a 10KΩ pull up, but this was not enough. 
 Be careful that the combined load does not exceed the 6 mA the BBB pins can 
safely sink.  

In case you need it, here’s the full list of python libraries I installed.  The 
first one is included in a fresh install, but check to see if it needs 
upgrading.  You can ignore the last 3 and use the one for your sensor instead.  
Nothing else is needed.  There is a lot of old information still posted; these 
should work on a fresh install.  Note the odd underscore in lis3dh is correct.  

sudo pip3 install Adafruit_BBIO -U
sudo pip3 install adafruit_circuitpython-lis3dh
sudo pip3 install adafruit-circuitpython-busdevice
sudo pip3 install adafruit-circuitpython-register
sudo pip3 install adafruit-circuitpython-ds3231
sudo pip3 install adafruit-circuitpython-bme680
sudo pip3 install adafruit-circuitpython-bno055

Hope this helps,

-Steve



> On Jan 25, 2021, at 8:06 AM, Astrid Hochart  wrote:
> 
> Hello everyone,
> 
> I'm new to this subject but I'm trying to collect temperature data from this 
> sensor : https://www.mikroe.com/thermo-9-click by using Python and a 
> BeagleBone Black Rev C. The BBB is new and I don't have any SD card so I 
> flashed nothing on it. My problem is that when I connect the sensor (where I 
> moved the resistance to allow I2C mode) the BBB detects nothing : do you have 
> any idea why ? Should I "enable" I2C pins ? 
> 
> I'll be grateful if someone can help me.
> 
> Best 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/307d5c0a-d2ff-4f0a-a914-67ad2e4fdf92n%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/26B1FAB2-B2A3-4E06-BAA6-3115856BB5AB%40gmail.com.

Re: [beagleboard] BeagleBone Black: MCP9600 thermocouple temperature convertor: I2C clock stretching issue

[Steve Lentz]

Jason:

What happens when you reading the device with the i2cdump utility? This has a 
mode setting to control whether it reads bytes (8 bits) or words (16 bits) at a 
time. For example:

i2cdump -y 2 0x67 b

Should dump the entire contents of the MCP9600 registers as bytes.   

There’s a man page that gives all the options.

I found this command useful when troubleshooting my own i2c devices.  If 
i2cdump works properly, that would seem to indicate a driver issue.  If it 
doesn’t work, then it’s something else.

-Steve



> On Jan 17, 2021, at 12:09 PM, Jason Kridner  wrote:
> 
> 
> 
> On Wednesday, June 19, 2019 at 12:12:05 PM UTC-4 maden...@gmail.com wrote:
> Dear friends, I'm trying to use the mikro-e Thermo K Click 
> , a break out board with Microchip's 
> MCP9600 
> 
>  thermocouple convertor, with the BeagleBone Black. It is connected by I2C 
> and supports a clock frequency of up to 100 kHz. 
> In order to read a measurement from the MCP9600 (at the I2C address 0x67), 
> six bytes of data have to be read from its register 0x00 on:
> 
> 
> As specified in the MCP9600's data sheet, clock stretching occurs after each 
> transmitted byte.
> 
> More than 90% of all queries yield non-sense values because clock stretching 
> after some bytes is missed and the previous one seems to be repeated then, 
> which looks like this:
> 
> 
> Do you have any idea what is going wrong there? I believed the BBB to support 
> clock stretching, and now I'm wondering if that is really the problem.
> 
> Thank you for your help in advance.
> 
> 
> Did you ever get any resolution on this? The hardware/driver should support 
> clock stretching, but I've started running into an issue where it doesn't 
> seem to be reporting the support properly--though I could be dealing with an 
> issue with a incompletely back-ported driver. It made me curious if you ever 
> found your issue.
>  
> 
> -- 
> 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/2d0c6fb6-7f05-4be8-892c-c0e52601c96fn%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/27B199CF-8A6A-4747-8FD6-F46BCB1467AE%40gmail.com.

Re: [beagleboard] PWM on P8_13

[Steve Lentz]

Robert:

I found a useful article on device tree overlays here: 
http://www.ofitselfso.com/BeagleNotes/Beaglebone_Black_And_Device_Tree_Overlays.php

After uncommenting the line disable_uboot_overlay_addr3=1 in /boot/uEnv.txt, 
PWM is working on pin 8_13, even with the Prototype Cape attached.

So I believe something in the overlay stored in EEPROM on this particular cape 
is interfering with PWM.  Here is a link to the cape I purchased in case you 
want to investigate further:  
https://www.mouser.com/ProductDetail/958-PROCPE-BBBCAPE/ 
<https://www.mouser.com/ProductDetail/958-PROCPE-BBBCAPE/>

Disabling loading of cape’s overlay is a workable solution for me, I am using 
it only to hold some passive circuits and optocouplers, so I am happy with this 
approach.  

Thanks again.

Rgds,
-Steve Lentz



> On Jan 15, 2021, at 2:58 PM, Robert Nelson  wrote:
> 
> On Fri, Jan 15, 2021 at 1:43 PM Steve Lentz  wrote:
>> 
>> I’ve investigated a bit more.  First, and I should have done this sooner, I 
>> removed all the capes I’m using and tested the bare Beaglebone black.  
>> Success, all four PWMs work.
>> 
>> Then I began adding capes one at a time.  I found that when a Prototype Cape 
>> is used, PWM is no longer available on P8_13.  To be absolutely certain, I 
>> connected a brand new out of the box GHI Prototype Cape.  No PWM on P8_13.  
>> Remove the cape and PWM works.
>> 
>> If I connect a Power Cape, PWM works, this would seem to rule out a bad 
>> solder joint or something physical on the BBB.
>> 
>> There is nothing near P8_13 on any of these capes, yet something is 
>> affecting that pin.
>> 
>> Is there something in the device tree that allows the cape to grab one of 
>> the PWM devices, perhaps for the variable LED that’s on the cape?
>> 
>> Any other ideas what would cause this?
> 
> Do you have a part number for the Prototype Cape used?
> 
> Sorry it doesn't ring a bell for me..
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.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/8A167D50-C80A-4609-884C-FF74A3715FD7%40gmail.com.

Re: [beagleboard] PWM on P8_13

[Steve Lentz]

Robert:

Here’s the Protocape I’m using. 

https://www.mouser.com/ProductDetail/GHI-Electronics/PROCPE-BBBCAPE/?qs=%2Fha2pyFaduhYaf7QzOXEjT4Cxvjq5LV4K%252BpzPqLfbemsoOspjhGUYAv785Skf%252BJZ
 
<https://www.mouser.com/ProductDetail/GHI-Electronics/PROCPE-BBBCAPE/?qs=/ha2pyFaduhYaf7QzOXEjT4Cxvjq5LV4K%2BpzPqLfbemsoOspjhGUYAv785Skf%2BJZ>

-Steve

> On Jan 15, 2021, at 2:58 PM, Robert Nelson  wrote:
> 
> On Fri, Jan 15, 2021 at 1:43 PM Steve Lentz  wrote:
>> 
>> I’ve investigated a bit more.  First, and I should have done this sooner, I 
>> removed all the capes I’m using and tested the bare Beaglebone black.  
>> Success, all four PWMs work.
>> 
>> Then I began adding capes one at a time.  I found that when a Prototype Cape 
>> is used, PWM is no longer available on P8_13.  To be absolutely certain, I 
>> connected a brand new out of the box GHI Prototype Cape.  No PWM on P8_13.  
>> Remove the cape and PWM works.
>> 
>> If I connect a Power Cape, PWM works, this would seem to rule out a bad 
>> solder joint or something physical on the BBB.
>> 
>> There is nothing near P8_13 on any of these capes, yet something is 
>> affecting that pin.
>> 
>> Is there something in the device tree that allows the cape to grab one of 
>> the PWM devices, perhaps for the variable LED that’s on the cape?
>> 
>> Any other ideas what would cause this?
> 
> Do you have a part number for the Prototype Cape used?
> 
> Sorry it doesn't ring a bell for me..
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.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/C2E1825D-6A93-4F66-B2E9-D08B2CE5FD1D%40gmail.com.

Re: [beagleboard] PWM on P8_13

[Steve Lentz]

I’ve investigated a bit more.  First, and I should have done this sooner, I 
removed all the capes I’m using and tested the bare Beaglebone black.  Success, 
all four PWMs work.

Then I began adding capes one at a time.  I found that when a Prototype Cape is 
used, PWM is no longer available on P8_13.  To be absolutely certain, I 
connected a brand new out of the box GHI Prototype Cape.  No PWM on P8_13.  
Remove the cape and PWM works.  

If I connect a Power Cape, PWM works, this would seem to rule out a bad solder 
joint or something physical on the BBB.

There is nothing near P8_13 on any of these capes, yet something is affecting 
that pin.  

Is there something in the device tree that allows the cape to grab one of the 
PWM devices, perhaps for the variable LED that’s on the cape?

Any other ideas what would cause this?

Thanks,
-Steve



> On Jan 15, 2021, at 10:54 AM, Steve Lentz  wrote:
> 
> Robert:
> 
> Thanks.  
> 
> Still returns an error
> 
> debian@beaglebone:/sys/class/pwm/pwm-7:1$ sudo sh -c "echo '40' >> 
> ./period"
> [sudo] password for debian:
> sh: 1: echo: echo: I/O error
> debian@beaglebone:/sys/class/pwm/pwm-7:1$ cat period
> 50
> 
> I can live with 2000 Hz, I’m just curious as to why this seems to be the only 
> allowed value for PWM frequency.  Is this intentional or is something missing 
> from the PWM driver?
> 
> Adafruit’s library does some odd things, for example the following results in 
> a 2000 Hz signal with 80% duty cycle:
> 
> >>> import Adafruit_BBIO.PWM as PWM
> >>> pin3 = "P8_19"
> >>> PWM.start(pin3, 25)
> >>> PWM.set_frequency(pin3,1000)
> Traceback (most recent call last):
>   File "", line 1, in 
> RuntimeError: Could not write to the frequency file
> >>> PWM.set_duty_cycle(pin3,40)
> 
> The error makes it clear 2000 Hz was not accepted, but Python carries on 
> thinking base frequency is now 1000 Hz and sets the duration of signal high 
> accordingly.
> 
> At least people should be aware of this if they try to use it.  
> 
> -Steve
> 
> 
>> On Jan 15, 2021, at 10:34 AM, Robert Nelson > <mailto:robertcnel...@gmail.com>> wrote:
>> 
>> On Fri, Jan 15, 2021 at 9:25 AM Steve Lentz > <mailto:stle...@gmail.com>> wrote:
>>> 
>>> OK, 3 of 4 PWM pins are working, but still no luck with P8_13.
>>> 
>>> I can see that Adafruit_BBIO is writing values into 
>>> /sys/class/pwm/pwm-7:1/duty_cycle but no output is being generated.
>>> 
>>> debian@beaglebone:/sys/class/pwm/pwm-7:1$ cat duty_cycle
>>> 20
>>> debian@beaglebone:/sys/class/pwm/pwm-7:1$ cat period
>>> 50
>>> 
>>> Pin 8_13 can still be used for GPIO.  I have not dug further into the 
>>> device files. Does this seem like a hardware or software issue?  Should I 
>>> reinstall the base image, accept that the board is flaky, or is there some 
>>> other possible solution?
>>> 
>>> Also, the PWM frequency is fixed at 2000 Hz (period = 50 ns).  Is this 
>>> intended?  I can work with 2000, so this is more out of curiosity.
>>> 
>>> Python returns the following errors:
>>> 
>>>>>> PWM.start(pin3,50,1000)
>>> Traceback (most recent call last):
>>>  File "", line 1, in 
>>> RuntimeError: Problem with a sysfs file
>>> 
>>>>>> PWM.set_frequency(pin3,1000)
>>> Traceback (most recent call last):
>>>  File "", line 1, in 
>>> RuntimeError: Could not write to the frequency file
>>> 
>>> Attempting to write into the period file directly returns the following:
>>> 
>>> debian@beaglebone:/sys/class/pwm/pwm-7:1$ sudo echo 40 > period
>>> [sudo] password for debian:
>>> echo: write error: Invalid argument
>> 
>> That's invalid, "sudo echo."
>> 
>> sudo sh -c "echo '40' >> ./period"
>> 
>> Besides, pwm should be "root:gpio" permissoins..
>> 
>> Regards,
>> 
>> 
>> --
>> Robert Nelson
>> https://rcn-ee.com/ <https://rcn-ee.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/58A77F3B-CD0F-42CD-80D4-CDFE3149263B%40gmail.com.

Re: [beagleboard] PWM

[Steve Lentz]

OK, 3 of 4 PWM pins are working, but still no luck with P8_13.  

I can see that Adafruit_BBIO is writing values into 
/sys/class/pwm/pwm-7:1/duty_cycle but no output is being generated.  

debian@beaglebone:/sys/class/pwm/pwm-7:1$ cat duty_cycle
20
debian@beaglebone:/sys/class/pwm/pwm-7:1$ cat period
50

Pin 8_13 can still be used for GPIO.  I have not dug further into the device 
files. Does this seem like a hardware or software issue?  Should I reinstall 
the base image, accept that the board is flaky, or is there some other possible 
solution?

Also, the PWM frequency is fixed at 2000 Hz (period = 50 ns).  Is this 
intended?  I can work with 2000, so this is more out of curiosity.  

Python returns the following errors:

>>> PWM.start(pin3,50,1000)
Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: Problem with a sysfs file

>>> PWM.set_frequency(pin3,1000)
Traceback (most recent call last):
  File "", line 1, in 
RuntimeError: Could not write to the frequency file

Attempting to write into the period file directly returns the following:

debian@beaglebone:/sys/class/pwm/pwm-7:1$ sudo echo 40 > period
[sudo] password for debian:
echo: write error: Invalid argument

The arguments 2000 (from Python) and 50 (echo) are accepted without no 
error.  Any other values are not accepted.



Thanks again,
-Steve


> On Jan 15, 2021, at 9:33 AM, randy cooper  wrote:
> 
> P8_13 is working for me as a PWM output, and I am using the Adafruit BBIO 
> library.   I’m using the latest image with LXQT (Debian 9.9 I believe).
> Randy
> 
> On Thursday, January 14, 2021 at 8:28:34 PM UTC-6 stl...@gmail.com wrote:
> OK, I rechecked and only Pin 8_13 is not working; the other three PWM pins 
> are good using Adafruit.PWM.  Pin 8_13 does respond to GPIO.HIGH and 
> GPIO.LOW, so I don’t think I’ve damaged the hardware.  Who knows what I have 
> managed to do to the /sys/class files.  If it doesn’t clear up on restart, I 
> will reinstall the image.  Of course 8_13 is the one I was planning to use, 
> but I can just as well wire something to 8_19 for now.
> 
> Thanks for the help.
> 
> -Steve
>   
> 
>> On Jan 14, 2021, at 8:00 PM, jonnymo  wrote:
>> 
>> The SpreadSheet at the following link will show you which pins on the BB 
>> Black can be set for PWM.
>> 
>> https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit#gid=1518010293
>> 
>> As far as the Adafruit BBIO libs, have you gone through the example at the 
>> Adafruit site?
>> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/pwm
>> 
>> If this is not working, could you provide any errors or output of the issue 
>> you are seeing?
>> 
>> The output of the following might be helpful:
>>/opt/scripts/tools/version.sh  
>> 
>> Cheers,
>> 
>> Jon
>>  
>> 
>> On Thu, Jan 14, 2021 at 4:42 PM Steve Lentz  wrote:
>> Black.  BeagleBoard.org Debian Buster IoT Image 2020-04-06.
>> 
>> FWIW, the Adafruit libraries let me control the pins as GPIO.
>> 
>> 
>> TY,
>> -Steve
>> 
>>> On Jan 14, 2021, at 7:02 PM, jonnymo  wrote:
>>> 
>>> Which BeagleBoard are you using?
>>> 
>>> Jon
>>> 
>>> On Thu, Jan 14, 2021 at 2:51 PM stl...@gmail.com  wrote:
>>> OK, I want to generate a PWM signal to send to a motor controller.  This is 
>>> simply to communicate the desired speed, the motor controller will do all 
>>> the heavy lifting.  
>>> 
>>> Unfortunately, the Adafruit_BBIO libraries appear broken and bonescript 
>>> doesn't seem any better.
>>> 
>>> After digging through Google results I found myself in /sys/class/pwm/ 
>>> using echo to write values into various files and through pure dumb luck 
>>> was able to get a 2 Khz square wave up on a scope and change its duty 
>>> cycle.  So at least my set up seems to be working at some level.  
>>> 
>>> However, I feel I am missing a bunch of information. Which pwmchip exports 
>>> to which pwm-X:X and corresponds to which pin?  "duty_cycle" is not really 
>>> duty cycle, it is nanoseconds high.  I can't change the period, even to 
>>> sensible values like 25 or 100.  Some of the information on Stack 
>>> Exchange is worrying, will pwm-4:0 always correspond to P9_14 or can this 
>>> change on boot?   
>>> 
>>> Is there a way to restore the functionality of the Adafruit BBIO libraries, 
>>> short of waiting for an update?  I did pip3 install -U.  Requirement 
>>> already satisfied: A

Re: [beagleboard] PWM

[Steve Lentz]

Thanks for that, I’ll look at it again today.  I may have mucked something up 
while digging into the /sys/class/pwm file structure or forgotten to do 
GPIO.cleanup() or some other combination of things.

-Steve

> On Jan 15, 2021, at 9:33 AM, randy cooper  wrote:
> 
> P8_13 is working for me as a PWM output, and I am using the Adafruit BBIO 
> library.   I’m using the latest image with LXQT (Debian 9.9 I believe).
> Randy
> 
> On Thursday, January 14, 2021 at 8:28:34 PM UTC-6 stl...@gmail.com wrote:
> OK, I rechecked and only Pin 8_13 is not working; the other three PWM pins 
> are good using Adafruit.PWM.  Pin 8_13 does respond to GPIO.HIGH and 
> GPIO.LOW, so I don’t think I’ve damaged the hardware.  Who knows what I have 
> managed to do to the /sys/class files.  If it doesn’t clear up on restart, I 
> will reinstall the image.  Of course 8_13 is the one I was planning to use, 
> but I can just as well wire something to 8_19 for now.
> 
> Thanks for the help.
> 
> -Steve
>   
> 
> 
>> On Jan 14, 2021, at 8:00 PM, jonnymo > > wrote:
>> 
> 
>> The SpreadSheet at the following link will show you which pins on the BB 
>> Black can be set for PWM.
>> 
>> https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit#gid=1518010293
>>  
>> <https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit#gid=1518010293>
>> 
>> As far as the Adafruit BBIO libs, have you gone through the example at the 
>> Adafruit site?
>> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/pwm
>>  
>> <https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/pwm>
>> 
>> If this is not working, could you provide any errors or output of the issue 
>> you are seeing?
>> 
>> The output of the following might be helpful:
>>/opt/scripts/tools/version.sh  
>> 
>> Cheers,
>> 
>> Jon
>>  
>> 
>> On Thu, Jan 14, 2021 at 4:42 PM Steve Lentz > > wrote:
>> Black.  BeagleBoard.org <http://beagleboard.org/> Debian Buster IoT Image 
>> 2020-04-06.
>> 
>> FWIW, the Adafruit libraries let me control the pins as GPIO.
>> 
>> 
>> TY,
>> -Steve
>> 
>>> On Jan 14, 2021, at 7:02 PM, jonnymo >> > wrote:
>>> 
>>> Which BeagleBoard are you using?
>>> 
>>> Jon
>>> 
>>> On Thu, Jan 14, 2021 at 2:51 PM stl...@gmail.com 
>>>  >> > wrote:
>>> OK, I want to generate a PWM signal to send to a motor controller.  This is 
>>> simply to communicate the desired speed, the motor controller will do all 
>>> the heavy lifting.  
>>> 
>>> Unfortunately, the Adafruit_BBIO libraries appear broken and bonescript 
>>> doesn't seem any better.
>>> 
>>> After digging through Google results I found myself in /sys/class/pwm/ 
>>> using echo to write values into various files and through pure dumb luck 
>>> was able to get a 2 Khz square wave up on a scope and change its duty 
>>> cycle.  So at least my set up seems to be working at some level.  
>>> 
>>> However, I feel I am missing a bunch of information. Which pwmchip exports 
>>> to which pwm-X:X and corresponds to which pin?  "duty_cycle" is not really 
>>> duty cycle, it is nanoseconds high.  I can't change the period, even to 
>>> sensible values like 25 or 100.  Some of the information on Stack 
>>> Exchange is worrying, will pwm-4:0 always correspond to P9_14 or can this 
>>> change on boot?   
>>> 
>>> Is there a way to restore the functionality of the Adafruit BBIO libraries, 
>>> short of waiting for an update?  I did pip3 install -U.  Requirement 
>>> already satisfied: Adafruit_BBIO in /usr/local/lib/python3.7/dist-packages 
>>> (1.2.0)
>>> 
>>> If that's not possible, is there any documentation on how the 
>>> /sys/class/pwm is intended to function?
>>> 
>>> Thank you,
>>> -Steve Lentz
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss 
>>> <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...@googlegroups.com 
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.co

Re: [beagleboard] PWM

[Steve Lentz]

OK, I rechecked and only Pin 8_13 is not working; the other three PWM pins are 
good using Adafruit.PWM.  Pin 8_13 does respond to GPIO.HIGH and GPIO.LOW, so I 
don’t think I’ve damaged the hardware.  Who knows what I have managed to do to 
the /sys/class files.  If it doesn’t clear up on restart, I will reinstall the 
image.  Of course 8_13 is the one I was planning to use, but I can just as well 
wire something to 8_19 for now.

Thanks for the help.

-Steve
  

> On Jan 14, 2021, at 8:00 PM, jonnymo  wrote:
> 
> The SpreadSheet at the following link will show you which pins on the BB 
> Black can be set for PWM.
> 
> https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit#gid=1518010293
>  
> <https://docs.google.com/spreadsheets/d/1fE-AsDZvJ-bBwzNBj1_sPDrutvEvsmARqFwvbw_HkrE/edit#gid=1518010293>
> 
> As far as the Adafruit BBIO libs, have you gone through the example at the 
> Adafruit site?
> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/pwm
>  
> <https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/pwm>
> 
> If this is not working, could you provide any errors or output of the issue 
> you are seeing?
> 
> The output of the following might be helpful:
>/opt/scripts/tools/version.sh  
> 
> Cheers,
> 
> Jon
>  
> 
> On Thu, Jan 14, 2021 at 4:42 PM Steve Lentz  <mailto:stle...@gmail.com>> wrote:
> Black.  BeagleBoard.org <http://beagleboard.org/> Debian Buster IoT Image 
> 2020-04-06.
> 
> FWIW, the Adafruit libraries let me control the pins as GPIO.
> 
> 
> TY,
> -Steve
> 
>> On Jan 14, 2021, at 7:02 PM, jonnymo > <mailto:jonnym...@gmail.com>> wrote:
>> 
>> Which BeagleBoard are you using?
>> 
>> Jon
>> 
>> On Thu, Jan 14, 2021 at 2:51 PM stl...@gmail.com <mailto:stl...@gmail.com> 
>> mailto:stle...@gmail.com>> wrote:
>> OK, I want to generate a PWM signal to send to a motor controller.  This is 
>> simply to communicate the desired speed, the motor controller will do all 
>> the heavy lifting.  
>> 
>> Unfortunately, the Adafruit_BBIO libraries appear broken and bonescript 
>> doesn't seem any better.
>> 
>> After digging through Google results I found myself in /sys/class/pwm/ using 
>> echo to write values into various files and through pure dumb luck was able 
>> to get a 2 Khz square wave up on a scope and change its duty cycle.  So at 
>> least my set up seems to be working at some level.  
>> 
>> However, I feel I am missing a bunch of information. Which pwmchip exports 
>> to which pwm-X:X and corresponds to which pin?  "duty_cycle" is not really 
>> duty cycle, it is nanoseconds high.  I can't change the period, even to 
>> sensible values like 25 or 100.  Some of the information on Stack 
>> Exchange is worrying, will pwm-4:0 always correspond to P9_14 or can this 
>> change on boot?   
>> 
>> Is there a way to restore the functionality of the Adafruit BBIO libraries, 
>> short of waiting for an update?  I did pip3 install -U.  Requirement already 
>> satisfied: Adafruit_BBIO in /usr/local/lib/python3.7/dist-packages (1.2.0)
>> 
>> If that's not possible, is there any documentation on how the /sys/class/pwm 
>> is intended to function?
>> 
>> Thank you,
>> -Steve Lentz
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/08130fba-0f75-464a-9041-d66a1c3a8cacn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/08130fba-0f75-464a-9041-d66a1c3a8cacn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> 
>> -- 
>> For more options, visit http://beagleboard.org/discuss 
>> <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 
>> <mailto:beagleboard+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>

Re: [beagleboard] PWM

[Steve Lentz]

Black.  BeagleBoard.org Debian Buster IoT Image 2020-04-06.

FWIW, the Adafruit libraries let me control the pins as GPIO.


TY,
-Steve

> On Jan 14, 2021, at 7:02 PM, jonnymo  wrote:
> 
> Which BeagleBoard are you using?
> 
> Jon
> 
> On Thu, Jan 14, 2021 at 2:51 PM stl...@gmail.com <mailto:stl...@gmail.com> 
> mailto:stle...@gmail.com>> wrote:
> OK, I want to generate a PWM signal to send to a motor controller.  This is 
> simply to communicate the desired speed, the motor controller will do all the 
> heavy lifting.  
> 
> Unfortunately, the Adafruit_BBIO libraries appear broken and bonescript 
> doesn't seem any better.
> 
> After digging through Google results I found myself in /sys/class/pwm/ using 
> echo to write values into various files and through pure dumb luck was able 
> to get a 2 Khz square wave up on a scope and change its duty cycle.  So at 
> least my set up seems to be working at some level.  
> 
> However, I feel I am missing a bunch of information. Which pwmchip exports to 
> which pwm-X:X and corresponds to which pin?  "duty_cycle" is not really duty 
> cycle, it is nanoseconds high.  I can't change the period, even to sensible 
> values like 25 or 100.  Some of the information on Stack Exchange is 
> worrying, will pwm-4:0 always correspond to P9_14 or can this change on boot? 
>   
> 
> Is there a way to restore the functionality of the Adafruit BBIO libraries, 
> short of waiting for an update?  I did pip3 install -U.  Requirement already 
> satisfied: Adafruit_BBIO in /usr/local/lib/python3.7/dist-packages (1.2.0)
> 
> If that's not possible, is there any documentation on how the /sys/class/pwm 
> is intended to function?
> 
> Thank you,
> -Steve Lentz
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/08130fba-0f75-464a-9041-d66a1c3a8cacn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/08130fba-0f75-464a-9041-d66a1c3a8cacn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAG99bkoUYXmrUU%2BwtoQnXTYAd3Uq6SAXsTFskbZ-75%2ByvAX3eQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/beagleboard/CAG99bkoUYXmrUU%2BwtoQnXTYAd3Uq6SAXsTFskbZ-75%2ByvAX3eQ%40mail.gmail.com?utm_medium=email&utm_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/44AF4518-7FEA-4331-9E61-5D442D484D20%40gmail.com.

Re: [beagleboard] Where to get help with Adafruit Circuit Python on BBB

[Steve Lentz]

Grrr, I installed it by copying files from their circuit python bundle, those 
instructions must be out of date.  I see they’ve made a proper package now, 
I’ll give it a try.

> On Dec 10, 2020, at 4:04 PM, jonnymo  wrote:
> 
> Do you have 'adafruit_bus_device' installed?
> 
> Ref:
> https://circuitpython.readthedocs.io/projects/busdevice/en/latest/api.html 
> <https://circuitpython.readthedocs.io/projects/busdevice/en/latest/api.html>
> https://circuitpython.readthedocs.io/projects/busdevice/en/latest/index.html#bus-device-installation
>  
> <https://circuitpython.readthedocs.io/projects/busdevice/en/latest/index.html#bus-device-installation>
> 
> Cheers,
> 
> Jon
> 
> 
> 
> 
> 
> On Thu, Dec 10, 2020 at 12:38 PM Steve Lentz  <mailto:stle...@gmail.com>> wrote:
> This is probably not for this forum, but perhaps you can give me some 
> direction.  
> 
> I have a BME680 and BNO055 connected to my BBB via i2c.  I2cdetect and 
> i2cdump work as expected, so I think I’m good with wiring and low level 
> stuff.  
> 
> I want to access these sensors from a Python program.  I have carefully 
> followed all of Adafruit’s instructions regarding installation of libraries, 
> copying of files, etc.
> 
> From the command line, I can communicate with the sensors as follows:
> 
> debian@beaglebone:/var/lib/cloud9$ python3
> Python 3.7.3 (default, Jul 25 2020, 13:03:44)
> [GCC 8.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import board
> >>> import busio
> >>> import adafruit_bno055
> >>> i2c = busio.I2C(board.SCL,board.SDA)
> >>> mybno055=adafruit_bno055.BNO055_I2C(i2c)
> >>> mybno055.gravity
> (-0.11, 0.52, -0.01)
> >>>
> 
> When I create the following program and try to run it, I get an error message.
> 
> #!/usr/bin/python3
> #//
> #
> # BMO055 Test
> # 
> #//
> 
> import time
> import board
> import busio
> import adafruit_bno055
> i2c = busio.I2C(board.SCL,board.SDA)
> mybno055=adafruit_bno055.BNO055_I2C(i2c)
> 
> while True:
> mybno055.gravity
> time.sleep(1.5)
> 
> Here is the error:
> 
> Traceback (most recent call last):
>   File "/var/lib/cloud9/PocketBeagle/bno055.py", line 11, in 
> import adafruit_bno055
>   File "/home/debian/.local/lib/python3.7/site-packages/adafruit_bno055.py", 
> line 37, in 
> from adafruit_bus_device.i2c_device import I2CDevice
> ModuleNotFoundError: No module named 'adafruit_bus_device.i2c_device'
> 
> Process exited with code: 1
> 
> I have checked that all the files appear to be in the cache at 
> /home/debian/.local/.  Python version is set to Python3.  The Python path in 
> Cloud9 points to /usr/local/lib/python3.7/dist-packages.  The included Python 
> examples (blinkLED.py) do work.  
> 
> Clearly everything that should be needed is installed, because it works from 
> the command line.  Why does this Python program fail?
> 
> Any advice appreciated.  
> 
> Thanks,
> -Steve
> 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/F6DC30FF-B89E-405E-84C0-1548AC86FEA2%40gmail.com
>  
> <https://groups.google.com/d/msgid/beagleboard/F6DC30FF-B89E-405E-84C0-1548AC86FEA2%40gmail.com?utm_medium=email&utm_source=footer>.
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> <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 
> <mailto:beagleboard+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAG99bkoqBD6T8ZVcK9JEPeJH4WqV%2B262GL8SqiPpgESSP5PDqw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/beagleboard/CAG99bkoqBD6T8ZVcK9JEPeJH4WqV%2B262GL8SqiPpgESSP5PDqw%40mail.gmail.com?utm_medium=email&utm_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/3B4B0831-DCEF-4846-A32C-E7FD8C803FFC%40gmail.com.

[beagleboard] Where to get help with Adafruit Circuit Python on BBB

[Steve Lentz]

This is probably not for this forum, but perhaps you can give me some 
direction.  

I have a BME680 and BNO055 connected to my BBB via i2c.  I2cdetect and i2cdump 
work as expected, so I think I’m good with wiring and low level stuff.  

I want to access these sensors from a Python program.  I have carefully 
followed all of Adafruit’s instructions regarding installation of libraries, 
copying of files, etc.

>From the command line, I can communicate with the sensors as follows:

debian@beaglebone:/var/lib/cloud9$ python3
Python 3.7.3 (default, Jul 25 2020, 13:03:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import board
>>> import busio
>>> import adafruit_bno055
>>> i2c = busio.I2C(board.SCL,board.SDA)
>>> mybno055=adafruit_bno055.BNO055_I2C(i2c)
>>> mybno055.gravity
(-0.11, 0.52, -0.01)
>>>

When I create the following program and try to run it, I get an error message.

#!/usr/bin/python3
#//
#
#   BMO055 Test
#   
#//

import time
import board
import busio
import adafruit_bno055
i2c = busio.I2C(board.SCL,board.SDA)
mybno055=adafruit_bno055.BNO055_I2C(i2c)

while True:
mybno055.gravity
time.sleep(1.5)

Here is the error:

Traceback (most recent call last):
  File "/var/lib/cloud9/PocketBeagle/bno055.py", line 11, in 
import adafruit_bno055
  File "/home/debian/.local/lib/python3.7/site-packages/adafruit_bno055.py", 
line 37, in 
from adafruit_bus_device.i2c_device import I2CDevice
ModuleNotFoundError: No module named 'adafruit_bus_device.i2c_device'

Process exited with code: 1

I have checked that all the files appear to be in the cache at 
/home/debian/.local/.  Python version is set to Python3.  The Python path in 
Cloud9 points to /usr/local/lib/python3.7/dist-packages.  The included Python 
examples (blinkLED.py) do work.  

Clearly everything that should be needed is installed, because it works from 
the command line.  Why does this Python program fail?

Any advice appreciated.  

Thanks,
-Steve


-- 
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/F6DC30FF-B89E-405E-84C0-1548AC86FEA2%40gmail.com.

Re: [beagleboard] BBAI RTC

[Steve Lentz]

As I understand it, there is a hardware clock, but it is not backed up by 
battery.  If the BBB always has access to a network, that’s not a big deal, it 
can grab time from NTP and reset the clock.  

I’m planning to use the BBB in an underwater housing and power it off for days 
at a time to save battery, so I needed another solution for keeping time.  The 
DS3231 suits this purpose well.

After trying for a while with sleep modes, alarms, FETS, relays etc, I’ve 
decided I need a separate MCU to act as the timer to wake everything up when 
the BBB is powered down.  I just received some new parts from Adafruit, we’ll 
see how that goes.  

-Steve


> On Sep 11, 2020, at 8:51 AM, Chinmay Pendharkar  wrote:
> 
> Thanks Steve!
> 
> I have used external RTCs with BBB before. I was wondering if anything 
> changed with the new Beaglebone AI. I can see some mention in the AM5729 
> datasheet, but not much on the BBAI System Reference documentation 
> https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual 
> 
> 
> -Chinmay
> 
> On Friday, September 11, 2020 at 8:14:24 PM UTC+8 stl...@gmail.com 
>  wrote:
> I just spent the last few weeks looking at the BBB RTC.
> 
> If you want a battery backed RTC, you will need to add one.  The Maxim DS3231 
> is one example.  Adafruit makes several breakout boards and modules so you 
> can pick your flavor of how you want to connect it.  The clock will be 
> connected to the I2C - 2 bus.
> 
> Then add this line to /boot/uEnv.txt:
> 
> dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo
> 
> 
> Restart, and that’s it.  Your BBB now has a battery backed RTC.  If it’s on a 
> network and can reach an NTP server, it will set the RTC automagically.
> 
> The BBB still does not have a good low power sleep mode.  The RTC will not 
> fix that, but it’s not the fault of the RTC, which otherwise works quite 
> nicely with the Linux drivers.
> 
> -Steve
> 
> 
> 
> 
>> On Sep 10, 2020, at 10:37 PM, Chinmay Pendharkar > > wrote:
>> 
> 
>> Hello,
>> 
>> Does the BeagleBone AI have an onboard RTC? If so is there any documentation 
>> about it and how it can work? If there is a mechanism to add 
>> battery/supercap to keep time.
>> 
>> -Chinmay
>> 
> 
>> -- 
>> 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...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/0cae3f1d-2f95-4128-8a81-440c770c05ben%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/670727d8-acff-4b25-9ee5-231c5f8e05ecn%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/71962CA2-88B9-4CB0-A88F-F4B866F3AD23%40gmail.com.

Re: [beagleboard] BBAI RTC

[Steve Lentz]

I just spent the last few weeks looking at the BBB RTC.

If you want a battery backed RTC, you will need to add one.  The Maxim DS3231 
is one example.  Adafruit makes several breakout boards and modules so you can 
pick your flavor of how you want to connect it.  The clock will be connected to 
the I2C - 2 bus.

Then add this line to /boot/uEnv.txt:

dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo


Restart, and that’s it.  Your BBB now has a battery backed RTC.  If it’s on a 
network and can reach an NTP server, it will set the RTC automagically.

The BBB still does not have a good low power sleep mode.  The RTC will not fix 
that, but it’s not the fault of the RTC, which otherwise works quite nicely 
with the Linux drivers.

-Steve



> On Sep 10, 2020, at 10:37 PM, Chinmay Pendharkar  wrote:
> 
> Hello,
> 
> Does the BeagleBone AI have an onboard RTC? If so is there any documentation 
> about it and how it can work? If there is a mechanism to add battery/supercap 
> to keep time.
> 
> -Chinmay
> 
> -- 
> 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/0cae3f1d-2f95-4128-8a81-440c770c05ben%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/D7148BB2-27F7-4134-ADD4-C07979641561%40gmail.com.

Re: [beagleboard] How to automatically set system time of BBB by external DS3231

[Steve Lentz]

That’s not quite what I am asking.  I want to set the alarm in the DS3231, shut 
down the BBB, completely, then have the Alarm / INT pin on the DS3231 initiate 
a series of events that eventually powers on the BBB.  Doing this, I can 
achieve a true zero power sleep state.  Nothing will draw power except the coin 
cell on the DS3231.  

I can set the alarm in the DS3231 using python libraries, is it possible to set 
that alarm using the device drivers?  I have a bunch of relay and delay 
circuits that area all working, this is the last link in the chain.  I will use 
the python if necessary but would prefer to use the kernel drivers.  

I need the BBB to power up for a couple hours every two weeks and last for a 
year on a stack of D cells; the normal sleep state draws too much power, I want 
to shut it off.  

The reddit page I linked describes the exact same problem and solution for 
RaspPi.  Is there a similar solution for BBB?

Thx,
Steve


https://www.reddit.com/r/raspberry_pi/comments/bn2ht5/ds3231_rtc_using_the_alarm_function/
 



> On Sep 4, 2020, at 5:40 PM, Robert Nelson  wrote:
> 
> On Fri, Sep 4, 2020 at 3:13 PM robert.sty...@gmail.com
>  wrote:
>> 
>> I do not know the AM3358 of the BBB, but from the schematic
>> P9.42 GPIO0_7 is XDMA_EVENT_INTR2
> 
> Really any GPIO_0 can be used for "wake-up" from "suspend"..
> 
> https://e2e.ti.com/support/processors/f/791/t/243392?How-to-wake-up-the-BeagleBone
> 
> https://processors.wiki.ti.com/index.php/AM335x_Power_Management_Standby_User%27s_Guide#GPIO_wakeup
> 
> It's not trivial..
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.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/CAOCHtYjBba%2Byja4ZMqXU4u68YLvxFvveycJM5CM%2BQSmkZJmsxA%40mail.gmail.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/F24ABF59-2BDF-4106-AD35-23E5C2077BDE%40gmail.com.

Re: [beagleboard] How to automatically set system time of BBB by external DS3231

[Steve Lentz]

Robert:

Is there a way to make the external DS3231 the wakeup device?  Just like in 
this RaspPi thread, I want to set the alarm and use the INT pin on the clock 
chip to activate something.  

https://www.reddit.com/r/raspberry_pi/comments/bn2ht5/ds3231_rtc_using_the_alarm_function/
 
<https://www.reddit.com/r/raspberry_pi/comments/bn2ht5/ds3231_rtc_using_the_alarm_function/>

The RaspPi dtoverlay command seems to use a different format and I’m at a loss 
how to translate this.

I’ve already made the INT pin work using Adafruit's python libraries for the 
DS3231, but I’d like to use the linux tools if possible - then I can also use 
the clock to set the system time.  Of course if the device tree is using the 
clock, the python libraries can’t get to it.  

Thanks again,



> On Sep 4, 2020, at 11:38 AM, Robert Nelson  wrote:
> 
> On Fri, Sep 4, 2020 at 10:28 AM Steve Lentz  wrote:
>> 
>> Robert:
>> 
>> Here you go; thanks for looking into this.
>> 
>> -Steve
>> 
>> 
>> debian@beaglebone:/dev$ sudo /opt/scripts/tools/version.sh
>> [sudo] password for debian:
>> git:/opt/scripts/:[7cdc270818b76d829d247cf05fe309c320a3929a]
>> eeprom:[A335BNLTEIA04218BBBK03D9]
>> model:[TI_AM335x_BeagleBone_Black]
>> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>> 2019.04-2-g07d5700e21]:[location: dd MBR]
>> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
>> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
>> UBOOT: Loaded Overlay:[BB-ADC-00A0]
>> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
>> UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
>> UBOOT: Loaded Overlay:[BBORG_PROTO-00A2]
>> kernel:[4.19.94-ti-r47]
>> nodejs:[v10.21.0]
>> /boot/uEnv.txt Settings:
>> uboot_overlay_options:[enable_uboot_overlays=1]
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>> uboot_overlay_options:[dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
> 
> This is the second time i've seen this.. is there a wiki somewhere
> showing the spaces??? We need to NUKE that asap..
> 
> dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.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/EDB15E56-5C7D-482F-AF1A-414FC7C443EA%40gmail.com.

Re: [beagleboard] How to automatically set system time of BBB by external DS3231

[Steve Lentz]

Good now.  It’s what comes from retyping commands from mailing lists while 
being spoiled by a lifetime of parsers that ignore whitespace.  I do not know 
the original source.  

Thanks,
-Steve


> On Sep 4, 2020, at 11:38 AM, Robert Nelson  wrote:
> 
> On Fri, Sep 4, 2020 at 10:28 AM Steve Lentz  wrote:
>> 
>> Robert:
>> 
>> Here you go; thanks for looking into this.
>> 
>> -Steve
>> 
>> 
>> debian@beaglebone:/dev$ sudo /opt/scripts/tools/version.sh
>> [sudo] password for debian:
>> git:/opt/scripts/:[7cdc270818b76d829d247cf05fe309c320a3929a]
>> eeprom:[A335BNLTEIA04218BBBK03D9]
>> model:[TI_AM335x_BeagleBone_Black]
>> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>> 2019.04-2-g07d5700e21]:[location: dd MBR]
>> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
>> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
>> UBOOT: Loaded Overlay:[BB-ADC-00A0]
>> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
>> UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
>> UBOOT: Loaded Overlay:[BBORG_PROTO-00A2]
>> kernel:[4.19.94-ti-r47]
>> nodejs:[v10.21.0]
>> /boot/uEnv.txt Settings:
>> uboot_overlay_options:[enable_uboot_overlays=1]
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>> uboot_overlay_options:[dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
> 
> This is the second time i've seen this.. is there a wiki somewhere
> showing the spaces??? We need to NUKE that asap..
> 
> dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.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/A02B3375-B3D4-47AE-944D-5D6C13D223FD%40gmail.com.

Re: [beagleboard] How to automatically set system time of BBB by external DS3231

[Steve Lentz]

Robert:

Here you go; thanks for looking into this.

-Steve


debian@beaglebone:/dev$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[7cdc270818b76d829d247cf05fe309c320a3929a]
eeprom:[A335BNLTEIA04218BBBK03D9]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
UBOOT: Loaded Overlay:[BBORG_PROTO-00A2]
kernel:[4.19.94-ti-r47]
nodejs:[v10.21.0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay = /lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.14.20200814.0-0~buster+20200814]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev 
users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi 
iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait 
uboot_detected_capes=BBORG_PROTO, coherent_pool=1M net.ifnames=0 lpj=1990656 
rng_core.default_quality=100 quiet]
dmesg | grep remote
[   58.172688] remoteproc remoteproc0: wkup_m3 is available
[   58.383916] remoteproc remoteproc0: powering up wkup_m3
[   58.383945] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, 
size 217168
[   58.384202] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   62.993005] remoteproc remoteproc1: 4a334000.pru is available
[   63.024061] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[   62.993005] remoteproc remoteproc1: 4a334000.pru is available
[   62.993220] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
successfully
[   63.024061] remoteproc remoteproc2: 4a338000.pru is available
[   63.024270] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
successfully
dmesg | grep pinctrl-single
[0.952687] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[0.966071] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

> On Sep 4, 2020, at 11:22 AM, Robert Nelson  wrote:
> 
> On Fri, Sep 4, 2020 at 9:59 AM Steve Lentz  wrote:
>> 
>> Tarmo:
>> 
>> I’ve been following this with some interest and finally got around to trying 
>> it on my BBB running the 2020-04-06 release.
>> 
>> I have an external DS3231 connected to I2C2. I’ve got it working and mounted 
>> as RTC1, but the magic of swapping the DS3231 for the AM335x-s is not 
>> happening for me.
>> 
>> I have confirmed the DS3231 is RTC1 by the simple method of asking for the 
>> time with the I2C jumpers disconnected, which results in an error.  
>> Reconnecting the jumpers restores operation of RTC1.  RTC0 works whether the 
>> jumpers are connected or not.
>> 
>> I added the dtb_overlay command to /boot/uEnv.txt and restarted.  I don’t 
>> have an rc.local file, so I ran echo ds3231 0x68 > 
>> /sys/class/i2c-adapter/i2c-2/new_device from the command line after 
>> rebooting.
>> 
>> What is needed so that the device tree swaps the two clocks, making the 
>> external DS3231 RTC0, as indicated in the thread below?  Is this something 
>> in the alpha image?
> 
> Let's check some things, please provide a dump of:
> 
> sudo /opt/scripts/tools/version.sh
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.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/DB5C489D-88D6-4F1E-971E-23447AFFE0C4%40gmail.com.

Re: [beagleboard] How to automatically set system time of BBB by external DS3231

[Steve Lentz]

Tarmo:

I’ve been following this with some interest and finally got around to trying it 
on my BBB running the 2020-04-06 release.  

I have an external DS3231 connected to I2C2. I’ve got it working and mounted as 
RTC1, but the magic of swapping the DS3231 for the AM335x-s is not happening 
for me.

I have confirmed the DS3231 is RTC1 by the simple method of asking for the time 
with the I2C jumpers disconnected, which results in an error.  Reconnecting the 
jumpers restores operation of RTC1.  RTC0 works whether the jumpers are 
connected or not.  

I added the dtb_overlay command to /boot/uEnv.txt and restarted.  I don’t have 
an rc.local file, so I ran echo ds3231 0x68 > 
/sys/class/i2c-adapter/i2c-2/new_device from the command line after rebooting.  

What is needed so that the device tree swaps the two clocks, making the 
external DS3231 RTC0, as indicated in the thread below?  Is this something in 
the alpha image?

Thx,
-Steve


> On Sep 1, 2020, at 4:16 AM, Tarmo Kuuse  wrote:
> 
> Hi Niresh,
> 
> On 01.09.20 07:43, Niresh wrote:
>> I've tested BB-I2C2-RTC-DS3231.dtbo in the new image 4.19.94-ti-r42, they 
>> mount rtc1 in /dev but system time is not updated with rtc1.  Attached dmesg 
>> with and without DS3231 overlay in uEnv.txt .
>> Following message with DS3231 overlay enabled.
>> root@beaglebone:/dev# hwclock -r -f /dev/rtc1
>> 2000-01-01 00:49:21.771707+00:00
> 
> That's OK. The device tree swaps rtc0 and rtc1. Now your DS3231 is /dev/rtc0 
> - which is what you need.
> 
> The AM335x-s RTC is /dev/rtc1 - it goes back to year 2000 on every boot. You 
> don't need it.
> 
>> root@beaglebone:/dev# timedatectl
>> Local time: Tue 2020-09-01 04:34:29 UTC
>> Universal time: Tue 2020-09-01 04:34:29 UTC
>> RTC time: Tue 2020-09-01 04:34:29
>> Time zone: Etc/UTC (UTC, +)
>> System clock synchronized: no
>> NTP service: active
>> RTC in local TZ: no
> 
> Seems to be correct. "RTC time" is your DS3231.
> 
>> debian@beaglebone:/dev$ dmesg | grep rtc
>> [1.280996] rtc-ds1307 2-0068: registered as rtc0
>> [1.283636] omap_rtc 44e3e000.rtc: already running
>> [1.284312] omap_rtc 44e3e000.rtc: registered as rtc1
>> [1.574739] [drm] Cannot find any crtc or sizes
>> [1.604280] rtc-ds1307 2-0068: setting system clock to 2020-09-01 
>> 04:30:36 UTC (1598934636)
> 
> That's your DS3231 being assigned /dev/rtc0 by the kernel and the system time 
> correctly set from it. Looks good.
> 
> The last step is to enable NTP synchronization:
> 
> $ sudo timedatectl set-ntp true
> 
> Then you're done. When network comes online, systemd-timesyncd will 
> synchronize both your DS3231 and the system time from NTP. Feel free to 
> fine-tune ("man timedatectl" and man "timesyncd.conf").
> 
> --
> Kind regards,
> Tarmo
> 
> -- 
> 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/a8f8f997-41a5-8032-4c21-e8cc425b49ae%40gmail.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/53F92013-C18B-417D-B4D2-857583B1E9C6%40gmail.com.

Re: [beagleboard] Can't connect to BBB over Ethernet

[Steve Lentz]

This has nothing to do with the BBB, it’s your Ubuntu machine protecting you 
from something it thinks could be dangerous.  If you switch from one board to 
another, you will get this warning.  If you haven’t connected to a board in a 
long time (years), you may get it as well.  If you garble up SSH the first time 
you connect, it will give you this warning.  

Here’s a helpful link:

https://stackabuse.com/how-to-fix-warning-remote-host-identification-has-changed-on-mac-and-linux/
 




> On Aug 26, 2020, at 9:01 AM, Pavel Yermolenko  wrote:
> 
> WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

-- 
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/90B4768A-DCA4-4E36-9E0E-1BED00ED0407%40gmail.com.

Re: [beagleboard] libgpiod on Beaglebone AI

[Steve Lentz]

Alright then.  Something in the chip is indeed flipping them on the same clock 
edge.

> On Aug 10, 2020, at 11:58 AM, Mark A. Yoder  wrote:
> 
> 
> 
> On my 100MHz 'scope they look the same.  I think it's one instruction 
> toggling the pair.  They are toggling at some 268KHz.
> 
> --Mark
> On Monday, August 10, 2020 at 11:43:49 AM UTC-4 stl...@gmail.com wrote:
> It’s unlikely to be exactly the same time, it’s just within some undefined 
> margin for error.  Compiled C code can get the two pins set within a small 
> number of 1 GHz clocks.  With a fast enough scope, you’’ll probably find at 
> least a few ns difference, if this isn’t obscured by parasitic capacitance in 
> the traces and wiring.  Sure, this is a 3 orders of magnitude less than 
> gpiod, but there are folks out there working in femtoseconds for whom a 
> nanosecond would be far too long.  Time is a very stretchy thing.  
> 
> 
>> On Aug 10, 2020, at 11:33 AM, Mark A. Yoder > > wrote:
>> 
> 
>> Interesting   I wrote a c version 
>> 
>>  and the pins are toggle at the exact same time.  Now, how to get gpioset to 
>> work correctly.
>> 
>> --Mark
>> 
>> On Monday, August 10, 2020 at 10:27:08 AM UTC-4 Mark A. Yoder wrote:
>> Yes, but the hardware on the am335x can toggle multiple pins on the same 
>> chip in the same clock cycle.  Seems like the software should be able to 
>> support it.
>> 
>> On Monday, August 10, 2020 at 10:20:10 AM UTC-4 evilw...@gmail.com <> wrote:
>> software takes time to execute.
>> 
>> 
>> On 8/10/2020 7:09 AM, Mark A. Yoder wrote:
>>> I'm starting to play with gpiod on a Beaglebone Black.  One of the 
>>> advantages of gpiod is you can toggle multiple pins on the same chip all at 
>>> once.
>>> So I try:
>>> while true; do 
>>> gpioset 1 18=0 19=0
>>> gpioset 1 18=1 19=1
>>> done
>>> 
>>> This is toggling pins P9_14 and P9_16.  I expect to see the two pins toggle 
>>> on at the same time, but what I get is
>>> a 4 microsecond delay from P9_14 switching and P9_16 switching.  
>>> 
>>> Should there be such a long delay?  I'd expect the two to switch at the 
>>> same time (which is what happens when toggle pins via the PRU).
>>> 
>>> I do the same experiment with python and I see a 70 us delay.
>>> 
>>> --Mark
>>> On Friday, March 27, 2020 at 3:58:21 PM UTC-4 Drew Fustini wrote:
>>> On Fri, Mar 27, 2020 at 8:45 PM John Allwine > 
>>> wrote: 
>>> > 
>>> > I don't intend to toggle a GPIO as fast as possible (except to test), but 
>>> > from a performance standpoint that demonstration seemed to indicate that 
>>> > there are issues with sysfs. Hopefully, libgpiod will prove to be better! 
>>> 
>>> Bartosz explains the differences and improvements that new gpiod 
>>> interface provides in this talk: 
>>> https://www.youtube.com/watch?v=cdTLewJCL1Y 
>>>  
>>> 
>>> Essentially, if you need read or set multiple lines, it is faster. 
>>> Also, it has an improved way to read events as well. 
>>> 
>>> Slides if you prefer over video: 
>>> https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776
>>>  
>>> 
>>>  
>> 
>>> -- 
>>> 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...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/16a18eef-a649-46d9-b126-f774a8eb1522n%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...@googlegroups.com 
>> .
> 
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/ab17b85d-7f42-42cb-9793-ed7d04a44e27n%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 
> ema

Re: [beagleboard] libgpiod on Beaglebone AI

[Steve Lentz]

It’s unlikely to be exactly the same time, it’s just within some undefined 
margin for error.  Compiled C code can get the two pins set within a small 
number of 1 GHz clocks.  With a fast enough scope, you’’ll probably find at 
least a few ns difference, if this isn’t obscured by parasitic capacitance in 
the traces and wiring.  Sure, this is a 3 orders of magnitude less than gpiod, 
but there are folks out there working in femtoseconds for whom a nanosecond 
would be far too long.  Time is a very stretchy thing.  

> On Aug 10, 2020, at 11:33 AM, Mark A. Yoder  wrote:
> 
> Interesting   I wrote a c version 
> 
>  and the pins are toggle at the exact same time.  Now, how to get gpioset to 
> work correctly.
> 
> --Mark
> 
> On Monday, August 10, 2020 at 10:27:08 AM UTC-4 Mark A. Yoder wrote:
> Yes, but the hardware on the am335x can toggle multiple pins on the same chip 
> in the same clock cycle.  Seems like the software should be able to support 
> it.
> 
> On Monday, August 10, 2020 at 10:20:10 AM UTC-4 evilw...@gmail.com 
>  wrote:
> software takes time to execute.
> 
> 
> On 8/10/2020 7:09 AM, Mark A. Yoder wrote:
>> I'm starting to play with gpiod on a Beaglebone Black.  One of the 
>> advantages of gpiod is you can toggle multiple pins on the same chip all at 
>> once.
>> So I try:
>> while true; do 
>> gpioset 1 18=0 19=0
>> gpioset 1 18=1 19=1
>> done
>> 
>> This is toggling pins P9_14 and P9_16.  I expect to see the two pins toggle 
>> on at the same time, but what I get is
>> a 4 microsecond delay from P9_14 switching and P9_16 switching.  
>> 
>> Should there be such a long delay?  I'd expect the two to switch at the same 
>> time (which is what happens when toggle pins via the PRU).
>> 
>> I do the same experiment with python and I see a 70 us delay.
>> 
>> --Mark
>> On Friday, March 27, 2020 at 3:58:21 PM UTC-4 Drew Fustini wrote:
>> On Fri, Mar 27, 2020 at 8:45 PM John Allwine > 
>> wrote: 
>> > 
>> > I don't intend to toggle a GPIO as fast as possible (except to test), but 
>> > from a performance standpoint that demonstration seemed to indicate that 
>> > there are issues with sysfs. Hopefully, libgpiod will prove to be better! 
>> 
>> Bartosz explains the differences and improvements that new gpiod 
>> interface provides in this talk: 
>> https://www.youtube.com/watch?v=cdTLewJCL1Y 
>>  
>> 
>> Essentially, if you need read or set multiple lines, it is faster. 
>> Also, it has an improved way to read events as well. 
>> 
>> Slides if you prefer over video: 
>> https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776
>>  
>> 
>>  
> 
>> -- 
>> 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...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/16a18eef-a649-46d9-b126-f774a8eb1522n%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/ab17b85d-7f42-42cb-9793-ed7d04a44e27n%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/A0B87564-F04B-48AA-9D42-0E258010DD3C%40gmail.com.

Re: [beagleboard] Powering off Beaglebone green

[Steve Lentz]

I have the exact same problem and just got an Adafruit Feather processor, RTC 
and latching relay.  These are sitting in pieces on my desk so I don’t yet know 
if this is a viable solution.  My goal is to wake up a BBB once very two weeks 
for 1-2 hours and to run from batteries for a year, I have a satellite modem, a 
motor and a few other things to run from the battery packso every bit of power 
counts.  Leaving the BBB to time itself would just about double the size of 
battery needed.  This is going in a place where there’s no energy to be 
harvested…

Will look into the MSP430 as well.  

> On Jun 19, 2020, at 10:06 AM, Jim F  wrote:
> 
> You might be able to modify the shutdown script so that the last thing it 
> does is drive your gpio to unset the power supply. I've never done that 
> before; we in fact used an msp430 to do what you need and more.
> 
> You can probably find more information about modifying the shutdown procedure 
> elsewhere. It would be standard Linux stuff, if anybody has done something 
> like it.
> 
> In the old days you could do init 1 to go to single user mode, and then 
> safely power off from there. In systemd labs I don't know if you can specify 
> something to be the last thing you do during shutdown.
> 
> You could also put an RC filter on the gpio output to give you a little time. 
> That's pretty janky though I think. I wouldn't sell something like that 
> (well, I probably wouldn't) but maybe it'll suit your needs.
> 
> Have fun googling! 
> 
> J
> 
> On Fri, Jun 19, 2020, 9:15 AM evilwulfie  > wrote:
> IF you want power supply control like that. You will need a small
> low power mcu like an msp430 running off of a small coin cell
> to manage power.
> 
> On 6/19/2020 12:37 AM, guillermito.ferr...@gmail.com 
>  wrote:
>> Hello Dennis,
>> 
>> I much appreciate your reply.
>> The point is that I have an external power supply that powers the BB and 
>> some other peripheral devices.
>> So if I make shutdown -h the BB turns off but the external power supply 
>> still remains on. This is why I have a GPIO pin on the BB to turn off the 
>> external power supply. But I cannot use this pin if the BB itself is off!
>> Hope it is clear now.
>> Best rgds,
>> G
>> 
>> Il giorno giovedì 18 giugno 2020 23:06:54 UTC+2, Dennis Bieber ha scritto:
>> On Thu, 18 Jun 2020 10:58:55 -0700 (PDT), in 
>> gmane.comp.hardware.beagleboard.user 
>> guillermito.ferrari-re5jqeeqqe8avxtiumw...@public.gmane.org <> wrote: 
>> 
>> >Hello everybody, 
>> >I have a GP output of a Beaglebone Green that turns the power off when it 
>> >is asserted by SW. It does its job well. 
>> >However, I would like to power the Beagle off after having done a shutdown 
>> >(rather than turn it off suddenly). 
>> >Is there any SW/HW trick to get this behavior? 
>> 
>> Are you talking about something that turns off an external power 
>> supply? On the BBB, and BBAI, "shutdown -h now" ends with the circuits 
>> behind the regulator chip being unpowered. 
>> 
>> Anything cutting power to the board itself likely needs to have a 
>> sense 
>> lead (maybe to one of the 5V header pins) which holds the power supply 
>> "active", and opens when it loses the 5V. Of course, that also implies one 
>> would need a momentary contact NO switch to the input of the power supply, 
>> bridging to an always-on 5V source in order to "jump-start" the system 
>> (hold down the NO switch to get the power supply to provide power to the 
>> board, release switch when the header 5V pin feeds back to the power supply 
>> control). Of course, you may have to find some way to prevent any voltage 
>> from the NO switch feeding back to the header pin. Maybe a pair of 
>> transistors -- one transistor controlling the power supply input, with the 
>> control lead shared by the output of the other transistor and the NO 
>> switch; the second transistor controlled by the header 5V pin. IE: this 
>> second transistor in/out is parallel with the NO switch. 
>> 
>> 
>> -- 
>> 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/83df0e35-6a5e-408f-902a-c3cd97453e49o%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoa

Re: [beagleboard] RS485 with CBB-Serial-r02

[Steve Lentz]

RS-485 is a multi-drop bus using 2 or 4 wires.  It does not include hardware 
flow control and hence the RTS signal is not used.  If you have a device that 
needs RTS, it is probably RS-232.  Look at any wiring diagram for RS-485 
connections.  

> On Jun 16, 2020, at 8:50 PM, Micka  wrote:
> 
> Can someone explain me why we can't use the rts signal for the rs485 ?
> 
> Le mer. 17 juin 2020 à 00:24, Bekir Bahadir  > a écrit :
> Also Im trying to get rs485 work over gpio with active high when 
> transmitting. Can anyone help? Ive creqtet a net dts with the gpios for 
> enabling the transmitter. Fo i need to patch the kernel for rs485 or is it 
> alreqdy included in the omap driver?
> 
> -- 
> 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/ce353b99-82d0-4b35-b310-fc4d756d391co%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/CAF%2BMRtm%3DppGWXAmjp74EjTFgzPrmPJGE4i07KkGtmvRXR-4NMw%40mail.gmail.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/7A49D2F4-85EE-4880-B501-ACB578CD92A8%40gmail.com.

Re: [beagleboard] Could PRU read this signals?

[Steve Lentz]

I too was skeptical of FPGAs until recently, I think you owe it to yourself to 
check out Zynq and Altera which combine FPGAs with ARM cores.  The PL (FPGA 
part of these chips) can align the clock edges and write the data into the 
memory of the ARM processor.  You might find it is possible to do the 
decimation in the PL saving the ARM for other things.  You could potentially 
even generate UDP packets in the PL, if all you want to do is move the data 
someplace else.  The infamous FPGA learning curve is quite real, but not 
insurmountable.  There are lots of tutorials available, both from the vendors 
and from other sources.


> On May 28, 2020, at 5:50 AM, PAk Ys  wrote:
> 
> Thank you TJF for that detailed answer and thank you too Andrew for your 
> insights.
> 
> We are trying to extract radar data from one radar board. The goal is not 
> have it working at 50MHz (which is the system max rate), but have the 
> possibility if needed. Probably we will work at 10 to 20MHz, and the data on 
> the BBB is only sent via Ethernet to another device in the same network. We 
> only need to extract the data from the 4 Data lines (channels) whenever CLK 
> changes, the Frame line is only used to synchronized at the beggining since 
> the format doesn't change.
> 
> We have already done this setup with DSPs and MCUs with Ethernet integrated 
> with no issues, however for my new design I only can use LVDS so a fast 
> device (like PRU) is needed. B eaglebone would give me much more flexibility 
> than a FPGA, because, I could decimate as you well said and/or implement a 
> simple radar data viewer on the ARM core.
> 
> 
> 
> On Thursday, May 28, 2020 at 10:48:56 AM UTC+2, Andrew P. Lentvorski wrote:
> What are you actually trying to do?  That's a 50Mbit sustained transfer rate 
> if bit time is 20ns.  100Mbit if 10ns.  And 4 channels.  That's 200-400Mbps. 
> You're moving a *TON* of data even at slower clock rates--there is no 
> resource on the BBB that can keep that up very long.
> 
> This seems quite questionable on the BBB ... even moreso if your timing 
> diagram is valid (which I suspect it is not).
> 
> First, given your diagram, the sampling point would have to be recovered.  
> Note that the Clock, Data, and Frame are all coincident.  Normally the clock 
> falls in the middle of the data window.  That's not easy to recover without a 
> PLL.  I doubt the BBB has enough resolution to hit the data stable point on 
> the data with any reliability at 50MHz.
> 
> Second, are you *actually* running at 50MHz?  Are you considering every 
> *cross* as the frequency (high-to-low on a single line) or are you 
> considering an individual signal rise-to-rise as the frequency.  Is that data 
> changing every 20ns or every *10ns*?  If it's 10ns, it's probably not 
> possible.
> 
> I would *STRONGLY* recommend that you use an FPGA.  Even an incredibly cheap 
> FPGA would deserialize that with ease and then you could put it into a form 
> in which you might be able abuse something like the RMII from the Ethernet 
> peripheral to transfer it out.
> 
> But it's still a *LOT* of data.  You need something that can handle gigabit 
> speeds if you keep this up even for a couple milliseconds.
> 
> Your best bet would be to use that FPGA to also decimate the data as well so 
> that you're working with a reasonable amount of data.
> 
> -- 
> 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/d45e79ae-736d-42c3-abc1-765b0274a34c%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/3EA35A76-EE37-4AB5-A62D-04E560E3FEEC%40gmail.com.

[beagleboard] No network interface for Pocket Beagle on Mac.

[Steve Lentz]

I have a new Pocket Beagle which I am trying to connect to a Mac via USB.

I have the latest image:  bone-debian-10.3-iot-armhf-2020-04-06-4gb.img
The Pocket Beagle appears as a USB drive on the Mac.
The Pocket Beagle works as expected on a Windows machine; 
http://192.168.7.2:3000 brings up Cloud9. (at least this proves the USB 
cable is good)
I have a Beagle Board Black that connects to the Mac via USB and works as 
expected.  http://beagleboard.local brings up Cloud9.  When I look at 
ifconfig, I can see the BBB attached as en7 with IP 192.168.6.1. (this 
would seem to rule out any problems on the Mac.)

However, when I connect the Pocket Beagle, I do not see a network interface 
being created; there are no new entries under ifconfig as there are when 
the BBB is connected.

At this point I have to suspect there is something subtly wrong in the 
Debian image that allows the BBB to work but not the Pocket Beagle.  

Has anyone actually successfully connected a Pocket Beagle to a Mac?

Any ideas on what I am missing?  

Thank you,
Steve


-- 
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/41097c5a-fcbe-4e92-8bb7-eda798f6b91b%40googlegroups.com.