[beagleboard] Re: beaglebone black PWM
Your best bet is to look at the book Exploring the Beaglebone by Derek Molloy. It gives you all the instructiions to setup a cross compiled environment on a Debian Linux version. It takes time - but DO IT. DOn't compile on the bone. Logn term it is not the way to go. On Thursday, April 14, 2016 at 3:56:50 AM UTC-5, Brainiac wrote: > > hi everyone, > > i'm working with BBB rev C for my final year project , i want to controle > a 3 step by step motors of a 3 axis cartesien robot, i didn't come to a > solution to set up a cross compiler for my BBB , i tried Eclipse and > NetBeans but it didn't work , can u help me to program the BBB ?? the " > Master " want a C program that can generate a PWM , and he wants to > controle the robot using a LabWindows/CVI human-machine interface , that's > another problem for me , i'm stocked , please need 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] 4D 4.3" Display Cape and Debian 8.3 Image compatability
I forgot to followup on this after seeing it multiple times. Touchscreen calibration still seems flaky. Sometimes it works for me. Other times not. Walt On Friday, February 26, 2016 at 6:41:24 PM UTC-6, RobertCNelson wrote: > On Fri, Feb 26, 2016 at 6:19 PM, Robert Nelson <robert...@gmail.com > > wrote: > > On Fri, Feb 26, 2016 at 6:08 PM, Walter Schilling <schi...@msoe.edu > > wrote: > >> Robert: > >> > >> To quote Apollo 13: "you, sir, are a steely-eyed missile man!" > >> > >> Works like a charm now. Now to determine whether I want to change the > image > >> I give my students or have them make this change when they first start > using > >> it. That's the $2000 question. > >> > >> Thanks for helping with the obvious! > > > > Sweet! > > > > BTW, don't get "too" attached to that image.. (i have a replacement > > being generated right now..) > > > > I just landed some patches today to utilize: > > > > https://github.com/nodesource/distributions > > > > for nodejs v0.12.x > > > > That's the really only change from last sunday's. it add's an > > additional repo in /etc/apt/sources.list... > > btw did the touch screen calibration actually works this time on first > bootup? > > We still need to tweak the filter on the v4.1.x adc/touchscreen driver.. > > Regards, > -- > Robert Nelson > https://rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PWM On Beaglebone black with Jessie
OK, so here is where I am at: #1 I wrote the following script, and, well it worked great... Until I had to reboot my machine: *#!/bin/bash# SE3910 Real Time Systems# PWM Bash shell script.# Author: W. Schilling# This script will enable PWM on the beaglebone connected to ECAPPWM0.# It will set the duty cycle to the value passed in, which is a value between 1 and 1.* *# Setup the pin as a PWM pin.config-pin P9.42 pwm* *# Export the control for the device, creating the directory structure that we w$echo 0 > /sys/class/pwm/pwmchip0/export* *# Setup the period for PWM to be 1 to make things nice and easy to work wit$echo 1 > /sys/class/pwm/pwmchip0/pwm0/period* *# Setup the duty cycle to the value passed in as $1echo $1 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle* *# Enable pwm echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable* However, when I rebooted my machine, the pin failed to toggle. I believe I inadvertently did something with capes that wasn't enabled when I first tried it. I then tried this script on my home beaglebone, running Robert Nelson's image bone-debian-8.3-lxqt-4gb-armhf-2016-02-21-4gb.img. This one, however, fails with the following: root@beaglebone:~# ./pwm2.sh 1000 P9_42 pinmux file not found! cape-universala overlay not found run "config-pin overlay cape-universala" to load the cape ./pwm2.sh: line 12: echo: write error: Device or resource busy ./pwm2.sh: line 15: /sys/class/pwm/pwmchip0/pwm0/period: No such file or directory ./pwm2.sh: line 18: /sys/class/pwm/pwmchip0/pwm0/duty_cycle: No such file or directory ./pwm2.sh: line 21: /sys/class/pwm/pwmchip0/pwm0/enable: No such file or directory root@beaglebone:~# I've tried the following, which results in different errors but still errors: root@beaglebone:~# config-pin overlay cape-universaln Loading cape-universaln overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-universaln root@beaglebone:~# ./pwm2.sh 1000 P9_42 pinmux file not found! cape-universala overlay not found run "config-pin overlay cape-universala" to load the cape ./pwm2.sh: line 12: echo: write error: Device or resource busy ./pwm2.sh: line 15: /sys/class/pwm/pwmchip0/pwm0/period: No such file or directory ./pwm2.sh: line 18: /sys/class/pwm/pwmchip0/pwm0/duty_cycle: No such file or directory ./pwm2.sh: line 21: /sys/class/pwm/pwmchip0/pwm0/enable: No such file or directory root@beaglebone:~# Ideas to try next? Walt -- 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] PWM On Beaglebone black with Jessie
Thanks. That helps quite a bit. I've still not quite got everything working, but I'm making headway. Now to find the magic decoder ring of pwm chips to pins and ports. On Monday, March 14, 2016 at 2:31:48 PM UTC-5, RobertCNelson wrote: > > On Mon, Mar 14, 2016 at 2:18 PM, Walter Schilling <schi...@msoe.edu > > wrote: > > I don't even see anything resembling bone_capemgr. This is my > /sys/devices > > directory: > > > > root@beaglebone:/sys/devices# ls > > armv7_cortex_a8 > > platform > > software > > tracepoint > > breakpoint > > soc0 > > system > > virtual > > root@beaglebone:/sys/devices# > > With "4.1" it's > > /sys/devices/platform/bone_capemgr/slots > > see: https://github.com/beagleboard/bb.org-overlays/ > > If you want 3.8, to match Derek's book: > > Use: Debian 7.9 from: > > http://beagleboard.org/latest-images > > Regards, > > > -- > Robert Nelson > https://rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] PWM On Beaglebone black with Jessie
I don't even see anything resembling bone_capemgr. This is my /sys/devices directory: root@beaglebone:/sys/devices# ls armv7_cortex_a8 platform software tracepoint breakpoint soc0 system virtual root@beaglebone:/sys/devices# On Monday, March 14, 2016 at 10:23:38 AM UTC-5, cmbaker3 wrote: > > Walt, > Try using a "*" in place of the "9". > Chad > > On 3/14/16 9:13 AM, Walter Schilling wrote: > > Good evening. > > I am currently using the latest beaglebone black debian image, and I am > trying to get pwm to work on the board using the instructions in Molloy's > Exploring the Beaglebone. Unfortunately, shall we say, it doesn't seem to > be working. I am unable to see the bone_capemgr.9 directory to setup the > SLOTS export. I suspect this may be due to changes between Debian > releases. With that being the case, is there some location that has the > current instructions for setting up the PWM module with the current image? > > Walt > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] PWM On Beaglebone black with Jessie
Good evening. I am currently using the latest beaglebone black debian image, and I am trying to get pwm to work on the board using the instructions in Molloy's Exploring the Beaglebone. Unfortunately, shall we say, it doesn't seem to be working. I am unable to see the bone_capemgr.9 directory to setup the SLOTS export. I suspect this may be due to changes between Debian releases. With that being the case, is there some location that has the current instructions for setting up the PWM module with the current image? Walt -- 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] 4D 4.3" Display Cape and Debian 8.3 Image compatability
Robert: To quote Apollo 13: "you, sir, are a steely-eyed missile man!" Works like a charm now. Now to determine whether I want to change the image I give my students or have them make this change when they first start using it. That's the $2000 question. *Thanks for helping with the obvious!* *Walt* On Friday, February 26, 2016 at 5:51:52 PM UTC-6, Walter Schilling wrote: > > Let me grab that one and see if it works better. > > On Friday, February 26, 2016 at 5:48:41 PM UTC-6, RobertCNelson wrote: >> >> On Fri, Feb 26, 2016 at 5:41 PM, Walter Schilling <schi...@msoe.edu> >> wrote: >> > Good afternoon. >> > >> > I am upgrading a course I teach to use the Debian 8.3 image that was >> > released in January. In the course, we use the 4D Systems 4.3" cape as >> a >> > touchscreen, and I am having difficulty getting it to work with the 8.3 >> > Debian release. My larger displays plug in and work fine, but the >> smaller >> > displays do not display anything. For right now I am booting off of a >> uSD, >> > though eventually I'm going to reflash the board itself. I'm sure it's >> a >> > simple config issue somewhere; I'm just not sure where to look. I >> tried a >> > few of the things mentioned in older posts (i.e. June 2015 or so) but >> did >> > not necessarily have any success (and I would have figured those >> changes >> > would have made it into the January 2016 release. >> > >> > Any ideas? >> >> Well how does: >> >> >> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots >> >> >> Compare: >> >> /boot/uEnv.txt >> >> dtb=am335x-boneblack-emmc-overlay.dtb >> >> Regards, >> >> -- >> Robert Nelson >> https://rcn-ee.com/ >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] 4D 4.3" Display Cape and Debian 8.3 Image compatability
Let me grab that one and see if it works better. On Friday, February 26, 2016 at 5:48:41 PM UTC-6, RobertCNelson wrote: > > On Fri, Feb 26, 2016 at 5:41 PM, Walter Schilling <schi...@msoe.edu > > wrote: > > Good afternoon. > > > > I am upgrading a course I teach to use the Debian 8.3 image that was > > released in January. In the course, we use the 4D Systems 4.3" cape as > a > > touchscreen, and I am having difficulty getting it to work with the 8.3 > > Debian release. My larger displays plug in and work fine, but the > smaller > > displays do not display anything. For right now I am booting off of a > uSD, > > though eventually I'm going to reflash the board itself. I'm sure it's > a > > simple config issue somewhere; I'm just not sure where to look. I tried > a > > few of the things mentioned in older posts (i.e. June 2015 or so) but > did > > not necessarily have any success (and I would have figured those changes > > would have made it into the January 2016 release. > > > > Any ideas? > > Well how does: > > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots > > > Compare: > > /boot/uEnv.txt > > dtb=am335x-boneblack-emmc-overlay.dtb > > Regards, > > -- > Robert Nelson > https://rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] 4D 4.3" Display Cape and Debian 8.3 Image compatability
Good afternoon. I am upgrading a course I teach to use the Debian 8.3 image that was released in January. In the course, we use the 4D Systems 4.3" cape as a touchscreen, and I am having difficulty getting it to work with the 8.3 Debian release. My larger displays plug in and work fine, but the smaller displays do not display anything. For right now I am booting off of a uSD, though eventually I'm going to reflash the board itself. I'm sure it's a simple config issue somewhere; I'm just not sure where to look. I tried a few of the things mentioned in older posts (i.e. June 2015 or so) but did not necessarily have any success (and I would have figured those changes would have made it into the January 2016 release. Any ideas? Thanks, Walt -- 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: Could use some bug tracking advice.
William: Shared memory is notoriously hard, and as has been pointed out, it really sounds like a synchronization issue that you are facing. Which leads to a couple of design questions: #1 Could what you are doing be accomplished with a POSIX threads system instead of processes? This would mean you would not need to copy the data over, just simply pass pointers from one thread to another in a producer-consumer model. #2 If you can not accomplish your solution via threads, how big is the data that you are sending and how often is it being sent? Maybe a pipe might be a better solution, as pipes intrinsically have their own synchronization built in. Walt On Sunday, August 23, 2015 at 12:31:43 AM UTC-5, William Hermans wrote: So I have a problem with some code I've been working on for the last few months. The code, which is compiled into two separate processes suddenly stops working. No error, nothing in dmesg, nothing in any file in /var/log period. It did however occur to me that since rsyslog is likely or possible disabled. What my code does is read from the CAN peripheral. Form extended packets out of the CAN frames( NMEA 2000 fastpackets ), and then writes the data into a POSIX shared memory file ( /dev/shm/file ). The second process simply reads from the file, and shuffles the data out over a websocket in json / human readable form. The data on the webside of things is tested accurate, although I do occasionally get a malformed json object warning from firefox firebug. The kernel I'm currently using is 4.2.0-rc4-bone2, which seems to have no noticeable problems. Anyway, I'm relatively new to Linux development, and was wondering if anyone might be able to offer some advice as to how I can track this down. It did occur to me that I could attempt to trap process signals, and see if anything interesting comes of that. Short of this however, do I have any other options ? Since my code runs for days before the processes stopping - I'm pretty sure the traditional gdb, strace / ltrace options would be ineffective. But maybe I'm wrong ? -- 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 4xInput Audio Channel
You might take a look at 4 channel audio input cards / devices. They are not cheap, but they can easily handle 4 inputs at the same time. One such device is http://www.amazon.com/Alesis-iO4-Four-Channel-Recording-Interface/dp/B004NMVUV4/ref=pd_ybh_2 On Thursday, May 28, 2015 at 8:28:15 AM UTC-5, sabe...@gmail.com wrote: Hi, I need to process 4 Audio Channels on BBB. The channels need to have resolution of atleast 16 bits and sampling of 48KHz. I need to know what kind of options could help me achieve this goal if its possible. Use 1xUSB Hub and 2xUSB sound cards containing mono inputs and use Beagle Boards USB port to stream in data. *4 Channel* Use 1xUSB Hub and 4xUSB sound cards containing mono microphone inputs. OR 2xAudio Cape of BeagleBone which can handle stereo input. OR Some other interface/board/cape that can handle 4x input channels. Any ideas ? Regards, -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
Pin muxing is something that can very easily be controlled in software / managed with software changes and routing on the board. However, if the physical interface is different, you end up throwing out all of the peripherals you have. Think of it this way: how standard would USB be if each version used a different physical interconnect? They haven't. There's a few standard interfaces out there for the hardware. Walt On Wednesday, May 20, 2015 at 10:05:15 AM UTC-5, Gerald wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schi...@msoe.edu javascript: wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org javascript: http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Future of BeagleBone (Black)?
I guess I should mention why, at least to me, it does matter. We use the Beagle in coursework on campus, teaching students how to develop real time systems. We first started out with the XM, and a set of peripherals. However, right as we were ready to gear up for the course, the XM peripherals became unavailable. So we switched to the bone, which was being supported at the time. But then as the class was rolling out, after we had designed the course to run with the BB Blacks, the Blacks disappeared from inventory (not to repeat that at all..) So we had to downgrade to the whites. But about the same time, access to the Angstrom distribution essentially vanished for a while as well. So we were somewhat stuck. This year things went smoother, as everything was available. But the challenge is, to do the course, we've got probably $400-$500 worth of equipment per student enrolled in the course. That's about $25-30K in equipment that needs to be amortized out over multiple years. So I guess, that's why I'm a bit concerned about incompatible formats being developed. On Wednesday, May 20, 2015 at 10:43:53 AM UTC-5, William Hermans wrote: Also, we're talking 10 years down the road here. Whose to say what will happen by then. Take a look at the MSP430 line of MCUs for example. I do not know the exact history of the MCU line, but it became popular, and it is still with us . . . refreshes have been made, changes / variations have been made. Now we have many different classes of MSP430 MCUs for different use cases. Lately TI even extended the MSP430 line by mixing in the M4F processor . For high end applications. Is it truly an MSP430 though ? Here, I think the more important question should be: Does it even matter ? On Wed, May 20, 2015 at 8:30 AM, William Hermans yyr...@gmail.com javascript: wrote: *That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes.* But we're not talking about an Arduino, or an rPI. We're talking about: a) a beagleBOARD class of system b) Then trying to compare it to the beagleBONE class of system. They're not the same. Also, if cape compatibility is the true motivation for this discussion. See this as an opportunity, not a hindrance. On Wed, May 20, 2015 at 8:04 AM, Gerald Coley ger...@beagleboard.org javascript: wrote: BeagleBone Black needed to be cheap. something had to go. Rest of the expansion signals are the same and those signals are still there on the board.. I disagree that the changes were radical. I fact, we lowered the cost and added features. If we change to another processor, the pin muxing changes. To comply with your desire to keep them all the same, you have just made my case. Gerald On Wed, May 20, 2015 at 9:42 AM, Walter Schilling schi...@msoe.edu javascript: wrote: That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org javascript: http://beagleboard.org/ http://circuitco.com/support/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe
Re: [beagleboard] Future of BeagleBone (Black)?
That's a real problem if the interface doesn't stay compatible in the future. When I look at Arduino, capes are compatible with previous versions. Same goes with the Raspberry Pi. Version 1 to version 2 adds features, but generally keeps compatibility between them. With the Beagle's, each version has had a radically different form factor and support. White's started with an extra header, removed for the blacks, breaking some capes. On Tuesday, May 19, 2015 at 9:30:37 AM UTC-5, RobertCNelson wrote: On Tue, May 19, 2015 at 9:24 AM, Philip philip@gmail.com javascript: wrote: On Tuesday, May 19, 2015 at 10:14:20 AM UTC-4, Gerald wrote: If I knew that, I would have mentioned that. I would say maybe late September. We hope to have a few beta boards in about 6 weeks. Jason is handling who gets those boards. Right now, we are going back into layout to fix yet another TI feature. Will the cape interface stay the same? Nope, and don't mention stuff like that, we don't want to give Gerald a heart attack.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: debian: release candidate: 2014-12-11
In other words, it sounds like there's a pretty good chance 1-27 is very close to what the final version will be (much closer than the 5.14.2014 that is out there now On Wednesday, January 28, 2015 at 9:38:29 PM UTC-6, RobertCNelson wrote: On Wed, Jan 28, 2015 at 9:26 PM, Walter Schilling schi...@msoe.edu javascript: wrote: RObert: Quick question on the status of this and the Official Beaglebone images from Beaglebone.org. How stable is the release of 1/25, and does it appear that it will be heading to the official Beaglebone.org page anytime soon? I'm getting ready to teach a class starting in March, and I'm trying to figure out which is the stablest point to start my work. Well, during testing of 1-25 CircuitCo found one more issue, which was just fixed in 1-27. (push button shutdown).. I might know more tomorrow.. So right now, i can only assume 1-27 will be used.. 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: debian: release candidate: 2014-12-11
RObert: Quick question on the status of this and the Official Beaglebone images from Beaglebone.org. How stable is the release of 1/25, and does it appear that it will be heading to the official Beaglebone.org page anytime soon? I'm getting ready to teach a class starting in March, and I'm trying to figure out which is the stablest point to start my work. Walt -- 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] Reccomended Development Linux
Good afternoon: I am getting ready to teach a class using the Beaglebone Black for a set of college students. Last year we were caught in the short supply of the black boards, so I'm getting started abit earlier. However, I'm trying to figure out the best distro and cross compilation environment to use. Last year I used a Ubuntu distro with the Debian image and while things went OK, there were some quirks. Based on feedback, I was planning on switching to a Debian distro, and I started building a VM for them to use for this purpose. However, it seems as if Debian is no longer including the gcc-arm-Linux-gnueabihf package, and many of the sites have indicated this is now obsolete. With that being the case, what is the current recommended cross compiler and platform for Beaglebone Black development? Walt Schilling -- 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] Reccomended Development Linux
Robert: Is this what you are using to build the kernel then? Walt On Tuesday, November 11, 2014 1:17:56 PM UTC-6, RobertCNelson wrote: On Tue, Nov 11, 2014 at 1:09 PM, Robert Nelson robert...@gmail.com javascript: wrote: On Tue, Nov 11, 2014 at 12:46 PM, Walter Schilling schi...@msoe.edu javascript: wrote: Good afternoon: I am getting ready to teach a class using the Beaglebone Black for a set of college students. Last year we were caught in the short supply of the black boards, so I'm getting started abit earlier. However, I'm trying to figure out the best distro and cross compilation environment to use. Last year I used a Ubuntu distro with the Debian image and while things went OK, there were some quirks. Based on feedback, I was planning on switching to a Debian distro, and I started building a VM for them to use for this purpose. However, it seems as if Debian is no longer including the gcc-arm-Linux-gnueabihf package, and many of the sites have indicated this is now obsolete. With that being the case, what is the current recommended cross compiler and platform for Beaglebone Black development? So right now there's a binutils for armhf in debian jessie: https://packages.debian.org/jessie/binutils-arm-linux-gnueabihf However the gcc cross compiler is still stuck in sid: https://packages.debian.org/sid/cpp-4.9-arm-linux-gnueabihf So once that migrates to jessie (if it migrates) you'll have matching armhf cross gcc/binutils/libs that can used to cross build projects for the bbb running jessie. Based on: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766626 This delay is expected.. So for users which to cross build packages, running Debian Jessie on the desktop (amd64 only) and running debian jessie on the bbb (1), they'll have matching gcc/lib/etc.. 1: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot 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] Beaglebone Cross Compilation Development Tools
Now that the Debian image has been released, has anyone placed the tools that build that particular version into an archive somewhere so that others can use them for building projects. I'm trying to do cross compilation of projects (which really is a much better way to go) when developing embedded systems. I've got a XUbuntu VM, but the armlinuxgnueabi tools are already newer than the ones used to build the production image, and some of the libraries are not compatible. With Angstrom, the tools used to be available on their site, but that has disappeared as well. Good CM practices would have both the source and the tools available. Walt -- 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 Cross Compilation Development Tools
That makes me feel better. Didn't realize Debian was being used to build the Debian image (though it makes perfect sense.) SO much of the material out there talks about Angstrom only. Walt On Saturday, April 5, 2014 4:37:27 PM UTC-5, RobertCNelson wrote: On Apr 5, 2014 4:27 PM, Walter Schilling schi...@msoe.edu javascript: wrote: Now that the Debian image has been released, has anyone placed the tools that build that particular version into an archive somewhere so that others can use them for building projects. I'm trying to do cross compilation of projects (which really is a much better way to go) when developing embedded systems. I've got a XUbuntu VM, but the armlinuxgnueabi tools are already newer than the ones used to build the production image, and some of the libraries are not compatible. With Angstrom, the tools used to be available on their site, but that has disappeared as well. Good CM practices would have both the source and the tools available. Well Ubuntu is not Debian... Goto debian.org Download wheezy iso, install armhf multiarch, bam same version of libs found on the official image. -- 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 Cross Compilation Development Tools
I see your Linux on Arm page has been updated VERY recently (i.e. last day or so...) I'mn assuming that set of instructions also will match with what is above. On Saturday, April 5, 2014 4:37:27 PM UTC-5, RobertCNelson wrote: On Apr 5, 2014 4:27 PM, Walter Schilling schi...@msoe.edu javascript: wrote: Now that the Debian image has been released, has anyone placed the tools that build that particular version into an archive somewhere so that others can use them for building projects. I'm trying to do cross compilation of projects (which really is a much better way to go) when developing embedded systems. I've got a XUbuntu VM, but the armlinuxgnueabi tools are already newer than the ones used to build the production image, and some of the libraries are not compatible. With Angstrom, the tools used to be available on their site, but that has disappeared as well. Good CM practices would have both the source and the tools available. Well Ubuntu is not Debian... Goto debian.org Download wheezy iso, install armhf multiarch, bam same version of libs found on the official image. -- 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] ssh fails write broken pipe
A great suggestion. We will try that out next. (Not something I've had to fight before.) On Tuesday, April 1, 2014 3:48:36 PM UTC-5, RobertCNelson wrote: On Tue, Apr 1, 2014 at 3:39 PM, Walter Schilling schi...@msoe.edujavascript: wrote: I have students working on the Beaglebone using the current Debian image. They are working in pairs. Student one has bone A and laptop a. Student two has bone B and laptop b. If b connects to B and then a connects to A, they receive an ssh failure with a broken pipe. If b connects to both A and B, then it works fine. It makes no sense to me at all. Any ideas? What does the -v option for ssh print out for debugging? 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] ssh fails write broken pipe
I have students working on the Beaglebone using the current Debian image. They are working in pairs. Student one has bone A and laptop a. Student two has bone B and laptop b. If b connects to B and then a connects to A, they receive an ssh failure with a broken pipe. If b connects to both A and B, then it works fine. It makes no sense to me at all. Any ideas? Walt -- 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] Phantom Button Presses on Beaglebone White
Good afternoon. I am working on a project on the beaglebone white (as the blacks are out of stock) and GPIO. I have tried two different setups, as shown below for my pushbutton, and I am using the circuitco prototyping cape. Configuration 1: I have my pushbutton connected from GPIO0_26 to ground, and there is a 3.3K pull up resistor connected to 3.3 volts. I am assuming there are no active pull up or pull downs in the system. Configuration 2: The pushbutton is connected in series from GPIO0_26 through the 3.3K resistor to 3.3 V, and we are relying on the internal pull down resistor to keep the pin low. In either case, I am getting phantom interrupts when I poll for the pin to change state. My gut feeling is they are brought on by noise. I'd like to do away with the exteral pull up or pull down, but I don't see any way to do that with the gpio driver from the documentation at https://www.kernel.org/doc/Documentation/gpio/sysfs.txt, as it doesn't seem to provide access to pull up and pull down configurations. This leads to the following questions: #1 Can someone provide me with the default pull up / pull down settings for an input when exported with /sys/class/gpio? #2 Short of going through the device tree (which seems horribly complicated to simply change a pull up or pull down resistor setting), is there an easy way to set of clear the PU/PD resistor through a c program? I have seen multiple tutorials online dealing with this issue, but most of them point to older kernel versions and when i try to follow them, they break very quickly. I am using the March 5, 2014 official beaglebone debian image. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Audio C ape Rev B Availability
Good evening. I am interested in obtaining information about the Audio Cape Rev B. It seems as if it is announced on the Beagleboard site, but I do not see any distributors with stock. Can anyone offer any further information as to when this device should be available? Walt Schilling -- 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: Directly accessing ARM registers from C/C++
I personally have not tried this, but have you thought about trying to use mmap to link the device driver io file directly into memory? Walt On Monday, March 3, 2014 2:48:10 PM UTC-6, dep...@phys.ksu.edu wrote: I've got a BeagleBone Black running Angstrom, and I want to directly access the ARM335 registers from my C/C++ programs. A trivial example would be to read the Device_ID at memory location 0x44E10600. To do this I tried: #include iostream using namespace std; unsigned long int *p; unsigned long int DevID = 0x44E10600; p1 = DevID; // = this gives a compiler error: invalid conversion from 'long unsigned int' to 'long unsigned int*' cout *p1 endl; // = if I cheat around the compiler error, I get a Segmentation fault from this statement // etc Note 1: just the p1 = DevI statement causes a fatal compiler error (as indicated in the comment. Note 2: I can get around this by using the -fpermissive compiler option, but then the cout statement (or any other way of extracting the contents of that memory location) gives me the segmentation fault. I *think* this is a permissions thing -- which means I ought to be able to fix it with some command. Is this correct? In any case, can someone tell me how to read/write to a particular memory location using c/c++? Much obliged! BDD -- 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/groups/opt_out.
[beagleboard] Re: Detecting a Beaglebone IP Addtress
On Thursday, February 13, 2014 9:58:03 PM UTC-6, Walter Schilling wrote: Board members: I've got an interesting problem that I'm trying to come up with a solution for. I am going to be teaching a class next quarter on the Beaglebone Black. Students will attach their bones to a network and program them remotely over ethernet. Code will be developed on a virtual machine running Linux and then connected via sftp to the board. However, the students will only have a bone and a prototyping cape available to them. WHat I am trying to figure out is the best way for them to determine the IP address of their board. By default, I know that the boards use dhcp to get an ip address. However, without a display, it's somewhat hard to get an ip address. Is there an easy way, maybe by using the usb connection, that students can figure out the IP address of the board so they can remote to it in an appropriate fashion. I've thought about simply pinging the boards, but with multiple boards on the network, that would only indicate that a board is connected, not that their board is connected. I suppose I could go to fixed IP's, but that would require them to change the SD card, which at first I'd rather use stock until they have gotten their feet wet. Any ideas or suggestions? Thanks, Walt PS: We'll be using a Debian image based of of Robert Nelson's work unless a new standard image comes out from Circuitco before then. -- 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/groups/opt_out.
Re: [beagleboard] Re: Detecting a Beaglebone IP Addtress
Thanks for all the ideas. This is the direction I plan on going now that I've made it work. As a side note, if you are trying this, make sure you have your VM in Bridges mode and not NAT mode. NAT will not work, but it works fine once you go into bridged mode. I just about strangled myself after I messed with it for a few hours thinking I had something really wrong with my hosts files only to change this and have it work. On Friday, February 14, 2014 10:34:22 AM UTC-6, RobertCNelson wrote: On Fri, Feb 14, 2014 at 10:22 AM, Walter Schilling schi...@msoe.edujavascript: wrote: Thanks for all of the responses. A couple of additional aspects to the problem: #1 I don't have access to the routers to adjust their setup, as that is controlled by our IT department that doesn't want to deal with configuration in that manner. #2 Students may work at home / dorms with a different network confiuration. I'm entrigued by the idea of writing the IP address to a file at boot. If I did that, then I probably could connect via usb and read that file back. I'll have to try that and see if I can get that working reliably. I've also thought about a program that blinked the lights on the board to display the ip, but I';m not sure that will be reliable either. (Hint: Maybe that would be a cool heartbeat to build into the onboard leds for this reason.) fyi: if you look closely at the debian testing images i've been pushing, the ip address is listed on the serial console above the login prompt.. However with systemd, it boots to fast, so eth0 is usually never updated (it's a race between getting ip and the init script that updates /etc/issue). Otherwise give each board a unique host name.. then user can just ssh root@unquie-hostname.local 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/groups/opt_out.
[beagleboard] Re: Detecting a Beaglebone IP Addtress
Thanks for all of the responses. A couple of additional aspects to the problem: #1 I don't have access to the routers to adjust their setup, as that is controlled by our IT department that doesn't want to deal with configuration in that manner. #2 Students may work at home / dorms with a different network confiuration. I'm entrigued by the idea of writing the IP address to a file at boot. If I did that, then I probably could connect via usb and read that file back. I'll have to try that and see if I can get that working reliably. I've also thought about a program that blinked the lights on the board to display the ip, but I';m not sure that will be reliable either. (Hint: Maybe that would be a cool heartbeat to build into the onboard leds for this reason.) -- 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/groups/opt_out.
Re: [beagleboard] Re: debian: test images (2014-01-10)
Robert: So far great work. It's overall working very well. That being said, I have a pair of questions: #1 I'm trying to use the camera cape with the board, and I get the following error message when I try to read from it using openCV: VIDIOC_REQBUFS: Cannot allocate memory. I believe this has something to do with the dd for the camera, but I'm not sure if it is something that requires mods to the dd or just a change in configuration. #2 I'm assuming this is by design, but when i try to read from the camera using gstreamer, I get a package not found error. It seems as if gstreamer isn't in this package, yet I aloso run into problems when I try to do an apt-get in that it can not be located. This may very well be by design and I just haven't overcome the issues. Thanks again for your hard work on this codebase. Walt On Wednesday, January 22, 2014 6:38:23 PM UTC-6, RobertCNelson wrote: On Wed, Jan 22, 2014 at 5:06 PM, Louis McCarthy comp...@gmail.comjavascript: wrote: Wow, Robert, you have been busy today! I was going to comment on xinput-calibrate, but you made a commit about 15 minutes before I did a clone, then I was trying to deal with touchscreen jitter and saw your patch of 3.8.13-bone37thanks for your work. I will test those out as soon as I can get them built :) Oh we got lucky on xinput-calibrate, i was starting to look up writing lightdm scripts, when i just hooked up the one found in their repo and rebooted.. It worked, so ship it. ;) On the capemgr front..I am looking into ways to get the dtbo files accessible at boot time. Option 1) Get capemgr to find /lib/firmware on startup Option 2) Put dtbo files into boot partition Couples issues, The *.dtbo's already compiled under /lib/firmware should work via the uEnv.txt *_enable call.. The kernel .config, build firmware in kernel is enabled. We are using an initrd. (helps hide the lack of rtc problem for rootfs and allows us to us uuid's for the eMMC, aka allowing single/multi mmc card combinations..) So, any modifications to any of the existing /lib/firmware/*.dtbo file will be ignored, as the kernel has it built-in. Any additions to /lib/firmware/*.dtbo are ignored as they are too late on boot (uEnv.txt *_enable call) and are not in the initrd. So.. I think we can fix the problem, by making sure all *.dtbo's (including new ones from users) are re-pulled into the initrd when it's regenerated. Here's the current initrd.img update routine. if [ ! -f /boot/initrd.img-$(uname -r) ] ; then update-initramfs -c -k $(uname -r) else update-initramfs -u -k $(uname -r) fi cp -v /boot/initrd.img-$(uname -r) /boot/uboot/initrd.img I'm guessing we just have to add the *.dtbo to one of the /etc/xyz files that update-initramfs utilizes.. 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/groups/opt_out.
Re: [beagleboard] Re: debian: test images (2014-01-10)
Well, there's good news and bad news. The good news, thanks to my own lack of knowledge, I was using the wrong packages for gstreamer. Thus, it wasn't finding them when I tried to install it. Alas, after installing gstreamer, I was able to construct the pipeline with the following command: gst-launch v4l2src device=/dev/video0 num-buffers=1 ! videoscale ! video/x-raw-yuv, width=640,height=480 ! jpegenc ! filesink location=test.jpg When I run this, I get the following error log: root@beaglebone:~/boneCV# gst-launch v4l2src device=/dev/video0 num-buffers=1 ! videoscale ! video/x-raw-yuv, width=640,height=480 ! jpegenc ! filesink location=test.jpg Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... WARNING: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not get parameters on device '/dev/video0' Additional debug info: v4l2src_calls.c(235): gst_v4l2src_set_capture (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: system error: Inappropriate ioctl for device Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element pipeline0. Execution ended after 140674416 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... root@beaglebone:~/boneCV# There is a test.jpg image created, but it is all black, as if the camera image is not read. This is being done with the 3.1 mp camera cape from circuitco. It's possible that I've got something wrong in my gstreamer pipeline, as I'm not an expert on it, but it does seem like there may be something with the driver. I'm going to try the same exact procedure with a USB camera to check my pipeline and go from there. Thanks again for your help. Walt On Wednesday, January 22, 2014 7:29:08 PM UTC-6, RobertCNelson wrote: On Wed, Jan 22, 2014 at 7:18 PM, Walter Schilling schi...@msoe.edujavascript: wrote: Robert: So far great work. It's overall working very well. That being said, I have a pair of questions: Which camera cape? Is this the Radium or the 3.1MP cape? ( in only have the 3.1MP ) #1 I'm trying to use the camera cape with the board, and I get the following error message when I try to read from it using openCV: VIDIOC_REQBUFS: Cannot allocate memory. I believe this has something to do with the dd for the camera, but I'm not sure if it is something that requires mods to the dd or just a change in configuration. Not really sure, I've gone so far as cat /dev/video0 on the 3.1 just to make sure it works.. Has anyone else in the beagleboard group tried opencv? #2 I'm assuming this is by design, but when i try to read from the camera using gstreamer, I get a package not found error. It seems as if gstreamer isn't in this package, yet I aloso run into problems when I try to do an apt-get in that it can not be located. This may very well be by design and I just haven't overcome the issues. Here's all the gstreamer options: http://packages.debian.org/search?keywords=gstreamersearchon=namessuite=stablesection=all make sure to refresh via: apt-get update ; apt-get install xyz Let me know what you need to make it work.. 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/groups/opt_out.
Re: [beagleboard] Re: debian: test images (2014-01-10)
Robert: Downloaded this build and have started playing with it. So far so good. That being said, I'm running into a slight issue. I've got a small issue that I'm not sure how to fix with Debian. I'm using the LCD7 with the black, and it is out of calibration. On the angstrom image, there was a calibration tool I could run, but I'm not seeing on the Debian port. Am I missing something obvious or just being clueless about how to do this with Debian? On Saturday, January 11, 2014 5:03:16 PM UTC-6, RobertCNelson wrote: On Sat, Jan 11, 2014 at 4:37 PM, Michael Long nik...@gmail.comjavascript: wrote: Is this beta specifically for the Beaglebones or should it work on the Beagleboard xM? I tried the setup_sdcard.sh method, substituting --uboot beagle_xm, but the resulting card didn't get very far in the boot process. Just the BeagleBone... The 'script' supports many different boards, however this image only contains the kernel for the BeagleBone.. The xM is already fully supported here: http://elinux.org/BeagleBoardDebian#Demo_Image This beta is specifically addressing: http://beagleboard.org/blog/2014-01-04-happy-new-year/ 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/groups/opt_out.
Re: [beagleboard] Re: Audio Cape with Beaglebone Black
Daniel: I'm curious as to whether you can shed any additional light on BBB compatibility with the audio cape. I'm trying to prepare for a course that will run in the spring, and we're looking to use audio, lcd screen, and camera cape. I'd like to go with the black for cost reasons, but I'm not sure of the support for the devices. Walt On Sunday, July 28, 2013 1:43:31 AM UTC-5, Daniel Nilsson wrote: Hi, Darren has been working on restoring support for the audio cape, this is done by reworking the HDMI support patch. There is nothing wrong with the audio cape or the support for it in mainline 3.8, it is the patch that adds support for HDMI on the beaglebone black that was implemented in a way that didn't take other audio peripherals into account. Darren has reworked this and sent an updated HDMI patch that restored audio support, but he wanted to do some more work on it before considering it done. Haven't heard since then, I'll ping him and check if he is still working on it. Regards Daniel On Sun, Jul 28, 2013 at 4:00 AM, Gerald Coley ger...@beagleboard.orgjavascript: wrote: Audio cape still does not work from what I can see. Darren never was working on it. He is working on HDMI issues I suggest you contact sup...@beagleboardtoys.com javascript: direct for help with their product. Gerald On Sat, Jul 27, 2013 at 5:55 PM, transis...@gmail.com javascript: wrote: It's been a month since it was mentioned that the audio cape compatibility problem was being looked at by Darren. In addition, there have been no updates since 6-20 for the flasher (BBB-eMMC-flasher-2013.06.20.img.xz). Has there been any progress on the BBB lately? Thanks. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ZJGwxA7BG4E/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
Re: [beagleboard] Audio Cape with Beaglebone Black
I'm having difficulty with this setup. I have a BBBone Black running the stock OS image from Angstrom, attached to an LCD7 display, and the Sound Cape. I've modified my uEnv.txt file to match that which is listed below. However, whenever my part starts to boot, the display blinks twice and it then goes back like it is rebooting. Is there something else I need to do to make this work with the LCD cape that I am missing? On Sunday, October 27, 2013 11:21:32 AM UTC-5, Yasir K wrote: It worked!! Well, I guess I didn't even know what I was staring at for 3 days, just removed the EMMC disable part and it works! Here is my uEnv.txt file now: optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-BONE-AUDI-01 Thanks so much Martin! However, I still have really poor quality audio playback from the cape using mplayer and an mp3 file. Where should I start to try and fix the audio quality issue? Also, it only works once very 2-3 tries. Any pointers to help me fix this issue would be much appreciated. On Saturday, October 26, 2013 10:36:36 PM UTC+2, Martin AA6E wrote: I'm not an expert on this, but it seems that you've disabled eMMC. So you shouldn't expect to boot from eMMC! Try eliminating BB-BONE-EMMC-2G from the disable list in uEnv. Martin On Sat, Oct 26, 2013 at 4:23 PM, Yasir K yas...@gmail.com wrote: **Update** Have managed to get the audio cape running by editing the uenv.txt file but only if I boot off an SD card, when I edit the uenv.txt file on the eMMC, the board does not boot. Audio playback has a lot of hiss and only works once every few times. Still need help in troubleshooting... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/ZJGwxA7BG4E/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Martin Ewing Branford, Connecticut martin@gmail.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/groups/opt_out.
Re: [beagleboard] BeagleBone 3.1MP Camera and Beaglebone Black Compatability
I've managed to get it to work, but now I'm running into a problem with the device driver. When I try to capture an image with openCV, I receive the following error: VIDIOC_REQBUFS: Cannot allocate memory. Is there somethign in the uenv.txt that needs to be set for the camera to function properly with openCV? I can make it work fine with Cheese and mplayer. On Monday, August 12, 2013 10:26:46 PM UTC-5, Gerald wrote: It shares the eMMC pins i know, so there could be a HW issue at play. I suggest you ask the manufacturer what the issue is. Gerald On Mon, Aug 12, 2013 at 9:40 PM, Walter Schilling schi...@msoe.edujavascript: wrote: Good evening. I am inquiring as to the compatability of the Beagleboard Black and the 3.1 MP Camera card. When I go to the listing of capes ( http://circuitco.com/support/index.php?title=BeagleBone_Capes#BeagleBone_Capes_Compatibility_Matrix), the camera is not listed as being compatible with the Beaglebone Black. Is this a simple problem software issue, or are there fundimental compability problems between the two issues that are unlikely to be easily resolved? Thanks for any information you can shed. Walt PS: The reason for my inquiry is I am getting ready to teach a class with the Bone, and I am going back and forth between the black and regular bone, as one of my labs uses the 3.1 MP camera. I'd like to go with the Black due to cost and other factors, but if this cape isn't compatible, it's not so easy to do.) -- 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
[beagleboard] Re: Boris is spreading mustaches around at DESIGN East
Did you ever manage to get this working? I'm having similar problems. On Friday, October 5, 2012 7:49:13 AM UTC-5, Mark A. Yoder wrote: Nope, cheese doesn't work either. Sounds like a driver isn't working. How do I fix it? On Tuesday, September 18, 2012 4:23:36 PM UTC-4, Jason Kridner wrote: Boris has been spreading mustaches around DESIGN East, sporting a BeagleBone-based BeagleStache[1] collar running OpenCV face detection with an added mustache. The demo is tomorrow, Sept 19th at 3PM in the DESIGN East Theater located on the Expo Floor, during the DESIGN East Gadget Freak DIY Lab[2]. There is a thread on Google+[3]. [1] http://beagleboard.org/project/stache (includes a couple of pictures) [2] http://east.ubmdesign.com/expo/design-east-theater [3] https://plus.google.com/u/1/104712705716996155416/posts/HQGjtxoQU27 -- 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/groups/opt_out.
[beagleboard] Stache Cam with BeagleBone 3.1MP Camera
Good afternoon. I recently downloaded the stache cam code from the web. I have a Beaglbone black and 3.1 MP Camera Cape. I've managed to get the code to compile (I wanted to cross compile from my Linux environment, but that is a future project), but when I run the compiled stache cam code, this is what I get: VIDIOC_REQBUFS: Cannot allocate memory munmap: Invalid argument munmap: Invalid argument munmap: Invalid argument munmap: Invalid argument Unable to stop the stream.: Bad File Descriptor munmap: Invalid argument munmap: Invalid argument munmap: Invalid argument munmap: Invalid argument Floating Point Exception I don't see in the stache cam code where there is a link to a specific device for the camera. If I try running the code passing in a 0 or 1 (which I assume represents the camera in the system), I receive the error message Could not load 0 or Could not load 1 I'm thinking there is something very simple I have wrong, either with the driver for the camera or the stache cam code. Any suggestions? -- 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/groups/opt_out.
[beagleboard] OpenCV Development Tool install
Hello. I'm having what very much is a beginners question, but thusfar I haven't seen a definitive answer. I am starting work with the BeagleBone Black running Angstrom and I would like to cross compile an OpenCV program. My development host is running XUbuntu, and I've installed the gnueabi cross compiler. However, I'm having trouble figuring out how to go about installing the libraries for OpenCV. I know I need them to be cross compiled for the Angstrom target, but is this available pre-packaged or do I need to build the OpenCV libraries from scratch using a cross compiler? Thanks for the answer to the (seemingly) basic question. Walt -- 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/groups/opt_out.
