[beagleboard] Re: RTC's SDA and SCL Resistors

[William B]

Actually what is happening is this: when I remove the power from the BBB, 
the date and time return to the default setting. Because the RTC is 
automatically associated with system time auto-tuning, then its time is 
also being changed incorrectly (I had not noticed this in reboot because it 
is necessary to remove the power).

How do I prevent the system from automatically correcting the RTC? How do I 
remove this connection from the RTC with the system?
I intend to create a script to set date and time.




-- 
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/20544dc3-3ce0-4ff7-82d8-9afcdb1c8e0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RTC's SDA and SCL Resistors

[William Hermans]

Well, rtc0 is most likely the on AM335x on die real time clock, which will
not persist time across reboots.

On Thu, Jul 27, 2017 at 7:54 PM, William B  wrote:

> Finally I got ... the last hint from William Hermans indicated me
> something about the device name, which could be "rtcX", which made me
> execute: "ls -la /dev/rtc*":
>
> root@beaglebone:~# ls -la /dev/rtc*
> lrwxrwxrwx 1 root root  4 May 21  2016 /dev/rtc -> rtc0
> crw--- 1 root root 254, 0 May 21  2016 /dev/rtc0
>
> 1) Replace "rtc1" with "rtc0" in the commands and everything works! (the
> system date and time were already correct):
>
> hwclock -w -f /dev/rtc0
>
> 2) To test if it worked and if the date and time were actually adjusted, I
> changed the system time, restarted the BBB and disconnected it from the
> internet to ensure the date and time would not be auto-tuned. After
> restarting it, I checked if the system time was still wrong and then read
> the RTC time (which must be correct!).
>
> hwclock -r -f /dev/rtc0
>
> It works!!! RTC date and time were correct.
>
> I don't even know how to thank everyone for their help. It should be
> simple to solve this problem, but it takes a lot of time, especially for
> those who don't have experience like me.
>
> Thank you very much!
>
>
>
>
> --
> 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/9c2b0a36-e70d-4fec-a904-6a0f6b5e0a49%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

[beagleboard] RE: What Are Some "Okay" Ways to Test If Specific Pins on the P8 and P9 Headers are Still Working?

[Mala Dies]

Hello,

The other day is when I did some incorrect measurements and almost burned 
down the "world." Anyway, I need some support. What are some surefire ways 
I can test my GPIO pins in the Debian distro with our commands?

Seth

P.S. I do not want to test them via hardware. I thought there might be a 
way to test them with our BASH in Debian. If you know and are willing to 
share, I would like to have you on board on this specific task. Thank you 
again for the support. 

-- 
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/d7e37911-f546-417d-9074-8f0a15797331%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RTC's SDA and SCL Resistors

[William Hermans]

William,

Also to save you from future grief. Make sure you load the proper drivers
for your hardware,then if you're going to write your own software to read
from the RTC. Use /dev/rtcx( probably /dev/rtc1 ), and do not try to read
directly from the RTC over I2C. Trust me . . .

On Thu, Jul 27, 2017 at 4:46 PM, William Hermans  wrote:

>
>
> On Thu, Jul 27, 2017 at 4:24 PM, William B  wrote:
>
>> Is there any other difference in this latest version of Debian? I'm
>> following a tutorial below, but the command "hwclock -r -f /dev/rtc1" is
>> indicating failure to communicate with the new device:
>>
>> *TUTORIAL*:
>> https://learn.adafruit.com/adding-a-real-time-clock-to-beagl
>> ebone-black/set-rtc-time
>>
>> *ERROR*:
>> root@beaglebone:~# hwclock -r -f /dev/rtc1
>> hwclock: Cannot access the Hardware Clock via any known method.
>>
>> *DEVICES*:
>> root@beaglebone:/# ls -la /sys/bus/i2c/devices
>> total 0
>> drwxr-xr-x 2 root root 0 Jul 27 20:19 .
>> drwxr-xr-x 4 root root 0 Jul 27 20:19 ..
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0024 ->
>> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0034 ->
>> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0034
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0050 ->
>> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0070 ->
>> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0070
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0054 ->
>> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0054
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0055 ->
>> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0055
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0056 ->
>> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0056
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0057 ->
>> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0057
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-0 ->
>> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-1 ->
>> ../../../devices/platform/ocp/4802a000.i2c/i2c-1
>> lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-2 ->
>> ../../../devices/platform/ocp/4819c000.i2c/i2c-2
>>
>>
> You have to write to the RTC before you can read from it. Something that
> guide confuses . . . So actually the first steps you need to take is like
> this:
> root@wgd:~# apt-get install ntpdate
> root@wgd:~# ntpdate pool.ntp.org
> 27 Jul 16:39:29 ntpdate[1903]: adjust time server 199.223.248.101 offset
> 0.004123 sec
>
> Then if it's important to be on the right timezone . . .
> ( optional )
> root@wgd:~# dpkg-reconfigure tzdata
>
> Current default time zone: 'America/Phoenix'
> Local time is now:  Thu Jul 27 16:40:54 MST 2017.
> Universal Time is now:  Thu Jul 27 23:40:54 UTC 2017.
>
> Then you can write to the RTC:
> root@wgd:~# hwclock -w -f /dev/rtc1
>
> So what all this does is update the system time, configures the timezone,
> so that system time can be written to the real time clock. You could in
> fact just write to the real time clock without doing all the above. But the
> RTC will not be accurate.
>
> Now we should be able to read from the RTC.
> root@wgd:~# hwclock -r -f /dev/rtc1
> Thu Jul 27 16:45:41 2017  -0.646341 seconds
>
>
>

-- 
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/CALHSORo8JLJgagSzrgN7bZi1xswr8%3DOTOr%2BqxABp4Y8BcjjswQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RTC's SDA and SCL Resistors

[William Hermans]

On Thu, Jul 27, 2017 at 4:24 PM, William B  wrote:

> Is there any other difference in this latest version of Debian? I'm
> following a tutorial below, but the command "hwclock -r -f /dev/rtc1" is
> indicating failure to communicate with the new device:
>
> *TUTORIAL*:
> https://learn.adafruit.com/adding-a-real-time-clock-to-
> beaglebone-black/set-rtc-time
>
> *ERROR*:
> root@beaglebone:~# hwclock -r -f /dev/rtc1
> hwclock: Cannot access the Hardware Clock via any known method.
>
> *DEVICES*:
> root@beaglebone:/# ls -la /sys/bus/i2c/devices
> total 0
> drwxr-xr-x 2 root root 0 Jul 27 20:19 .
> drwxr-xr-x 4 root root 0 Jul 27 20:19 ..
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0024 ->
> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0034 ->
> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0034
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0050 ->
> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0070 ->
> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0070
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0054 ->
> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0054
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0055 ->
> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0055
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0056 ->
> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0056
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0057 ->
> ../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0057
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-0 ->
> ../../../devices/platform/ocp/44e0b000.i2c/i2c-0
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-1 ->
> ../../../devices/platform/ocp/4802a000.i2c/i2c-1
> lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-2 ->
> ../../../devices/platform/ocp/4819c000.i2c/i2c-2
>
>
You have to write to the RTC before you can read from it. Something that
guide confuses . . . So actually the first steps you need to take is like
this:
root@wgd:~# apt-get install ntpdate
root@wgd:~# ntpdate pool.ntp.org
27 Jul 16:39:29 ntpdate[1903]: adjust time server 199.223.248.101 offset
0.004123 sec

Then if it's important to be on the right timezone . . .
( optional )
root@wgd:~# dpkg-reconfigure tzdata

Current default time zone: 'America/Phoenix'
Local time is now:  Thu Jul 27 16:40:54 MST 2017.
Universal Time is now:  Thu Jul 27 23:40:54 UTC 2017.

Then you can write to the RTC:
root@wgd:~# hwclock -w -f /dev/rtc1

So what all this does is update the system time, configures the timezone,
so that system time can be written to the real time clock. You could in
fact just write to the real time clock without doing all the above. But the
RTC will not be accurate.

Now we should be able to read from the RTC.
root@wgd:~# hwclock -r -f /dev/rtc1
Thu Jul 27 16:45:41 2017  -0.646341 seconds

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

[beagleboard] Re: RTC's SDA and SCL Resistors

[William B]

Is there any other difference in this latest version of Debian? I'm 
following a tutorial below, but the command "hwclock -r -f /dev/rtc1" is 
indicating failure to communicate with the new device:

*TUTORIAL*:
https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/set-rtc-time

*ERROR*:
root@beaglebone:~# hwclock -r -f /dev/rtc1
hwclock: Cannot access the Hardware Clock via any known method.

*DEVICES*:
root@beaglebone:/# ls -la /sys/bus/i2c/devices
total 0
drwxr-xr-x 2 root root 0 Jul 27 20:19 .
drwxr-xr-x 4 root root 0 Jul 27 20:19 ..
lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0024 -> 
../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024
lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0034 -> 
../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0034
lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0050 -> 
../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050
lrwxrwxrwx 1 root root 0 Jul 27 20:19 0-0070 -> 
../../../devices/platform/ocp/44e0b000.i2c/i2c-0/0-0070
lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0054 -> 
../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0054
lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0055 -> 
../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0055
lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0056 -> 
../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0056
lrwxrwxrwx 1 root root 0 Jul 27 20:19 2-0057 -> 
../../../devices/platform/ocp/4819c000.i2c/i2c-2/2-0057
lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-0 -> 
../../../devices/platform/ocp/44e0b000.i2c/i2c-0
lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-1 -> 
../../../devices/platform/ocp/4802a000.i2c/i2c-1
lrwxrwxrwx 1 root root 0 Jul 27 20:19 i2c-2 -> 
../../../devices/platform/ocp/4819c000.i2c/i2c-2

-- 
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/02f0803f-23ce-4f6a-985c-daadcd9f7d2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[William Hermans]

On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  wrote:

> This is probably the best guide you're going to find on the subject.
>
> https://www.youtube.com/watch?v=T9yFyWsyyGk
>
> Never used it myself( I do not cross compile ), but I'm confident DR
> Molly's instructions work.
>

Just in case it's not clear, R Molly shows how to setup remote debugging
towards the end I think. Been a while since I've watched this.

-- 
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/CALHSORoA%3D5HscShmCFzV0beyQnqnRnE1SZrQPy2DfGj3fA8cPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[William Hermans]

This is probably the best guide you're going to find on the subject.

https://www.youtube.com/watch?v=T9yFyWsyyGk

Never used it myself( I do not cross compile ), but I'm confident DR
Molly's instructions work.

-- 
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/CALHSORrj%3D7YCkk7f0ipJ2QyQ1P%3DUBRtT-h-4qrXuTopcLMnbOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RTC's SDA and SCL Resistors

[William Hermans]

On Thu, Jul 27, 2017 at 3:02 PM, William B  wrote:

> *Grahan:*
> You're 100% correct. Running "i2cdetect -y -r 2" instead of "1" at the
> end, it detected the RTC at address 0x68, as we can see in the available
> tutorials.
> Answering your question, I'm using the latest available Debian release
> (bone-debian-8.8-iot-armhf-2017-07-01-4gb.img) available here:
> https://rcn-ee.net/rootfs/bb.org/testing/2017-07-01/iot/
>
> *William Hermans: *
> When I run the command "i2cdetect -l", I get this information:
>
> root@beaglebone:~# i2cdetect -l
> i2c-0   i2c OMAP I2C adapterI2C adapter
> i2c-1   i2c OMAP I2C adapterI2C adapter
> i2c-2   i2c OMAP I2C adapterI2C adapter
>
>
> Now I can continue with the process normally and as soon as it works I
> report here.
>
> Thank you again!!!
>

Sounds about right . ..
root@wgd:~# cat /sys/bus/i2c/devices/2-0068/name
ds3232

Funny, I'm actually using an i2c RTC, forgot, and confused the temp sensor
I'm using over one wire. By the way, the DS3232 is also an accurate RTC,
but it does cost like $8.xx per. So not exactly cheap.

-- 
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/CALHSORppVeu1WzRMfO2g4Uw_XXq3OGPizrhuNO8Pwk%3DfvguOgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PWM pins fluctuating during boot?

[Graham]

I think you need to assume that pretty much anything can happen while the 
board is booting or crashing, and inhibit all servo activities unless you 
know the BBB is in positive control.

Depending on how "large" your fixed-wing is, it probably would not be a bad 
idea to put some kind of watch-dog timer in the system, so that if the 
software crashes/stops/looses-interest/reboots/low-battery/ the servos all 
go to some neutral/safe setting.

--- Graham

== 

-- 
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/cfbb6678-2ba3-401a-83a6-c9c4ed0ac50e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

John,
Thanks a lot.
I am debugging a user space app.
I guess I didn't realize I could use Eclipse on my host and debug on the 
target without the binaries on the host. I do have the sources on my host 
anyway.
I have never heard of CCSV7 but a quick look at 
http://www.ti.com/tool/ccstudio is attractive. I'll check it out.
Thanks,
Clark

On Wednesday, July 26, 2017 at 4:57:41 PM UTC-7, john3909 wrote:

> Are you debugging user space app or kernel code like drivers, kernel 
> modules, etc?
>
> If you are debugging user space app, you have two solutions:
> 1) use gdbserver on your BBB and Code Composer Studio (CCSV7) or Eclipse 
> on your host, which uses gdb for debugging. You will need your BBB source 
> code on your host. I recommend that you use NFS to host your BBB rootfs on 
> your host machine. 
> 2) use USB200 JTAG debugger and use CCSV7 for debugging.
>
> For kernel code debugging, you can use 2) above, but the debugging is 
> limited because CCSV7 isn’t kernel aware. 
>
> Regards,
> John
>
>
>
>
> On Jul 26, 2017, at 4:34 PM, clarkbr...@gmail.com  wrote:
>
> I really need to have a symbolic interface to gdb running on my BBBs.  
> Here is my situation.
> I keep build copies of the software on the BBB and compile them on the BBB.
> I edit them on my PC, keeping the masters in a local repo. I manually move 
> them over after editing to compile them on the BBB.
> I have tried debugging on the BBB with gdb and its command line interface 
> but the code has gotten too complicated nowadays.
> I am running the 2017-03-19 image with updates. I am concerned about the 
> file space remaining on the BBB so I don't want a big app on the BBB.
> I can do X to my desktop, so an X frontend to dbg seems like the best 
> answer.
> In other situations, I have used Eclipse CDT on my dev station (that was a 
> Ubuntu box) but cross compiling and remote debugging were a problem. I 
> ended up pushing the sources over and compiling over on the BBB and never 
> remote debugged.
> Now I have a Windows dev station and I could put Eclipse on it, but things 
> like cross compiling would be a disaster.
> I push the BBB pretty hard with my app. The BBB is only a single 
> processor.  Whatever the front end it shouldn't take a lot of cpu. I guess 
> during debugging sessions, the cpu load is excusable tho.
> I don't think the file space for putting Eclipse CDT on the BBB is 
> affordable, otherwise I like running Eclipse on the BBB. I can teach 
> Eclipse where my repo is. I could run it via X from my PC.
> I could rebuild the bots but use a big SD card so file space isn't a 
> problem. I guess I haven't accreted s much stuff that rebuilding would 
> be a set back.
> So what to do?
> Thanks,
> Clark
>
> -- 
> 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/08df6016-8563-4d7a-98be-1feffb97e20a%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6feb4433-64ca-488a-94da-7859f82a6442%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PWM pins fluctuating during boot?

[OwenMc]

Hello everyone,

I'm currently trying to use a BBBlue to control a large fixed wing UAV via 
Ardupilot. I set everything up as per these instructions 
 and it all worked perfectly first 
time round. After a few power cycles, however, I've noticed that the servos 
will twitch to random positions while the board is booting and sometimes 
these twitches will latch causing serious binding to occur (causing me to 
disconnect the battery to avoid damage), once the Ardupilot code starts the 
servos return to their default position. I've tried a couple of different 
servos (Hitec, Multiplex, Turnigy) and all are effected to a greater or 
lesser extent.

Today, I hooked up a scope to some of the PWM pins to see what was going on 
and noticed that they do indeed toggle between high and low a couple of 
times during the boot process. Whilst none of this toggling correlates to a 
valid servo signal (e.g. ~800-2200us @ 50Hz), it seems to be this that is 
causing the twitching, possibly because the servos don't do much in the way 
of signal validation.

I figure this might be something to do with the initialisation of the board 
and the pinmuxes, but does anyone know exactly what's going on? And more 
importantly, is there anything that can be done to solve it?

Thanks in advance!
Owen

-- 
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/2ece7e9e-de0d-4381-97b2-77fc0fb3ca44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RTC's SDA and SCL Resistors

[William B]

*Grahan:*
You're 100% correct. Running "i2cdetect -y -r 2" instead of "1" at the end, 
it detected the RTC at address 0x68, as we can see in the available 
tutorials.
Answering your question, I'm using the latest available Debian release 
(bone-debian-8.8-iot-armhf-2017-07-01-4gb.img) available here:
https://rcn-ee.net/rootfs/bb.org/testing/2017-07-01/iot/

*William Hermans: *
When I run the command "i2cdetect -l", I get this information:

root@beaglebone:~# i2cdetect -l
i2c-0   i2c OMAP I2C adapterI2C adapter
i2c-1   i2c OMAP I2C adapterI2C adapter
i2c-2   i2c OMAP I2C adapterI2C adapter


Now I can continue with the process normally and as soon as it works I 
report here.

Thank you again!!!




-- 
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/3ac8db97-2938-433e-992b-2422278bb1c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RTC's SDA and SCL Resistors

[William Hermans]

It's not so much the debian version, as it is the kernel. kernel 3.8.x is
different from kernel 4.x. The easiest way to see what is attached it this:
root@wgd:~# i2cdetect -l
i2c-0   i2c OMAP I2C adapterI2C adapter
i2c-1   i2c OMAP I2C adapterI2C adapter
i2c-2   i2c OMAP I2C adapterI2C adapter

-- 
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/CALHSORrD516bSiRBEroWhgdzPs3NiWRYZKo4%3DELKtKPCHeJ3-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RTC's SDA and SCL Resistors

[Graham]

What version of Debian are you running.

On Debian 8, what was in the docs as I2C-1 is now I2C-2.

Hook your translator to pins P9-19 and P9-20 and run "i2cdetect -y -r 2"

I2C-2 is enabled in the device tree by default.

--- Graham

==

-- 
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/b6342b82-8238-4745-9b70-924d8edc4d0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RTC's SDA and SCL Resistors

[William Hermans]

On Thu, Jul 27, 2017 at 1:24 PM, William B  wrote:

> Hi!
> I bought the I2C logic converter 3.3V => 5v and I've connected the RTC to
> the BBB, but running "i2cdetect -y -r 1" doesn't find the RTC device. I've
> checked the wiring of the connections and I repeated the process a few
> times, but it doesn't detect the RTC.
>
> Any suggestion?
>

#1 You're sure you're connected to I2C-1 ?
#2 Did you load the device tree to get I2C-1 active ? It's not enabled by
default.

-- 
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/CALHSORozg7BMqWW3yETxvMFhvWWHoOqrGN1DRrr5cTF%3DCZnhyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: RTC's SDA and SCL Resistors

[William B]

Hi! 
I bought the I2C logic converter 3.3V => 5v and I've connected the RTC to 
the BBB, but running "i2cdetect -y -r 1" doesn't find the RTC device. I've 
checked the wiring of the connections and I repeated the process a few 
times, but it doesn't detect the RTC.

Any suggestion?




-- 
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/8020d029-3445-4a93-acf7-de2bfc84e67d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Adafruit Python library for BeagleBone Blue, naming conventions

[Drew Fustini]

On Thu, Jul 27, 2017 at 8:13 AM, Mark A. Yoder  wrote:
> Is anyone updating the Adafruit Python library[1]  for the Blue?

I've not started working on that yet.  But I would very happy to
review any github issues or pull requests related to Blue support.

> What do you think?  These should also apply to BoneScript.

Could you please open an issue with these suggestions?  If you have
time, please make a pull request with changes you think might be
needed in source/common.c.

Thanks,
Drew

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

Re: [beagleboard] BBGW console packages?

[ferdster]

Thank you!

On Thursday, July 27, 2017 at 11:43:18 AM UTC-6, RobertCNelson wrote:
>
> On Thu, Jul 27, 2017 at 12:06 PM, Robert Nelson  > wrote: 
> > On Thu, Jul 27, 2017 at 11:26 AM, ferdster  > wrote: 
> >> I remember following these instructions a few months ago, but now when 
> I try 
> >> to apt-get install firmware-ti-connectivity, I get the no installation 
> >> candidate error. 
> >> 
> >> I can't apt-get install bb-wl18xx-firmware since it depends on 
> >> firmware-ti-connectivity. 
> >> 
> >> Running Ubuntu 16.04.1 (4.4.45-bone-rt-r16). 
> > 
> > Yeah i suppose ubuntu doesn't split those out.. 
> > 
> > give me a moment to get this built and pushed out: 
> > 
> > 
> https://github.com/rcn-ee/repos/commit/e26517ceabc7aca524ac98ecdeb4f685a5f843a2
>  
>
> and pushed out 
>
> 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/822bd85f-8cdd-4c82-a640-864f1b0eeb8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBGW console packages?

[Robert Nelson]

On Thu, Jul 27, 2017 at 12:06 PM, Robert Nelson  wrote:
> On Thu, Jul 27, 2017 at 11:26 AM, ferdster  wrote:
>> I remember following these instructions a few months ago, but now when I try
>> to apt-get install firmware-ti-connectivity, I get the no installation
>> candidate error.
>>
>> I can't apt-get install bb-wl18xx-firmware since it depends on
>> firmware-ti-connectivity.
>>
>> Running Ubuntu 16.04.1 (4.4.45-bone-rt-r16).
>
> Yeah i suppose ubuntu doesn't split those out..
>
> give me a moment to get this built and pushed out:
>
> https://github.com/rcn-ee/repos/commit/e26517ceabc7aca524ac98ecdeb4f685a5f843a2

and pushed out

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

Re: [beagleboard] BBGW console packages?

[Robert Nelson]

On Thu, Jul 27, 2017 at 11:26 AM, ferdster  wrote:
> I remember following these instructions a few months ago, but now when I try
> to apt-get install firmware-ti-connectivity, I get the no installation
> candidate error.
>
> I can't apt-get install bb-wl18xx-firmware since it depends on
> firmware-ti-connectivity.
>
> Running Ubuntu 16.04.1 (4.4.45-bone-rt-r16).

Yeah i suppose ubuntu doesn't split those out..

give me a moment to get this built and pushed out:

https://github.com/rcn-ee/repos/commit/e26517ceabc7aca524ac98ecdeb4f685a5f843a2

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/CAOCHtYgff_CdCHhw29%3DAifDOUAyU0%2BdataN7RihjKDDLbaeH1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBGW console packages?

[ferdster]

I remember following these instructions a few months ago, but now when I 
try to apt-get install firmware-ti-connectivity, I get the no installation 
candidate error.

I can't apt-get install bb-wl18xx-firmware since it depends on 
firmware-ti-connectivity.

Running Ubuntu 16.04.1 (4.4.45-bone-rt-r16).

Thanks.

On Thursday, June 30, 2016 at 5:05:20 PM UTC-6, Mark Grosen wrote:
>
> Ok, I cloned that and copied into /lib/firmware and now the WiFi works 
> (have not tried BT). So, after you fix the firmware package, I think the 
> list of packages needed is:
> * wireless-tools
> * iw
> * wpasupplicant
> * bb-wl18xx-firmware
> * firmware-ti-connectivity
> I am not using connman, etc. 
>
> I also changed uEnv.txt to use dtb=am335x-bonegreen-wireless.dtb - is this 
> required?
>
> Mark
>
>
> On Thu, Jun 30, 2016 at 2:58 PM Robert Nelson  > wrote:
>
>> On Thu, Jun 30, 2016 at 4:54 PM, Mark Grosen > > wrote:
>> > Thanks, Robert. That got me the conf.bin file so that error is gone, 
>> but it
>> > is still looking for wl18xx-fw-4.bin which does not exist. It seems 
>> like I
>> > do need firmware-ti-connectivity otherwise there are no .bin files in
>> > /lib/firmware/ti-connecivity. Is there a different firmware package?
>>
>> Yeah, that comes from the mainline tree, i need to update the
>> firmware-ti-connectivty package..
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ti-connectivity
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgh%3D3unJ3jcNWV4UDw6q3SpiPdCnkZXjM2LvJKZQiJTyA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[beagleboard] Adafruit Python library for BeagleBone Blue, naming conventions

[Mark A. Yoder]

Is anyone updating the Adafruit Python library[1]  for the Blue? 

[2] doesn't appear to have any definitions for the Blue's connectors. 

For example, *GPIO1_17* appears on the Black at *P9_23*.  On the Blue it 
appears on pin 4 for the *GP0* header[3].


Should this be referred to as *GP0_4* since it's pin 4, or should it be 
*GP0_2* since it's the second IO pin on the header, or maybe *GP0_1* is we 
should start numbering with 0?

Another example, The analog in's appear on the ADC header.


Should AIN0 be referred to as *AIN0*, or *ADC_3*, or *ADC_1*, or *ADC_0*? 
 I can justify every choice.

My suggestion is to make it as easy as possible for the beginner and stick 
to the schematic and silk screen.


For example:
GP0_0GPIO1_25
GP0_1GPIO1_17
GP1_0GPIO3_2
UT0_RX   UART0_RX
S1_MOSI  SPI1_MOSI

ADC0 AIN0
AIN0 AIN0  (both refer to AIN0)

What do you think?  These should also apply to BoneScript.

--Mark

[1] https://github.com/adafruit/adafruit-beaglebone-io-python.git
[2] 
https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/common.c
[3] 
https://github.com/beagleboard/beaglebone-blue/raw/master/BeagleBone_Blue_sch.pdf
 
 (page 1, bottom middle)

-- 
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/954dfec1-dcbd-4d40-9494-03f5624ac8f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Looking for Fritzing drawing for BeagleBone Blue

[Mark A. Yoder]

Has anyone created a Fritzing drawing for the Blue?  I'm planning on using 
the Blue in my class this fall and it's time to start writing the 
instructions.

--Mark

-- 
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/9db82592-9622-4c4a-98b6-0de1a076f8ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [beagleboard] Negative voltage on GPIO

[Gerald Coley]

0V or Ground.
No negative voltages of any amount.

From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
Behalf Of claudiocplar...@gmail.com
Sent: Thursday, July 27, 2017 6:46 AM
To: BeagleBoard 
Subject: Re: [beagleboard] Negative voltage on GPIO


Thank you for the reply.

But what is the minimum voltage that can be applied to a GPIO without breaking 
them?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d5cde9e4-2a46-47c0-b38b-1df889d3ce35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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