[beagleboard] Why Beaglebone Black Rev C from RS Components/RS Online are made by or branded as ISO TECH?

[Reese Dum]

Hi

I plan on buying some Beaglebone Black Rev Cs..

But RS Components is my only most convenient source...

I am wondering...
Why Beaglebone Black Rev C from RS Components/RS Online are made by or 
branded as ISO TECH?

http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/7753805/

Are they clones?

Are they official?

Why ISO TECH? Was this an error?

I only know of the Element 14 version of the Beaglebone Black so I am wary 
of buying my BBB rev C from RS, but that is my only source from where I am.

Hopefully Jason or someone else from Beagleboard could clarify this since 
RS is part of their distributor list. Much much appreciated.

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

[beagleboard] Re: Beginner PRU Issue

[foreverska]

Okay so this is weird.   It's been working fine for the past few days.  I 
uploaded code that I was testing and it wasn't responding like I expected 
so I ctl-c out of the program.  I edited the code and ran it again but it 
failed to exit like normal.  So I restarted the BB, modprobed, edited the 
code so all it does is turn on a light and exit.  I run it but the light 
doesn't come on and it doesn't exit.

How is it fine one second and not loading the next?  Is it possible for 
PRUs to be hard hung?  I wouldn't think they could keep code after a reset.

On Sunday, May 11, 2014 3:55:29 PM UTC-5, foreverska wrote:
>
> You have responded to this at a fortuitous time.  I JUST got it working on 
> an example code.
> - I edited the device tree turning on the PRUSS system and turning off the 
> status lights
> - modprobe uio_pruss
> - sudo ./[program name]
> and boom it started blinking just as it should.  Now it doesn't exit 
> properly and I will have to play with the clear_event() to see if that's 
> the root but I'm very happy with it right this second.
>
> On Sunday, May 11, 2014 3:38:36 PM UTC-5, CEB wrote:
>>
>> "It stopped segfaulting when I sudoed the program so I copied in the 
>> whole code.  The compiler complains that there aren't enough parameters for 
>> prussdrv_pru_clear_event.  The header does have two parameters but all 
>> other TI documentation only has one.  If I just throw a zero as the second 
>> parameter it will run but does nothing because who knows what I'm doing. "
>>
>>
>> - show quoted text -
>> In several examples I see:prussdrv_pru_clear_event (PRU_EVTOUT_0, 
>> PRU0_ARM_INTERRUPT);
>>
>> I'm trying to get a feel for this too.  Maybe this will help.
>>
>>
>>
>>

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

Re: [beagleboard] BBB-Debian fails to flash [from master]

[smith . winston . 101]

On Wednesday, May 14, 2014 11:40:23 PM UTC-4, RobertCNelson wrote:
>
> Yeah.. I was debugging blank eMMC's at CircuitCo i ended up breaking 
> everyone else's..
>
> cd /opt/scripts/tools/
> git pull
>
> and you'll get all the fixes from tonight..
>
> It should work, I'll fire up a new build tomorrow and refresh the demo 
> images.. ;)
>

It works.  Fantastic, thanks for the extremely quick response!

-W 

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

Re: [beagleboard] BBB-Debian fails to flash [from master]

[Robert Nelson]

On Wed, May 14, 2014 at 10:34 PM,  wrote:

> Hi Robert,
>
> I built a set of images using the latest image-builder (from the master
> branch), after booting from the SD card, the image fails to flash.  There
> doesn't appear to be a log file, but after running the
> beaglebone-black-eMMC-flasher.sh script with -x, it seems that it's
> failing in the partition_drive() step.  I think it's because /boot/uboot is
> mounted in /etc/fstab to the SD card (mmcblk0p1) and the script is trying
> to umount mmcblk1p1 which isn't actually mounted, which in turn causes
> write_failure() to get called.  Anyway, here's the output (below).
>


Yeah.. I was debugging blank eMMC's at CircuitCo i ended up breaking
everyone else's..

cd /opt/scripts/tools/
git pull

and you'll get all the fixes from tonight..

It should work, I'll fire up a new build tomorrow and refresh the demo
images.. ;)

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB-Debian fails to flash [from master]

[smith . winston . 101]

Hi Robert,

I built a set of images using the latest image-builder (from the master 
branch), after booting from the SD card, the image fails to flash.  There 
doesn't appear to be a log file, but after running the 
beaglebone-black-eMMC-flasher.sh script with -x, it seems that it's failing 
in the partition_drive() step.  I think it's because /boot/uboot is mounted 
in /etc/fstab to the SD card (mmcblk0p1) and the script is trying to umount 
mmcblk1p1 which isn't actually mounted, which in turn causes 
write_failure() to get called.  Anyway, here's the output (below).

-W.

root@beaglebone:/etc/init.d# /bin/bash -x 
/opt/scripts/tools/beaglebone-black-eMMC-flasher.sh
+ grep -q root
+ id
+ unset boot_drive
++ grep /boot/uboot
++ LC_ALL=C
++ lsblk -l
++ awk '{print $1}'
+ boot_drive=mmcblk0p1
+ '[' xmmcblk0p1 = x ']'
+ '[' xmmcblk0p1 = xmmcblk0p1 ']'
+ source=/dev/mmcblk0
+ destination=/dev/mmcblk1
+ '[' xmmcblk0p1 = xmmcblk1p1 ']'
+ check_running_system
+ '[' '!' -f /boot/uboot/uEnv.txt ']'
+ echo -
-
+ echo 'debug copying: [/dev/mmcblk0] -> [/dev/mmcblk1]'
debug copying: [/dev/mmcblk0] -> [/dev/mmcblk1]
+ lsblk
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk1boot0 179:16   0 1M  1 disk 
mmcblk1boot1 179:24   0 1M  1 disk 
mmcblk0  179:00   3.7G  0 disk 
├─mmcblk0p1  179:1096M  0 part /boot/uboot
└─mmcblk0p2  179:20   1.6G  0 part /
mmcblk1  179:80   1.8G  0 disk 
├─mmcblk1p1  179:9096M  0 part 
└─mmcblk1p2  179:10   0   1.7G  0 part 
+ echo -
-
+ '[' '!' -b /dev/mmcblk1 ']'
+ update_boot_files
++ uname -r
+ '[' '!' -f /boot/initrd.img-3.8.13-bone50 ']'
++ uname -r
+ update-initramfs -u -k 3.8.13-bone50
update-initramfs: Generating /boot/initrd.img-3.8.13-bone50
++ uname -r
+ '[' -f /boot/vmlinuz-3.8.13-bone50 ']'
++ uname -r
+ '[' -f /boot/initrd.img-3.8.13-bone50 ']'
++ uname -r
+ cp -v /boot/initrd.img-3.8.13-bone50 /boot/uboot/initrd.img
`/boot/initrd.img-3.8.13-bone50' -> `/boot/uboot/initrd.img'
++ uname -r
+ mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d 
/boot/initrd.img-3.8.13-bone50 /boot/uboot/uInitrd
Image Name:   initramfs
Created:  Thu May 15 03:19:02 2014
Image Type:   ARM Linux RAMDisk Image (uncompressed)
Data Size:2959366 Bytes = 2890.01 kB = 2.82 MB
Load Address: 
Entry Point:  
+ partition_drive
+ flush_cache
+ sync
+ umount_p1
+ '[' -b /dev/mmcblk1p1 ']'
+ echo 'umounting: /dev/mmcblk1p1'
umounting: /dev/mmcblk1p1
+ umount /dev/mmcblk1p1
umount: /dev/mmcblk1p1: not mounted
+ force_umount_p1
+ echo 'Trying to force umount -l of /dev/mmcblk1p1'
Trying to force umount -l of /dev/mmcblk1p1
+ flush_cache
+ sync
+ umount -l /dev/mmcblk1p1
umount: /dev/mmcblk1p1: not mounted
+ write_failure
+ echo 'writing to [/dev/mmcblk1] failed...'
writing to [/dev/mmcblk1] failed...
+ '[' -e /sys/class/leds/beaglebone:green:usr0/trigger ']'
+ echo heartbeat
+ echo heartbeat
+ echo heartbeat
+ echo heartbeat
+ echo -
-
+ flush_cache
+ sync
+ umount /dev/mmcblk1p1
umount: /dev/mmcblk1p1: not mounted
+ true
+ umount /dev/mmcblk1p2
umount: /dev/mmcblk1p2: not mounted
+ true
+ exit

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

Re: [beagleboard] Using GPIO

[Jason Kridner]

On Wed, May 14, 2014 at 11:18 PM, Robert Nelson wrote:

>
>
>
> On Wed, May 14, 2014 at 10:15 PM, Jason Kridner 
> wrote:
>
>>
>>
>>
>> On Wed, May 14, 2014 at 10:51 PM, Charles Steinkuehler <
>> char...@steinkuehler.net> wrote:
>>
>>> On 5/14/2014 9:44 PM, Jason Kridner wrote:
>>> > On Wed, May 14, 2014 at 9:57 PM, Jason Kridner 
>>> wrote:
>>> >>
>>> >>
>>> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakesme
>>>  think that P9-31 isn't requested by cape-universaln, yet the
>>> >> conflict still happens. Leaving the .dts files around might be
>>> helpful.
>>>
>>> Look in: /opt/source/beaglebone-universal-io/
>>>
>>> > I think I found it:
>>> > https://github.com/cdsteinkuehler/beaglebone-universal-io/pull/5
>>>
>>> Thanks Jason!  Merged.
>>>
>>> I always disable the HDMI (with audio) so didn't catch this one.
>>>
>>
>> Still getting the error and trying to track it down.
>>
>
> Rename the file and echo it into the slots later once in userspace. (it
> has the same name as the file built-into the kernel)
>

That did it!

BTW, did you see the pull request on cape-firmware? Are we not going to
encourage cape makers to push their .dts files there? Is there a good
upstream for them that doesn't involve our massive patch tree?


>
> Regards,
>
> --
> Robert Nelson
> http://www.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using GPIO

[Robert Nelson]

On Wed, May 14, 2014 at 10:15 PM, Jason Kridner wrote:

>
>
>
> On Wed, May 14, 2014 at 10:51 PM, Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> On 5/14/2014 9:44 PM, Jason Kridner wrote:
>> > On Wed, May 14, 2014 at 9:57 PM, Jason Kridner 
>> wrote:
>> >>
>> >>
>> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakesme
>>  think that P9-31 isn't requested by cape-universaln, yet the
>> >> conflict still happens. Leaving the .dts files around might be helpful.
>>
>> Look in: /opt/source/beaglebone-universal-io/
>>
>> > I think I found it:
>> > https://github.com/cdsteinkuehler/beaglebone-universal-io/pull/5
>>
>> Thanks Jason!  Merged.
>>
>> I always disable the HDMI (with audio) so didn't catch this one.
>>
>
> Still getting the error and trying to track it down.
>

Rename the file and echo it into the slots later once in userspace. (it has
the same name as the file built-into the kernel)

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using GPIO

[Jason Kridner]

On Wed, May 14, 2014 at 10:51 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 5/14/2014 9:44 PM, Jason Kridner wrote:
> > On Wed, May 14, 2014 at 9:57 PM, Jason Kridner 
> wrote:
> >>
> >>
> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakesme
>  think that P9-31 isn't requested by cape-universaln, yet the
> >> conflict still happens. Leaving the .dts files around might be helpful.
>
> Look in: /opt/source/beaglebone-universal-io/
>
> > I think I found it:
> > https://github.com/cdsteinkuehler/beaglebone-universal-io/pull/5
>
> Thanks Jason!  Merged.
>
> I always disable the HDMI (with audio) so didn't catch this one.
>

Still getting the error and trying to track it down.


>
> Robert:
> This will need to get migrated to the kernel source as well.  Can you
> handle that or should I send a patch (or pull request against ??) ?
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] HC-05 Bluetooth and the beagle bone black ...

[liyaoshi]

As I understand , hciconifg and hcitools will be the basic Bluez test utils

First , make sure your HC-05 module can run with hciconfig

hciconfig -a to see what's output


2014-05-15 1:57 GMT+08:00 Pedro Gonzalez :

>
> Hi there!
>
> Newbie here ... sorry if too basic or already answered somewhere, I can
> not find what I'm looking for. Here is my problem:
>
> I'm trying to connect my BBB to an android device via bluetooth. I'm using
> a HC-05 device and followed the instructions in 
> here.
> It works to some extent. Bluetooth connects to the devide and I can send
> messages to my android device runninga terminal software ( BLUETERM).
> Problem is that I can not read from the device (which BTW is the sole
> purpose of the connection ...).
>
> I'm doing it pretty basic by now, just some echo hello > /dev/ttyO4 and
> cat /dev/ttyO4 The first works, the latter doesn´t. All I'm trying to do by
> now is to make some sort of simple android app that can turn on and off
> some LED on the BBB. Later will go more complex but what I need now is to
> set the foundations to my project.
>
> It would be great if there is a tutorial somewhere on how to open a shell
> over bluetooth from the android device, would be wonderful. I found some on
> how to do it on rasPi but no luck with BBB
>
> Any advice? any tutorials? any help ...??
>
> If I have to be more specific please let me know what you need and I'll
> give the informion. I'm running trhe latest armstrong distribution n a BBB
> rev B.
>
> Thanks for any help!
>
> Pedro
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using GPIO

[Robert Nelson]

On Wed, May 14, 2014 at 9:51 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 5/14/2014 9:44 PM, Jason Kridner wrote:
> > On Wed, May 14, 2014 at 9:57 PM, Jason Kridner 
> wrote:
> >>
> >>
> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakesme
>  think that P9-31 isn't requested by cape-universaln, yet the
> >> conflict still happens. Leaving the .dts files around might be helpful.
>
> Look in: /opt/source/beaglebone-universal-io/
>
> > I think I found it:
> > https://github.com/cdsteinkuehler/beaglebone-universal-io/pull/5
>
> Thanks Jason!  Merged.
>
> I always disable the HDMI (with audio) so didn't catch this one.
>
> Robert:
> This will need to get migrated to the kernel source as well.  Can you
> handle that or should I send a patch (or pull request against ??) ?
>

No worries, i'll pull in that change tomorrow, i found a another half dozen
new cape dtbo's i need to add. ;)

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 625 MHz leak?

[liyaoshi]

625M clock noise maybe from 125M clocksource， or 25M
This might be from ethernet
Do you use GIGA ethernet ?
And
Try to unplug the RJ45 cable


2014-05-15 5:01 GMT+08:00 Gerald Coley :

> OK. Understood. Different test equipment will yield different results. And
> it can be effected by the SW you are running.
>
> Gerald
>
>
> On Wed, May 14, 2014 at 3:59 PM,  wrote:
>
>> It's not something unique to our board--a stock BBB has the same problem.
>>
>>
>> On Wednesday, May 14, 2014 1:41:29 PM UTC-7, Gerald wrote:
>>
>>> Sounds like you may have grounding issues or unterminated pin . Using a
>>> probe should let you be able to determine which side of the chip it is.
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Wed, May 14, 2014 at 3:37 PM,  wrote:
>>>
 It seems to come from right around the processor, but we couldn't
 pinpoint it any more precisely than that, or even to one side of the board
 or other.


 On Wednesday, May 14, 2014 10:56:28 AM UTC-7, Gerald wrote:

> In order to mitigate it you need to figure out where it
> is coming from. A probe test will help in that area. Have you run one?
> Using ferrites on all cables generally helps in these types of issues.
>
> Gerald
>
>
>
> On Wed, May 14, 2014 at 12:01 PM,  wrote:
>
>> We have a BBB-based design currently undergoing FCC testing, and
>> they've found a bit of noise at 625 MHz. Has anyone else encountered 
>> this,
>> or know what it might be, or how to mitigate it?
>>
>> --
>> 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.
>>
>> 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...@googlegroups.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.
>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using GPIO

[Charles Steinkuehler]

On 5/14/2014 9:44 PM, Jason Kridner wrote:
> On Wed, May 14, 2014 at 9:57 PM, Jason Kridner  wrote:
>>
>> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakes
>>  me think that P9-31 isn't requested by cape-universaln, yet the
>> conflict still happens. Leaving the .dts files around might be helpful.

Look in: /opt/source/beaglebone-universal-io/

> I think I found it:
> https://github.com/cdsteinkuehler/beaglebone-universal-io/pull/5

Thanks Jason!  Merged.

I always disable the HDMI (with audio) so didn't catch this one.

Robert:
This will need to get migrated to the kernel source as well.  Can you
handle that or should I send a patch (or pull request against ??) ?

-- 
Charles Steinkuehler
char...@steinkuehler.net

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

Re: [beagleboard] Using GPIO

[Jason Kridner]

On Wed, May 14, 2014 at 9:57 PM, Jason Kridner  wrote:

>
>
> On Wednesday, May 14, 2014 9:04:02 PM UTC-4, RobertCNelson wrote:
>>
>>
>>
>>
>> On Wed, May 14, 2014 at 8:00 PM, Jason Kridner wrote:
>>
>>
>>>
>>> On Thursday, May 1, 2014 2:22:37 PM UTC-4, Charles Steinkuehler wrote:

 On 5/1/2014 1:18 PM, Hannes Hörting wrote:
 > Hi Charles!
 >
 > Sorry for the question, but what did you mean with just load?
 > New BBB and set the first Commando:
 > echo cape-universal > /sys/devices/bone_capemgr.*/slots
 >
 > And there I get Write Error. File exists.
 >
 > Guess without this command I cannot proceed?

 You're probably having an issue with the audio pins if you haven't
 disabled the HDMI cape (leaving the HDMIn without audio to load).

 If HDMI is grabbing the audio pins, you need to load the universaln
 cape
 which leaves the audio pins open:

 echo cape-universaln > /sys/devices/bone_capemgr.*/slots

>>>
>>> With the 4/23 Debian image, I get the following error when running the
>>> above command fresh:
>>>
>>> [ 1184.038531] bone-capemgr bone_capemgr.9: part_number
>>> 'cape-universaln', version 'N/A'
>>> [ 1184.038814] bone-capemgr bone_capemgr.9: slot #9: generic override
>>> [ 1184.038866] bone-capemgr bone_capemgr.9: bone: Using override eeprom
>>> data at slot 9
>>> [ 1184.038918] bone-capemgr bone_capemgr.9: slot #9: 'Override Board
>>> Name,00A0,Override Manuf,cape-universaln'
>>> [ 1184.039193] bone-capemgr bone_capemgr.9: slot #9: Requesting part
>>> number/version based 'cape-universaln-00A0.dtbo
>>> [ 1184.039246] bone-capemgr bone_capemgr.9: slot #9: Requesting firmware
>>> 'cape-universaln-00A0.dtbo' for board-name 'Override Board Name', version
>>> '00A0'
>>> [ 1184.039313] bone-capemgr bone_capemgr.9: slot #9: dtbo
>>> 'cape-universaln-00A0.dtbo' loaded; converting to live tree
>>> [ 1184.159501] bone-capemgr bone_capemgr.9: slot #9: cape-universaln
>>> conflict P9.31 (#5:BB-BONELT-HDMI)
>>>
>>
>> Pin Conflict. ^^
>>
>> Make sure you disable the cape you need to disable before loading that
>> specific cape.
>>
>
> Is there not a version of cape-universal that doesn't use the eMMC or HDMI
> pins?
>
>
> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dtsmakes
>  me think that P9-31 isn't requested by cape-universaln, yet the
> conflict still happens. Leaving the .dts files around might be helpful.
>

I think I found it:
https://github.com/cdsteinkuehler/beaglebone-universal-io/pull/5


>
>
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Board reporting wrong revision number

[Robert Nelson]

On Wed, May 14, 2014 at 9:23 PM, Rohi Zacharia wrote:

> I have a beaglebone black that i just recieved which when i load the the
> support page over usb tether i get "Your board is connected Beaglebone
> Black rev 00A5. However when i check the board it has the AM3358BZCZ100
> processor. Is this some bug in the software or is there another way to make
> sure everything is right?
>

It should be fine. The image came out shortly before the new hardware.  So
new users (like you) should fork bone101 and send jason a patch to fix it.
;)

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Board reporting wrong revision number

[Rohi Zacharia]

I have a beaglebone black that i just recieved which when i load the the 
support page over usb tether i get "Your board is connected Beaglebone 
Black rev 00A5. However when i check the board it has the AM3358BZCZ100 
processor. Is this some bug in the software or is there another way to make 
sure everything is 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using GPIO

[Jason Kridner]

On Wednesday, May 14, 2014 9:04:02 PM UTC-4, RobertCNelson wrote:
>
>
>
>
> On Wed, May 14, 2014 at 8:00 PM, Jason Kridner wrote:
>
>>
>>
>> On Thursday, May 1, 2014 2:22:37 PM UTC-4, Charles Steinkuehler wrote:
>>>
>>> On 5/1/2014 1:18 PM, Hannes Hörting wrote: 
>>> > Hi Charles! 
>>> > 
>>> > Sorry for the question, but what did you mean with just load? 
>>> > New BBB and set the first Commando: 
>>> > echo cape-universal > /sys/devices/bone_capemgr.*/slots 
>>> > 
>>> > And there I get Write Error. File exists. 
>>> > 
>>> > Guess without this command I cannot proceed? 
>>>
>>> You're probably having an issue with the audio pins if you haven't 
>>> disabled the HDMI cape (leaving the HDMIn without audio to load). 
>>>
>>> If HDMI is grabbing the audio pins, you need to load the universaln cape 
>>> which leaves the audio pins open: 
>>>
>>> echo cape-universaln > /sys/devices/bone_capemgr.*/slots 
>>>
>>
>> With the 4/23 Debian image, I get the following error when running the 
>> above command fresh:
>>
>> [ 1184.038531] bone-capemgr bone_capemgr.9: part_number 
>> 'cape-universaln', version 'N/A'
>> [ 1184.038814] bone-capemgr bone_capemgr.9: slot #9: generic override
>> [ 1184.038866] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>> data at slot 9
>> [ 1184.038918] bone-capemgr bone_capemgr.9: slot #9: 'Override Board 
>> Name,00A0,Override Manuf,cape-universaln'
>> [ 1184.039193] bone-capemgr bone_capemgr.9: slot #9: Requesting part 
>> number/version based 'cape-universaln-00A0.dtbo
>> [ 1184.039246] bone-capemgr bone_capemgr.9: slot #9: Requesting firmware 
>> 'cape-universaln-00A0.dtbo' for board-name 'Override Board Name', version 
>> '00A0'
>> [ 1184.039313] bone-capemgr bone_capemgr.9: slot #9: dtbo 
>> 'cape-universaln-00A0.dtbo' loaded; converting to live tree
>> [ 1184.159501] bone-capemgr bone_capemgr.9: slot #9: cape-universaln 
>> conflict P9.31 (#5:BB-BONELT-HDMI)
>>
>
> Pin Conflict. ^^
>
> Make sure you disable the cape you need to disable before loading that 
> specific cape.
>

Is there not a version of cape-universal that doesn't use the eMMC or HDMI 
pins?

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universaln-00A0.dts
 
makes me think that P9-31 isn't requested by cape-universaln, yet the 
conflict still happens. Leaving the .dts files around might be helpful.
 

>
> Regards,
>
> -- 
> Robert Nelson
> http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using GPIO

[Robert Nelson]

On Wed, May 14, 2014 at 8:00 PM, Jason Kridner  wrote:

>
>
> On Thursday, May 1, 2014 2:22:37 PM UTC-4, Charles Steinkuehler wrote:
>>
>> On 5/1/2014 1:18 PM, Hannes Hörting wrote:
>> > Hi Charles!
>> >
>> > Sorry for the question, but what did you mean with just load?
>> > New BBB and set the first Commando:
>> > echo cape-universal > /sys/devices/bone_capemgr.*/slots
>> >
>> > And there I get Write Error. File exists.
>> >
>> > Guess without this command I cannot proceed?
>>
>> You're probably having an issue with the audio pins if you haven't
>> disabled the HDMI cape (leaving the HDMIn without audio to load).
>>
>> If HDMI is grabbing the audio pins, you need to load the universaln cape
>> which leaves the audio pins open:
>>
>> echo cape-universaln > /sys/devices/bone_capemgr.*/slots
>>
>
> With the 4/23 Debian image, I get the following error when running the
> above command fresh:
>
> [ 1184.038531] bone-capemgr bone_capemgr.9: part_number 'cape-universaln',
> version 'N/A'
> [ 1184.038814] bone-capemgr bone_capemgr.9: slot #9: generic override
> [ 1184.038866] bone-capemgr bone_capemgr.9: bone: Using override eeprom
> data at slot 9
> [ 1184.038918] bone-capemgr bone_capemgr.9: slot #9: 'Override Board
> Name,00A0,Override Manuf,cape-universaln'
> [ 1184.039193] bone-capemgr bone_capemgr.9: slot #9: Requesting part
> number/version based 'cape-universaln-00A0.dtbo
> [ 1184.039246] bone-capemgr bone_capemgr.9: slot #9: Requesting firmware
> 'cape-universaln-00A0.dtbo' for board-name 'Override Board Name', version
> '00A0'
> [ 1184.039313] bone-capemgr bone_capemgr.9: slot #9: dtbo
> 'cape-universaln-00A0.dtbo' loaded; converting to live tree
> [ 1184.159501] bone-capemgr bone_capemgr.9: slot #9: cape-universaln
> conflict P9.31 (#5:BB-BONELT-HDMI)
>

Pin Conflict. ^^

Make sure you disable the cape you need to disable before loading that
specific cape.

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Using GPIO

[Jason Kridner]

On Thursday, May 1, 2014 2:22:37 PM UTC-4, Charles Steinkuehler wrote:
>
> On 5/1/2014 1:18 PM, Hannes Hörting wrote: 
> > Hi Charles! 
> > 
> > Sorry for the question, but what did you mean with just load? 
> > New BBB and set the first Commando: 
> > echo cape-universal > /sys/devices/bone_capemgr.*/slots 
> > 
> > And there I get Write Error. File exists. 
> > 
> > Guess without this command I cannot proceed? 
>
> You're probably having an issue with the audio pins if you haven't 
> disabled the HDMI cape (leaving the HDMIn without audio to load). 
>
> If HDMI is grabbing the audio pins, you need to load the universaln cape 
> which leaves the audio pins open: 
>
> echo cape-universaln > /sys/devices/bone_capemgr.*/slots 
>

With the 4/23 Debian image, I get the following error when running the 
above command fresh:

[ 1184.038531] bone-capemgr bone_capemgr.9: part_number 'cape-universaln', 
version 'N/A'
[ 1184.038814] bone-capemgr bone_capemgr.9: slot #9: generic override
[ 1184.038866] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 9
[ 1184.038918] bone-capemgr bone_capemgr.9: slot #9: 'Override Board 
Name,00A0,Override Manuf,cape-universaln'
[ 1184.039193] bone-capemgr bone_capemgr.9: slot #9: Requesting part 
number/version based 'cape-universaln-00A0.dtbo
[ 1184.039246] bone-capemgr bone_capemgr.9: slot #9: Requesting firmware 
'cape-universaln-00A0.dtbo' for board-name 'Override Board Name', version 
'00A0'
[ 1184.039313] bone-capemgr bone_capemgr.9: slot #9: dtbo 
'cape-universaln-00A0.dtbo' loaded; converting to live tree
[ 1184.159501] bone-capemgr bone_capemgr.9: slot #9: cape-universaln 
conflict P9.31 (#5:BB-BONELT-HDMI)
[ 1184.169509] bone-capemgr bone_capemgr.9: slot #9: Failed verification
 

>
> -- 
> Charles Steinkuehler 
> char...@steinkuehler.net 
>

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

Re: [beagleboard] Stuck with applying the device tree overlay file (dtbo) On BeagleBoard-XM, any suggestions how?

[Gilco333]

Thank you, definitely valuable tips! :-)

On Thursday, May 15, 2014 3:14:39 AM UTC+3, RobertCNelson wrote:
>
>
>
>
> On Wed, May 14, 2014 at 7:07 PM, Gilco333 
> > wrote:
>
>> Wow, thank you Robert for the super quick answer :-)
>>
>> A short question before I'll read and delve into more depth about the 
>> subject:
>> I have noticed during the boot process, the beagleboard-xM (rev B) prints 
>> on screen:
>>
>> "reading /dtbs/omap3-beagle-xm-ab.dtb
>> 60695 bytes read in 13 ms (4.5 MiB/s)
>> ## Error: "expansion_args" not defined
>>
>
> That's just an old variable in u-boot for the old "board" file boot. (the 
> buddy=spidev etc crap)
>  
>
>>
>> Kernel image @ 0x8030 [ 0x00 - 0x3e2f38 ]
>> ## Flattened Device Tree blob at 815f
>>Booting using the fdt blob at 0x815f
>>Using Device Tree in place at 815f, end 81601d16
>>
>> Starting kernel .."
>>
>> So I searched for the omap3-beagle-xm-ab.dts (on linux_kernel-3.14.4 
>> source) in order to modify it. but couldn't find it, found only 
>> omap3-beagle-xm.dts 
>> googled and found only this skinny file: omap3-beagle-xm-ab.dts, which 
>> contains:
>>
>
> Yeah, just got merged to mainline a few weeks back.
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-beagle-xm-ab.dts?id=refs/tags/v3.15-rc5
>
>
>> /include/ "omap3-beagle-xm.dts"
>>
>> /* On Rev A/B USBHOST_PWR_EN is active high */
>>
>> &hsusb2_power {
>>
>> enable-active-high;
>>
>> };
>>
>> Is it the correct file? which I should: 
>> 1) modify
>> 2) compile it to dtb 
>> 3) overwrite the exist file in /boot/uboot/dtbs/omap3-beagle-xm-ab.dtb 
>>
>
>
> It's actually way easier to just "decompile" it with dtc, then recompile 
> it again.
>
> dtc -I dtb -O dts omap3-beagle-xm-ab.dtb > omap3-beagle-xm-ab.dts
>
> Regards,
>
> -- 
> Robert Nelson
> http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stuck with applying the device tree overlay file (dtbo) On BeagleBoard-XM, any suggestions how?

[Robert Nelson]

On Wed, May 14, 2014 at 7:07 PM, Gilco333  wrote:

> Wow, thank you Robert for the super quick answer :-)
>
> A short question before I'll read and delve into more depth about the
> subject:
> I have noticed during the boot process, the beagleboard-xM (rev B) prints
> on screen:
>
> "reading /dtbs/omap3-beagle-xm-ab.dtb
> 60695 bytes read in 13 ms (4.5 MiB/s)
> ## Error: "expansion_args" not defined
>

That's just an old variable in u-boot for the old "board" file boot. (the
buddy=spidev etc crap)


>
> Kernel image @ 0x8030 [ 0x00 - 0x3e2f38 ]
> ## Flattened Device Tree blob at 815f
>Booting using the fdt blob at 0x815f
>Using Device Tree in place at 815f, end 81601d16
>
> Starting kernel .."
>
> So I searched for the omap3-beagle-xm-ab.dts (on linux_kernel-3.14.4
> source) in order to modify it. but couldn't find it, found only
> omap3-beagle-xm.dts
> googled and found only this skinny file: omap3-beagle-xm-ab.dts, which
> contains:
>

Yeah, just got merged to mainline a few weeks back.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-beagle-xm-ab.dts?id=refs/tags/v3.15-rc5


> /include/ "omap3-beagle-xm.dts"
>
> /* On Rev A/B USBHOST_PWR_EN is active high */
>
> &hsusb2_power {
>
> enable-active-high;
>
> };
>
> Is it the correct file? which I should:
> 1) modify
> 2) compile it to dtb
> 3) overwrite the exist file in /boot/uboot/dtbs/omap3-beagle-xm-ab.dtb
>


It's actually way easier to just "decompile" it with dtc, then recompile it
again.

dtc -I dtb -O dts omap3-beagle-xm-ab.dtb > omap3-beagle-xm-ab.dts

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stuck with applying the device tree overlay file (dtbo) On BeagleBoard-XM, any suggestions how?

[Gilco333]

Wow, thank you Robert for the super quick answer :-)

A short question before I'll read and delve into more depth about the 
subject:
I have noticed during the boot process, the beagleboard-xM (rev B) prints 
on screen:

"reading /dtbs/omap3-beagle-xm-ab.dtb
60695 bytes read in 13 ms (4.5 MiB/s)
## Error: "expansion_args" not defined
Kernel image @ 0x8030 [ 0x00 - 0x3e2f38 ]
## Flattened Device Tree blob at 815f
   Booting using the fdt blob at 0x815f
   Using Device Tree in place at 815f, end 81601d16

Starting kernel .."

So I searched for the omap3-beagle-xm-ab.dts (on linux_kernel-3.14.4 
source) in order to modify it. but couldn't find it, found only 
omap3-beagle-xm.dts 
googled and found only this skinny file: omap3-beagle-xm-ab.dts, which 
contains:

/include/ "omap3-beagle-xm.dts"

/* On Rev A/B USBHOST_PWR_EN is active high */

&hsusb2_power {

enable-active-high;

};

Is it the correct file? which I should: 
1) modify
2) compile it to dtb 
3) overwrite the exist file in /boot/uboot/dtbs/omap3-beagle-xm-ab.dtb 

Thank you again.

Have a great week!


On Wednesday, May 14, 2014 3:50:14 PM UTC+3, RobertCNelson wrote:
>
> On Tue, May 13, 2014 at 6:41 PM,  > 
> wrote: 
> > 
> > Hi There, 
> > I have recently took my Beagleboard-xM and put on it the Ubuntu 14.04 
> LTS 
> > (3.14.2-armv7-x5), 
> > then I tried to mux PIn3 (GPIO_139), after reading thoroughly the pages 
> from 
> > both the "System Reference Manual"(Page 110) and the "Technical 
> Reference 
> > Manual" of the processor (Pages 2444-2453). 
> > So I wrote the dts file and compiled it via dtc. 
> > 
> > but now I got stuck how do I apply the changes on runtime? 
> > 
> > I saw on the beaglebone there is a slots file (/sys/devices/.../slots) 
> which 
> > was triggering the change, 
> > after we echoed to it the dtbo file. but in my case we are talking about 
> > beagleboard-xM which there is no such kind of file. 
> > can someone elaborate what should I do? 
>
> Modify the base dtb file, the capemgr wasn't ported to the xM. When 
> overlay's hit mainline we will visit this again. 
>
> Regards, 
>
>
> -- 
> Robert Nelson 
> http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone as LAN webserver for a media-heavy site

[sandervocke]

Thanks for replying. I guess you're right - I can never know for sure until 
I try.

Still, if there's anyone out there who's used the Black as a webserver and 
found it to be insufficient, I would be interested to know what it choked 
on for comparison.

On Tuesday, May 13, 2014 6:33:27 AM UTC+12, William Hermans wrote:
>
> The only way you're going to know is if you set it up and test. I am 
> thinking if it can handle your HD video that it should do just fine.
>
>
> On Mon, May 12, 2014 at 4:44 AM, > wrote:
>
>> Hi everyone,
>>
>> I was hoping you could give me some advice on the BeagleBone boards.
>>
>> For a home project, I'm looking for something that can run a webserver 
>> that would only ever serve 1 to 3 clients at a time. The website itself is 
>> a little bit heavy though - basically it will show the client pictures and 
>> videos that are stored in an SQL database and perform some extra functions.
>>
>> I was lucky enough to borrow a BeagleBone Black from a friend, and do a 
>> quick check to serve a MP4 HD video file over LAN (HTML5 video). Seemed to 
>> work OK.
>>
>> Unfortunately I do not have time to set up and try out the entire website 
>> (which also has some php server-side scripting going on, doing queries on 
>> the SQL database, fetching lots of thumbnails to preview media files, etc). 
>> On top of all that, the Bone would be running a (very simple) Python server 
>> application that listens on a socket and forwards HTTP requests to some USB 
>> device connected to it.
>>
>> The video result was encouraging, but I have no clue what to expect 
>> performance-wise from the Bone when it's confronted with all the stuff 
>> listed above. I understand it's hard to say based on this brief 
>> explanation, but I was wondering whether you could do an educated guess: is 
>> this too much for the Beagle boards, or should they be able to handle this 
>> alright?
>>
>> 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...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Quadcopter!

[Jason Kridner]

On Monday, May 12, 2014 8:11:10 PM UTC-4, Mike McDonald wrote:
>
> Hey guys,
>
> A group of Rose-Hulman students have been hard at work this past year 
> building a Beaglebone Quadcopter with these goals in mind:
>
> 1. Low cost ($100-150 w/o Beaglebone)
> 2. Fully open source (Cape, Frame, and all control software) on our 
> Github
> .
> 3. Easy to assembly and repair (we estimate it will take 1-2 hours to 
> assemble and get ready to fly)
> 4. Durable and easy to fly (currently supports USB game controller 
> control, though we initially tested using a USB RC controller, though it's 
> also possible to eventually use a cell phone as a controller) with a 10 
> minute flight time
> 5. Sensor packed: 9-Axis (MPU 9150), Altimeter (BMP 180), Ultrasonic 
> Rangefinder (HC SR04), Battery Gas Gauge (MAX 17044), and CMOS Camera 
> (OV7670).
>
> The Quadcopter is flown via WiFi and Bluetooth (though streaming video 
> doesn't yet work over Bluetooth) from a host computer (you need somewhere 
> to view the streaming video from). Additionally, we're using a Debian image 
> and have added Xenomai for better real time performance. We're also using 
> both PRU's: one for real time motor control and one for the camera. With 
> the quadcopter software running, we've still got 80+% of the CPU free for 
> other processing (OpenCV, etc.).
>
> We're currently using a PID control scheme, but we may be switching to a 
> sweet state variable feedback system (or getting a senior design group next 
> year to do it).
>
> So, we want some feedback from you guys on the following:
>
>1. 
> *Would you buy one of these Quadcopters? *
>
> Absolutely! 

>
>1. 
>2. 
> *Is our price point reasonable? Is this something worth selling ourselves 
>or would this be a good kickstarter project? *
>
> $100 is reasonable. $150 is kinda pushing the limit a bit for me. Looks 
great for experimenting and I think it'd be a good kickstarter. Hopefully 
you build up some good community interest here first and discover the 
killer feature for which everyone needs this. :-)

>
>1. 
>2. *Are there any other features you think are critical (wouldn't buy 
>without it)?*
>
> Having the camera is awesome. I might want an optional GPS and/or 3G 
modem. Can I add one myself? I don't think it is required in the bundle.
 

> If you want to dive deeper into our design:
>
>1. *How does the software look (particularly the PRU to C interface)? 
>Would you be willing to maintain it, or update it to State Variable?*
>
> Looks like the main routine is control_alg. Personally, I kinda like the 
structure of libpruio from what I've seen so far, where there is a C 
library interface provided. I also like the messaging approach of Matt 
Ranostay's PRU lighting code. Do you have any code documentation that would 
make it easier to review? I don't think many people are going to dive into 
your code until they know what problems it solves and how modular it is 
such that they feel they could start using parts of it.

Looks like you have a lot running on the PRU. Do you have a summary? 

>
>1. *How does the PCB look? Are there any flaws you see? Would you want 
>to add or remove any other sensors?*
>
> Layout seems pretty simple and clean. 
Is 
https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/blob/master_rev2/noncode/Board/Quad32brd.png
 
the latest?  All of the versions are a bit confusing for me.
 

>
>1. *How does the mechanical design (Quadcopter frame) look? Is it 
>aesthetically pleasing? Easy to build (if you have a laser cutter, give it 
>a try and let us know)? Easy to fix when broken?*
>
> I have access to a laser cutter at my hackerspace, but I've never used it. 
Do you have simple pictures of the pieces or any hints on where I could 
order some pre-cut pieces like with Shapeways?
 

> Here are some pictures:
>
>
> 
>
>
> 
>
>
> 
>
>
> 
>
> Videos are available on here 
> (and on the 
> github).
>  
> Our best video is probably 
> here,
>  
> as it shows it both flying as well as the streaming video.
>
> If you guys

Re: [beagleboard] Re: Dude, where's my BeagleBone Black?

[Dave Nelson]

Wahoo! I got my order in right away.

Now I can use my Rev B in a permanent project and keep the C as something
to play/learn with.


On Wed, May 14, 2014 at 3:32 PM, David Funk  wrote:

> Be prepared to order just as soon as you get that message and you too can
> be a proud owner!
>
> *Message from Adafruit Industries:*
> Thank you for ordering from Adafruit Industries,
>
> This message was sent to you at the request of Adafruit Industries to
> notify you that the electronic shipment information below has been
> transmitted to UPS.
>
>
>
> On it's way!  Oh yeah!
>
>
>
>
> -david
>
>
>
>
> On Wed, May 14, 2014 at 10:45 AM,  wrote:
>
>> It was out of stock at adafruit this morning but just received a message
>> they were back in stock. I don't know how many for how long.
>>
>
>
>
>
>  --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Quadcopter!

[Mike McDonald]

I just checked G-10 prices on McMaster, and they are a bit steep for what 
we'd want to sell (about $20 for a 1/8"x1'x1' 
sheet) 
(compared to just over ~$1 for the 1'x1' sheet of plywood).

I think we're going to end up with several tiers of quadcopter frame, with 
the base model being wood or acrylic and higher end models using G-10 or 
Carbon (or aluminum, possibly though that's ~30% heavier than G-10).

The quadcopter currently weighs about 400-450 grams, and we're generating 
around 800 grams of thurst, so we could use heavier frames, it just 
degrades performance some.

Lastly, the CAD designs are all out there, so you're free to make one out 
of any material (exotic or otherwise) that you can machine :) Personally 
I'd love to see the titanium quadcopter!

--Mike

On Wednesday, May 14, 2014 5:38:31 PM UTC-4, Mike McDonald wrote:
>
> Skip,
>
> Thanks for the feedback. I forgot to mention above, but we're including a 
> GPS on the Rev 3.2 boards (just got them and will assemble them soon) 
> that's the same as the Adafruit Ultimate 
> GPS. 
> It seemed to be a good combo of power and cost (we can get them in bulk for 
> $15). We haven't incorporated this into the code, but given the nature of 
> OSS, we're taking the Field of Dreams approach ("If you build it they will 
> develop with it"), providing a platform that works and can be expanded upon 
> as more users desire that functionality.
>
> Version 1.0 of the frame was laser cut acrylic, and you're right, it 
> flexed a good bit (which worried us a lot). We also made it out of wood for 
> comparison and got significantly better performance, and slightly less flex 
> (for half the weight). We considered materials like G-10 (actually just 
> making the cape the frame [terrible idea since if it breaks you're screwed 
> and have to replace the most expensive part]) and carbon fiber (expensive 
> and difficult to work with as laser cutters have issues with carbon), and 
> settled on this frame design since it provides the minimum amount of 
> structure necessary to provide what we need at the given cost point. We 
> have also included an extra arm and extra landing plate in case either of 
> these break (possibly just two arms in the future). The design we have also 
> allows for adding longer arms (and more arms) to easily make any geometry 
> multicopter (tri to octo), while a "traditional" frame simply couldn't do 
> that.
>
> As for durability, we're a bunch of college kids, so breaking things is 
> pretty much routine. We've spent a good part of the last month crashing 
> this quadcopter into the ground, the ceiling, walls, ourselves, trees, etc. 
> and seem to be getting pretty good durability from it. We could have made 
> the frame out of a stronger material (G-10, aluminum, etc.), but we 
> actually kinda want the frame to break before anything else on the 
> quadcopter does, since the frame is the cheapest and easiest to repair, 
> we'd rather have it fail than have a strong frame end up transferring force 
> to the cape or the bone. I think the easiest solution to making our frame 
> more durable would be to double up on the arms (put a set on the top and 
> bottom of the main plate, and beef up the supports by where they attach) to 
> get some 3D strength (like the frame you posted). I think we will try a 
> stiffer material (G-10 or similar fiberglass) and see how that goes. I 
> could even see a world where we simply make the base frame and the arms as 
> PCB's and run traces for the motors out to the end of the arms.
>
> Thanks and let me know if you have other thoughts around this,
> --Mike
>
> On Wednesday, May 14, 2014 11:12:24 AM UTC-4, skip wrote:
>>
>> Mike,
>>
>> That is a very interesting project. For ~$250 mark I think it is a 
>> viable kickstarter project. I'd buy one. I like the idea of having the 
>> extra compute power to experiment with OpenCV, sense and avoid systems, 
>> etc. Some things that would be nice to add / change (although these aren't 
>> really deal breakers) are GPS position and altitude hold (perhaps using a 
>> uBlox NEO 6M.) One thing that does concern me is the frame. It looks like 
>> laser cut acrylic. I don't think that material is strong or rigid enough 
>> for a quad frame of that size. I'd look into G10 as an option. This would 
>> increase your cost, but would provide a much better frame. Another option 
>> is to look at some of the cheaper, off the shelf frames available. Flite 
>> Test makes some great kits using mostly wood (and some G10) that are cheap 
>> and possibly more robust. They are also very easy to fix in the event of a 
>> crash. The H quad has the largest payload platform, you can find it here;   
>> http://shop.flitetest.com/multirotors/knuckle-h-quad-370-kit/ I think a 
>> robust, or easily repairable frame is very important considering the 
>> application here. Since this is such a great platfo

Re: [beagleboard] Beaglebone Quadcopter!

[Mike McDonald]

Skip,

Thanks for the feedback. I forgot to mention above, but we're including a 
GPS on the Rev 3.2 boards (just got them and will assemble them soon) 
that's the same as the Adafruit Ultimate 
GPS. 
It seemed to be a good combo of power and cost (we can get them in bulk for 
$15). We haven't incorporated this into the code, but given the nature of 
OSS, we're taking the Field of Dreams approach ("If you build it they will 
develop with it"), providing a platform that works and can be expanded upon 
as more users desire that functionality.

Version 1.0 of the frame was laser cut acrylic, and you're right, it flexed 
a good bit (which worried us a lot). We also made it out of wood for 
comparison and got significantly better performance, and slightly less flex 
(for half the weight). We considered materials like G-10 (actually just 
making the cape the frame [terrible idea since if it breaks you're screwed 
and have to replace the most expensive part]) and carbon fiber (expensive 
and difficult to work with as laser cutters have issues with carbon), and 
settled on this frame design since it provides the minimum amount of 
structure necessary to provide what we need at the given cost point. We 
have also included an extra arm and extra landing plate in case either of 
these break (possibly just two arms in the future). The design we have also 
allows for adding longer arms (and more arms) to easily make any geometry 
multicopter (tri to octo), while a "traditional" frame simply couldn't do 
that.

As for durability, we're a bunch of college kids, so breaking things is 
pretty much routine. We've spent a good part of the last month crashing 
this quadcopter into the ground, the ceiling, walls, ourselves, trees, etc. 
and seem to be getting pretty good durability from it. We could have made 
the frame out of a stronger material (G-10, aluminum, etc.), but we 
actually kinda want the frame to break before anything else on the 
quadcopter does, since the frame is the cheapest and easiest to repair, 
we'd rather have it fail than have a strong frame end up transferring force 
to the cape or the bone. I think the easiest solution to making our frame 
more durable would be to double up on the arms (put a set on the top and 
bottom of the main plate, and beef up the supports by where they attach) to 
get some 3D strength (like the frame you posted). I think we will try a 
stiffer material (G-10 or similar fiberglass) and see how that goes. I 
could even see a world where we simply make the base frame and the arms as 
PCB's and run traces for the motors out to the end of the arms.

Thanks and let me know if you have other thoughts around this,
--Mike

On Wednesday, May 14, 2014 11:12:24 AM UTC-4, skip wrote:
>
> Mike,
>
> That is a very interesting project. For ~$250 mark I think it is a 
> viable kickstarter project. I'd buy one. I like the idea of having the 
> extra compute power to experiment with OpenCV, sense and avoid systems, 
> etc. Some things that would be nice to add / change (although these aren't 
> really deal breakers) are GPS position and altitude hold (perhaps using a 
> uBlox NEO 6M.) One thing that does concern me is the frame. It looks like 
> laser cut acrylic. I don't think that material is strong or rigid enough 
> for a quad frame of that size. I'd look into G10 as an option. This would 
> increase your cost, but would provide a much better frame. Another option 
> is to look at some of the cheaper, off the shelf frames available. Flite 
> Test makes some great kits using mostly wood (and some G10) that are cheap 
> and possibly more robust. They are also very easy to fix in the event of a 
> crash. The H quad has the largest payload platform, you can find it here;   
> http://shop.flitetest.com/multirotors/knuckle-h-quad-370-kit/ I think a 
> robust, or easily repairable frame is very important considering the 
> application here. Since this is such a great platform for experimenting 
> with autonomous or semi-autonomous flight there are most certainly going to 
> be crashes. Having a frame that will survive or be easily repaired would be 
> a must.
>
> Thanks,
> SKip
>
> On May 12, 2014, at 8:11 PM, Mike McDonald wrote:
>
> Hey guys,
>
> A group of Rose-Hulman students have been hard at work this past year 
> building a Beaglebone Quadcopter with these goals in mind:
>
> 1. Low cost ($100-150 w/o Beaglebone)
> 2. Fully open source (Cape, Frame, and all control software) on our 
> Github
> .
> 3. Easy to assembly and repair (we estimate it will take 1-2 hours to 
> assemble and get ready to fly)
> 4. Durable and easy to fly (currently supports USB game controller 
> control, though we initially tested using a USB RC controller, though it's 
> also possible to eventually use a cell phone as a controller) with a 10 
> minute flight time
> 5. Sensor packed: 9-Axis 

Re: [beagleboard] PRU prussdrv_open gives Bus error, Custom PREEMPT_RT Linux kernel 3.14

[Sungjin Chun]

In my case, I solved similar problem with enabling clock and power domain 
configuration, refer

https://github.com/chunsj/nxctrl/blob/master/NXCTRL.c#L223

Sent from my iPad

> On May 15, 2014, at 5:36 AM, henrikff...@gmail.com wrote:
> 
> 
> Hi,
> I'm currently running a 3.14 PREEMPT_RT build based of Robert C Nelsons 
> repository. I've got GPIO and uart up and running. And now my attention has 
> turned to the PRU. The 3.14 build does not have a capemanager so i setup my 
> device trees at build.
> I based my PRU work of the old PRU patch: 
> https://github.com/beagleboard/kernel/blob/3.12/patches/pru/0001-These-are-the-patches-necessary-for-enabling-the-PRU.patchh
> Now, booting gives me no error messages from uio_pruss. And uio0-7 appears in 
> /dev/. However, when running a test project (which ran perfectly fine under 
> non-modified 3.8 kernel) prussdrv_open() failes: Bus error
> 
> This happens every time prussdrv_open tries to read from its memory mapped 
> areas like:
> if (pruss_io[(AM18XX_INTC_PHYS_BASE - AM18XX_DATARAM0_PHYS_BASE) >> 2]
> == AM18XX_PRUSS_INTC_REV)
> 
> 
> Now the pruss is defined in am33xx.dtsi:
> 
> pruss: pruss@4a30 {
> compatible = "ti,pruss-v2";
> ti,hwmods = "pruss";
> ti,deassert-hard-reset = "pruss", "pruss";
> reg = <0x4a30 0x08>;
> ti,pintc-offset = <0x2>;
> interrupt-parent = <&intc>;
> status = "okay";
> interrupts = <20 21 22 23 24 25 26 27>;
> };
> 
> And one of my dtsi include files to the am335x-boneblack.dts enables it:
> 
>&pruss{  
>   status = "okay"; 
>   pinctrl-names = "default";
>   pinctrl-0 = <&pru_gpio_pins>; 
>};
> 
> I then modprobe uio_pruss before running the test application.
> 
> I have little clue how to fix this, so any pointers or help would be much 
> appreciated:)
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Quadcopter!

[Mike McDonald]

The project is feature complete as of now, and everything is available on 
the Github:

Were we to sell a product, it would likely be 6 or so months before we 
would begin shipping everything, as we would have to get parts pipelines 
set up, production going, and good fulfillment going. That being said, if 
you wanted to, we're confident you could build your own (assuming you have 
access to a laser cutter [or a steady hand] and a way to make PCB's 
[probably a low volume quick turn place like Advanced Circuits or Silver 
Circuits {in the US at least, not sure what's best for where you are}]).

Frame CAD 
Designs: 
https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/tree/master_rev2/noncode/CAD

PCB 
Design: 
https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/tree/master_rev2/noncode/Board
 

Software: 
https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/tree/master_rev2/code

We will be publishing a .img file with our custom Debian image as well, so 
it can be easily flashed.

We don't know what our plans are for shipping (especially overseas, we may 
have issues with US Export laws concerning shipping quadcopters with GPS 
capability 
[ITAR
]).

Thanks for your interest!

--Mike

On Wednesday, May 14, 2014 9:41:18 AM UTC-4, Programmer wrote:
>
>
>  Hi,
>
> Your project certain looks  really interesting .
> Yes, I would be interested in buying one if the proce doesn't exceed 
> $250,-- but depending on the features
> this would not be my limit.
>
> Are you goinh to publich the diagrams and Software?
>
> Can you post/email regularly.?
>
> When do you expect a compeletion date? 
> Postage to the EU a problem?
>
> All the best wishes for your project
>
> NT
>

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

[beagleboard] PRU prussdrv_open gives Bus error, Custom PREEMPT_RT Linux kernel 3.14

[henrikffoss]

Hi,
I'm currently running a 3.14 PREEMPT_RT build based of Robert C Nelsons 
repository. I've got GPIO and uart up and running. And now my attention has 
turned to the PRU. The 3.14 build does not have a capemanager so i setup my 
device trees at build.
I based my PRU work of the old PRU patch: 
https://github.com/beagleboard/kernel/blob/3.12/patches/pru/0001-These-are-the-patches-necessary-for-enabling-the-PRU.patchh
Now, booting gives me no error messages from uio_pruss. And uio0-7 appears 
in /dev/. However, when running a test project (which ran perfectly fine 
under non-modified 3.8 kernel) prussdrv_open() failes: Bus error

This happens every time prussdrv_open tries to read from its memory mapped 
areas like:

if (pruss_io[(AM18XX_INTC_PHYS_BASE - AM18XX_DATARAM0_PHYS_BASE) >> 2]
== AM18XX_PRUSS_INTC_REV)



Now the pruss is defined in am33xx.dtsi:

pruss: pruss@4a30 {
compatible = "ti,pruss-v2";
ti,hwmods = "pruss";
ti,deassert-hard-reset = "pruss", "pruss";
reg = <0x4a30 0x08>;
ti,pintc-offset = <0x2>;
interrupt-parent = <&intc>;
status = "okay";
interrupts = <20 21 22 23 24 25 26 27>;
};

And one of my dtsi include files to the am335x-boneblack.dts enables it:

   &pruss{  
  status = "okay"; 
  pinctrl-names = "default";
  pinctrl-0 = <&pru_gpio_pins>; 
   };

I then modprobe uio_pruss before running the test application.

I have little clue how to fix this, so any pointers or help would be much 
appreciated:)

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

Re: [beagleboard] Beaglebone Quadcopter!

[Mike McDonald]

A traditional radio transmitter can be used via the USB (similar to how RC 
Simulators use them). As for a receiver... We currently have control and 
video streaming over WiFi (or Bluetooth), so you'd have to implement a two 
radio solution. A WiFi or Bluetooth USB dongle would be included, or could 
be provided (would be cheaper to provide your own).

A note on pricing: the quadcopter parts kit (everything except the 
BeagleBoard) would be sold for around $100. This doesn't include a 
controller (to keep the cost down, we can't). The thought on this was that 
most people have access to a USB controller of some sort (Xbox, etc.).

--Mike

On Tuesday, May 13, 2014 1:33:38 PM UTC-4, Dave Nelson wrote:
>
> I like it and for $100 I would buy one immediately, $150 would make me 
> think twice. It would also be fun for me as a builder to add a traditional 
> radio remote to it also.
>
>
> On Tue, May 13, 2014 at 11:24 AM, Razvan Margineanu Andrei <
> razvan.m...@gmail.com > wrote:
>
>> Your project looks excelent and it is by far the coolest project 
>> involving the BBB. I have a few BBB laying around from an old project 
>> (about 50 :) ). Might consider trying something like this. Great work guys 
>> really great 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...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 625 MHz leak?

[Gerald Coley]

OK. Understood. Different test equipment will yield different results. And
it can be effected by the SW you are running.

Gerald


On Wed, May 14, 2014 at 3:59 PM,  wrote:

> It's not something unique to our board--a stock BBB has the same problem.
>
>
> On Wednesday, May 14, 2014 1:41:29 PM UTC-7, Gerald wrote:
>
>> Sounds like you may have grounding issues or unterminated pin . Using a
>> probe should let you be able to determine which side of the chip it is.
>>
>> Gerald
>>
>>
>>
>> On Wed, May 14, 2014 at 3:37 PM,  wrote:
>>
>>> It seems to come from right around the processor, but we couldn't
>>> pinpoint it any more precisely than that, or even to one side of the board
>>> or other.
>>>
>>>
>>> On Wednesday, May 14, 2014 10:56:28 AM UTC-7, Gerald wrote:
>>>
 In order to mitigate it you need to figure out where it is coming from.
 A probe test will help in that area. Have you run one? Using ferrites on
 all cables generally helps in these types of issues.

 Gerald



 On Wed, May 14, 2014 at 12:01 PM,  wrote:

> We have a BBB-based design currently undergoing FCC testing, and
> they've found a bit of noise at 625 MHz. Has anyone else encountered this,
> or know what it might be, or how to mitigate it?
>
> --
> 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.
>
> 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...@googlegroups.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 625 MHz leak?

[lee]

It's not something unique to our board--a stock BBB has the same problem.


On Wednesday, May 14, 2014 1:41:29 PM UTC-7, Gerald wrote:
>
> Sounds like you may have grounding issues or unterminated pin . Using a 
> probe should let you be able to determine which side of the chip it is.
>
> Gerald
>
>
>
> On Wed, May 14, 2014 at 3:37 PM, > wrote:
>
>> It seems to come from right around the processor, but we couldn't 
>> pinpoint it any more precisely than that, or even to one side of the board 
>> or other.
>>
>>
>> On Wednesday, May 14, 2014 10:56:28 AM UTC-7, Gerald wrote:
>>
>>> In order to mitigate it you need to figure out where it is coming from. 
>>> A probe test will help in that area. Have you run one? Using ferrites on 
>>> all cables generally helps in these types of issues.
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Wed, May 14, 2014 at 12:01 PM,  wrote:
>>>
 We have a BBB-based design currently undergoing FCC testing, and 
 they've found a bit of noise at 625 MHz. Has anyone else encountered this, 
 or know what it might be, or how to mitigate it?
  
 -- 
 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.

 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...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Audio Cape Rev B1

[Aaron Clarke]

Thanks for the link, I quickly wrote down the steps I took to get the cape 
working on my blog in case it's useful to anyone else.

http://blog.embeddedcoding.com/2014/05/getting-started-with-audio-cape.html

I haven't tried to dynamically load the overlay again, but that isn't 
necessary for what I'm doing.

Best regards,

Aaron

On Wednesday, May 14, 2014 3:31:19 PM UTC-4, dande...@gmail.com wrote:
>
> info on this can be found here:
>
> https://groups.google.com/d/msg/beagleboard/81TsiNp4Bok/FZKXz9GHpHoJ
>
> the wiki page will be updated shortly with more details...
>
> Dave
>
>
> On Wednesday, May 14, 2014 8:18:40 AM UTC-5, Aaron Clarke wrote:
>>
>> I'm looking for some help getting the audio cape rev. B1 running on 
>> debian.  I'm not able to load the overlay, I suspect I'm using the wrong 
>> kernel or need to compile the firmware into the kernel.
>>
>> Circuitco provided an overlay, I have the latest image I can 
>> find, BBB-eMMC-flasher-debian-7.4-2014-04-23-2gb.img
>>
>> I downloaded the overlay here:
>> http://elinux.org/CircuitCo:Audio_Cape_RevB
>>
>> From above link: 
>> "The device tree overlay is available at the bottom of this page. ... The 
>> current Debian images have the required patches and will play audio 
>> normally."
>>
>> I compiled the overlay on the board with this command
>> #dtc -o dtb -o BB-BONE-AUDI-02-00A0.dtbo -b 0 -@ BB-BONE-AUDI-02-00A0.dts 
>> and put it in /lib/firmware
>>
>> root@beaglebone:~# echo BB-BONE-AUDI-02 > 
>> /sys/devices/bone_capemgr*/slots 
>> -bash: echo: write error: Invalid argument
>>
>> dmesg output:
>> [  290.610210] bone-capemgr bone_capemgr.9: part_number 
>> 'BB-BONE-AUDI-02', version 'N/A'
>> [  290.612723] bone-capemgr bone_capemgr.9: slot #7: generic override
>> [  290.612784] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
>> data at slot 7
>> [  290.612836] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
>> Name,00A0,Override Manuf,BB-BONE-AUDI-02'
>> [  290.613099] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
>> number/version based 'BB-BONE-AUDI-02-00A0.dtbo
>> [  290.613153] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
>> 'BB-BONE-AUDI-02-00A0.dtbo' for board-name 'Override Board Name', version 
>> '00A0'
>> [  290.617371] bone-capemgr bone_capemgr.9: slot #7: dtbo 
>> 'BB-BONE-AUDI-02-00A0.dtbo' loaded; converting to live tree
>> [  290.617415] Invalid device tree blob header
>> [  290.622050] bone-capemgr bone_capemgr.9: slot #7: Failed to unflatten
>>
>> I tried to disable HDMI but that didn't help.
>>
>> This blog post mentions a possible bug that makes it necessary compile a 
>> kernel or change a setting to get loadable overlays.  Is that the case here?
>>
>> http://hipstercircuits.com/enable-device-tree-overlay-on-startup-on-beaglebone-black/
>>
>> Thanks,
>>
>> Aaron
>>
>

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

Re: [beagleboard] 625 MHz leak?

[Gerald Coley]

Sounds like you may have grounding issues or unterminated pin . Using a
probe should let you be able to determine which side of the chip it is.

Gerald



On Wed, May 14, 2014 at 3:37 PM,  wrote:

> It seems to come from right around the processor, but we couldn't pinpoint
> it any more precisely than that, or even to one side of the board or other.
>
>
> On Wednesday, May 14, 2014 10:56:28 AM UTC-7, Gerald wrote:
>
>> In order to mitigate it you need to figure out where it is coming from. A
>> probe test will help in that area. Have you run one? Using ferrites on all
>> cables generally helps in these types of issues.
>>
>> Gerald
>>
>>
>>
>> On Wed, May 14, 2014 at 12:01 PM,  wrote:
>>
>>> We have a BBB-based design currently undergoing FCC testing, and they've
>>> found a bit of noise at 625 MHz. Has anyone else encountered this, or know
>>> what it might be, or how to mitigate it?
>>>
>>> --
>>> 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.
>>>
>>> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] 625 MHz leak?

[lee]

It seems to come from right around the processor, but we couldn't pinpoint 
it any more precisely than that, or even to one side of the board or other.

On Wednesday, May 14, 2014 10:56:28 AM UTC-7, Gerald wrote:
>
> In order to mitigate it you need to figure out where it is coming from. A 
> probe test will help in that area. Have you run one? Using ferrites on all 
> cables generally helps in these types of issues.
>
> Gerald
>
>
>
> On Wed, May 14, 2014 at 12:01 PM, > wrote:
>
>> We have a BBB-based design currently undergoing FCC testing, and they've 
>> found a bit of noise at 625 MHz. Has anyone else encountered this, or know 
>> what it might be, or how to mitigate it?
>>  
>> -- 
>> 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Where to Find BBB Training?

[jmelson]

On Wednesday, May 14, 2014 11:41:21 AM UTC-5, Nathan wrote:
>
> Yea, I think we'd prefer to rewrite everything rather than mapping. 
>
> We'll probably just stick with Angstrom.  Or do you have a better 
> suggestion there? 
>
>
> Angstrom is being phased out, in favor of Robert Nelson's
Debian-based  kernel.  This is what is now shipping with all
new Beagle Bones.  A VERY easy way to get started with this
is the machinekit package.  it was aimed at a specific use
for the board, with a specific package, LinuxCNC, a motion
control system.  But, you get the R Nelson kernel with Xenomai
installed, and a very simple way to build it to a micro SD
card.  I've done a couple of these when I found Angstrom to
not have the necessary libraries/includes I needed.

Jon

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

Re: [beagleboard] Audio Cape Rev B1

[Aaron Clarke]

Thanks, I built and tested it and working fine.

Aaron

On Wednesday, May 14, 2014 10:05:13 AM UTC-4, RobertCNelson wrote:
>
> On Wed, May 14, 2014 at 8:18 AM, Aaron Clarke 
> > 
> wrote: 
> > I'm looking for some help getting the audio cape rev. B1 running on 
> debian. 
> > I'm not able to load the overlay, I suspect I'm using the wrong kernel 
> or 
> > need to compile the firmware into the kernel. 
> > 
> > Circuitco provided an overlay, I have the latest image I can find, 
> > BBB-eMMC-flasher-debian-7.4-2014-04-23-2gb.img 
> > 
> > I downloaded the overlay here: 
> > http://elinux.org/CircuitCo:Audio_Cape_RevB 
> > 
> > From above link: 
> > "The device tree overlay is available at the bottom of this page. ... 
> The 
> > current Debian images have the required patches and will play audio 
> > normally." 
> > 
> > I compiled the overlay on the board with this command 
> > #dtc -o dtb -o BB-BONE-AUDI-02-00A0.dtbo -b 0 -@ 
> BB-BONE-AUDI-02-00A0.dts 
> > and put it in /lib/firmware 
> > 
> > root@beaglebone:~# echo BB-BONE-AUDI-02 > 
> /sys/devices/bone_capemgr*/slots 
> > -bash: echo: write error: Invalid argument 
> > 
> > dmesg output: 
> > [  290.610210] bone-capemgr bone_capemgr.9: part_number 
> 'BB-BONE-AUDI-02', 
> > version 'N/A' 
> > [  290.612723] bone-capemgr bone_capemgr.9: slot #7: generic override 
> > [  290.612784] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data 
> > at slot 7 
> > [  290.612836] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
> > Name,00A0,Override Manuf,BB-BONE-AUDI-02' 
> > [  290.613099] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
> > number/version based 'BB-BONE-AUDI-02-00A0.dtbo 
> > [  290.613153] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
> > 'BB-BONE-AUDI-02-00A0.dtbo' for board-name 'Override Board Name', 
> version 
> > '00A0' 
> > [  290.617371] bone-capemgr bone_capemgr.9: slot #7: dtbo 
> > 'BB-BONE-AUDI-02-00A0.dtbo' loaded; converting to live tree 
> > [  290.617415] Invalid device tree blob header 
> > [  290.622050] bone-capemgr bone_capemgr.9: slot #7: Failed to unflatten 
> > 
> > I tried to disable HDMI but that didn't help. 
> > 
>
> Odd, i missed that one.. 
>
> This should fix it going forward. 
>
>
> https://github.com/RobertCNelson/linux-dev/commit/d15af8d70b402f6415dbaaf1319819e91fac1951
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Eth0 config on BBB (default Angstrom image 2013.09.04)

[Chriskner]

Cody,

>From your linked page I followed:
 root@beaglebone:~# ifconfig eth0 192.168.0.50 netmask 255.255.255.0 up
and it seems to work fine.

root@beaglebone:~# ifconfig 
eth0  Link encap:Ethernet  HWaddr 1C:BA:8C:98:51:96
  inet addr:192.168.0.50  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::1eba:8cff:fe98:5196/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:440 errors:0 dropped:0 overruns:0 frame:0
  TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:194321 (189.7 KiB)  TX bytes:13314 (13.0 KiB)
  Interrupt:56

   

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:716 errors:0 dropped:0 overruns:0 frame:0
  TX packets:716 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:50064 (48.8 KiB)  TX bytes:50064 (48.8 KiB)

   

usb0  Link encap:Ethernet  HWaddr EE:50:BC:2B:38:79
  inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:365684 errors:0 dropped:0 overruns:0 frame:0
  TX packets:29997 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:177609506 (169.3 MiB)  TX bytes:5316659 (5.0 MiB)

I can now now ssh via eth0 and usb.

Thanks!

-Chris


On Wednesday, May 14, 2014 3:25:42 PM UTC-4, cody wrote:
>
> This may help
>
> http://www.cyberciti.biz/tips/howto-ubuntu-linux-convert-dhcp-network-configuration-to-static-ip-configuration.html
>
>

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

[beagleboard] Re: Audio Cape Rev B1

[danders . dev]

info on this can be found here:

https://groups.google.com/d/msg/beagleboard/81TsiNp4Bok/FZKXz9GHpHoJ

the wiki page will be updated shortly with more details...

Dave


On Wednesday, May 14, 2014 8:18:40 AM UTC-5, Aaron Clarke wrote:
>
> I'm looking for some help getting the audio cape rev. B1 running on 
> debian.  I'm not able to load the overlay, I suspect I'm using the wrong 
> kernel or need to compile the firmware into the kernel.
>
> Circuitco provided an overlay, I have the latest image I can 
> find, BBB-eMMC-flasher-debian-7.4-2014-04-23-2gb.img
>
> I downloaded the overlay here:
> http://elinux.org/CircuitCo:Audio_Cape_RevB
>
> From above link: 
> "The device tree overlay is available at the bottom of this page. ... The 
> current Debian images have the required patches and will play audio 
> normally."
>
> I compiled the overlay on the board with this command
> #dtc -o dtb -o BB-BONE-AUDI-02-00A0.dtbo -b 0 -@ BB-BONE-AUDI-02-00A0.dts 
> and put it in /lib/firmware
>
> root@beaglebone:~# echo BB-BONE-AUDI-02 > /sys/devices/bone_capemgr*/slots 
> -bash: echo: write error: Invalid argument
>
> dmesg output:
> [  290.610210] bone-capemgr bone_capemgr.9: part_number 'BB-BONE-AUDI-02', 
> version 'N/A'
> [  290.612723] bone-capemgr bone_capemgr.9: slot #7: generic override
> [  290.612784] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 7
> [  290.612836] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
> Name,00A0,Override Manuf,BB-BONE-AUDI-02'
> [  290.613099] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
> number/version based 'BB-BONE-AUDI-02-00A0.dtbo
> [  290.613153] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
> 'BB-BONE-AUDI-02-00A0.dtbo' for board-name 'Override Board Name', version 
> '00A0'
> [  290.617371] bone-capemgr bone_capemgr.9: slot #7: dtbo 
> 'BB-BONE-AUDI-02-00A0.dtbo' loaded; converting to live tree
> [  290.617415] Invalid device tree blob header
> [  290.622050] bone-capemgr bone_capemgr.9: slot #7: Failed to unflatten
>
> I tried to disable HDMI but that didn't help.
>
> This blog post mentions a possible bug that makes it necessary compile a 
> kernel or change a setting to get loadable overlays.  Is that the case here?
>
> http://hipstercircuits.com/enable-device-tree-overlay-on-startup-on-beaglebone-black/
>
> Thanks,
>
> Aaron
>

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

Re: [beagleboard] Re: Dude, where's my BeagleBone Black?

[David Funk]

Be prepared to order just as soon as you get that message and you too can
be a proud owner!

*Message from Adafruit Industries:*
Thank you for ordering from Adafruit Industries,

This message was sent to you at the request of Adafruit Industries to
notify you that the electronic shipment information below has been
transmitted to UPS.



On it's way!  Oh yeah!




-david




On Wed, May 14, 2014 at 10:45 AM,  wrote:

> It was out of stock at adafruit this morning but just received a message
> they were back in stock. I don't know how many for how long.
>

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

Re: [beagleboard] Eth0 config on BBB (default Angstrom image 2013.09.04)

[Cody Lacey]

This may help
http://www.cyberciti.biz/tips/howto-ubuntu-linux-convert-dhcp-network-configuration-to-static-ip-configuration.html


On Wed, May 14, 2014 at 10:30 AM, Chriskner  wrote:

> Hi all,
>
> I searched without success for an explanation on how to configure eth0 on
> the BBB Angstrom for a static IP (ultimately from a python script - but
> that's later).
>
> Could somebody share a link on how to do this?
>
> I hope to configure eth0 for something like:
> IP: 192.168.0.50
> mask: 255.255.255.0
>
> ...while preserving the USB-eth configuration (which has the default
> settings).
>
> If this is difficult, is this a good reason to switch to Debian?
>
> Regards,
>
> Chris
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB SPI//ADXL375

[José Luis Redrejo]

2014-05-14 14:49 GMT+02:00 Stuart Reynard :
> Hi Jose,
>
> I finished this project a couple of weeks ago.
>
> I wanted to thank you for getting back to me with such helpful information,
> and I also wanted to follow up with my solution to the SPI problem (for
> future users).
>

Great

> I ended up using a different driver file for SPI0 than the one provided by
> Adafruit:
>
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>
> Guide for adding SPI driver:
>
> http://stackoverflow.com/questions/21276090/beaglebone-black-enable-spi-interface
>

I'm not using adafruit library anymore. It doesn't work with newest
kernels, so I had to use another one.

> For me, the easiest method for verification was to read the DEVID register
> on the accelerometer.
>
> #python code:
> print spi.xfer2([0x80,0x00])
>
> This prints a list of 2 bytes. With how I understand SPI to work, the second
> byte in the printed list should always be the DEVID. The first byte may or
> may not be the DEVID. This is just one of the nuances of the data flow of
> SPI.


I think it's not a spi fault but a combination of spi and the way
Analog Devices set it up .

Thanks for your advices and confirmation.

José L.


>
> -Stuart
>
>
>
>
> On Sunday, March 30, 2014 3:43:07 PM UTC-4, José Luis Redrejo wrote:
>>
>> Hello Stuart, I've been using BBB to communicate with another Analog
>> Devices device (ADE7753) , and I can confirm you that it works.
>> Have you tried to do a loopback test before connecting the ADXL275?
>> Just use a wire in the BBB to join DI and DO in P9, and run this
>> program:
>>
>>
>> from Adafruit_BBIO.SPI import SPI
>>
>> spi = SPI(0,0)
>> spi.mode=2
>>
>> spi.msh=200
>> spi.open(0,0)
>>
>> print spi.xfer2([32, 11, 110, 22, 220])
>> spi.close()
>>
>> You should see 32,11,110,22,220 in your terminal as it's returned by
>> the spi instruction.
>>
>> You don't need
>> spi.cshigh = low
>> because that's its default value.
>>
>> If the loopback test works, then you can try with the device. I can
>> confirm you that using ADE7753 and adafruit python library I have need
>> some time to get it working, until I found out the trick.
>>
>> Regards.
>> José L.
>>
>>
>>
>> 2014-03-30 18:10 GMT+02:00 Stuart Reynard :
>> > I am working on a design project involving a BeagleBone Black and an
>> > ADXL375
>> > Accelerometer.
>> >
>> > Per the data sheet (attached), in order to enable the maximum sampling
>> > rate
>> > of the ADXL375, I need my BBB to communicate with the ADXL375 over SPI
>> > (I2C
>> > is not fast enough for this).
>> >
>> > I have used the Adafruit library for I2C just to test the functionality
>> > of
>> > the ADXL375, and I can confirm that the accel. does in fact work.
>> > However, I
>> > am unsure of how to even perform a simple read of the ADXL375 DEVID
>> > register
>> > using SPI. I have included my steps for how I think a read should be
>> > performed, but I suspect that this process is incorrect as I get no
>> > output.
>> >
>> > I am using the Adafruit BBIO library which I understand is just a python
>> > wrapper for the file spimodule.c. All of this is available here:
>> >
>> > https://github.com/adafruit/adafruit-beaglebone-io-python/
>> >
>> > Based on that code, I am not sure if I will need to hold CS low using
>> > one of
>> > the methods/variables of an SPI object or if the
>> > writebytes()/readbytes()
>> > methods take care of this for me. In other words, I don't know if I
>> > should
>> > be doing something like
>> >
>> > spi.cshigh = low
>> > spi.writebytes([list])
>> > spi.readbytes(numBytes)
>> >
>> > OR if I can just do
>> >
>> > spi.writebytes([list])
>> > spi.readbytes(numBytes)
>> >
>> > Process for reading from SPI (from python terminal):
>> >
>> > from Adafruit_BBIO.SPI import SPI
>> >
>> > #using SPI bus 0 on P9 of BBB, assuming i'm using dev0, not really sure
>> > how
>> > to determine this, but I have no other peripherals connected
>> > spi = SPI(0,0)
>> >
>> > #set desired frequency, 2MHz
>> > spi.msh = 200
>> >
>> > #per the ADXL375 datasheet, when performing a read, need to send a byte
>> > where bits 0-5 are address bits (DEVID register is 0x0), bit 6 is a
>> > multiple
>> > bytes bit (for reading/writing multiple bytes), and bit 7 is a
>> > read/write
>> > bit where read is '1' and write is '0'
>> >
>> > #so I use 0b1000 or 0x80 and call writebytes
>> > spi.writebytes([0x80])
>> >
>> > From here I receive no output, even if I do spi.readbytes(1), I get [0]
>> > back.
>> >
>> > I have a pretty good understanding of Linux, Python, C, and the concept
>> > of
>> > SPI seems simple enough, but this is my first experience with a BBB. I
>> > feel
>> > like I am missing something simple like setting CS low, which I don't
>> > think
>> > is very clearly documented in the attributes for the SPI library.
>> >
>> > Here is some info about my BBB:
>> > lsb_release -a
>> > Distributor ID: Angstrom
>> > Description: Angstrom GNU/Linux v2012.12 (Core edition)
>> > Release: v2012.12
>> > Cod

[beagleboard] Re: Dude, where's my BeagleBone Black?

[armstrong . james]

It was out of stock at adafruit this morning but just received a message 
they were back in stock. I don't know how many for how long.

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

[beagleboard] Re: Where to Find BBB Training?

[Nathan]

Yea, I think we'd prefer to rewrite everything rather than mapping.

We'll probably just stick with Angstrom.  Or do you have a better
suggestion there?

As far as real time requirements go, we do have some.  The goal is to
use the real time units on the BBB to offset most of these
requirements.  They're mainly machine control routines that can be
easily handled by the RTUs.

On 5/5/14, robert.berger  wrote:
> Hi,
>
> On Sunday, May 4, 2014 3:50:39 PM UTC+3, nath...@gmail.com wrote:
>>
>> Thanks for all the responses.
>>
>> I'm specifically looking for something that gets into embedded
>> kernel/driver development using the BBB.  I don't have a ton of embedded
>> linux experience, although I've played around with it some.  The idea is
>> that we hope to be migrate from a legacy RTOS to an embedded linux
>> environment.
>>
>
> Hmmm. I would really recommend to try to understand how (Embedded) Linux
> works before jumping into kernel/driver development. If you don't
> understand the system architecture and start it like what you are used to
> from your legacy RTOS it will most likely be wrong. And with respect to
> kernel/driver development I also would start with Linux drivers in general
> before looking into BBB specifics. To get started - and some more - with
> kernel and drivers I would recommend (besides my own trainings) this[1].
>
> I am __NOT__ a big fan of mapping layers, but with Xenomai [2] you might be
>
> able to partially move over code from the legacy RTOS to Linux.
>
> Do you have real-time requirements?
>
> What distro do you plan to use on the BBB? [3]?
>
>
>>
>> Somewhere in the U.S. preferably.
>>
>>
> My trainings are offered world wide on-site. But for a just a few trainees
> (which is most likely your case) you could avoid my travel expenses with an
>
> instructor driven remote training. For such cases I host all the equipment
> in Europe and you access it remotely. A trainee gets access to a Linux
> machine with cross compiler and stuff which also exports kernel/fdt over
> tftp and the rootfs over nfs. The console of the target board is accessible
>
> and once it runs you can also ssh into it.
>
> Regards,
>
> Robert
>
> [1] http://eudyptula-challenge.org/
> [2] http://www.xenomai.org/
> [3] https://www.yoctoproject.org/
>
>
>>

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

[beagleboard] HC-05 Bluetooth and the beagle bone black ...

[Pedro Gonzalez]

Hi there!

Newbie here ... sorry if too basic or already answered somewhere, I can not 
find what I'm looking for. Here is my problem:

I'm trying to connect my BBB to an android device via bluetooth. I'm using 
a HC-05 device and followed the instructions in 
here. 
It works to some extent. Bluetooth connects to the devide and I can send 
messages to my android device runninga terminal software ( BLUETERM). 
Problem is that I can not read from the device (which BTW is the sole 
purpose of the connection ...).

I'm doing it pretty basic by now, just some echo hello > /dev/ttyO4 and cat 
/dev/ttyO4 The first works, the latter doesn´t. All I'm trying to do by now 
is to make some sort of simple android app that can turn on and off some 
LED on the BBB. Later will go more complex but what I need now is to set 
the foundations to my project.

It would be great if there is a tutorial somewhere on how to open a shell 
over bluetooth from the android device, would be wonderful. I found some on 
how to do it on rasPi but no luck with BBB

Any advice? any tutorials? any help ...??

If I have to be more specific please let me know what you need and I'll 
give the informion. I'm running trhe latest armstrong distribution n a BBB 
rev B.

Thanks for any help!

Pedro

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

Re: [beagleboard] 625 MHz leak?

[Gerald Coley]

In order to mitigate it you need to figure out where it is coming from. A
probe test will help in that area. Have you run one? Using ferrites on all
cables generally helps in these types of issues.

Gerald



On Wed, May 14, 2014 at 12:01 PM,  wrote:

> We have a BBB-based design currently undergoing FCC testing, and they've
> found a bit of noise at 625 MHz. Has anyone else encountered this, or know
> what it might be, or how to mitigate it?
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] 625 MHz leak?

[lee]

We have a BBB-based design currently undergoing FCC testing, and they've 
found a bit of noise at 625 MHz. Has anyone else encountered this, or know 
what it might be, or how to mitigate it?

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

[beagleboard] BBB and BB-View 4.3" LCD

[Colin Bester]

I have installed and have working a 4.3" BB-View LCD on my Angstrom 
Beaglebone black, however I am unable to resize application windows to fit 
size of LCD.

Dragging window frame only marginally changes the window size and maxmizing 
the window doesn't help either - window stays much larger than LCD.

Looking for suggestions as it's pretty unusable in its current state.

~Colin

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

Re: [beagleboard] battery or supercap for rtc and sync?

[ivo welch]

thank you, gerald.  very helpful to know what is in the cards and what is
not.




Ivo Welch (ivo.we...@gmail.com)
http://www.ivo-welch.info/
J. Fred Weston Professor of Finance
Anderson School at UCLA, C519
Director, UCLA Anderson Fink Center for Finance and Investments
Free Finance Textbook, http://book.ivo-welch.info/
Editor, Critical Finance Review, http://www.critical-finance-review.org/


On Wed, May 14, 2014 at 6:28 AM, Gerald Coley wrote:

> You would be better off just adding an external RTC. There are
> capes available that add a RTC. Any battery that was adequate to keep
> the board up for shutdown would be more than a typical RTC would require.
> The isn't enough space on the board to add a rechargeable battery that
> large.
>
> I have no plans to make these changes, but thanks for the input.
>
> Gerald
>
>
> On Tue, May 13, 2014 at 5:10 PM, ivo welch  wrote:
>
>>
>> I love this little device.  thanks to jason and team for putting this
>> together.
>>
>> I have only one feature suggestion (complaint): I wish there was a teeny
>> battery or supercapacitor on this device.
>>
>> first, I would prefer to keep the RTC running on powerdown.  second, and
>> more importantly, with a battery, it could provide 5 seconds of power after
>> a powerdown to flush (sync) buffers to the sd card, so I would not have to
>> constantly flush buffers manually in order to have my data logged before my
>> robot ran into the wall.  having to flush manually constantly slows down
>> what I can do tremendously.
>>
>> ok, I admit that I am not the ideal target user for which the BBB was
>> designed.  I am not a hardware enthusiast.  however, another $10 for a
>> version of the BBB with a battery already built-in and just 5 seconds of
>> guaranteed power (or, even better, a powerdown signal to the OS and 5
>> seconds) would be ideal for me.
>>
>> is there a chance that a small battery could make it into the next
>> revision?
>>
>> /iaw
>>
>>  --
>> 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.
>>
>> 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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/s3VoyPS5g3c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Problem with Adafruit BBIO on Ubuntu - presumably dtb related

[William Hermans]

>
> *The library was designed and tested using only root/sudo to access GPIO
> at this time. For more details, please review the documents at
> http://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black
> .
> *


Also, there is supposed to be a patch. However, it would be nice if people
were to contribute to the community that they do not break fundamental
permission rules , . .   As this only confuses people who do not know
better, and can potentially lead to these same users leaving their systems
wide open.


On Wed, May 14, 2014 at 8:36 AM, Robert Nelson wrote:

> On Wed, May 14, 2014 at 10:21 AM,   wrote:
> > So many many many thanks, after hours of searching for the solution, you
> > pointed with the answer: root access..
>
> There's a pretty big conversation on the bug tracker, that this "root"
> only situation needs to be fixed:
>
>
> https://github.com/adafruit/adafruit-beaglebone-io-python/issues/36#issuecomment-43083987
>
> Regards,
>
> --
> Robert Nelson
> http://www.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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Problem with Adafruit BBIO on Ubuntu - presumably dtb related

[Robert Nelson]

On Wed, May 14, 2014 at 10:21 AM,   wrote:
> So many many many thanks, after hours of searching for the solution, you
> pointed with the answer: root access..

There's a pretty big conversation on the bug tracker, that this "root"
only situation needs to be fixed:

https://github.com/adafruit/adafruit-beaglebone-io-python/issues/36#issuecomment-43083987

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Problem with Adafruit BBIO on Ubuntu - presumably dtb related

[wgaonar]

So many many many thanks, after hours of searching for the solution, you 
pointed with the answer: root access..

On Thursday, March 6, 2014 3:38:43 PM UTC-6, c...@isbd.net wrote:
>
> Robert Nelson > wrote: 
> > On Thu, Mar 6, 2014 at 1:11 PM,  > wrote: 
> > > I am trying to use the Adafruit BBIO library on a BBB with Ubuntu 
> > > 13.10 installed.  It's for reading ADC values and sending some digital 
> > > data. 
> > > 
> > > A trivial program as follows shows the error:- 
> > > 
> > > #!/usr/bin/python 
> > > import os 
> > > import sys 
> > > import Adafruit_BBIO.ADC as ADC 
> > > # 
> > > # 
> > > # Read A2D using Adafruit libraries 
> > > # 
> > > ADC.setup() 
> > > 
> > > 
> > > As soon as it executes the ADC.setup() call I get the following 
> error:- 
> > > 
> > > chris@beaglebone$ bt.py 
> > > Traceback (most recent call last): 
> > >   File "/home/chris/bin/bt.py", line 9, in  
> > > ADC.setup() 
> > > RuntimeError: Unable to setup ADC system. Possible causes are: 
> > >   - A cape with a conflicting pin mapping is loaded 
> > >   - A device tree object is loaded that uses the same name for a 
> fragment: helper 
> > > 
> > > 
> > > 
> > > This worked OK on the Angstrom distribution but for lots of reasons I 
> > > want to use Ubuntu. 
> > > 
> > > So, what's wrong, I'm not running anything at all before running the 
> > > above.  There are no capes installed.  I get the above error if I 
> > > simply power up the system and run the above code.  Is it just some 
> sort of 
> > > name conflict with more than one thing called 'helper' or am I 
> > > misunderstanding what it's telling me? 
> > 
> > According to dmesg, did it actually load anything? 
> > 
> > Probally also need the patch "dtc" .. 
> > 
> > wget -c https://raw.github.com/RobertCNelson/tools/master/pkgs/dtc.sh 
> > chmod +x dtc.sh 
> > ./dtc.sh 
> > 
> No, after a little while I twigged what the problem was, it needs root 
> access to work. 
>
> It's not a big issue for me at the moment but it does seem a bit wrong 
> to need root access to be able to get at the GPIO and ADC data.  Is 
> there some sort of group membership I can add to my user to make it 
> work or maybe some library needs to be SETUID? 
>
> On the Angstrom distribution of course everything is done as root, 
> that's why it worked there. 
>
> That dtc patch is only needed for SPI and UART use I think, I don't 
> need those. 
>
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Quadcopter!

[Warner Tabor]

Mike,
   
That is a very interesting project. For ~$250 mark I think it is a viable 
kickstarter project. I'd buy one. I like the idea of having the extra compute 
power to experiment with OpenCV, sense and avoid systems, etc. Some things that 
would be nice to add / change (although these aren't really deal breakers) are 
GPS position and altitude hold (perhaps using a uBlox NEO 6M.) One thing that 
does concern me is the frame. It looks like laser cut acrylic. I don't think 
that material is strong or rigid enough for a quad frame of that size. I'd look 
into G10 as an option. This would increase your cost, but would provide a much 
better frame. Another option is to look at some of the cheaper, off the shelf 
frames available. Flite Test makes some great kits using mostly wood (and some 
G10) that are cheap and possibly more robust. They are also very easy to fix in 
the event of a crash. The H quad has the largest payload platform, you can find 
it here;   http://shop.flitetest.com/multirotors/knuckle-h-quad-370-kit/ I 
think a robust, or easily repairable frame is very important considering the 
application here. Since this is such a great platform for experimenting with 
autonomous or semi-autonomous flight there are most certainly going to be 
crashes. Having a frame that will survive or be easily repaired would be a must.

Thanks,
SKip

On May 12, 2014, at 8:11 PM, Mike McDonald wrote:

> Hey guys,
> 
> A group of Rose-Hulman students have been hard at work this past year 
> building a Beaglebone Quadcopter with these goals in mind:
> 
> 1. Low cost ($100-150 w/o Beaglebone)
> 2. Fully open source (Cape, Frame, and all control software) on our Github.
> 3. Easy to assembly and repair (we estimate it will take 1-2 hours to 
> assemble and get ready to fly)
> 4. Durable and easy to fly (currently supports USB game controller control, 
> though we initially tested using a USB RC controller, though it's also 
> possible to eventually use a cell phone as a controller) with a 10 minute 
> flight time
> 5. Sensor packed: 9-Axis (MPU 9150), Altimeter (BMP 180), Ultrasonic 
> Rangefinder (HC SR04), Battery Gas Gauge (MAX 17044), and CMOS Camera 
> (OV7670).
> 
> The Quadcopter is flown via WiFi and Bluetooth (though streaming video 
> doesn't yet work over Bluetooth) from a host computer (you need somewhere to 
> view the streaming video from). Additionally, we're using a Debian image and 
> have added Xenomai for better real time performance. We're also using both 
> PRU's: one for real time motor control and one for the camera. With the 
> quadcopter software running, we've still got 80+% of the CPU free for other 
> processing (OpenCV, etc.).
> 
> We're currently using a PID control scheme, but we may be switching to a 
> sweet state variable feedback system (or getting a senior design group next 
> year to do it).
> 
> So, we want some feedback from you guys on the following:
> Would you buy one of these Quadcopters?
> Is our price point reasonable? Is this something worth selling ourselves or 
> would this be a good kickstarter project?
> Are there any other features you think are critical (wouldn't buy without it)?
> If you want to dive deeper into our design:
> How does the software look (particularly the PRU to C interface)? Would you 
> be willing to maintain it, or update it to State Variable?
> How does the PCB look? Are there any flaws you see? Would you want to add or 
> remove any other sensors?
> How does the mechanical design (Quadcopter frame) look? Is it aesthetically 
> pleasing? Easy to build (if you have a laser cutter, give it a try and let us 
> know)? Easy to fix when broken?
> Here are some pictures:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Videos are available on here (and on the github). Our best video is probably 
> here, as it shows it both flying as well as the streaming video.
> 
> If you guys have any questions, respond here or email me back.
> 
> Thanks!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling SPI

[Robert Nelson]

On Wed, May 14, 2014 at 10:25 AM, Robert Nelson  wrote:
> On Wed, May 14, 2014 at 9:54 AM, James S  wrote:
>> I followed the instructions here
>> http://elinux.org/BeagleBone_Black_Enable_SPIDEV but SPI1 is still not
>> initialising properly.
>>
>> uEnv.txt
>> optargs=quiet drm.debug=7
>> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> capemgr.enable_partno=BB-SPI1-01
>>
>> The result is:
>> root@beaglebone:~# dmesg | grep SPI
>> [0.00] Kernel command line: console=tty0 console=ttyO0,115200n8
>> quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> capemgr.enable_partno=BB-SPI1-01 root=/dev/mmcblk0p2 ro rootfstype=ext4
>> rootwait fixrtc quiet init=/lib/systemd/systemd
>> [0.732452] bone-capemgr bone_capemgr.9: enabled_partno part_number
>> 'BB-SPI1-01', version 'N/A', prio '0'
>> [0.732498] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
>> Name,00A0,Override Manuf,BB-SPI1-01'
>> [0.736957] bone-capemgr bone_capemgr.9: loader: before slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> [0.736974] bone-capemgr bone_capemgr.9: loader: check slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> [0.736990] bone-capemgr bone_capemgr.9: loader: after slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> [0.737006] bone-capemgr bone_capemgr.9: slot #7: Requesting part
>> number/version based 'BB-SPI1-01-00A0.dtbo
>> [0.737024] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
>> 'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
>> [1.110253] bone-capemgr bone_capemgr.9: failed to load firmware
>> 'BB-SPI1-01-00A0.dtbo'
>> [1.118721] bone-capemgr bone_capemgr.9: loader: failed to load slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
>>  0: 54:PF---
>>  1: 55:PF---
>>  2: 56:PF---
>>  3: 57:PF---
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>>
>> Then doing a
>>  echo BB-SPI1-01 > /sys/devices/bone_capemgr.9/slots
>>
>> the output is
>> root@beaglebone:~# dmesg | grep SPI
>> [0.00] Kernel command line: console=tty0 console=ttyO0,115200n8
>> quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> capemgr.enable_partno=BB-SPI1-01 root=/dev/mmcblk0p2 ro rootfstype=ext4
>> rootwait fixrtc quiet init=/lib/systemd/systemd
>> [0.732452] bone-capemgr bone_capemgr.9: enabled_partno part_number
>> 'BB-SPI1-01', version 'N/A', prio '0'
>> [0.732498] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
>> Name,00A0,Override Manuf,BB-SPI1-01'
>> [0.736957] bone-capemgr bone_capemgr.9: loader: before slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> [0.736974] bone-capemgr bone_capemgr.9: loader: check slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> [0.736990] bone-capemgr bone_capemgr.9: loader: after slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> [0.737006] bone-capemgr bone_capemgr.9: slot #7: Requesting part
>> number/version based 'BB-SPI1-01-00A0.dtbo
>> [0.737024] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
>> 'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
>> [1.110253] bone-capemgr bone_capemgr.9: failed to load firmware
>> 'BB-SPI1-01-00A0.dtbo'
>> [1.118721] bone-capemgr bone_capemgr.9: loader: failed to load slot-7
>> BB-SPI1-01:00A0 (prio 0)
>> [  353.544405] bone-capemgr bone_capemgr.9: part_number 'BB-SPI1-01',
>> version 'N/A'
>> [  353.544700] bone-capemgr bone_capemgr.9: slot #8: 'Override Board
>> Name,00A0,Override Manuf,BB-SPI1-01'
>> [  353.544960] bone-capemgr bone_capemgr.9: slot #8: Requesting part
>> number/version based 'BB-SPI1-01-00A0.dtbo
>> [  353.545012] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware
>> 'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
>> [  353.552302] bone-capemgr bone_capemgr.9: slot #8: dtbo
>> 'BB-SPI1-01-00A0.dtbo' loaded; converting to live tree
>>
>> I then changed uEnv.txt to:
>> ##Disable HDMI
>> optargs=quiet drm.debug=7
>> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> #capemgr.enable_partno=BB-SPI1-01
>>
>> After reboot I get:
>> root@beaglebone:~# dmesg | grep SPI
>> root@beaglebone:~#
>>
>> When I enter:
>> root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
>>  0: 54:PF---
>>  1: 55:PF---
>>  2: 56:PF---
>>  3: 57:PF---
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>> root@beaglebone:~#
>>
>> And then type:
>> root@beaglebone:~# echo BB-SPI1-01 > /sys/devices/bone_capemgr.9/slots
>>
>> I get:
>> root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
>>  0: 54:PF---
>>  1: 55:PF---
>>  2: 56:PF---
>>  3: 57:PF---
>>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>  5: ff:P-O-- Bone-Bl

[beagleboard] Eth0 config on BBB (default Angstrom image 2013.09.04)

[Chriskner]

Hi all,

I searched without success for an explanation on how to configure eth0 on 
the BBB Angstrom for a static IP (ultimately from a python script - but 
that's later).

Could somebody share a link on how to do this?

I hope to configure eth0 for something like:
IP: 192.168.0.50
mask: 255.255.255.0

...while preserving the USB-eth configuration (which has the default 
settings).

If this is difficult, is this a good reason to switch to Debian?

Regards,

Chris

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

Re: [beagleboard] Enabling SPI

[Robert Nelson]

On Wed, May 14, 2014 at 9:54 AM, James S  wrote:
> I followed the instructions here
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV but SPI1 is still not
> initialising properly.
>
> uEnv.txt
> optargs=quiet drm.debug=7
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> capemgr.enable_partno=BB-SPI1-01
>
> The result is:
> root@beaglebone:~# dmesg | grep SPI
> [0.00] Kernel command line: console=tty0 console=ttyO0,115200n8
> quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> capemgr.enable_partno=BB-SPI1-01 root=/dev/mmcblk0p2 ro rootfstype=ext4
> rootwait fixrtc quiet init=/lib/systemd/systemd
> [0.732452] bone-capemgr bone_capemgr.9: enabled_partno part_number
> 'BB-SPI1-01', version 'N/A', prio '0'
> [0.732498] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
> Name,00A0,Override Manuf,BB-SPI1-01'
> [0.736957] bone-capemgr bone_capemgr.9: loader: before slot-7
> BB-SPI1-01:00A0 (prio 0)
> [0.736974] bone-capemgr bone_capemgr.9: loader: check slot-7
> BB-SPI1-01:00A0 (prio 0)
> [0.736990] bone-capemgr bone_capemgr.9: loader: after slot-7
> BB-SPI1-01:00A0 (prio 0)
> [0.737006] bone-capemgr bone_capemgr.9: slot #7: Requesting part
> number/version based 'BB-SPI1-01-00A0.dtbo
> [0.737024] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
> 'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [1.110253] bone-capemgr bone_capemgr.9: failed to load firmware
> 'BB-SPI1-01-00A0.dtbo'
> [1.118721] bone-capemgr bone_capemgr.9: loader: failed to load slot-7
> BB-SPI1-01:00A0 (prio 0)
> root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>
> Then doing a
>  echo BB-SPI1-01 > /sys/devices/bone_capemgr.9/slots
>
> the output is
> root@beaglebone:~# dmesg | grep SPI
> [0.00] Kernel command line: console=tty0 console=ttyO0,115200n8
> quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> capemgr.enable_partno=BB-SPI1-01 root=/dev/mmcblk0p2 ro rootfstype=ext4
> rootwait fixrtc quiet init=/lib/systemd/systemd
> [0.732452] bone-capemgr bone_capemgr.9: enabled_partno part_number
> 'BB-SPI1-01', version 'N/A', prio '0'
> [0.732498] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
> Name,00A0,Override Manuf,BB-SPI1-01'
> [0.736957] bone-capemgr bone_capemgr.9: loader: before slot-7
> BB-SPI1-01:00A0 (prio 0)
> [0.736974] bone-capemgr bone_capemgr.9: loader: check slot-7
> BB-SPI1-01:00A0 (prio 0)
> [0.736990] bone-capemgr bone_capemgr.9: loader: after slot-7
> BB-SPI1-01:00A0 (prio 0)
> [0.737006] bone-capemgr bone_capemgr.9: slot #7: Requesting part
> number/version based 'BB-SPI1-01-00A0.dtbo
> [0.737024] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
> 'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [1.110253] bone-capemgr bone_capemgr.9: failed to load firmware
> 'BB-SPI1-01-00A0.dtbo'
> [1.118721] bone-capemgr bone_capemgr.9: loader: failed to load slot-7
> BB-SPI1-01:00A0 (prio 0)
> [  353.544405] bone-capemgr bone_capemgr.9: part_number 'BB-SPI1-01',
> version 'N/A'
> [  353.544700] bone-capemgr bone_capemgr.9: slot #8: 'Override Board
> Name,00A0,Override Manuf,BB-SPI1-01'
> [  353.544960] bone-capemgr bone_capemgr.9: slot #8: Requesting part
> number/version based 'BB-SPI1-01-00A0.dtbo
> [  353.545012] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware
> 'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [  353.552302] bone-capemgr bone_capemgr.9: slot #8: dtbo
> 'BB-SPI1-01-00A0.dtbo' loaded; converting to live tree
>
> I then changed uEnv.txt to:
> ##Disable HDMI
> optargs=quiet drm.debug=7
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
> #capemgr.enable_partno=BB-SPI1-01
>
> After reboot I get:
> root@beaglebone:~# dmesg | grep SPI
> root@beaglebone:~#
>
> When I enter:
> root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
> root@beaglebone:~#
>
> And then type:
> root@beaglebone:~# echo BB-SPI1-01 > /sys/devices/bone_capemgr.9/slots
>
> I get:
> root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf

Re: [beagleboard] Future versions of Beagle board with more RAM And Flash?

[Philip Polstra]

current version is 512MB RAM and 4GB Flash.  I have done lots of CPU
intensive hacking with the BeagleBone.


On Wed, May 14, 2014 at 8:31 AM,  wrote:

>
> I would love to use the beagleboard but I need a fair amount of RAM. 256MB
> is not enough .
>
> Ist there a chance of a future version with 1GB RAM and Flash?
>
> At the moment I must use the Raspberry Pi (512mb)  or the Banana Pi.(1GB)
>
> Just a thought!
>
> M
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Future versions of Beagle board with more RAM And Flash?

[Gerald Coley]

BeagleBone Black has 512MB DDR3 and 4GB eMMC.

I have no plans to update the two BeagleBoards.

Gerald



On Wed, May 14, 2014 at 8:31 AM,  wrote:

>
> I would love to use the beagleboard but I need a fair amount of RAM. 256MB
> is not enough .
>
> Ist there a chance of a future version with 1GB RAM and Flash?
>
> At the moment I must use the Raspberry Pi (512mb)  or the Banana Pi.(1GB)
>
> Just a thought!
>
> M
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: high-end case for the BBB?

[rodney . hill]

Hi Ivo,
i appreciate your review.  the chassis design is two pieces with a simple 
but clean look and style by design.  we wanted to have a professional look 
while being very low cost and competitive.  for those who want something 
beautiful - it is possible but not every customer wants to pay for that.  
we can make extrusions, and plastic molds, castings, decals, and many 
different types of chassis and computer products.  we make computers that 
look like art for high end clients and we make ones that can survive 
underwater or under a taxi cab seats.

airflow is not a concern for this device - it is really low power and gains 
some from radiation cooling from the chassis paint inside as well as 
conduction spread across the board.  Logic Supply specializes in 
fanless/ventless industrial computer design and can cool i7 devices without 
fans or air vents in 70c ambient environments.

colors - again, black and orange are standard options.  logos are not 
expensive to process.  but need to be done at the time of manufacturing of 
the metal to be cost effective.  minimum order quantity will apply usually 
1000 pieces.  in these quantities the customized solution retail price is 
only a little more expensive than the standard unit price + some 
engineering dollars.  screws can be painted at the same time as the 
chassis, or there are other options (ex no screws, silver screws, bottom 
screws and not side).  this idea of this BBB chassis is it will work for 
80% of the clients and if it does not work then describe how it needs to be 
different for your project and it will be easy to quote.

expansion - the chassis top has 3 screw positions on the side  - we design 
capes to fit inside by elevating the top chassis to a higher level.  again, 
the focus is to prototype what you want and then order the metal custom for 
your application.  most customization is only a few days at most for simple 
designs.  then produced by laser or stamping processes in the factory.

power supply - there are some limitations to the beaglebone board (access 
to buttons and power options) - there are options for hiding power again it 
is an engineering project to do that.  for standard product we do not see 
the demand to justify the premium.  custom product is another discussion.

i hope this helps, and i wish you luck with all your projects!
Rodney
product development @ Logic Supply


On Tuesday, May 13, 2014 5:57:01 PM UTC-4, ivo welch wrote:
>
>
> so here is my mini review of the LogicSupply case, BB100-ORANGE.  I am a 
> newbie embedded computer starter, but long-term computer programmer.
>
> the case itself is industrial looking, made of steel.  for an enduser like 
> me, this is a somewhat rare and unusual look.  I am more used to "one-piece 
> looks", where the whole case looks like one.  there is a clear 
> top-and-bottom separation in this case here.  all in all, the look aspect 
> for me is not good or bad, just different.
>
> the tolerances are very good.
>
> there are no airflow holes at the top of the case.  I have not yet run 
> stress tests on the BBB, so I do not know whether this will be an issue.  I 
> would have preferred some holes, if only to hear a buzzer that I want to 
> install on it.
>
> there is very little top clearance to add anything on the inside.
>
> the outside screws are in black.  it would be nice to have the option of 
> orange screws to match the case.
>
> customization (e.g., a logo) seems to be quite expensive.
>
> it is a very good case, and it is very reasonably priced.  I don't think 
> there is any other professional-looking case right now.  so, go for it.
>
>
> other observations
>
> * the Logic-Supply wall wart is expensive at $9 a piece.  I would have 
> paid $10 to have the wall wart replaced by an internal power-supply.
>
> regards,
>
> /iaw
>
>

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

[beagleboard] Future versions of Beagle board with more RAM And Flash?

[ntrewartha2]

I would love to use the beagleboard but I need a fair amount of RAM. 256MB 
is not enough .

Ist there a chance of a future version with 1GB RAM and Flash? 

At the moment I must use the Raspberry Pi (512mb)  or the Banana Pi.(1GB) 

Just a thought!

M

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

Re: [beagleboard] Enabling SPI

[James S]

I followed the instructions here 
http://elinux.org/BeagleBone_Black_Enable_SPIDEV but SPI1 is still not 
initialising properly. 

uEnv.txt
optargs=quiet drm.debug=7 
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
capemgr.enable_partno=BB-SPI1-01

The result is:
root@beaglebone:~# dmesg | grep SPI
[0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
capemgr.enable_partno=BB-SPI1-01 root=/dev/mmcblk0p2 ro rootfstype=ext4 
rootwait fixrtc quiet init=/lib/systemd/systemd
[0.732452] bone-capemgr bone_capemgr.9: enabled_partno part_number 
'BB-SPI1-01', version 'N/A', prio '0'
[0.732498] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
Name,00A0,Override Manuf,BB-SPI1-01'
[0.736957] bone-capemgr bone_capemgr.9: loader: before slot-7 
BB-SPI1-01:00A0 (prio 0)
[0.736974] bone-capemgr bone_capemgr.9: loader: check slot-7 
BB-SPI1-01:00A0 (prio 0)
[0.736990] bone-capemgr bone_capemgr.9: loader: after slot-7 
BB-SPI1-01:00A0 (prio 0)
[0.737006] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
number/version based 'BB-SPI1-01-00A0.dtbo
[0.737024] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[1.110253] bone-capemgr bone_capemgr.9: failed to load firmware 
'BB-SPI1-01-00A0.dtbo'
[1.118721] bone-capemgr bone_capemgr.9: loader: failed to load slot-7 
BB-SPI1-01:00A0 (prio 0)
root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

Then doing a 
 echo BB-SPI1-01 > /sys/devices/bone_capemgr.9/slots

the output is 
root@beaglebone:~# dmesg | grep SPI
[0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
capemgr.enable_partno=BB-SPI1-01 root=/dev/mmcblk0p2 ro rootfstype=ext4 
rootwait fixrtc quiet init=/lib/systemd/systemd
[0.732452] bone-capemgr bone_capemgr.9: enabled_partno part_number 
'BB-SPI1-01', version 'N/A', prio '0'
[0.732498] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
Name,00A0,Override Manuf,BB-SPI1-01'
[0.736957] bone-capemgr bone_capemgr.9: loader: before slot-7 
BB-SPI1-01:00A0 (prio 0)
[0.736974] bone-capemgr bone_capemgr.9: loader: check slot-7 
BB-SPI1-01:00A0 (prio 0)
[0.736990] bone-capemgr bone_capemgr.9: loader: after slot-7 
BB-SPI1-01:00A0 (prio 0)
[0.737006] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
number/version based 'BB-SPI1-01-00A0.dtbo
[0.737024] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[1.110253] bone-capemgr bone_capemgr.9: failed to load firmware 
'BB-SPI1-01-00A0.dtbo'
[1.118721] bone-capemgr bone_capemgr.9: loader: failed to load slot-7 
BB-SPI1-01:00A0 (prio 0)
[  353.544405] bone-capemgr bone_capemgr.9: part_number 'BB-SPI1-01', 
version 'N/A'
[  353.544700] bone-capemgr bone_capemgr.9: slot #8: 'Override Board 
Name,00A0,Override Manuf,BB-SPI1-01'
[  353.544960] bone-capemgr bone_capemgr.9: slot #8: Requesting part 
number/version based 'BB-SPI1-01-00A0.dtbo
[  353.545012] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 
'BB-SPI1-01-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[  353.552302] bone-capemgr bone_capemgr.9: slot #8: dtbo 
'BB-SPI1-01-00A0.dtbo' loaded; converting to live tree

I then changed uEnv.txt to:
##Disable HDMI
optargs=quiet drm.debug=7 
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
#capemgr.enable_partno=BB-SPI1-01

After reboot I get:
root@beaglebone:~# dmesg | grep SPI
root@beaglebone:~#

When I enter:
root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
root@beaglebone:~#

And then type:
root@beaglebone:~# echo BB-SPI1-01 > /sys/devices/bone_capemgr.9/slots

I get:
root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI1-01
root@beaglebone:~#

It looks like SPI1 is there!






On Tuesday, May 13, 2014 8:53:44 PM UTC+1, James S wrote:
>
> Thanks! Looks like a stupid mistake, I'll check it out.
>
> On Tuesday, May 13, 2014 5:38:39 PM UTC+1

[beagleboard] BeagleBone Black powered by PoE (Power over Ethernet)?

[James Zapico]

This simple injector from adafruit might work. It's not full POE compliant 
though, so probably won't work in long cable runs. 
http://www.adafruit.com/products/435

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

Re: [beagleboard] Audio Cape Rev B1

[Robert Nelson]

On Wed, May 14, 2014 at 8:18 AM, Aaron Clarke  wrote:
> I'm looking for some help getting the audio cape rev. B1 running on debian.
> I'm not able to load the overlay, I suspect I'm using the wrong kernel or
> need to compile the firmware into the kernel.
>
> Circuitco provided an overlay, I have the latest image I can find,
> BBB-eMMC-flasher-debian-7.4-2014-04-23-2gb.img
>
> I downloaded the overlay here:
> http://elinux.org/CircuitCo:Audio_Cape_RevB
>
> From above link:
> "The device tree overlay is available at the bottom of this page. ... The
> current Debian images have the required patches and will play audio
> normally."
>
> I compiled the overlay on the board with this command
> #dtc -o dtb -o BB-BONE-AUDI-02-00A0.dtbo -b 0 -@ BB-BONE-AUDI-02-00A0.dts
> and put it in /lib/firmware
>
> root@beaglebone:~# echo BB-BONE-AUDI-02 > /sys/devices/bone_capemgr*/slots
> -bash: echo: write error: Invalid argument
>
> dmesg output:
> [  290.610210] bone-capemgr bone_capemgr.9: part_number 'BB-BONE-AUDI-02',
> version 'N/A'
> [  290.612723] bone-capemgr bone_capemgr.9: slot #7: generic override
> [  290.612784] bone-capemgr bone_capemgr.9: bone: Using override eeprom data
> at slot 7
> [  290.612836] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
> Name,00A0,Override Manuf,BB-BONE-AUDI-02'
> [  290.613099] bone-capemgr bone_capemgr.9: slot #7: Requesting part
> number/version based 'BB-BONE-AUDI-02-00A0.dtbo
> [  290.613153] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
> 'BB-BONE-AUDI-02-00A0.dtbo' for board-name 'Override Board Name', version
> '00A0'
> [  290.617371] bone-capemgr bone_capemgr.9: slot #7: dtbo
> 'BB-BONE-AUDI-02-00A0.dtbo' loaded; converting to live tree
> [  290.617415] Invalid device tree blob header
> [  290.622050] bone-capemgr bone_capemgr.9: slot #7: Failed to unflatten
>
> I tried to disable HDMI but that didn't help.
>

Odd, i missed that one..

This should fix it going forward.

https://github.com/RobertCNelson/linux-dev/commit/d15af8d70b402f6415dbaaf1319819e91fac1951

Regards,

-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Quadcopter!

[Programmer]

 Hi,

Your project certain looks  really interesting .
Yes, I would be interested in buying one if the proce doesn't exceed 
$250,-- but depending on the features
this would not be my limit.

Are you goinh to publich the diagrams and Software?

Can you post/email regularly.?

When do you expect a compeletion date? 
Postage to the EU a problem?

All the best wishes for your project

NT

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

Re: [beagleboard] BeagleBone Black powered by PoE (Power over Ethernet)?

[Gerald Coley]

Yes, if you add it externally and regulate the voltage to 5V and if it can
deliver the current. POE is not built into the BBB so you must apply power
via the 5VDC port. You can find injector boards at several different places

There may be a cape for this, but I am not aware of one. Adding it
externally is a lot simpler.

Gerald



On Wed, May 14, 2014 at 2:18 AM, Christian wrote:

> Can BeagleBone Black only be powered by using PoE? In my project I want to
> avoid using too many cables. So the possibilty to use one cable for power
> and data would be very interesting. In this case a network switch would be
> working as an injector. The BeagleBone Black would only receive power from
> the Ethernet Port without using the 5V DC Port or microUSB Port. If PoE is
> not available by default, are there possibilties to upgrade by using a cape
> or an additional circuit?
>
>
>  --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] SPI remains in read mode (infinitely) after giving command root@beagleboard:~# cat < /dev/spidev4.0

[mustafa . shaikh29]

Hi,

  We are using beagleboard xm in our project - we have configure our board 
for SPI4.0,also configured GPIO pin 16 as irq pin , 
  The problem with this code is if we try to read  spidev4.0 by giving 
command as root@beagleboard:~# cat < /dev/spidev4.0 
   it  remains in read mode and reads the following data contineously.

   [  764.107574] read-8 00
   [  764.110321] read-8 00
   [  764.112579] read-8 00
   [  764.114868] read-8 00
   [  764.117340] read-8 00
   [  764.119628] read-8 00
   [  764.121917] read-8 00
   [  764.124389] read-8 00
 

 Any suggestions to come out from this infinite loop from spi read 

  

 
CODE  




PATH => vim arch/arm/mach-omap2/board-omap3beagle.c

 

#define OMAP3BEAGLE_GPIO_GS_IRQ 16  /* Pin No. 16 (GPIO) is converted into 
irq */


static void __init omap3_beagle_config_mcspi4_mux(void)
{
omap_mux_init_signal("mcbsp1_clkr.mcspi4_clk", OMAP_PIN_INPUT);
omap_mux_init_signal("mcbsp1_fsx.mcspi4_cs0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("mcbsp1_dx.mcspi4_simo", OMAP_PIN_OUTPUT);
omap_mux_init_signal("mcbsp1_dr.mcspi4_somi", 
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("etk_d2.gpio_16", OMAP_PIN_INPUT);
omap_mux_init_signal("etk_d1.gpio_15", OMAP_PIN_INPUT);
}

static struct spi_board_info beagle_mcspi_board_info[] __initdata = {
// spi 4.0
{
.modalias   = "spidev",
.max_speed_hz   = 100, //1MHz
.bus_num= 4,
.chip_select= 0,
.mode = SPI_MODE_1,
.irq= OMAP_GPIO_IRQ(OMAP3BEAGLE_GPIO_GS_IRQ),
.controller_data = &beagle_mcspi_config,
},
};

static void __init omap3beagle_gs_init(void)
{
if ((gpio_request(OMAP3BEAGLE_GPIO_GS_IRQ, "GS_IRQ") == 0) &&
(gpio_direction_input(OMAP3BEAGLE_GPIO_GS_IRQ) == 0)) {
gpio_export(OMAP3BEAGLE_GPIO_GS_IRQ, 0);
beagle_mcspi_board_info[0].irq  = 
OMAP_GPIO_IRQ(OMAP3BEAGLE_GPIO_GS_IRQ);
set_irq_type(beagle_mcspi_board_info[0].irq, 
IRQ_TYPE_EDGE_BOTH);

printk(KERN_INFO "OMAP3BEAGLE_GPIO_GS_IRQ. registered 
\n");

} else {
printk(KERN_ERR "could not obtain gpio for GS_IRQ\n");
return;
}
spi_register_board_info(beagle_mcspi_board_info,
ARRAY_SIZE(beagle_mcspi_board_info));
}



 

 

XXX

static unsigned
omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer)
{


if (word_len <= 8) {
u8  *rx;
const u8*tx;

rx = xfer->rx_buf;
tx = xfer->tx_buf;

do {
c -= 1;
if (tx != NULL) {
if (mcspi_wait_for_reg_bit(chstat_reg,
OMAP2_MCSPI_CHSTAT_TXS) < 
0) {
dev_err(&spi->dev, "TXS timed 
out\n");
goto out;
}
#ifdef DBG_PRINT
printk(KERN_INFO "write-%d %02x\n", 
word_len, *tx);
#endif
#ifdef VERBOSE
dev_dbg(&spi->dev, "write-%d %02x\n",
word_len, *tx);
#endif
__raw_writel(*tx++, tx_reg);
}
if (rx != NULL) {
if (mcspi_wait_for_reg_bit(chstat_reg,
OMAP2_MCSPI_CHSTAT_RXS) < 
0) {
dev_err(&spi->dev, "RXS timed 
out\n");
goto out;
}
/* prevent last RX_ONLY read from triggering
 * more word i/o: switch to rx+tx
 */
if (c == 0 && tx == NULL)
mcspi_write_chconf0(spi, l);
*rx++ = __raw_readl(rx_reg);
#ifdef VERBOSE
dev_dbg(&spi->dev, "read-%d %02x\n",
word_len, *(rx

[beagleboard] BeagleBone Black powered by PoE (Power over Ethernet)?

[Christian]

Can BeagleBone Black only be powered by using PoE? In my project I want to 
avoid using too many cables. So the possibilty to use one cable for power 
and data would be very interesting. In this case a network switch would be 
working as an injector. The BeagleBone Black would only receive power from 
the Ethernet Port without using the 5V DC Port or microUSB Port. If PoE is 
not available by default, are there possibilties to upgrade by using a cape 
or an additional circuit?


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

[beagleboard] Audio Cape Rev B1

[Aaron Clarke]

I'm looking for some help getting the audio cape rev. B1 running on debian. 
 I'm not able to load the overlay, I suspect I'm using the wrong kernel or 
need to compile the firmware into the kernel.

Circuitco provided an overlay, I have the latest image I can 
find, BBB-eMMC-flasher-debian-7.4-2014-04-23-2gb.img

I downloaded the overlay here:
http://elinux.org/CircuitCo:Audio_Cape_RevB

>From above link: 
"The device tree overlay is available at the bottom of this page. ... The 
current Debian images have the required patches and will play audio 
normally."

I compiled the overlay on the board with this command
#dtc -o dtb -o BB-BONE-AUDI-02-00A0.dtbo -b 0 -@ BB-BONE-AUDI-02-00A0.dts 
and put it in /lib/firmware

root@beaglebone:~# echo BB-BONE-AUDI-02 > /sys/devices/bone_capemgr*/slots 
-bash: echo: write error: Invalid argument

dmesg output:
[  290.610210] bone-capemgr bone_capemgr.9: part_number 'BB-BONE-AUDI-02', 
version 'N/A'
[  290.612723] bone-capemgr bone_capemgr.9: slot #7: generic override
[  290.612784] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
data at slot 7
[  290.612836] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
Name,00A0,Override Manuf,BB-BONE-AUDI-02'
[  290.613099] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
number/version based 'BB-BONE-AUDI-02-00A0.dtbo
[  290.613153] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
'BB-BONE-AUDI-02-00A0.dtbo' for board-name 'Override Board Name', version 
'00A0'
[  290.617371] bone-capemgr bone_capemgr.9: slot #7: dtbo 
'BB-BONE-AUDI-02-00A0.dtbo' loaded; converting to live tree
[  290.617415] Invalid device tree blob header
[  290.622050] bone-capemgr bone_capemgr.9: slot #7: Failed to unflatten

I tried to disable HDMI but that didn't help.

This blog post mentions a possible bug that makes it necessary compile a 
kernel or change a setting to get loadable overlays.  Is that the case here?
http://hipstercircuits.com/enable-device-tree-overlay-on-startup-on-beaglebone-black/

Thanks,

Aaron

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

Re: [beagleboard] battery or supercap for rtc and sync?

[Gerald Coley]

You would be better off just adding an external RTC. There are
capes available that add a RTC. Any battery that was adequate to keep
the board up for shutdown would be more than a typical RTC would require.
The isn't enough space on the board to add a rechargeable battery that
large.

I have no plans to make these changes, but thanks for the input.

Gerald


On Tue, May 13, 2014 at 5:10 PM, ivo welch  wrote:

>
> I love this little device.  thanks to jason and team for putting this
> together.
>
> I have only one feature suggestion (complaint): I wish there was a teeny
> battery or supercapacitor on this device.
>
> first, I would prefer to keep the RTC running on powerdown.  second, and
> more importantly, with a battery, it could provide 5 seconds of power after
> a powerdown to flush (sync) buffers to the sd card, so I would not have to
> constantly flush buffers manually in order to have my data logged before my
> robot ran into the wall.  having to flush manually constantly slows down
> what I can do tremendously.
>
> ok, I admit that I am not the ideal target user for which the BBB was
> designed.  I am not a hardware enthusiast.  however, another $10 for a
> version of the BBB with a battery already built-in and just 5 seconds of
> guaranteed power (or, even better, a powerdown signal to the OS and 5
> seconds) would be ideal for me.
>
> is there a chance that a small battery could make it into the next
> revision?
>
> /iaw
>
>  --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] DC-DC of TPS65950 getting broken, beagleboard

[Gerald Coley]

I have no idea what your issue may be. We have never had any issues of any
consequence on the TPS65950 over the last three years. If you chose not to
follow the layout, there may be other issues that you have, not just the
skinny etch..You may have component issues. And the PMIC may actually be
fine and the issue is in other parts of the board where too much current is
being consumed..

As to why we did what we did, all I can say is many years of experiences.
You always want to make power planes as big as you can. There is
no valid reason not to.The greater the etch the lower the resistance and
the lower the voltage drop.


On Tue, May 13, 2014 at 7:25 PM, <4ndr3...@gmail.com> wrote:

> Hello,
>
> I manufactured and produced a board that basically is the same as the
> beagleboard.
>
> 1) I got it working for some hours (configuring linux), and after that it
> suddenly stopped responding. The TPS65950 was really hot (really,really
> hot!), the VDD1 module was consuming too much current and the output was
> 2.6V instead of the 1.3V it should be. My conclusion is that the module got
> broken.
>
> 2) I cut some tracks and I supplied it with an external source. I worked
> again. I continued configuring linux on it. After some hours, it suddenly
> stopped responding again. I realized that the VIO module of the TPS65950
> was consuming too much current and it´s output was 0.4V instead of the 1.8V
> it should be. My conclusion is that the module got broken.
>
> With this evidences I compared the routing of my board with the routing of
> the beagleboard and I realized that in the beagleboard the connections
> between the outputs of the DC-DC (VIO module and VDD1 module are DC-DC) and
> the coils are made with planes instead of tracks. In my board the
> connection between the output of the modules and the coils are made with
> thin and long tracks.
>
> are my DC-DCs getting broken because of the bad routing?
> do you remember any similar problem while you where manufacturing
> prototypes and designing the beagleboard (or other similar boards)?
> if you did not have any problem similar to mine, why you used planes in
> all the connections of the coils?
>
> Thank you very much, I really appreciate your help.
>
> Andrés Cecilia Luque
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stuck with applying the device tree overlay file (dtbo) On BeagleBoard-XM, any suggestions how?

[Robert Nelson]

On Tue, May 13, 2014 at 6:41 PM,   wrote:
>
> Hi There,
> I have recently took my Beagleboard-xM and put on it the Ubuntu 14.04 LTS
> (3.14.2-armv7-x5),
> then I tried to mux PIn3 (GPIO_139), after reading thoroughly the pages from
> both the "System Reference Manual"(Page 110) and the "Technical Reference
> Manual" of the processor (Pages 2444-2453).
> So I wrote the dts file and compiled it via dtc.
>
> but now I got stuck how do I apply the changes on runtime?
>
> I saw on the beaglebone there is a slots file (/sys/devices/.../slots) which
> was triggering the change,
> after we echoed to it the dtbo file. but in my case we are talking about
> beagleboard-xM which there is no such kind of file.
> can someone elaborate what should I do?

Modify the base dtb file, the capemgr wasn't ported to the xM. When
overlay's hit mainline we will visit this again.

Regards,


-- 
Robert Nelson
http://www.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB SPI//ADXL375

[Stuart Reynard]

Hi Jose,

I finished this project a couple of weeks ago. 

I wanted to thank you for getting back to me with such helpful information, 
and I also wanted to follow up with my solution to the SPI problem (for 
future users).

I ended up using a different driver file for SPI0 than the one provided by 
Adafruit:

http://elinux.org/BeagleBone_Black_Enable_SPIDEV

Guide for adding SPI driver:

http://stackoverflow.com/questions/21276090/beaglebone-black-enable-spi-interface

For me, the easiest method for verification was to read the DEVID register 
on the accelerometer.

#python code:
print spi.xfer2([0x80,0x00])

This prints a list of 2 bytes. With how I understand SPI to work, the 
second byte in the printed list should always be the DEVID. The first byte 
may or may not be the DEVID. This is just one of the nuances of the data 
flow of SPI.

-Stuart



On Sunday, March 30, 2014 3:43:07 PM UTC-4, José Luis Redrejo wrote:
>
> Hello Stuart, I've been using BBB to communicate with another Analog 
> Devices device (ADE7753) , and I can confirm you that it works. 
> Have you tried to do a loopback test before connecting the ADXL275? 
> Just use a wire in the BBB to join DI and DO in P9, and run this 
> program: 
>
>
> from Adafruit_BBIO.SPI import SPI 
>
> spi = SPI(0,0) 
> spi.mode=2 
>
> spi.msh=200 
> spi.open(0,0) 
>
> print spi.xfer2([32, 11, 110, 22, 220]) 
> spi.close() 
>
> You should see 32,11,110,22,220 in your terminal as it's returned by 
> the spi instruction. 
>
> You don't need 
> spi.cshigh = low 
> because that's its default value. 
>
> If the loopback test works, then you can try with the device. I can 
> confirm you that using ADE7753 and adafruit python library I have need 
> some time to get it working, until I found out the trick. 
>
> Regards. 
> José L. 
>
>
>
> 2014-03-30 18:10 GMT+02:00 Stuart Reynard >: 
>
> > I am working on a design project involving a BeagleBone Black and an 
> ADXL375 
> > Accelerometer. 
> > 
> > Per the data sheet (attached), in order to enable the maximum sampling 
> rate 
> > of the ADXL375, I need my BBB to communicate with the ADXL375 over SPI 
> (I2C 
> > is not fast enough for this). 
> > 
> > I have used the Adafruit library for I2C just to test the functionality 
> of 
> > the ADXL375, and I can confirm that the accel. does in fact work. 
> However, I 
> > am unsure of how to even perform a simple read of the ADXL375 DEVID 
> register 
> > using SPI. I have included my steps for how I think a read should be 
> > performed, but I suspect that this process is incorrect as I get no 
> output. 
> > 
> > I am using the Adafruit BBIO library which I understand is just a python 
> > wrapper for the file spimodule.c. All of this is available here: 
> > 
> > https://github.com/adafruit/adafruit-beaglebone-io-python/ 
> > 
> > Based on that code, I am not sure if I will need to hold CS low using 
> one of 
> > the methods/variables of an SPI object or if the 
> writebytes()/readbytes() 
> > methods take care of this for me. In other words, I don't know if I 
> should 
> > be doing something like 
> > 
> > spi.cshigh = low 
> > spi.writebytes([list]) 
> > spi.readbytes(numBytes) 
> > 
> > OR if I can just do 
> > 
> > spi.writebytes([list]) 
> > spi.readbytes(numBytes) 
> > 
> > Process for reading from SPI (from python terminal): 
> > 
> > from Adafruit_BBIO.SPI import SPI 
> > 
> > #using SPI bus 0 on P9 of BBB, assuming i'm using dev0, not really sure 
> how 
> > to determine this, but I have no other peripherals connected 
> > spi = SPI(0,0) 
> > 
> > #set desired frequency, 2MHz 
> > spi.msh = 200 
> > 
> > #per the ADXL375 datasheet, when performing a read, need to send a byte 
> > where bits 0-5 are address bits (DEVID register is 0x0), bit 6 is a 
> multiple 
> > bytes bit (for reading/writing multiple bytes), and bit 7 is a 
> read/write 
> > bit where read is '1' and write is '0' 
> > 
> > #so I use 0b1000 or 0x80 and call writebytes 
> > spi.writebytes([0x80]) 
> > 
> > From here I receive no output, even if I do spi.readbytes(1), I get [0] 
> > back. 
> > 
> > I have a pretty good understanding of Linux, Python, C, and the concept 
> of 
> > SPI seems simple enough, but this is my first experience with a BBB. I 
> feel 
> > like I am missing something simple like setting CS low, which I don't 
> think 
> > is very clearly documented in the attributes for the SPI library. 
> > 
> > Here is some info about my BBB: 
> > lsb_release -a 
> > Distributor ID: Angstrom 
> > Description: Angstrom GNU/Linux v2012.12 (Core edition) 
> > Release: v2012.12 
> > Codename: Core edition 
> > 
> > uname -a 
> > Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l 
> GNU/Linux 
> > 
> > I have also attached the breakout board user guide for the ADXL375. I 
> would 
> > be happy to come back with any additional info. 
> > 
> > Thanks, 
> > Stuart 
> > 
> > -- 
> > For more options, visit http://beagleboard.org/discuss 
> > --- 
> > You received thi

[beagleboard] Re: Cannot run a python script on powerup

[mike rankin]

I made the change and it now works perfectly!

Thank you,
Mike

On Tuesday, May 13, 2014 3:46:06 PM UTC-3, Chriskner wrote:
>
> Nobody else has chimed in - and nearly anyone would be more qualified...
>
> Could it be that you didn't properly specify 'python' in the "execstart" 
> section of  [Service]?
>
> This:
> ExecStart=/home/root/py-gaugette/samples/python new_test.py
>
> Should be this:
>
> ExecStart=/usr/bin/python new_test.py
>
> -Chris
>
> On Tuesday, May 13, 2014 7:21:09 AM UTC-4, mike rankin wrote:
>>
>> I found a great post over at: 
>> http://stackoverflow.com/questions/11152657/angstrom-start-up-processes-beagleboneon
>>  how to have a python script run on power up. 
>>
>> My python code that displays text on an oled screen runs fine on Angstrom 
>> when I run it manually.
>>
>> The web page says to:
>>
>> Create a new file in /lib/systemd/system/ (rfidreader.service in my 
>> example) with a content like:
>>
>> [Unit]
>> Description=Start Python RFID reader
>>
>> [Service]
>> WorkingDirectory=/...Python script path.../
>> ExecStart=/usr/bin/python rfidreader.py
>> KillMode=process
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> Then execute the following command to install the service:
>>
>> systemctl enable rfidreader.service
>>
>> To start the service, you can reboot or execute
>>
>> systemctl start rfidreader.service
>>
>> To check if the service is running and get the latest outputs from the 
>> script:
>>
>> systemctl status rfidreader.service
>>
>>
>>
>> *My code:*
>> [Unit]
>> Description=Start Python Oled
>>
>> [Service]
>> WorkingDirectory=/home/root/py-gaugette/samples/
>> ExecStart=/home/root/py-gaugette/samples/python new_test.py
>> KillMode=process
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> *My error message:*
>> root@beaglebone:~# systemctl status oled.service
>> oled.service - Start Python Oled
>>   Loaded: loaded (/lib/systemd/system/oled.service; enabled)
>>   Active: *failed* (Result: exit-code) since Tue 2014-05-13 00:12:38 
>> GMT+3; 23s ago
>> Process: 666 ExecStart=/home/root/py-gaugette/samples/python new_test.py 
>> *(code=exited, 
>> status=203/EXEC)*
>>   CGroup: name=systemd:/system/oled.service
>>
>> May 13 00:12:38 beaglebone systemd[1]: Starting Start Python Oled...
>> May 13 00:12:38 beaglebone systemd[1]: Started Start Python Oled.
>> May 13 00:12:38 beaglebone systemd[1]: *oled.service: main process 
>> exited, code=exited, status=203/EXEC*
>> May 13 00:12:38 beaglebone systemd[1]: *Unit oled.service entered failed 
>> state*
>>
>>
>>

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

[beagleboard] Re: Official eQEP driver Support

[Teknoman117]

I don't believe that actually will change the I/O configuration.  For the 
pin ctrl entry to be adopted, it needs to be used by some driver.  Turns 
out there is a "pinmux helper" device.  Check out this blog 
post: http://hipstercircuits.com/enable-serialuarttty-on-beaglebone-black/. 
 More specifically, this section:

fragment@2 {
target = <&ocp>;
__overlay__ {
test_helper: helper {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart5>;
status = "okay";
};
};
};


- Nathaniel

On Tuesday, May 13, 2014 1:55:00 AM UTC-7, Strawson wrote:
>
> Actually, let me be more specific. I use the pinmux lines and enable the 
> PWM Subsystem as follows
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
>  pinctrl_eqep0: pinctrl_eqep0_pins {
>  pinctrl-single,pins = <
> 0x1A8 0x21  /* P9_41 = GPIO3_20 = EQEP0_index, MODE1 
> */
> 0x1AC 0x21  /* P9_25 = GPIO3_21 = EQEP0_strobe, MODE1 
> */   
> 0x1A0 0x31  /* P9_42 = GPIO3_18 = EQEP0A_in, MODE1 */ 
>   
> 0x1A4 0x31  /* P9_27 = GPIO3_19 = EQEP0B_in, MODE1 */ 
>   
>>;
>   };
> };
> };
> 
> fragment@1 {
>   target = <&epwmss0>;
> __overlay__ {
>status = "okay";
> };
> };
>
>
> I am not using the following fragment passing parameters to the kernel 
> driver
>
> fragment@2 {
> target = <&eqep0>;
>   __overlay__ {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_eqep0>;
> 
> count_mode = <0>;  /* 0 - Quadrature mode, normal 90 phase offset 
> cha & chb.  1 - Direction mode.  cha input = clock, chb input = direction */
> swap_inputs = <0>; /* Are channel A and channel B swapped? (0 - 
> no, 1 - yes) */
> invert_qa = <1>;   /* Should we invert the channel A input?  */
> invert_qb = <1>;   /* Should we invert the channel B input? I 
> invert these because my encoder outputs drive transistors that pull down the 
> pins */
> invert_qi = <0>;   /* Should we invert the index input? */
> invert_qs = <0>;   /* Should we invert the strobe input? */
> 
>  status = "okay";
> };
> };
>
>
> This is for two reasons. Firstly, I don't see how this would change the 
> behavior of the hardware if I'm setting the registers anyway. Secondly, it 
> fails to load because eqep is not a part of the 
> default am335x-boneblack.dtb located in /boot/uboot/dtbo in debian
>
> When trying to load this, dmesg returns
>
> [  523.086537] bone-capemgr bone_capemgr.9: slot #10: dtbo 
> 'bone_eqep0-00A0.dtbo' loaded; converting to live tree
> [  523.090030] of_resolve: Could not find symbol 'eqep0'
> [  523.095581] bone-capemgr bone_capemgr.9: slot #10: Failed to resolve 
> tree
>
>
>
> In Angstrom, this file was located in /boot/am335x-boneblack.dtb. Attached 
> is a modified version of this that was provided by TI and results in the 
> eqep dts loading correctly in angstrom. This file has since changed in the 
> Debian release and the fix no longer works. As stated in the first post in 
> this thread, it would be nice if the correct eqep entries and your driver 
> were included in the public image so that this functionality can be used 
> out of the box like pwm.
>
>
> On Monday, May 12, 2014 11:53:08 PM UTC-7, Strawson wrote:
>>
>> Hi Nathaniel. The correct device tree fragments are loaded, pins are 
>> multiplexed correctly, and all 3 eqep channels work perfectly with your 
>> driver. The supplied mmap code from my last post also works perfectly, but 
>> only if I insmod the compiled .ko kernel module first. Strange, I know.
>>
>> On Monday, May 12, 2014 11:41:14 PM UTC-7, Teknoman117 wrote:
>>>
>>> I'll certainly take a look at this next week.  Currently in the middle 
>>> of finals and Maker Faire is this weekend.  And in all honesty, once i 
>>> figure out whats going on with the driver, its still a good idea to use the 
>>> kernel based implementation, mainly because you can take advantage of 
>>> hardware interrupts and not have to busy wait.  I know there are sleep 
>>> methods, but unless something like Xenomai is being used, you're at the 
>>> mercy of the scheduler...  
>>>
>>> Although, just to rule it out - are you still applying a device tree 
>>> overlay?  The supplied DTS files do more than just initialize the driver, 
>>> they setup the IO configuration, as the default board config doesn't bring 
>>> out the eQEP lines. 
>>>
>>> - Nathaniel Lewis
>>>
>>> On Saturday, May 10, 2014 12:25:14 AM UTC-7, Strawson wrote:

 I believe it is enabled. From my last post:  the PWMSS clock config 
 returns
 CL