There are also several IMU drivers in the mainline linux kernel
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/imu?h=v4.14
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
Does anyone know of a beaglebone cape with IMU capabilities that is still
in production? I have found plenty that seem to be end-of-life.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
I figured out the problem.
Buildroot was automatically adding the following compiler flags. Removing
these fixed the problem.
-D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are
e: No such file or directory
loaded module : gbm_pvr.so
found valid GBM backend : gbm_pvr.so
gbm_surface_create
Segmentation fault
On Friday, November 10, 2017 at 9:30:44 AM UTC-6, Kyle wrote:
>
>
> I have created the appropriate buildroot configuration for the beaglebone
> black SG
I have created the appropriate buildroot configuration for the beaglebone
black SGX graphics stack here:
https://bitbucket.org/j_omega/buildroot
This is built with all of the necessary components from TI SDK 4.01.00 to
support the kmscube application.
However, I am having difficulties with the
On Wednesday, August 19, 2015 at 12:06:08 PM UTC-5, Carlos Novaes wrote:
>
>
> I tend to agree with that most of the time. Maybe I am biasing my question
> on a limited experience with PRU applications.
> From my point of view PRU are good for relatively simple tasks, that
> should be fast and
Yep, that approach works well. Thanks!
On Friday, August 14, 2015 at 6:53:35 PM UTC-5, Carlos Novaes wrote:
>
> I was unable to use the NOPx instructions, same error. But you can define
> a macro, ex:
> .macro NOP
> MOV r1, r1
> .endm
>
> .macro NOP2
> MOV r1, r1
> MOV r1, r1
> ;endm
>
> and
On Thursday, August 13, 2015 at 2:01:48 PM UTC-5, TJF wrote:
>
> Hi!
>
> The assembler also supports a NOPn operation (NOP0 - NOPf). See SRM
> chapter 5.3.4.1.18 for details.
>
> BR
>
I read that (SRM page 61) and mentioned in my post that I had tried them.
"thus far every iteration I have t
This seems like a question that ought to be easy to answer but so far my
searching has not turned up a clear one. I need a NOP on occasion to
balance out timing on things and thus far every iteration I have tried of
NOPx results in 'instruction illegal for core version'. I'm having to do
dum
I think I figured out the progression:
1.) I have a single partition install. That was how the flasher wrote it.
So it seems it's not safe to load g_multi.
2.) I don't have the two files tested for loading g_ether so it does not
load that module
3.) It falls through to load g_serial.
The on
#In a single partition setup, dont load g_multi, as we could trash the
linux file system...
if [ "x${root_drive}" = "x/dev/mmcblk0p1" ] || [ "x${root_drive}" =
"x/dev/mmcblk1p1" ] ; then
if [ -f /usr/sbin/udhcpd ] || [ -f /usr/sbin/dnsmasq ] ; then
#Make sure (# CONFIG_USB_ETH_EEM is not s
Ahhh ok, they are exclusive. didn't realize that. How can I control
what's being loaded at boot? it's not in /etc/modules and I can't unload
it presently as it's 'in use'. I'd rather load g_multi at boot if I can.
>
> Well... unload g_serial.. Otherwise g_multi/g_ether won't load..
Hello all,
I purchased a Rev C board a few months ago and set it aside to look at a
bit later. Started working with it more this week and I'm running into
things that seem to be different now. I'm running the eMMC flashed version
with 3.8.13-bone72 kernel. I believe pulled this image from th
Is there a way to determine the mmc device (internal or external microSD
card) that the beaglebone black is booting from within u-boot?
I know u-boot will always identify that mmc 0 is exernal and mmc 1 is
internal. But that doesn't tell me which mmc device u-boot.img is
currently booting. I
Alternatively, use an Arduino to manage the I2C butchering device and get
your data from the Arduino. Honestly I wish these psudo-I2C devices were
driven out. There is a protocol for a reason.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because
edded-core/tree/meta/recipes-devtools/python/python3_3.3.3.bb?h=master
>
>
> On Friday, November 14, 2014 5:12:30 PM UTC-5, kyle...@gmail.com wrote:
>>
>> I've tried getting python 3.3 here:
>> http://www.python.org/ftp/python/3.3.3/Python-3.3.3.tgz
>>
>
Yes, I'm aware of the learning curve. I've been working with them since
they came out. I also don't know what to report other than every image
after the 05-14 image booting from SD is not operating the expected on
either A5A board. When I went back to 05-14 the devices show up, and the
po
I've tried every image now down to 08-05 and none seem to be fully
functional. Each image has had these same issues:
- Power button does nothing, have to press and hold for 8 secs to force
shutdown.
- No USB network device appears at the host.
- No SD partition is mounted from the device.
M
Then it appears your cape is working and the chips are at least visible to
the bus. You should be able to use the smbus system calls to talk to
them. Might be able to do something with i2cget.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message
I have two older A5A boards that I'm trying to use the August/Sept
standalone SD images with. Both behave much different than the older
image (not sure which one maybe june/july) I'm using from my recently fried
Rev C board. I was able to take the backup image from that board and
write it t
So it appears you should expect to see a device between 0x20 through 0x27
from the datasheets. The device address is 0*010* when not shifted
for the R/W bit. That corresponds to 0x20 as the base chip address and
the A1,A2, and A3 pins can set up to 7 other address for the final three
bi
This was a big reason why I chose to use an I2C external ADC for measuring
raw battery voltage in a project of mine. Gating that voltage from
hitting the pins prior to PMIC startup was way more complicated than
hooking up a 4 channel ADC on the I2C bus and using that powered by the
3.3V rail.
Reverse polarity is pretty well-known way to kill many devices.
--
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
A GPIO configured as an input will not draw substantial current from the line
it's connected to. It is sensitive to the charge level on the line and will
not draw current from it (exempting the gate capacitor charge-up). A GPIO that
is set to OUTPUT a high signal is now a potential source of c
A GPIO configured as an input will not draw substantial current from the line
it's connected to. It is sensitive to the charge level on the line and will
not draw current from it (exempting the gate capacitor charge-up). A GPIO that
is set to OUTPUT a high signal is now a potential source of c
I had tried the USB cable, and was getting ready to say that wasn't working
when I realized I had forgotten to install the network driver on this Mac. I
was afraid I had done something in interfaces that was not allowing that device
to come up. Once that was done I was able to contact it on th
Will there be any way to eliminate the boot-hang waiting for DHCP? My other
distributions (Arch) will come up without delay and if Ethernet is present it's
on and working if not, it doesn't come up. I ask because I'm sitting here
hosed now since my boot up is to eMMC, the wireless is not com
If you can get a serial console hooked up to the board it may give you more
insight into where it is failing during the boot process.
On Tuesday, July 22, 2014 1:58:15 AM UTC-5, Peter wrote:
>
> Hi All
> I have a problem with my BBB. When connecting the power, the power led
> comes on, but no us
Check the last page of the schematic. P8.15 is inside the bracket labeled
"Caution: Used On Board". If I could find my old post I'd confirm it was
that pin but I ran into something similar where some pins were pulled one
way or the other in hardware and my circuit could not use the pin. It
Why are you forcing protocol version 1 (-1 parameter)? Since the error
message says it can't use protocol 1 why don't you stop trying to to force
it?
ssh root@192.168.7.2
should be all the command you need.
--
For more options, visit http://beagleboard.org/discuss
---
You received this
Cool, just learned something myself today! Now that I think about it I
think it's I2C where the speed is set in device-tree only.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To
>
>
>
> How do upgrade the kernel? apt-get upgrade does not do the trick.
>
Nevermind found it on the Wiki.
--
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 t
It's a timing issue. Adding a "sleep 10" to rc.local did the trick.
--
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,
Well that almost got it. I set the eth0 interface to a static ip and that
speeds up boot by a bunch it also seems to cause it to no longer bring up
the wireless interface. I can manually ifup wlan1 and it will come online
but it's ignored at boot up.
Putting "ifup wlan1" into /etc/rc.local
Just found an updated drawing for the black that shows those as being
allocated to the onboard eMMC1, which will require reset for these to be
used as GPIO...
On Friday, July 18, 2014 10:21:42 AM UTC-7, Kyle Price wrote:
>
> Hi,
>
> I have worked with various different developme
Is the USR3 LED flashing at a rate of once per second?
On Sunday, June 15, 2014 6:39:14 PM UTC-7, Stephen Nicholson wrote:
>
>
> I have been trying the demo JavaScript files and I keep getting the message
>
> Debugger LIstening on Port 15454
>
> when I run the js file and it not doing anything.
>
Hi,
I have worked with various different development platforms before, though
mostly in C/C++, so a lot of the Bonescript/Node.js stuff is very new to
me, and I am having some trouble with some very simple tasks...
Recently I was trying to take in push button switches and in an effort to
build
It's set in device tree at boot time. I don't think you are going to find
a way to change that on the fly with a running system.
On Wednesday, July 16, 2014 10:21:02 AM UTC-5, Ardit Cuka wrote:
>
> I just need a code in python that sets that frequency to what i want!
>
> On Tuesday, July 15,
If there is a pullup then your pulldown will have to be several times stronger
to make sure that the floating value becomes a logic low. You now have an
effective voltage divider with a pullup / pulldown configuration. Fighting
against the configured on-chip pullup is going to mean that to out
Not that I know of. The device tree can change the pin config to default low
but that does not take effect till boot up so there would still be several
seconds in the HW default condition. I just recently went through something
similar where I had to redesign a lot of stuff on my own PCB sinc
I have had no luck with any small wireless dongle other than the ASUS N10
dongle. I've been able to keep relatively stable connections with it.
Sometimes prolonged periods of intense activity like upgrading the system can
seem to cause it to go off to la-la land never to be heard from again
On a related note: If my sensors are buffered and gated to sys_resetn am I
safe if the BBB powers down a few ms before the rest? My circuit watches the
3.3V regulator output and when it falls away the power for the entire circuit
is killed as well but it takes 5-9ms for the power controller to
Depends on the I/O line. Almost all of the LCD_whatever pins are used to boot
up. In addition there are a few I/O that are driven by default until the
overlay is applied and the pin is exported for GPIO.
I'm not sure on the specifics but I have always run under the impression that
power appl
You may be better off in the long run coding this to convert the value to
string data, transmit the string and convert back on the other end. No reason
you can't send binary jibberish over the wire but debugging that later on can
be a real bear. If you have tons of floats to send with huge v
A float is just 4 bytes of binary data that is coded to show the decimal point
position and the number before and after the point. The trick is that you have
to tell the C++ compiler that you are not making a stupid mistake and really do
want to treat the float as an array of bytes:
void send_
He's using a Saleae logic analyzer so no way to alter the ground lead. This
isn't ringing, when you see it on a short time-base it's very clearly a period
of time between bytes when the data line is released and begins to rise back up
to the positive rail. It's often too short to trigger a logi
mage from 2013/08/21 with the 3.8.13-bone30
kernel with the new overlay in it.
Any advice or insight is greatly appreciated!
Kyle
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" g
I think I have seen those on my scope during I2C transactions as well. They
look like little shark fins that sometimes get high enough to be seen as a
logic 1. They have no impact on the device as it's just the transition time
between when the master is done transmitting the device address a
On Monday, February 17, 2014 3:03:44 PM UTC-5, c...@isbd.net wrote:
>
> Kyle Koerth > wrote:
> > [-- text/plain, encoding quoted-printable, charset: UTF-8, 52 lines --]
> >
> > I imagine you have found this site http://beagleboard.org/latest-images,
>
>
>
I imagine you have found this site http://beagleboard.org/latest-images,
that is where the official images are. I know that they haven't been
updated recently, but I hear that a Debian version is coming along nicely,
should be out soon.
The kernel in the most recent official image might be out
look at the output from:
# netstat -lan | grep tcp
-> Is the SSH service set to listen on any IP "0.0.0.0:22"?
-> If you note the IP of the wlan0 connection then disconnect the USB cable
can you connect (assuming you are not powering it via USB)?
-> Can you connect on SSH to the eth0 ip wh
Cleaver! As long as you are not controlling power to other things that is
extremely cool.
--
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 recei
I'm working on a PCB now to mate with some software to allow the user to
press a button, which will send a long GPIO signal to the ARM system. A
daemon process monitors that GPIO and does an orderly shutdown when it goes
low. The daemon also sets another GPIO high as it begins to shutdown.
Is that the case now with your Pi implementation? No proper shutdown?
The EMMC is subject to FS corruption from improper shutdown same as any
media. In general I try to keep the FS utilization to under 60 to 70%.
Give the thing lots of room to wear-level, especially with an OS that
likes to
I've had good luck with Arch Linux and the ASUS N10. I just install
wpa_supplicant and from there use the standard netctl profile system and it
will connect up no problem. I gave up on Angstrom a while ago. Same
adapter simply would not run in that and there were so many other issues I
ju
Are you driving any of the pins with a high or low at power on? Every pin
in the LCD_DATA range is used by the bone to select it's boot mode and are
configured on the board to be set at a default value. If you drive those
pins with another value you just altered the boot configuration. You
So after I had a nice PCB all laid out and routed I was looking at some of
the GPIO I was planning to use with a voltmeter and noticed I had a lot of
problems. These problems took the form of some GPIO being pulled up or
down at power-up in opposition to the control signals I was planning.
So after I had a nice PCB all laid out and routed I was looking at some of
the GPIO I was planning to use with a voltmeter and noticed I had a lot of
problems. These problems took the form of some GPIO being pulled up or
down at power-up in opposition to the control signals I was planning.
I checked the MicroCenter retail store in my area and they had 5 in stock.
Certainly not enough for a project but enough for the "I need on to play
with right now" issues.
On Wednesday, January 8, 2014 10:40:48 PM UTC-6, mark.s@gmail.com wrote:
>
> It says MCM Electronics, and MCM is out
I do not believe the kernel drivers support a system running as a slave
device on the bus. To do this you would have to create your own bit-banged
version of an I2C slave using GPIO. You'd have to use memory mapped GPIO
to manage most normal I2C clock speeds. I'm not sure if the I2C hardware
At this point i'd almost be ready to paypal someone if they can provide a
working sample. Now my earlier edits no longer work in the boneblack.dtb
file and prevent the system from booting up at all. I still seem no closer
to understanding how some of the magic numbers in the fragment syntax a
61 matches
Mail list logo
