[beagleboard] Re: BBB: bare metal programming in C - what is need on the SD card?

[Martin H.]

Hi Reinhard,

regarding pin toggling this link might be useful:
http://e2e.ti.com/support/embedded/starterware/f/790/t/366081.aspx

Regards,
Martin H.


Am Montag, 20. Oktober 2014 15:23:46 UTC+2 schrieb reinhar...@gmail.com:
>
> Hello,
>
> after nearly 2 weeks of struggling my first LED blinking works under the 
> following constitution:
> -) Beaglebone black, Element14, rev.C
> -) no OS --> holding "boot" button, when powering
> -) Code Composure Studio v6
> -) Starterware (without BBB patch:
>
> http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/index_FDS.html
>  
> (DOES NOT WORK AT THE MOMENT)
> -) XDS100v2 emulator
>
> 1.) 
> The maximum frequency for toggling the pin is 1.6 MHz,
> but I need maximum speed. 
> In my understanding there is still a speed decrease as the system is 
> running in *emulation *mode.
> Correct?
>
> 2.)
> From the build process of CCS I have got a .out file.
> *What are the next steps to get the program running from the SD card?*
> Please be very precise - I have already heard of MOL, u-boot, GEL 
> file,,
> but there does not seem to be a step-by-step tutorial.
>
> 3.)
> *What are the next steps to get the program running from the eMMC?*
>
>
> You see, I want to do bare-metal C programming, without linux or any other 
> OS,
> as I must operate (pin toggling, computations,...) as fast as possible.
>
>
> Your help is very appreciated!
>
> Reinhard
>
>

-- 
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] Unable to deploy Android image on beaglebone black

[Prasad Marathe]

Hello,

I am trying to deploy Android image on beaglebone black as mentioned in 
http://elinux.org/Beagleboard:Android this URL. But after following the 
steps mentioned, User LED's are not blinking. So i am not able to deploy 
the image on beaglebone black. kindly help to sort this issue.
I am using following tools for deployment:

Host machine - 32 bit Windows XP service pack 3
Beaglebone black - rev 00A5 S/N 2014BBBK0661 running BoneScript 0.2.4 at 
192.168.7.2
OS on eMMC - Debian
Supply - 5V 2A Adapter
SD card used for Android image deployment - 8GB class 4 SanDisk Micro SD 
card

-- 
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] Getting rid of that web / USB server

[Robert Nelson]

On Tue, Oct 21, 2014 at 8:59 AM, Julian Gold
 wrote:
> I need to free up "disk" space and CPU cycles on my BBB and want to get rid
> of the Cloud 9 service as well as the thing that serves web pages when
> connected to the host USB. How do I do this?

cloud9 ide is stored under: /opt/cloud9

Or you could just start with the 200Mb "console" version listed here:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-10-08

and build up your image from that..

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] Getting rid of that web / USB server

[Julian Gold]

I need to free up "disk" space and CPU cycles on my BBB and want to get rid 
of the Cloud 9 service as well as the thing that serves web pages when 
connected to the host USB. How do I do this?

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

Re: [beagleboard] Implementing a ring buffer / circular buffer for communnication between PRU and ARM on BBB.

[Charles Steinkuehler]

On 10/20/2014 4:05 PM, Rafael Vega wrote:
> 
> Thanks for the input Peter, you made me realize I had a mistake:
> 
> The idea here is that ONLY the PRU changes the end pointer (write position 
> pointer) and ONLY the ARM changes the start pointer (read position 
> pointer).  Also, the pointers are updated AFTER the data is read or written 
> (thus the memory barrier on the ARM side).
> 
> When the ARM is reading/updating the start pointer, the PRU could write 
> messages to fill the buffer, changing the start pointer and corrupting the 
> buffer. To avoid this, I have changed the PRU code as follows. Note that if 
> the buffer is full, new messages will be dropped, you can lower the chances 
> of this happening by making the buffer larger.
> 
> inline void buffer_write(unsigned int message){
>unsigned int is_full = (*buffer_end == (*buffer_start^buffer_size)); // 
> ^ is orex
>if(!is_full){
>   shared_ram[*buffer_end & (buffer_size-1)] = message;
>   *buffer_end = (*buffer_end+1) & (2*buffer_size - 1);
>}
> }

Careful with the buffer size handling!  It's hard to tell the difference
between empty and full, since in both cases the read and write pointers
are identical.

It looks like you're trying to use an extra bit of buffer_end to track
empty/full, but I don't think your logic is correct.  I don't see how
the MSB (indicating buffer full) ever gets cleared once set.

I've found it's usually much less hassle to live with a maximum buffer
size of N-1 (ie: full = 127 elements, not 128) rather than try to
properly handle the complexity of properly tracking empty/full.  Note
that there are *LOTS * of subtle ways you can mess up the empty/full
logic (it's even harder to do properly than the basic pointer handling
for reads/writes), so if you do try to use all buffer elements, be
*VERY* careful with your code.  I recommend reviewing the Linux kernel
code if you need a reference implementation.

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

[beagleboard] Missing .dts files in Debian distro?

[Teiresias]

Hi all, just a quick question.  I'm new to programming embedded Linux, 
having done most of my work for various embedded applications using 
to-the-metal AVR programming (using home brew cyclic executives and the 
like, I've never really had the need for an actual OS until now) and doing 
VHDL design on FPGAs (and doing the associated PCB circuit design), however 
I am slowly wrapping my head around programming for something running an 
actual OS.  I could toss this over to an actual software guy, but it seems 
like a good learning experience.

I foresee needing to design my own carrier board (essentially a large cape) 
and am trying to learn about device trees and device tree overlays.  I 
noticed however, that the available device tree sources (and even the 
blobs) found on the latest official Angstrom and Debian distros are much 
different - with there seemingly being far fewer in the file system of the 
Debian distro.  Am I just looking in the wrong place or were many of the 
sources just left out of the debian distro?

Thanks for the 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] Missing .dts files in Debian distro?

[Robert Nelson]

On Tue, Oct 21, 2014 at 9:44 AM, Teiresias  wrote:
> Hi all, just a quick question.  I'm new to programming embedded Linux,
> having done most of my work for various embedded applications using
> to-the-metal AVR programming (using home brew cyclic executives and the
> like, I've never really had the need for an actual OS until now) and doing
> VHDL design on FPGAs (and doing the associated PCB circuit design), however
> I am slowly wrapping my head around programming for something running an
> actual OS.  I could toss this over to an actual software guy, but it seems
> like a good learning experience.
>
> I foresee needing to design my own carrier board (essentially a large cape)
> and am trying to learn about device trees and device tree overlays.  I
> noticed however, that the available device tree sources (and even the blobs)
> found on the latest official Angstrom and Debian distros are much different
> - with there seemingly being far fewer in the file system of the Debian
> distro.  Am I just looking in the wrong place or were many of the sources
> just left out of the debian distro?


https://github.com/beagleboard/linux/tree/3.8

https://github.com/beagleboard/linux/tree/3.8/arch/arm/boot/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] Device Tree Location in Debian

[Altaf]

Hello, 

Any further help, if possible can you point to some more debug commands where I 
can share some more info that may be useful. I'm stuck can't get 24 bit display.

Regards 
Altaf

-- 
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] Device Tree Location in Debian

[Robert Nelson]

On Tue, Oct 21, 2014 at 9:51 AM, Altaf  wrote:
> Hello,
>
> Any further help, if possible can you point to some more debug commands where 
> I can share some more info that may be useful. I'm stuck can't get 24 bit 
> display.

Honestly, i haven't dove into the 3.8 tree in over a month or two.
It's so old, it's more of a waste of time as it's a kernel i really
don't care about anymore.

However on v3.14.x i got 24bit working on the Chipsee bbb-exp-c lcd..

http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Chipsee_bbb-exp-c

dts:
https://github.com/beagleboard/linux/blob/3.14/arch/arm/boot/dts/am335x-bone-bbb-exp-c.dts

main include for bbb-exp-c
https://github.com/beagleboard/linux/blob/3.14/arch/arm/boot/dts/am335x-bone-bbb-exp-c.dtsi

panel:
https://github.com/beagleboard/linux/blob/3.14/arch/arm/boot/dts/am335x-bone-panel-1240x600-24bit.dtsi

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] Implementing a ring buffer / circular buffer for communnication between PRU and ARM on BBB.

[Bas Laarhoven]

On 21-10-2014 16:33, Charles Steinkuehler wrote:

On 10/20/2014 4:05 PM, Rafael Vega wrote:

Thanks for the input Peter, you made me realize I had a mistake:

The idea here is that ONLY the PRU changes the end pointer (write position
pointer) and ONLY the ARM changes the start pointer (read position
pointer).  Also, the pointers are updated AFTER the data is read or written
(thus the memory barrier on the ARM side).

When the ARM is reading/updating the start pointer, the PRU could write
messages to fill the buffer, changing the start pointer and corrupting the
buffer. To avoid this, I have changed the PRU code as follows. Note that if
the buffer is full, new messages will be dropped, you can lower the chances
of this happening by making the buffer larger.

inline void buffer_write(unsigned int message){
unsigned int is_full = (*buffer_end == (*buffer_start^buffer_size)); //
^ is orex
if(!is_full){
   shared_ram[*buffer_end & (buffer_size-1)] = message;
   *buffer_end = (*buffer_end+1) & (2*buffer_size - 1);
}
}

Careful with the buffer size handling!  It's hard to tell the difference
between empty and full, since in both cases the read and write pointers
are identical.

It looks like you're trying to use an extra bit of buffer_end to track
empty/full, but I don't think your logic is correct.  I don't see how
the MSB (indicating buffer full) ever gets cleared once set.

I've found it's usually much less hassle to live with a maximum buffer
size of N-1 (ie: full = 127 elements, not 128) rather than try to
properly handle the complexity of properly tracking empty/full.  Note
that there are *LOTS * of subtle ways you can mess up the empty/full
logic (it's even harder to do properly than the basic pointer handling
for reads/writes), so if you do try to use all buffer elements, be
*VERY* careful with your code.  I recommend reviewing the Linux kernel
code if you need a reference implementation.



Rafael,

This is good advice from Charles! I've been running this n-1 scheme with 
my own
PRU code and BeBoPr software for over two years now and it has proven 
rock stable.
No concurrency or cache coherency issues, no locking needed and no data 
re-ordering

problems!

You can find the C-code in the following file:
https://github.com/modmaker/BeBoPr/blob/master/pruss_stepper.c
(start with 'pruss_command')
The PRUSS code is not open source, but I think the C-code shows enough 
detail.


Cheers,
-- Bas

--
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: Unable to deploy Android image on beaglebone black

[Andrew Henderson]

There is a newer version of Android available.  The version referenced on 
the elinux.org page is JellyBean 4.2.2, and the newer one is KitKat 4.4.4. 
 You can get the newer one at bbbandroid.org.

The easiest way to troubleshoot this sort of thing is to use an FTDI cable 
to monitor the BBB during boot.  This will allow you to capture the debug 
output from the bootloader and the kernel.  Since you are using Windows XP, 
you won't be able to natively mount the partitions of your microSD card and 
look at them to ensure that you wrote the image properly.  You could try 
using an application like Linux Reader to see the partitions on your Win32 
machine: http://www.diskinternals.com/linux-reader.

You need to verify two things: 

1. Did you write the image properly to the microSD card?  There can be a 
few causes for this, including not decompressing the image prior to writing 
and getting a bad write to the microSD card.  If you can see the four 
partitions (one VFAT, three EXT4), then you probably wrote the image OK.

2. Is the bootloader at least getting into kernel boot?  You'll need to see 
the FTDI output to determine this.

Andrew
 

On Tuesday, October 21, 2014 5:03:56 AM UTC-4, Prasad Marathe wrote:
>
>
> Hello,
>
> I am trying to deploy Android image on beaglebone black as mentioned in 
> http://elinux.org/Beagleboard:Android this URL. But after following the 
> steps mentioned, User LED's are not blinking. So i am not able to deploy 
> the image on beaglebone black. kindly help to sort this issue.
> I am using following tools for deployment:
>
> Host machine - 32 bit Windows XP service pack 3
> Beaglebone black - rev 00A5 S/N 2014BBBK0661 running BoneScript 0.2.4 at 
> 192.168.7.2
> OS on eMMC - Debian
> Supply - 5V 2A Adapter
> SD card used for Android image deployment - 8GB class 4 SanDisk Micro SD 
> card
>

-- 
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] Device Tree Location in Debian

[Altaf]

Hello, 

Thanks for all your help and time I will check and get back with results. 

Regards
Altaf

-- 
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: bare metal programming in C - what is need on the SD card?

[Travis Estep]

Starterware includes a bootloader that pulls a program from the SD card and 
loads it and runs it. As far as toggling the GPIO pins very fast, you're not 
going to get good results. This is an applications processor, not made for real 
time programming. That's why TI included 2 PRU units on the chip. If you want 
GPIO speed, that is the only way to go.

-- 
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: Anyone interested in LEGO EV3? I'm trying to transplant EV3 system to Beaglebone Black.

[Fat Cat Man]

Yes, I've came to my hometown to hold a wedding ceremony last 2 weeks.
I've updated all the linux drivers to 1.06x. Now it works fine with the 
native labview language.
Now I'm making the smart UART sensor, I have already made a prototype. It 
can measure couple of analog channels and transmit the data throuth the 
uart. It means a huge kinds of arduino analog sensors can be used for ev3 
now: ) And it's very easy to develop any kind of new sensors.


在 2014年10月13日星期一UTC+8上午8时18分48秒，janszyma...@gmail.com写道：
>
> Hi,
>
>  Are you still working on it?
> If yes, any progress so far?
>
> Jan
>
> On Thursday, 17 July 2014 16:21:40 UTC+10, Fat Cat Man wrote:
>>
>> As you know, LEGO announced their Mindstorms EV3 robot system last year. 
>> The EV3 system is based on linux, they published the full source code at 
>> *https://github.com/mindboards/ev3sources* 
>>  
>>
>> When I got the source code, I was wondering if I can transplant all the 
>> code to Beaglebone Black. The EV3 use a TI AM1808 MCU as its cpu and BBB 
>> use TI AM3359. Many of the registers are common. So after several months 
>> work, I'm almost done. Here are some pitcures shows my progress:
>>
>>
>> 
>>
>>
>> 
>>
>>
>> 
>>
>>
>> As you can see, there are still some bugs in the system. After the main 
>> lms2012 program running for a while, it would appear a warning, and then 
>> quit. Now I'm designing the cape PCB board. It can provide the input and 
>> output capacity as same as EV3.
>>
>>
>>
>>

-- 
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: EasyVR 2.0

[artem . pastukhov]

I'm trying to write an library for python, but i'm not python dev :(
https://github.com/pastukhov/EasyVR

понедельник, 20 октября 2014 г., 14:58:14 UTC+4 пользователь Tulsi написал:
>
> Anybody worked on EasyVR 2.0 with beaglebone black? EasyVR 2.0 provides 
> SDK which has support for Arduino.
>

-- 
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] BBxM Ubuntu 14.4 HDMI problem

[sokolic . andrej]

Thanks! That worked like a charm



On Monday, October 20, 2014 5:06:17 PM UTC+2, RobertCNelson wrote:
>
> On Mon, Oct 20, 2014 at 10:02 AM, Robert Nelson  > wrote: 
> > On Sun, Oct 19, 2014 at 8:15 PM,  > 
> wrote: 
> >> Hi, 
> >> 
> >> I'm new to this world and to this forum so I don't know is it the right 
> >> place for the question. 
> >> I've been trying to install ubuntu on my beagleboard xM for a few days 
> now 
> >> and still no success. First I tried to install it using windows 7 
> following 
> >> this tutorial: 
> >> http://www.elinux.org/Beagleboard:BeagleBoard-xM 
> >> and I've managed to successfully install demo OS that is shipping with 
> the 
> >> Beagleboard xM, but when I tried to do the same with Ubuntu 14.4 I ran 
> into 
> >> a problem. Installation on the SD card went without a glitch but when I 
> >> tried to boot it from BB xM all I got was a brief orange screen and 
> than 
> >> nothing, TV was signaling "No signal" but in a very uncommon fashion 
> (like 
> >> he is getting something but can't interpret it). Next interesting thing 
> was 
> >> that my keyboard worked, when I pressed CTR+ALT+DEL it restarted. I 
> looked 
> >> all over the internet but couldn't find a solution. 
> >> 
> >> Ubuntu .img I got from here: https://rcn-ee.net/deb/microsd/trusty/ 
> >> 
> >> Can someone help me with that? And can someone point me to some older 
> Ubuntu 
> >> .img files (not .tar)? 
> > 
> > Sounds like edid detection of your monitor failed. Do you have a 
> > serial connection avaiable to debug? 
> > 
> > In /boot/uEnv.txt you can force a resolution via: 
> > 
> > cmdline=video=DVI-D-1-1:1024x768@60e 
>
> Opps, extra "-1" in there: 
>
> cmdline=video=DVI-D-1:1024x768@60e 
>
> 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] USB Camera on BBB (Debian GNU/Linux 7)

[sidkcis]

Hello all,
same issue with me. i can not find /dev/video0 
i am using Debian  on beaglebone black rev C

debian@beaglebone:~$ uname -a
Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
GNU/Linux


debian@beaglebone:~$ lsusb
Bus 001 Device 003: ID 413c:1004 Dell Computer Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 413c:2006 Dell Computer Corp. 
Bus 001 Device 007: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 001 Device 006: ID 15d9:0a4f Trust International B.V. 


debian@beaglebone:~$ lsmod | grep video
uvcvideo   57013  0 
videobuf2_vmalloc   2490  1 uvcvideo

debian@beaglebone:~$ sudo modprobe uvcvideo

doesn't show any output.
any suggestion?

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

Re: [beagleboard] Beaglebone Black won't power on, did I do something wrong? :(

[baantunes]

Hi,

I think I also fried my BBB.
No led light when powered, either with USB or jack.

Can I request a RMA from Portugal?
What would be the expected cost?

Thanks
Bruno

On Thursday, July 4, 2013 3:38:46 PM UTC+1, Gerald wrote:
>
> You have blown the processor. Request an RMA.
>
> beagleboard.org/support/rma
>
> No fuses on the board. Plugging in the USB and DC supply is totally 
> acceptable and supported.
>
> Gerald
>
>
>
> On Thu, Jul 4, 2013 at 3:21 AM, Will Kostelecky  > wrote:
>
>> Help!
>>
>> My BBB was working fine, great in fact, but not so much at the moment.   
>> When I plug it into a power source, be it a known good 5v supply that I 
>> have been using with it for weeks, or into either of two computers via USB, 
>> I get one dim little flash from the power LED and then NOTHING else.   No 
>> other lights flash.   If I hold down the power switch I will get another 
>> brief and dim flash after a couple of seconds.   Again, no other LEDs light 
>> and nothing else happens.
>>
>> This started to happen when I plugged the BBB into a computer using a USB 
>> cable while it was still plugged into the 5V power source.  Could this have 
>> fried something?   Are there any poly fuses that might come back to life 
>> after a rest?
>>
>> Frustrating as I was making such good progress on my project!
>>
>> Will
>>
>>
>> On Tuesday, 30 April 2013 15:23:23 UTC+1, Gerald wrote:
>>
>>> You are a pioneer! Columbus was not looking for America. But you are now 
>>> the Columbus of the power button!
>>>
>>> I am trying convince the SW folks to add support for the power button 
>>> but it is down the list  somewhere.
>>>
>>> Gerald
>>>
>>> On Tuesday, April 30, 2013, Jason Stapels wrote:
>>>
 An update for the curious. After some prodding from the 
 all-power-Gerald, I was able to bring the board back to life again by... 
 are you ready... holding down the POWER button. Which means I'm probably 
 the biggest idiot ever!? I guess I expected the PWR led to be lit any time 
 5V was feeding the board, regardless of it's On/Off state.

 Certainly, in the dozen or so previous times I plugged the board in, 
 just giving it power caused it to power on, so the idea of the POWER 
 button 
 actually being used to turn it on never occurred to me. If I could save 
 face just a little here, I did actually press it a couple times before 
 throwing in the towel, I just didn't consider holding it down for a few 
 seconds.

 In embarrassed shame,
 ~ Jason

 On Tuesday, April 30, 2013 8:19:57 AM UTC-4, Jason Stapels wrote:
>
> Hi all,
>
> Just wanted to share my experience with my dead BBB. It's my first 
> experience with the Beagle line so it's possible I did something wrong 
> somewhere so I thought it would be a good idea to share my experiences in 
> case other newb's read this. Feel free to skip to the bottom for the 
> symptoms.
>
> -- Begin Background Info --
>
> I was lucky enough to get my BBB almost right away from Digikey. I 
> immediately installed the drivers on my Mac and started playing around 
> with 
> it the first night. Unfortunately, the second night I couldn't get my Mac 
> to allocate an IP address through the USB to talk to it so I thought 
> maybe 
> I shouldn't have skipped that "update software" step. So next I 
> downloaded 
> the latest "flash eMMC" image, wrote it to an SD card and then went 
> through 
> the upgrade process.
>
> Here's where things went a little South. After the first attempt the 
> USR lights eventually went solid (presumably indicating the flashing 
> process was finished) but when I rebooted it without the SD card, the 
> power 
> light would come on but it wouldn't boot. After a couple repower attempts 
> I 
> decided to flash it again. This time, at some point during the flash 
> process, the board seemed to just lose power (all the LEDs were off). 
> Attempts to power the board resulted in the same as before, power light 
> comes on but no booting.
>
> So, my assumption was I messed up the SD card image. I 
> downloaded/reimaged the SD card again, went through the flash process and 
> this time it seemed to finish. Now when I powered on the board it 
> appeared 
> to boot up. However, I still couldn't get it to pick up an IP address 
> from 
> the Mac (after reinstalling both drivers and a couple reboots). I read 
> somewhere that someone had a similar issue and an update to Angstrom 
> solved 
> it.
>
> This time I plugged the board into my linux box and I was able to 
> access the running linux image (yay!). I immediately SSH'd in, and went 
> through the Angstrom upgrade (opkg update; opkg upgrade). The upgrade 
> took 
> awhile and seemed to have a few issues with the new kernel modules 
> (/lib/modules/bl

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[liku50]

Hi Andrew,

Thanks for the reply.

The only log for zygote that i can see in my FTDI output is: 

[   23.539523] warning: `zygote' uses 32-bit capabilities (legacy support 
in use)

Then some other logs like:

[   44.074598] init: sys_prop: permission denied uid:1003  
name:service.bootanim.exit

Is this the expected output??

On Tuesday, 21 October 2014 06:49:52 UTC+5:30, Andrew Henderson wrote:
>
> I don't see any errors that are out of the ordinary in your FTDI output. 
>  How long did you wait before giving up?  If there is a failure on the 
> first boot, you should see some sort of failure beyond that in the log. 
>  You can also run logcat from the FTDI shell to get some more details.  If 
> you see that zygote is started in your log, you're well on your way.  It 
> takes several minutes on the first boot before the top level screen comes 
> up.  Until then, you just see the "Android" animation on the screen.
>
> The FTDI shell belong to the "shell" user and group, not root.  If you'd 
> like to use root, plug in your USB cable and use ADB to shell in to the 
> system.
>
> Andrew
>
>
> On Monday, October 20, 2014 3:26:22 AM UTC-4, lik...@gmail.com wrote:
>>
>>
>> Hi Andrew,
>>
>> Thanks very much for the great work.
>>
>> Now i am trying to port AOSP 4.4.4 (KitKat) for the BBB by using your 
>> repo manifest XML file. I built the U-boot, Kernel Successfully and also 
>> created the Filesystem.  But the problem is after putting all the built 
>> images into the microSD card, while booting i am getting some errors. i 
>> think it is not booting upto the android level, as it is getting stuck 
>> somewhere else. please take a look at the errors: 
>>
>> [2.847248]   #0: TI BeagleBone Black
>> [3.559459] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
>> mode. Opts: (null)
>> [3.568018] VFS: Mounted root (ext4 filesystem) on device 179:2.
>> [3.575446] devtmpfs: mounted
>> [3.578863] Freeing init memory: 244K
>> [4.602721] init (1): /proc/1/oom_adj is deprecated, please use 
>> /proc/1/oom_score_adj instead.
>> [4.705862] init: /dev/hw_random not found
>> [4.710863] init: cannot open '/initlogo.rle'
>> [4.823625] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data 
>> mode. Opts: nomblk_io_submit,errors=panic
>> [4.862816] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>> [4.886477] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>> [4.893231] init: /dev/hw_random not found
>> [4.923083] init: cannot find '/system/bin/sgx/rc.pvr', disabling 'pvr'
>> [4.934643] init: cannot find '/system/bin/rild', disabling 
>> 'ril-daemon'
>> [4.948132] healthd: wakealarm_init: timerfd_create failed
>> [4.958423] healthd: No charger supplies found
>> [4.967361] init: cannot find '/system/etc/install-recovery.sh', 
>> disabling 'flash_recovery'
>> [4.979856] healthd: BatteryStatusPath not found
>> [4.989605] healthd: BatteryHealthPath not found
>> [4.998759] init: property 'sys.powerctl' doesn't exist while 
>> expanding '${sys.powerctl}'
>> [5.012524] healthd: BatteryPresentPath not found
>> [5.018248] healthd: BatteryCapacityPath not found
>> [5.023926] init: powerctl: cannot expand '${sys.powerctl}'
>> [5.030486] healthd: BatteryVoltagePath not found
>> [5.035933] init: property 'sys.sysctl.extra_free_kbytes' doesn't 
>> exist while expanding '${sys.sysctl.extra_free_kbytes}'
>> [5.047582] healthd: BatteryTemperaturePath not found
>> [5.053002] healthd: BatteryTechnologyPath not found
>> [5.058308] init: cannot expand '${sys.sysctl.extra_free_kbytes}' 
>> while writing to '/proc/sys/vm/extra_free_kbytes'
>> [5.069792] binder: 91:91 transaction failed 29189, size 0-0
>> [5.076145] init: property 'sys.sysctl.tcp_def_init_rwnd' doesn't 
>> exist while expanding '${sys.sysctl.tcp_def_init_rwnd}'
>> [5.088106] init: cannot expand '${sys.sysctl.tcp_def_init_rwnd}' 
>> while writing to '/proc/sys/net/ipv4/tcp_default_init_rwnd'
>> *shell@beagleboneblack:/ $*
>>
>> I am expecting *root@android* over here, whereas i am getting 
>> *shell@beagleboneblack* in this case
>>
>> Could you please help me out on this. Expecting a quick response from 
>> your end..
>>
>>
>> After 
>> On Sunday, 28 September 2014 20:44:24 UTC+5:30, Andrew Henderson wrote:
>>>
>>> Hello all. I have released a new port of Android for the BBB.  This 
>>> version uses AOSP 4.4.4 (KitKat) and the 3.8 Linux kernel. I have made 
>>> build instructions and a pre-made image available at 
>>> http://www.bbbandroid.org.  I use a combination of AOSP repos and 
>>> Rowboat build scripts, and I have a few custom repos for the kernel, 
>>> bootloader, and additional "external" tools (such as i2c-tools).  You can 
>>> view the repo manifest XML file for the project here:
>>>
>>>
>>> https://github.com/hendersa/bbbandroid-manifest/blob/master/bbbandroid-aosp-4.4.4_r1-3.8.xml
>>>
>>> Because this Android image uses the 3.8 kernel, you sh

Re: [beagleboard] Beaglebone Black won't power on, did I do something wrong? :(

[Gerald Coley]

You can request an RMA from anywhere. I suggest that you do that. Cost
would be mainly the shipping cost to us.

Gerald

On Tue, Oct 21, 2014 at 6:48 AM,  wrote:

> Hi,
>
> I think I also fried my BBB.
> No led light when powered, either with USB or jack.
>
> Can I request a RMA from Portugal?
> What would be the expected cost?
>
> Thanks
> Bruno
>
> On Thursday, July 4, 2013 3:38:46 PM UTC+1, Gerald wrote:
>>
>> You have blown the processor. Request an RMA.
>>
>> beagleboard.org/support/rma
>>
>> No fuses on the board. Plugging in the USB and DC supply is totally
>> acceptable and supported.
>>
>> Gerald
>>
>>
>>
>> On Thu, Jul 4, 2013 at 3:21 AM, Will Kostelecky 
>> wrote:
>>
>>> Help!
>>>
>>> My BBB was working fine, great in fact, but not so much at the moment.
>>> When I plug it into a power source, be it a known good 5v supply that I
>>> have been using with it for weeks, or into either of two computers via USB,
>>> I get one dim little flash from the power LED and then NOTHING else.   No
>>> other lights flash.   If I hold down the power switch I will get another
>>> brief and dim flash after a couple of seconds.   Again, no other LEDs light
>>> and nothing else happens.
>>>
>>> This started to happen when I plugged the BBB into a computer using a
>>> USB cable while it was still plugged into the 5V power source.  Could this
>>> have fried something?   Are there any poly fuses that might come back to
>>> life after a rest?
>>>
>>> Frustrating as I was making such good progress on my project!
>>>
>>> Will
>>>
>>>
>>> On Tuesday, 30 April 2013 15:23:23 UTC+1, Gerald wrote:
>>>
 You are a pioneer! Columbus was not looking for America. But you are
 now the Columbus of the power button!

 I am trying convince the SW folks to add support for the power button
 but it is down the list  somewhere.

 Gerald

 On Tuesday, April 30, 2013, Jason Stapels wrote:

> An update for the curious. After some prodding from the
> all-power-Gerald, I was able to bring the board back to life again by...
> are you ready... holding down the POWER button. Which means I'm probably
> the biggest idiot ever!? I guess I expected the PWR led to be lit any time
> 5V was feeding the board, regardless of it's On/Off state.
>
> Certainly, in the dozen or so previous times I plugged the board in,
> just giving it power caused it to power on, so the idea of the POWER 
> button
> actually being used to turn it on never occurred to me. If I could save
> face just a little here, I did actually press it a couple times before
> throwing in the towel, I just didn't consider holding it down for a few
> seconds.
>
> In embarrassed shame,
> ~ Jason
>
> On Tuesday, April 30, 2013 8:19:57 AM UTC-4, Jason Stapels wrote:
>>
>> Hi all,
>>
>> Just wanted to share my experience with my dead BBB. It's my first
>> experience with the Beagle line so it's possible I did something wrong
>> somewhere so I thought it would be a good idea to share my experiences in
>> case other newb's read this. Feel free to skip to the bottom for the
>> symptoms.
>>
>> -- Begin Background Info --
>>
>> I was lucky enough to get my BBB almost right away from Digikey. I
>> immediately installed the drivers on my Mac and started playing around 
>> with
>> it the first night. Unfortunately, the second night I couldn't get my Mac
>> to allocate an IP address through the USB to talk to it so I thought 
>> maybe
>> I shouldn't have skipped that "update software" step. So next I 
>> downloaded
>> the latest "flash eMMC" image, wrote it to an SD card and then went 
>> through
>> the upgrade process.
>>
>> Here's where things went a little South. After the first attempt the
>> USR lights eventually went solid (presumably indicating the flashing
>> process was finished) but when I rebooted it without the SD card, the 
>> power
>> light would come on but it wouldn't boot. After a couple repower 
>> attempts I
>> decided to flash it again. This time, at some point during the flash
>> process, the board seemed to just lose power (all the LEDs were off).
>> Attempts to power the board resulted in the same as before, power light
>> comes on but no booting.
>>
>> So, my assumption was I messed up the SD card image. I
>> downloaded/reimaged the SD card again, went through the flash process and
>> this time it seemed to finish. Now when I powered on the board it 
>> appeared
>> to boot up. However, I still couldn't get it to pick up an IP address 
>> from
>> the Mac (after reinstalling both drivers and a couple reboots). I read
>> somewhere that someone had a similar issue and an update to Angstrom 
>> solved
>> it.
>>
>> This time I plugged the board into my linux box and I was able to
>> access the

Re: [beagleboard] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6

[Robert Nelson]

On Tue, Oct 21, 2014 at 8:29 AM,   wrote:
>
> Hello ,
>
> could anyone please tell me what is happing here i am telling here every
> thing step vise
>
> Download kernel from : git clone git://github.com/beagleboard/kernel.git
> cd kernel
> git checkout 3.8
> ./patch.sh
> cp configs/beaglebone kernel/arch/arm/configs/beaglebone_defconfig
> wget
> http://arago-project.org/git/projects/?p=am33x-cm3.git\;a=blob_plain\;f=bin/am335x-pm-firmware.bin\;hb=HEAD
> -O kernel/firmware/am335x-pm-firmware.bin
> cd kernel
> make ARCH=arm CROSS_COMPILE=arm-linux-gnu- beaglebone_defconfig
> make ARCH=arm CROSS_COMPILE=arm-linux-gnu- uImage dtbs
>
> After these step i got zImage and am335x-bone.dtb
>
> Then i have created partition on SD card take a look of SD card partition
>
> http://elinux.org/Building_BBB_Kernel#Downloading_and_building_the_Linux_Kernel

Some needs to delete/rewrite that section, i'll let you do that...
here's what you need to change:

git tree:
https://github.com/beagleboard/linux

branch:
3.8

config:
bb.org_defconfig

drop firmware

make ARCH=arm CROSS_COMPILE=arm-linux-gnu- bb.org_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnu- zImage modules dtbs

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: bare metal programming in C - what is need on the SD card?

[Jason Kridner]

On Mon, Oct 20, 2014 at 9:23 AM,  wrote:

> Hello,
>
> after nearly 2 weeks of struggling my first LED blinking works under the
> following constitution:
> -) Beaglebone black, Element14, rev.C
> -) no OS --> holding "boot" button, when powering
> -) Code Composure Studio v6
> -) Starterware (without BBB patch:
>
> http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/index_FDS.html
> (DOES NOT WORK AT THE MOMENT)
> -) XDS100v2 emulator
>
> 1.)
> The maximum frequency for toggling the pin is 1.6 MHz,
> but I need maximum speed.
> In my understanding there is still a speed decrease as the system is
> running in *emulation *mode.
> Correct?
>

I don't think emulation should slow you down if you are using hardware
breakpoints. The recommendations on using the PRUs would certainly result
in improved switching times, but I'm confident you could optimize your ARM
Cortex-A8 code quite a bit as well. Care to share your source and your
compilation options? Did you use "-O3" for example? Are you going through a
non-optimal library? Would you consider optimizing at the
cache/assembly/etc levels?


>
> 2.)
> From the build process of CCS I have got a .out file.
> *What are the next steps to get the program running from the SD card?*
> Please be very precise - I have already heard of MOL, u-boot, GEL
> file,,
> but there does not seem to be a step-by-step tutorial.
>

The StarterWare boot instructions as mentioned elsewhere should help. I
thought those instructions were fairly step-by-step. U-boot SPL (MLO) seems
like it would provide the most open and extensible examples. I suggest you
try writing the step-by-step.


>
> 3.)
> *What are the next steps to get the program running from the eMMC?*
>
>
> You see, I want to do bare-metal C programming, without linux or any other
> OS,
> as I must operate (pin toggling, computations,...) as fast as possible.
>

The eMMC looks just like an SD card to the processor. You simply need to
flash your code onto the eMMC the same way you would an SD card---except
that you can't remove it. You could boot over USB if you want to program
the eMMC without doing it from an existing system booted off of the eMMC or
SD ports. See https://github.com/ungureanuvladvictor/BBBlfs.


>
>
> Your help is very appreciated!
>
> Reinhard
>
>  --
> 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] USB Camera on BBB (Debian GNU/Linux 7)

[DLF]

running the same kernel & camera I got it workingmy notes are here, ... 
you may find some hints

http://dumb-looks-free.blogspot.fr/2014/05/beaglebone-black-bbb-with-logitech-c270.html

On Tuesday, 21 October 2014 09:49:16 UTC+2, sid...@gmail.com wrote:
>
> Hello all,
> same issue with me. i can not find /dev/video0 
> i am using Debian  on beaglebone black rev C
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
> GNU/Linux
>
>
> debian@beaglebone:~$ lsusb
> Bus 001 Device 003: ID 413c:1004 Dell Computer Corp. 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 004: ID 413c:2006 Dell Computer Corp. 
> Bus 001 Device 007: ID 046d:0825 Logitech, Inc. Webcam C270
> Bus 001 Device 006: ID 15d9:0a4f Trust International B.V. 
>
>
> debian@beaglebone:~$ lsmod | grep video
> uvcvideo   57013  0 
> videobuf2_vmalloc   2490  1 uvcvideo
>
> debian@beaglebone:~$ sudo modprobe uvcvideo
>
> doesn't show any output.
> any suggestion?
>

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

Re: [beagleboard] Implementing a ring buffer / circular buffer for communnication between PRU and ARM on BBB.

[Guy Grotke]

I have not done this with the PRU, but I work with all sorts of other 
chips that have to use ring buffers.  It is usually easiest to start 
with head = tail = 0 as the starting (buffer empty) case. Then drop 
bytes on the sender side if head++ would == tail.  It gets really simple 
if the head and tail indexes (not pointers) are a data size that equals 
the size of your ring buffer, for example a 256 byte buffer with 
unsigned char indexes, because then you just increment the indexes right 
across the 255=>0 wrap point.


On 10/21/2014 8:06 AM, Bas Laarhoven wrote:

On 21-10-2014 16:33, Charles Steinkuehler wrote:

On 10/20/2014 4:05 PM, Rafael Vega wrote:

Thanks for the input Peter, you made me realize I had a mistake:

The idea here is that ONLY the PRU changes the end pointer (write 
position

pointer) and ONLY the ARM changes the start pointer (read position
pointer).  Also, the pointers are updated AFTER the data is read or 
written

(thus the memory barrier on the ARM side).

When the ARM is reading/updating the start pointer, the PRU could write
messages to fill the buffer, changing the start pointer and 
corrupting the
buffer. To avoid this, I have changed the PRU code as follows. Note 
that if
the buffer is full, new messages will be dropped, you can lower the 
chances

of this happening by making the buffer larger.

inline void buffer_write(unsigned int message){
unsigned int is_full = (*buffer_end == 
(*buffer_start^buffer_size)); //

^ is orex
if(!is_full){
   shared_ram[*buffer_end & (buffer_size-1)] = message;
   *buffer_end = (*buffer_end+1) & (2*buffer_size - 1);
}
}

Careful with the buffer size handling!  It's hard to tell the difference
between empty and full, since in both cases the read and write pointers
are identical.

It looks like you're trying to use an extra bit of buffer_end to track
empty/full, but I don't think your logic is correct.  I don't see how
the MSB (indicating buffer full) ever gets cleared once set.

I've found it's usually much less hassle to live with a maximum buffer
size of N-1 (ie: full = 127 elements, not 128) rather than try to
properly handle the complexity of properly tracking empty/full. Note
that there are *LOTS * of subtle ways you can mess up the empty/full
logic (it's even harder to do properly than the basic pointer handling
for reads/writes), so if you do try to use all buffer elements, be
*VERY* careful with your code.  I recommend reviewing the Linux kernel
code if you need a reference implementation.



Rafael,

This is good advice from Charles! I've been running this n-1 scheme 
with my own
PRU code and BeBoPr software for over two years now and it has proven 
rock stable.
No concurrency or cache coherency issues, no locking needed and no 
data re-ordering

problems!

You can find the C-code in the following file:
https://github.com/modmaker/BeBoPr/blob/master/pruss_stepper.c
(start with 'pruss_command')
The PRUSS code is not open source, but I think the C-code shows enough 
detail.


Cheers,
-- Bas



--
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] Detailed instructions on how to edit the LCD4/LCD7 DTO P9_21 dependancy to open SPI/UART

[mettingc]

I am trying to prototype a handheld sensor with a touchscreen display using 
the LCD4 and the ADC from Circuitco. After searching the internet for a 
while I learned that there is a conflict between the two capes at P9_21 and 
that the LCD4 cape doesn't actually use it. Furthermore, it looks like the 
LCD4/7 device trees are loaded at boot and so the only way to fix the 
problem is to recompile the kernel. I know what lines to remove from the 
LCD device tree; however, I've never compiled a kernel before and there are 
a lot of different instructions for the beaglebone pointing to various 
repositories, tools, etc. and I don't know how to filter out what I need. 
Has anyone done this before and can you provide a newbie explanation of how 
to accomplish 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] LCD Resistive Touchscreen with BBB

[James Le]

Will a touchscreen such as this 
(http://www.ebay.com/itm/7-Inch-N070ICG-LD4-1280-800-LCD-Panel-HDMI-VGA-2AV-Driver-Board-Touch-Screen-/191131777439?pt=US_Laptop_Screens_LCD_Panels&hash=item2c8057799f)
 
with its usb touchscreen interface work right out of the box for the 
Beaglebone Black? I'll be using a Debian-machinekit version linux on the 
BeagleBone so that I can use either Touchy or gmoccapy to control LinuxCNC. 

-- 
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] Implementing a ring buffer / circular buffer for communnication between PRU and ARM on BBB.

[Rafael Vega]

Thanks everyone for the feedback! This is indeed more tricky than I had 
thought. 
I'll post back later with a revised implementation 
:)



On Tuesday, October 21, 2014 12:44:05 PM UTC-5, Guy Grotke wrote:
>
> I have not done this with the PRU, but I work with all sorts of other 
> chips that have to use ring buffers.  It is usually easiest to start 
> with head = tail = 0 as the starting (buffer empty) case. Then drop 
> bytes on the sender side if head++ would == tail.  It gets really simple 
> if the head and tail indexes (not pointers) are a data size that equals 
> the size of your ring buffer, for example a 256 byte buffer with 
> unsigned char indexes, because then you just increment the indexes right 
> across the 255=>0 wrap point. 
>
> On 10/21/2014 8:06 AM, Bas Laarhoven wrote: 
> > On 21-10-2014 16:33, Charles Steinkuehler wrote: 
> >> On 10/20/2014 4:05 PM, Rafael Vega wrote: 
> >>> Thanks for the input Peter, you made me realize I had a mistake: 
> >>> 
> >>> The idea here is that ONLY the PRU changes the end pointer (write 
> >>> position 
> >>> pointer) and ONLY the ARM changes the start pointer (read position 
> >>> pointer).  Also, the pointers are updated AFTER the data is read or 
> >>> written 
> >>> (thus the memory barrier on the ARM side). 
> >>> 
> >>> When the ARM is reading/updating the start pointer, the PRU could 
> write 
> >>> messages to fill the buffer, changing the start pointer and 
> >>> corrupting the 
> >>> buffer. To avoid this, I have changed the PRU code as follows. Note 
> >>> that if 
> >>> the buffer is full, new messages will be dropped, you can lower the 
> >>> chances 
> >>> of this happening by making the buffer larger. 
> >>> 
> >>> inline void buffer_write(unsigned int message){ 
> >>> unsigned int is_full = (*buffer_end == 
> >>> (*buffer_start^buffer_size)); // 
> >>> ^ is orex 
> >>> if(!is_full){ 
> >>>shared_ram[*buffer_end & (buffer_size-1)] = message; 
> >>>*buffer_end = (*buffer_end+1) & (2*buffer_size - 1); 
> >>> } 
> >>> } 
> >> Careful with the buffer size handling!  It's hard to tell the 
> difference 
> >> between empty and full, since in both cases the read and write pointers 
> >> are identical. 
> >> 
> >> It looks like you're trying to use an extra bit of buffer_end to track 
> >> empty/full, but I don't think your logic is correct.  I don't see how 
> >> the MSB (indicating buffer full) ever gets cleared once set. 
> >> 
> >> I've found it's usually much less hassle to live with a maximum buffer 
> >> size of N-1 (ie: full = 127 elements, not 128) rather than try to 
> >> properly handle the complexity of properly tracking empty/full. Note 
> >> that there are *LOTS * of subtle ways you can mess up the empty/full 
> >> logic (it's even harder to do properly than the basic pointer handling 
> >> for reads/writes), so if you do try to use all buffer elements, be 
> >> *VERY* careful with your code.  I recommend reviewing the Linux kernel 
> >> code if you need a reference implementation. 
> >> 
> > 
> > Rafael, 
> > 
> > This is good advice from Charles! I've been running this n-1 scheme 
> > with my own 
> > PRU code and BeBoPr software for over two years now and it has proven 
> > rock stable. 
> > No concurrency or cache coherency issues, no locking needed and no 
> > data re-ordering 
> > problems! 
> > 
> > You can find the C-code in the following file: 
> > https://github.com/modmaker/BeBoPr/blob/master/pruss_stepper.c 
> > (start with 'pruss_command') 
> > The PRUSS code is not open source, but I think the C-code shows enough 
> > detail. 
> > 
> > Cheers, 
> > -- Bas 
> > 
>
>

-- 
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] GPIO burnout with Beaglebone black

[sixvolts]

I'm having a problem where GPIO pins will stop working the beaglebone black.

I've hooked up a 3.3v RS485 transceiver and that all seems to working fine. 
We hooked up a GPIO pin (pin 25 on P9, GPIO 117) to monitor the receive 
output of the transceiver to check to see if the bus is active or quiet. 

This pin seems to work for a few minutes and the stop working forever on 
each beaglebone black. However, everything works just fine on our older 
beaglebone white boards. Any idea if something changed or what's going on? 

-- 
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] GPIO burnout with Beaglebone black

[Gerald Coley]

Are you doing this part correctly?

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Usage

Gerald



On Tue, Oct 21, 2014 at 1:48 PM, sixvolts  wrote:

> I'm having a problem where GPIO pins will stop working the beaglebone
> black.
>
> I've hooked up a 3.3v RS485 transceiver and that all seems to working
> fine. We hooked up a GPIO pin (pin 25 on P9, GPIO 117) to monitor the
> receive output of the transceiver to check to see if the bus is active or
> quiet.
>
> This pin seems to work for a few minutes and the stop working forever on
> each beaglebone black. However, everything works just fine on our older
> beaglebone white boards. Any idea if something changed or what's going on?
>
> --
> 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] GPIO Burnout Problem on Beaglebone Black

[crazybucket]

I'm working on a project and we keep seeing this bizarre issue where GPIO 
pins just stop working. 

We've hooked up pin 25 (GPIO 117) to the receive side of a 3.3v RS485 
transceiver to monitor for traffic on the bus. The pin seems to work for a 
little bit, and then stop working forever.

To add another level of bizarreness, this problem does not happen on the 
older beaglebone whites we have, only the blacks. 

Any ideas? We can't find anything wrong with how we've hooked it up or the 
signals coming in/out of the board. 

-- 
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] GPIO Burnout Problem on Beaglebone Black

[Gerald Coley]

Are you doing this part correctly?

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Usage

Gerald


On Tue, Oct 21, 2014 at 1:20 PM, crazybucket  wrote:

> I'm working on a project and we keep seeing this bizarre issue where GPIO
> pins just stop working.
>
> We've hooked up pin 25 (GPIO 117) to the receive side of a 3.3v RS485
> transceiver to monitor for traffic on the bus. The pin seems to work for a
> little bit, and then stop working forever.
>
> To add another level of bizarreness, this problem does not happen on the
> older beaglebone whites we have, only the blacks.
>
> Any ideas? We can't find anything wrong with how we've hooked it up or the
> signals coming in/out of the board.
>
> --
> 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] GPIO burnout with Beaglebone black

[sixvolts]

On Tuesday, October 21, 2014 1:52:30 PM UTC-5, Gerald wrote:
>
> Are you doing this part correctly?
>
> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Usage
>
> Gerald
>
>
To the best of my knowledge, yes. We're using all kinds of pins and other 
parts of the board without issues. 

-- 
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] GPIO burnout with Beaglebone black

[Gerald Coley]

You will want to check and see if the pin is being used is defaulted as an
output, Some pins are outputs by default and others are inputs., If you
start driving it before it is set to an input by SW, then that could cause
issues. Check the datasheet for the AM3358.

Gerald


On Tue, Oct 21, 2014 at 2:00 PM, sixvolts  wrote:

>
>
> On Tuesday, October 21, 2014 1:52:30 PM UTC-5, Gerald wrote:
>>
>> Are you doing this part correctly?
>>
>> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Usage
>>
>> Gerald
>>
>>
> To the best of my knowledge, yes. We're using all kinds of pins and other
> parts of the board without issues.
>
> --
> 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: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Yes, that is the expected output.  You're through most of the boot process 
if zygote is started.  Therefore, you aren't experiencing bootloader or 
kernel problems.

Can you describe the problem that you are seeing in more detail?  Do you 
see anything on the screen at all?  You should see the "Android" animation 
screen while the system is starting up.  If you aren't seeing anything at 
all on the screen, then you might be having HDMI issues (like a bad cable 
that isn't reporting EDID information fro your display to the BBB). Look 
back through your FTDI log and look for any messages regarding tilcdc.  If 
you see something like this:

[3.680634] tilcdc 4830e000.lcdc: found TDA19988
[3.686131] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.693072] [drm] No driver support for vblank timestamp query.
[3.699640] tilcdc 4830e000.lcdc: No connectors reported connected with 
modes
[3.707162] [drm] Cannot find any crtc or sizes - going 1024x768
[3.722056] Console: switching to colour frame buffer device 128x48
[3.733792] tilcdc 4830e000.lcdc: fb0:  frame buffer device

... then you are experiencing a cable problem.

If you can see the "Android" animation screen and that screen never exits, 
then let me know and we can troubleshoot from there.  But this:

[   44.074598] init: sys_prop: permission denied uid:1003  
name:service.bootanim.exit

... tells me that your animation screen finished and that the system booted 
up properly.

Andrew


On Tuesday, October 21, 2014 12:48:59 AM UTC-4, lik...@gmail.com wrote:
>
> Hi Andrew,
>
> Thanks for the reply.
>
> The only log for zygote that i can see in my FTDI output is: 
>
> [   23.539523] warning: `zygote' uses 32-bit capabilities (legacy support 
> in use)
>
> Then some other logs like:
>
> [   44.074598] init: sys_prop: permission denied uid:1003  
> name:service.bootanim.exit
>
> Is this the expected output??
>
> On Tuesday, 21 October 2014 06:49:52 UTC+5:30, Andrew Henderson wrote:
>>
>> I don't see any errors that are out of the ordinary in your FTDI output. 
>>  How long did you wait before giving up?  If there is a failure on the 
>> first boot, you should see some sort of failure beyond that in the log. 
>>  You can also run logcat from the FTDI shell to get some more details.  If 
>> you see that zygote is started in your log, you're well on your way.  It 
>> takes several minutes on the first boot before the top level screen comes 
>> up.  Until then, you just see the "Android" animation on the screen.
>>
>> The FTDI shell belong to the "shell" user and group, not root.  If you'd 
>> like to use root, plug in your USB cable and use ADB to shell in to the 
>> system.
>>
>> Andrew
>>
>>
>> On Monday, October 20, 2014 3:26:22 AM UTC-4, lik...@gmail.com wrote:
>>>
>>>
>>> Hi Andrew,
>>>
>>> Thanks very much for the great work.
>>>
>>> Now i am trying to port AOSP 4.4.4 (KitKat) for the BBB by using your 
>>> repo manifest XML file. I built the U-boot, Kernel Successfully and also 
>>> created the Filesystem.  But the problem is after putting all the built 
>>> images into the microSD card, while booting i am getting some errors. i 
>>> think it is not booting upto the android level, as it is getting stuck 
>>> somewhere else. please take a look at the errors: 
>>>
>>> [2.847248]   #0: TI BeagleBone Black
>>> [3.559459] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
>>> mode. Opts: (null)
>>> [3.568018] VFS: Mounted root (ext4 filesystem) on device 179:2.
>>> [3.575446] devtmpfs: mounted
>>> [3.578863] Freeing init memory: 244K
>>> [4.602721] init (1): /proc/1/oom_adj is deprecated, please use 
>>> /proc/1/oom_score_adj instead.
>>> [4.705862] init: /dev/hw_random not found
>>> [4.710863] init: cannot open '/initlogo.rle'
>>> [4.823625] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data 
>>> mode. Opts: nomblk_io_submit,errors=panic
>>> [4.862816] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>>> [4.886477] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>>> [4.893231] init: /dev/hw_random not found
>>> [4.923083] init: cannot find '/system/bin/sgx/rc.pvr', disabling 
>>> 'pvr'
>>> [4.934643] init: cannot find '/system/bin/rild', disabling 
>>> 'ril-daemon'
>>> [4.948132] healthd: wakealarm_init: timerfd_create failed
>>> [4.958423] healthd: No charger supplies found
>>> [4.967361] init: cannot find '/system/etc/install-recovery.sh', 
>>> disabling 'flash_recovery'
>>> [4.979856] healthd: BatteryStatusPath not found
>>> [4.989605] healthd: BatteryHealthPath not found
>>> [4.998759] init: property 'sys.powerctl' doesn't exist while 
>>> expanding '${sys.powerctl}'
>>> [5.012524] healthd: BatteryPresentPath not found
>>> [5.018248] healthd: BatteryCapacityPath not found
>>> [5.023926] init: powerctl: cannot expand '${sys.powerctl}'
>>> [5.030486] healthd: BatteryVoltagePath not found
>>> [5.035933] init: 

Re: [beagleboard] GPIO burnout with Beaglebone black

[sixvolts]

We've configured the pin as an input after the device boots. Even with with 
just a jumper wire between the two pins, an output and an input, the 
behavior on the black and white is different. Here's how we set it up:
sudo sh -c 'echo "60" > /sys/class/gpio/export'
sudo sh -c 'echo "117" > /sys/class/gpio/export'
sudo sh -c 'echo "in" > /sys/class/gpio/gpio60/direction'
sudo sh -c 'echo "in" > /sys/class/gpio/gpio117/direction'
sudo sh -c 'echo "falling" > /sys/class/gpio/gpio60/edge'
sudo sh -c 'echo "falling" > /sys/class/gpio/gpio117/edge'



On Tuesday, October 21, 2014 2:16:48 PM UTC-5, Gerald wrote:
>
> You will want to check and see if the pin is being used is defaulted as an 
> output, Some pins are outputs by default and others are inputs., If you 
> start driving it before it is set to an input by SW, then that could cause 
> issues. Check the datasheet for the AM3358.
>
> Gerald
>
>
> On Tue, Oct 21, 2014 at 2:00 PM, sixvolts 
> > wrote:
>
>>
>>
>> On Tuesday, October 21, 2014 1:52:30 PM UTC-5, Gerald wrote:
>>>
>>> Are you doing this part correctly?
>>>
>>> http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Usage
>>>
>>> Gerald
>>>
>>>
>> To the best of my knowledge, yes. We're using all kinds of pins and other 
>> parts of the board without issues. 
>>
>> -- 
>> 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] GPIO burnout with Beaglebone black

[Gerald Coley]

Did you compare the schematic of the two boards? There are two pins on the
BBB that have a second optional pin connected to it. You need to make sure
you take care of the one you are not using as well.

Gerald


On Tue, Oct 21, 2014 at 2:54 PM, sixvolts  wrote:

> We've configured the pin as an input after the device boots. Even with
> with just a jumper wire between the two pins, an output and an input, the
> behavior on the black and white is different. Here's how we set it up:
> sudo sh -c 'echo "60" > /sys/class/gpio/export'
> sudo sh -c 'echo "117" > /sys/class/gpio/export'
> sudo sh -c 'echo "in" > /sys/class/gpio/gpio60/direction'
> sudo sh -c 'echo "in" > /sys/class/gpio/gpio117/direction'
> sudo sh -c 'echo "falling" > /sys/class/gpio/gpio60/edge'
> sudo sh -c 'echo "falling" > /sys/class/gpio/gpio117/edge'
>
>
>
> On Tuesday, October 21, 2014 2:16:48 PM UTC-5, Gerald wrote:
>>
>> You will want to check and see if the pin is being used is defaulted as
>> an output, Some pins are outputs by default and others are inputs., If you
>> start driving it before it is set to an input by SW, then that could cause
>> issues. Check the datasheet for the AM3358.
>>
>> Gerald
>>
>>
>> On Tue, Oct 21, 2014 at 2:00 PM, sixvolts  wrote:
>>
>>>
>>>
>>> On Tuesday, October 21, 2014 1:52:30 PM UTC-5, Gerald wrote:

 Are you doing this part correctly?

 http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_
 Header_Usage

 Gerald


>>> To the best of my knowledge, yes. We're using all kinds of pins and
>>> other parts of the board without issues.
>>>
>>> --
>>> 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] Implementing a ring buffer / circular buffer for communnication between PRU and ARM on BBB.

[Jason Kridner]

It might be interesting to compare this with the implementation of the
ARM/PRU ring buffer in http://beaglelogic.net. Ideally, we'll end up with a
standard Linux vring implementation for efficiently communicating with the
PRUs. Doing this communications efficiently is big advantage to us looking
at moving to remote_proc rather than using uio_pruss where userspace needs
to get involved and might slow down the data movement.

On Tue, Oct 21, 2014 at 2:44 PM, Rafael Vega  wrote:

> Thanks everyone for the feedback! This is indeed more tricky than I had
> thought.
> I'll post back later with a revised implementation
> :)
>
>
>
>
> On Tuesday, October 21, 2014 12:44:05 PM UTC-5, Guy Grotke wrote:
>>
>> I have not done this with the PRU, but I work with all sorts of other
>> chips that have to use ring buffers.  It is usually easiest to start
>> with head = tail = 0 as the starting (buffer empty) case. Then drop
>> bytes on the sender side if head++ would == tail.  It gets really simple
>> if the head and tail indexes (not pointers) are a data size that equals
>> the size of your ring buffer, for example a 256 byte buffer with
>> unsigned char indexes, because then you just increment the indexes right
>> across the 255=>0 wrap point.
>>
>> On 10/21/2014 8:06 AM, Bas Laarhoven wrote:
>> > On 21-10-2014 16:33, Charles Steinkuehler wrote:
>> >> On 10/20/2014 4:05 PM, Rafael Vega wrote:
>> >>> Thanks for the input Peter, you made me realize I had a mistake:
>> >>>
>> >>> The idea here is that ONLY the PRU changes the end pointer (write
>> >>> position
>> >>> pointer) and ONLY the ARM changes the start pointer (read position
>> >>> pointer).  Also, the pointers are updated AFTER the data is read or
>> >>> written
>> >>> (thus the memory barrier on the ARM side).
>> >>>
>> >>> When the ARM is reading/updating the start pointer, the PRU could
>> write
>> >>> messages to fill the buffer, changing the start pointer and
>> >>> corrupting the
>> >>> buffer. To avoid this, I have changed the PRU code as follows. Note
>> >>> that if
>> >>> the buffer is full, new messages will be dropped, you can lower the
>> >>> chances
>> >>> of this happening by making the buffer larger.
>> >>>
>> >>> inline void buffer_write(unsigned int message){
>> >>> unsigned int is_full = (*buffer_end ==
>> >>> (*buffer_start^buffer_size)); //
>> >>> ^ is orex
>> >>> if(!is_full){
>> >>>shared_ram[*buffer_end & (buffer_size-1)] = message;
>> >>>*buffer_end = (*buffer_end+1) & (2*buffer_size - 1);
>> >>> }
>> >>> }
>> >> Careful with the buffer size handling!  It's hard to tell the
>> difference
>> >> between empty and full, since in both cases the read and write
>> pointers
>> >> are identical.
>> >>
>> >> It looks like you're trying to use an extra bit of buffer_end to track
>> >> empty/full, but I don't think your logic is correct.  I don't see how
>> >> the MSB (indicating buffer full) ever gets cleared once set.
>> >>
>> >> I've found it's usually much less hassle to live with a maximum buffer
>> >> size of N-1 (ie: full = 127 elements, not 128) rather than try to
>> >> properly handle the complexity of properly tracking empty/full. Note
>> >> that there are *LOTS * of subtle ways you can mess up the empty/full
>> >> logic (it's even harder to do properly than the basic pointer handling
>> >> for reads/writes), so if you do try to use all buffer elements, be
>> >> *VERY* careful with your code.  I recommend reviewing the Linux kernel
>> >> code if you need a reference implementation.
>> >>
>> >
>> > Rafael,
>> >
>> > This is good advice from Charles! I've been running this n-1 scheme
>> > with my own
>> > PRU code and BeBoPr software for over two years now and it has proven
>> > rock stable.
>> > No concurrency or cache coherency issues, no locking needed and no
>> > data re-ordering
>> > problems!
>> >
>> > You can find the C-code in the following file:
>> > https://github.com/modmaker/BeBoPr/blob/master/pruss_stepper.c
>> > (start with 'pruss_command')
>> > The PRUSS code is not open source, but I think the C-code shows enough
>> > detail.
>> >
>> > Cheers,
>> > -- Bas
>> >
>>
>>  --
> 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: Unable to deploy Android image on beaglebone black

[William Hermans]

>
> *Since you are using Windows XP, you won't be able to natively mount the
> partitions of your microSD card and look at them to ensure that you wrote
> the image properly. *



I would highly recommend using at minimum a virtual machine for running
some form of Linux as a support system.

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

[David Miller]

Hi Jason,

That was it! I was still using Angstrom. Thanks a lot for your help!

David

On Fri, Oct 17, 2014 at 9:38 PM, Jason Kridner  wrote:

> On Fri, Oct 17, 2014 at 8:03 PM, David Miller 
> wrote:
>
>> Yes, I am using the same webcam as specified. It is working with 'Cheese'
>> app as well as when activated from command line like you suggested. When
>> running under X, I can see it detects faces and adds mustaches to them.
>>
>
> Great!
>
>
>>
>> Not sure if it is relevant, but when executing ./stache under X, I see
>> some errrors like in http://pastebin.com/7V3PcsYt even though the camera
>> streaming is still working.
>>
>
> Those notices at the bottom are harmless.
>
> Sounds like it might be an Xauthority issue. Are you running Angstrom or
> Debian? Reversing this patch might help if using Angstrom:
> https://github.com/jadonk/stache/commit/c2c21510f11bc9cf254f89e1b66a265225d9c565
>
> Have you tried running 'runstache'?
>
>
>>
>> David
>>
>>
>>
>>
>> On Fri, Oct 17, 2014 at 4:41 PM, Jason Kridner 
>> wrote:
>>
>>> On Wed, Oct 15, 2014 at 12:19 PM, David Miller 
>>> wrote:
>>>
 Hi Jason,

 I am trying to re-create the awesome demo
 http://beagleboard.org/project/stache. I have followed the
 instructions there to clone the github repo and 'make & make install' it.
 However, when double clicking the beagle icon on desktop or execute
 ./runstache from the command line nothing is running.

 I checked the log file and see this:

 root@beaglebone:~/stache# cat /var/log/beaglestache.log
 {"level":"info","message":"LED
 initialized","timestamp":"2012-11-22T12:06:20.265Z"}
 {"level":"info","message":"stache exited: 1 signal:
 null","timestamp":"2012-11-22T12:06:20.759Z"}
 {"level":"info","message":"LED
 initialized","timestamp":"2012-11-22T12:20:00.471Z"}
 {"level":"info","message":"End
 LED","timestamp":"2012-11-22T12:20:00.507Z"}
 {"level":"info","message":"stache exited: 1 signal:
 null","timestamp":"2012-11-22T12:20:01.003Z"}
 {"level":"info","message":"LED
 initialized","timestamp":"2012-11-22T12:29:54.564Z"}
 {"level":"info","message":"End
 LED","timestamp":"2012-11-22T12:29:54.601Z"}
 {"level":"info","message":"stache exited: 1 signal:
 null","timestamp":"2012-11-22T12:29:55.070Z"}

 It look like there's some error when the program exits. Do you have any
 pointer that I can use to troubleshoot this?

>>>
>>> Well, I guess we know that the 'runstache' script is running based on
>>> tapping the 'beaglestache.desktop' icon and that it has successfully
>>> launched 'node tweetstache.js'. It seems 'stache' is spawned, but dies
>>> within a second of being launched. Given that the return code is a 1, it
>>> seems it isn't reaching one of the error conditions that exit with an
>>> alternative code.
>>>
>>> Question: Do you have a webcam installed and does it show up to Linux?
>>>
>>> You can attempt to start 'stache' manually by opening up a terminal
>>> under X and running the app. You can do so remotely by using 'ssh -X
>>> root@beaglebone.local' and then executing 'stache'. Please report what
>>> you see on the terminal output.
>>>
>>>

 Thanks!
 David

>>>
>>>
>>
>

-- 
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: Anyone interested in LEGO EV3? I'm trying to transplant EV3 system to Beaglebone Black.

[janszymanski12345]

Congratulations on your wedding, but once married will you have any time 
for the project?
Are you willing to share your work?

Regards
Jan

On Wednesday, October 22, 2014 2:45:26 AM UTC+11, Fat Cat Man wrote:
>
> Yes, I've came to my hometown to hold a wedding ceremony last 2 weeks.
> I've updated all the linux drivers to 1.06x. Now it works fine with the 
> native labview language.
> Now I'm making the smart UART sensor, I have already made a prototype. It 
> can measure couple of analog channels and transmit the data throuth the 
> uart. It means a huge kinds of arduino analog sensors can be used for ev3 
> now: ) And it's very easy to develop any kind of new sensors.
>
>
> 在 2014年10月13日星期一UTC+8上午8时18分48秒，janszyma...@gmail.com写道：
>>
>> Hi,
>>
>>  Are you still working on it?
>> If yes, any progress so far?
>>
>> Jan
>>
>> On Thursday, 17 July 2014 16:21:40 UTC+10, Fat Cat Man wrote:
>>>
>>> As you know, LEGO announced their Mindstorms EV3 robot system last year. 
>>> The EV3 system is based on linux, they published the full source code at 
>>> *https://github.com/mindboards/ev3sources* 
>>>  
>>>
>>> When I got the source code, I was wondering if I can transplant all the 
>>> code to Beaglebone Black. The EV3 use a TI AM1808 MCU as its cpu and BBB 
>>> use TI AM3359. Many of the registers are common. So after several months 
>>> work, I'm almost done. Here are some pitcures shows my progress:
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>>
>>> As you can see, there are still some bugs in the system. After the main 
>>> lms2012 program running for a while, it would appear a warning, and then 
>>> quit. Now I'm designing the cape PCB board. It can provide the input and 
>>> output capacity as same as EV3.
>>>
>>>
>>>
>>>

-- 
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 kernel update

[janszymanski12345]

Hi,

How to update the kernel on BBB debian?


debian@beaglebone:~$ uname -a
Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
GNU/Linux
debian@beaglebone:~$ sudo apt-get install linux-image-3.14.19-ti-r27
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-image-3.14.19-ti-r27
E: Couldn't find any package by regex 'linux-image-3.14.19-ti-r27'
debian@beaglebone:~$


-- 
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] Using nano on Eclipse with Remote System Explorer's ssh terminals

[Curt Carpenter]

Can anyone offer any hints about using the nano editor via the Remote 
System Explorer's ssh terminal?  I can't seem to navigate around the 
editing screen, and end up starting PuTTY to edit files.  Are their some 
configuration files that have to be set up on Eclipse or the RSE?

-- 
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 kernel update

[Robert Nelson]

On Tue, Oct 21, 2014 at 6:29 PM,   wrote:
> Hi,
>
> How to update the kernel on BBB debian?
>
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l
> GNU/Linux
> debian@beaglebone:~$ sudo apt-get install linux-image-3.14.19-ti-r27
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package linux-image-3.14.19-ti-r27
> E: Couldn't find any package by regex 'linux-image-3.14.19-ti-r27'
> debian@beaglebone:~$

cat /etc/dogtag

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] BB - XM using Yocto

[Allan Granados]

Hi,

I have created an Image using Yocto Project and Meta-ti for the BB -XM, 
looking at the kernel messages I saw it only brings up CPU 0. Anyone knows 
if its planned to bring the second CPU in new kernel versions?

The actual kernel version Im using is:
Linux beagleboard 3.14.17 #1 SMP Tue Oct 21 11:15:41 CST 2014 armv7l 
GNU/Linux

And as you can see it only brings up CP0, I dont know if this could be a 
problem with my DTB, although Im specifying the DTB file to load. 
root@beagleboard:~# cat /proc/cpuinfo 
processor   : 0
model name  : ARMv7 Processor rev 2 (v7l)
Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part: 0xc08
CPU revision: 2

Hardware: Generic OMAP36xx (Flattened Device Tree)
Revision: 
Serial  : 

If anyone have information about this it will be a great help. Thanks
--Allan Granados

-- 
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] BB - XM using Yocto

[Robert Nelson]

On Tue, Oct 21, 2014 at 7:58 PM, Allan Granados  wrote:
>
> Hi,
>
> I have created an Image using Yocto Project and Meta-ti for the BB -XM,
> looking at the kernel messages I saw it only brings up CPU 0. Anyone knows
> if its planned to bring the second CPU in new kernel versions?

"second" cpu, since when did the xm (dm3730) grow a second cpu? ;)

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 nano on Eclipse with Remote System Explorer's ssh terminals

[Robert Nelson]

On Tue, Oct 21, 2014 at 7:19 PM, Curt Carpenter <1cjcarpen...@att.net> wrote:
> Can anyone offer any hints about using the nano editor via the Remote System
> Explorer's ssh terminal?  I can't seem to navigate around the editing
> screen, and end up starting PuTTY to edit files.  Are their some
> configuration files that have to be set up on Eclipse or the RSE?

http://www.codexpedia.com/text-editor/nano-text-editor-command-cheatsheet/

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 kernel update

[janszymanski12345]

debian@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org BeagleBone Debian Image 2014-05-14
debian@beaglebone:~$


On Wednesday, October 22, 2014 11:53:57 AM UTC+11, RobertCNelson wrote:
>
> On Tue, Oct 21, 2014 at 6:29 PM,  > 
> wrote: 
> > Hi, 
> > 
> > How to update the kernel on BBB debian? 
> > 
> > 
> > debian@beaglebone:~$ uname -a 
> > Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 
> armv7l 
> > GNU/Linux 
> > debian@beaglebone:~$ sudo apt-get install linux-image-3.14.19-ti-r27 
> > Reading package lists... Done 
> > Building dependency tree 
> > Reading state information... Done 
> > E: Unable to locate package linux-image-3.14.19-ti-r27 
> > E: Couldn't find any package by regex 'linux-image-3.14.19-ti-r27' 
> > debian@beaglebone:~$ 
>
> cat /etc/dogtag 
>
> 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 kernel update

[Robert Nelson]

On Tue, Oct 21, 2014 at 8:43 PM,   wrote:
>
> debian@beaglebone:~$ cat /etc/dogtag
> BeagleBoard.org BeagleBone Debian Image 2014-05-14
> debian@beaglebone:~$

That's pre-repo..

Run:

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --ti-kernel
sudo reboot

This will install: (--ti-kernel switches to the ti channel)

http://rcn-ee.net/deb/wheezy-armhf/LATEST-ti

"v3.14.19-ti-r30"

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 kernel update

[janszymanski12345]

Thanks Robert, but it didn't work

debian@beaglebone:~$ df -h
Filesystem  Size  Used Avail 
Use% Mounted on
rootfs  3.4G  1.5G  1.8G  
45% /
.
debian@beaglebone:~$ cd /opt/scripts/tools/
debian@beaglebone:/opt/scripts/tools$ git pull
.
`/boot/vmlinuz-3.14.19-ti-r30' -> `/boot/uboot/zImage'
`/boot/initrd.img-3.14.19-ti-r30' -> `/boot/uboot/initrd.img'
cp: writing `/boot/uboot/initrd.img': No space left on device
*cp: failed to extend `/boot/uboot/initrd.img': No space left on device*
-
Script done: please reboot
debian@beaglebone:/opt/scripts/tools$

Jan

On Wednesday, October 22, 2014 12:53:44 PM UTC+11, RobertCNelson wrote:
>
> On Tue, Oct 21, 2014 at 8:43 PM,  > 
> wrote: 
> > 
> > debian@beaglebone:~$ cat /etc/dogtag 
> > BeagleBoard.org BeagleBone Debian Image 2014-05-14 
> > debian@beaglebone:~$ 
>
> That's pre-repo.. 
>
> Run: 
>
> cd /opt/scripts/tools/ 
> git pull 
> sudo ./update_kernel.sh --ti-kernel 
> sudo reboot 
>
> This will install: (--ti-kernel switches to the ti channel) 
>
> http://rcn-ee.net/deb/wheezy-armhf/LATEST-ti 
>
> "v3.14.19-ti-r30" 
>
> 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 kernel update

[Robert Nelson]

On Tue, Oct 21, 2014 at 10:23 PM,   wrote:
> Thanks Robert, but it didn't work
>
> debian@beaglebone:~$ df -h
> Filesystem  Size  Used Avail
> Use% Mounted on
> rootfs  3.4G  1.5G  1.8G
> 45% /
> .
> debian@beaglebone:~$ cd /opt/scripts/tools/
> debian@beaglebone:/opt/scripts/tools$ git pull
> .
> `/boot/vmlinuz-3.14.19-ti-r30' -> `/boot/uboot/zImage'
> `/boot/initrd.img-3.14.19-ti-r30' -> `/boot/uboot/initrd.img'
> cp: writing `/boot/uboot/initrd.img': No space left on device
> cp: failed to extend `/boot/uboot/initrd.img': No space left on device

Ran out of space in the "boot" partition, you can either clean up some
of the extra stuff under /boot/uboot/

Or just reflash the latest..

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-10-08

One of the big improvements, we moved the kernel files into the ext4
partition so the above never happens..

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: Linux-3.8.13 with RGB resolution 320x240

[Minh Phuong Dang]

 

> Pls help me,


AM3352 without GPU, should we use drivers/gpu/drm/tilcdc or 
drivers/video/da8xx-fb.c ??? 

  

-- 
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] Beaglebone Black Rev c doesn't boot up

[Amr M.Elsaid]

I made a mistake by connecting a button and an LED to the BeagleBone Black 
Rev C without shutting it down first so It suddenly stopped and nothing is 
lighting up at all and I've tried to connect it to external power supply or 
the usb connection but what happens is the power LED lit up once only and 
dims, and whenever I press the Power button the power LED Light up only 
once and nothing happens, so Is there anything that I can do about it or 
the board is fried?

-- 
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: BBB kernel update

[janszymanski12345]

OK, I did it, but where is uEnv.txt?

before I was able to do that:

in /mnt/emmcfat edit uEnv.txt

##Disable HDMI

#optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

optargs=capemgr.enable_partno=BB-UART1,BB-SPIDEV0

How to do it now?



On Wednesday, 22 October 2014 10:29:12 UTC+11, janszyma...@gmail.com wrote:
>
> Hi,
>
> How to update the kernel on BBB debian?
>
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
> GNU/Linux
> debian@beaglebone:~$ sudo apt-get install linux-image-3.14.19-ti-r27
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package linux-image-3.14.19-ti-r27
> E: Couldn't find any package by regex 'linux-image-3.14.19-ti-r27'
> debian@beaglebone:~$
>
>
>

-- 
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] difference between available beaglebone display capes

[Eric Fort]

what is the difference between

http://www.4dsystems.com.au/product/4DCAPE_70T/
and
http://boardzoo.com/index.php/bone-lcd7.html

or

http://www.4dsystems.com.au/product/4DCAPE_43/
and
http://boardzoo.com/index.php/bone-lcd4.html

are both well supported under the current debian install?  how are these
boards different?


Thanks,

Eric

-- 
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: Anyone interested in LEGO EV3? I'm trying to transplant EV3 system to Beaglebone Black.

[Fat Cat Man]

Of course I will continue working on this project. I'm developing a lot of 
new sensors now : )

After all these works done, I will put the source code to github. At 
present, all the code is a little messy and I don't have time to clear up 
it.

Now I'm finding someone who has BBB and LEGO EV3 to help me test the EVB 
cape : )

在 2014年10月22日星期三UTC+8上午7时10分12秒，janszyma...@gmail.com写道：
>
> Congratulations on your wedding, but once married will you have any time 
> for the project?
> Are you willing to share your work?
>
> Regards
> Jan
>
> On Wednesday, October 22, 2014 2:45:26 AM UTC+11, Fat Cat Man wrote:
>>
>> Yes, I've came to my hometown to hold a wedding ceremony last 2 weeks.
>> I've updated all the linux drivers to 1.06x. Now it works fine with the 
>> native labview language.
>> Now I'm making the smart UART sensor, I have already made a prototype. It 
>> can measure couple of analog channels and transmit the data throuth the 
>> uart. It means a huge kinds of arduino analog sensors can be used for ev3 
>> now: ) And it's very easy to develop any kind of new sensors.
>>
>>
>> 在 2014年10月13日星期一UTC+8上午8时18分48秒，janszyma...@gmail.com写道：
>>>
>>> Hi,
>>>
>>>  Are you still working on it?
>>> If yes, any progress so far?
>>>
>>> Jan
>>>
>>> On Thursday, 17 July 2014 16:21:40 UTC+10, Fat Cat Man wrote:

 As you know, LEGO announced their Mindstorms EV3 robot system last 
 year. The EV3 system is based on linux, they published the full source 
 code 
 at *https://github.com/mindboards/ev3sources* 
  

 When I got the source code, I was wondering if I can transplant all the 
 code to Beaglebone Black. The EV3 use a TI AM1808 MCU as its cpu and BBB 
 use TI AM3359. Many of the registers are common. So after several months 
 work, I'm almost done. Here are some pitcures shows my progress:


 


 


 


 As you can see, there are still some bugs in the system. After the main 
 lms2012 program running for a while, it would appear a warning, and then 
 quit. Now I'm designing the cape PCB board. It can provide the input and 
 output capacity as same as EV3.





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