[beagleboard] Looking for Fritzing drawing for BeagleBone Blue

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

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

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

RE: [beagleboard] Negative voltage on GPIO

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

Re: [beagleboard] BBGW console packages?

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

Re: [beagleboard] BBGW console packages?

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

Re: [beagleboard] BBGW console packages?

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

Re: [beagleboard] BBGW console packages?

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

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

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

Re: [beagleboard] recommendation for a symbolic debugger

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

[beagleboard] Re: PWM pins fluctuating during boot?

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

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

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

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

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

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

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

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

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

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

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*: >

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

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,

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

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

Re: [beagleboard] recommendation for a symbolic debugger

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.

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

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

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

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

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

*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

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

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 adapter

[beagleboard] PWM pins fluctuating during boot?

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

Re: [beagleboard] recommendation for a symbolic debugger

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

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

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