[beagleboard] how to capture audio using audio cape rev B1 with mic ?
Hi friends, I have a BB white and one BB audio cape rev B1. kernel version 3.8.13 and debian rootfs. I'm able to use the BB audio cape with this setup for audio output nicely but as the audio input is line in, I can't use the mic in directly. So, using the mic input, my hardware person has made changes to the audio cape, and he asked me to make mic bias as 2.5V. For, making the mic bias 2.5, I got this link and a patch there: https://groups.google.com/forum/#!topic/beagleboard/qBpwQ0UZcIM Then I tried to use the mic to capture the input audio (using arecord) in synchronization with alsamixer I was trying to vary various parameters in the alsamixer for line2L, line2R, Mic3L etc but could not get it working. Then I found this, saying some changes to be done in device tree overlay for audio cape: https://groups.google.com/forum/#!searchin/beagleboard/audio$20cape$20mic$20bias$20device$20tree/beagleboard/RsYJhgT3CHo/Q1yKCmeEuJMJ After this change I tried to capture the audio in a similar way playing around with alsamixer. But nothing seems to be helping. If anyone has successfully used the mic with audio cape, please help me out. Thanks, aniket jesu -- 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: Initially load capes on AM335x without EEPROM
Julien penou87@... writes: OK. So I took the sources from your git repository and I'm trying to force the capemgr to load the emmc. I'm trying to modify the patch.sh file to force it. Do you know if there is an easiest way to do it ? I'm sorry, I'm a beginner concerning kernel things. The kernel compilation takes quite some time, it will save me a lot of time if you could give me a hint. Best regards, Julien Forget it, it's ok. Actually I took the 3.16 kernel. I just have a few things to fix during the kernel compilation (no LCD, default cpu-freq at 800MHz...) and it will be perfect. Thanks a lot for your advices. -- 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: Initially load capes on AM335x without EEPROM
On Wed, Aug 13, 2014 at 8:49 AM, Julien peno...@gmail.com wrote: Julien penou87@... writes: OK. So I took the sources from your git repository and I'm trying to force the capemgr to load the emmc. I'm trying to modify the patch.sh file to force it. Do you know if there is an easiest way to do it ? I'm sorry, I'm a beginner concerning kernel things. The kernel compilation takes quite some time, it will save me a lot of time if you could give me a hint. Best regards, Julien Forget it, it's ok. Actually I took the 3.16 kernel. I just have a few things to fix during the kernel compilation (no LCD, default cpu-freq at 800MHz...) and it will be perfect. which lcd? https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/pinmux/0009-am335x-bone-common-pinmux-lcd4.patch https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/dts/0001-am335x-boneblack-add-cpu0-opp-points.patch#L155 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] Re: 3 proposed patches for next 3.8.13-bone5x update
I can arrange to have one of the 4D Systems 4 LCD's sent to you. If that would help. I could also do the kernel testing here to help isolate the offender. I should be able to apply the patches one at a time and do a quick partial recompile after each patch is applied? To answer your question about the DTB, I was just using whatever DTB's are used in the Debian build generated via Robert Nelson's omap-image-builder. Alex On 8/13/2014 12:44 AM, B. Scott Michel wrote: Robert: I'll try to get my hands on the Element-14 4 LCD to see if it happens with that LCD. I have the same company's 7 LCD cape -- should be able to narrow it down to either the board DTB or a compiler bug. -scooter Sent from my iPad On Aug 12, 2014, at 5:14 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel scooter@gmail.com wrote: Alexander: I apologize for the delayed response -- I've been on travel for a customer with more customers keeping me tied up in meetings yesterday and today. I was going to ask which DTB you were using because your description sounded as if pixel timings were off. Sounds like Robert found the issue (were they my patches??) My suspicion, it might be a compiler bug. 0009-sitara_red_blue_swap_workaround.patch We are dealing with: gcc version 4.6.3 (Debian 4.6.3-14) I just disabled them for the time being.. https://github.com/RobertCNelson/bb-kernel/commit/59ba8323a910c7c3c032ee455d534ad43fba07f8 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 Black Rev. C: Protecting GPIO pins during boot until SYS_RESETn signal is HI
What kind of solutions are others out there using to protect GPIO pins during boot? I have a sensor connected that is loop powered so it will be applying voltage at all times to the BBB. My thought is to use some sort of FET bus to protect the board. Ideas or thoughts? Thanks. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Please advise best stable kernel version
I found this link when asking myself the same question. Hope this will help. https://www.kernel.org/finger_banner On Saturday, August 9, 2014 12:53:46 AM UTC+2, Dejan Nenov wrote: Hello, It appears that the most popular kernel version out is https://github.com/RobertCNelson/bb-kernel/tree/3.8.13-boneXX However, Robert's git branches have tags up to 3.16.bone-2 Can you please advise as to which version/tag would be best for a new project - most important is support for SPI, USB Wireless WiFi and overall stability. Thank you, Dejan Nenov -- 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: MediaTek (Logic Supply) Wi-Fi adapter for BBB and Debian
Hi Russ Hall, Your help will be greatly appreciated ! I am a beginner about BBB and trying to use UWN200 on BBB(*rev C with debian 3.8.13*), I have tried to follow the tutorial on http://inspire.logicsupply.com/2014/07/beaglebone-wifi-installation.html However, Stucking at step3 with red warning *NO wireless network found.* Seems like at the very beginning there is something wrong: After I type lsmod, I got this: not using by one instead of 0 * mt7601Usta601404 0* The Result of lsusb is the same: Bus 001 Device 002: ID 148f:7601 Ralink Technology, Corp. When it comes to ifconfig-a, it shows like this: ra0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Because the strange HWaddr, I guess there must be something wrong , maybe just the first step. I search for a long time and don't know how to start fix the bug. On Sunday, May 25, 2014 4:52:18 AM UTC-7, Russ Hall wrote: You are right! I studied the Debian documentation yesterday and modified my /etc/network/interfaces file, and it did work! It isn't fast to come up, taking about 90 seconds, and probably needs the 5V adapter connected, too. I made exactly the changes you put here. Quotes should be around the names in lines 3 and 4. On Saturday, May 24, 2014 10:19:21 AM UTC-5, Trevize Daneel wrote: No, you don't need a monitor you should be good. You can always check this site for your chipset : http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers also type dmesg to see if you have any errors type lsmod to see if your kernel module is loaded But ra0 is your network interface name and iwlist shows it which means you have your dongle recognized. Have you initialized you network interface? Type ifconfig -a to check if you have ra0 listed.If so, add this to your /etc/network/interfaces and reboot to and check again. auto ra0 iface ra0 inet dhcp wpa-ssid YOUR-SSID-HERE wpa-psk YOUR-PASSWORD-HERE On Saturday, May 24, 2014 4:29:57 PM UTC+3, Russ Hall wrote: The new Debian version did not change non-installation of the Wi-Fi adapter. I still can't figure out what is missing. Here is a sample from terminal: debian@beaglebone:~$ iwlist scan ra0 Failed to read scan data : Network is down loInterface doesn't support scanning. eth0 Interface doesn't support scanning. usb0 Interface doesn't support scanning. debian@beaglebone:~$ iwconfig ra0 Ralink STA lono wireless extensions. eth0 no wireless extensions. usb0 no wireless extensions. debian@beaglebone:~$ sudo ifup ra0 Ignoring unknown interface ra0=ra0. debian@beaglebone:~$ This installation is possible via terminal, no? Or must I get a monitor, keyboard, and mouse connected to BBB? On Thursday, May 22, 2014 11:34:39 AM UTC-5, Russ Hall wrote: If anyone could please write a small tutorial on getting this adapter working on the Rev. C BBB it would be appreciated. It was said that Debian already supported this hardware but it does not work. Compiling my own drivers is not user-friendly! I downloaded the driver files from MediaTek and it has 254 files in one directory. -- 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] BeagleBoard Black user LEDs not blinking after connecting via USB
Hello Im facing the same problem did you happen to know the answer ?? Thanks On Monday, November 25, 2013 1:29:56 AM UTC-5, Anantha Krishnan wrote: Hello Gerald, I followed the procedure given here - http://elinux.org/Beagleboard:Updating_The_Software *10) Hold switch S2 (Boot Switch, see picture below) down by pressing on it and holding it while plugging in the power cable.* 1. Whenever I powered on the board(with SD card) by holding Boot switch, nothing happened, only the power LED will be ON all other USER LEDs will be OFF, I tried holding boot switch for several minutes. 2. Also, without holding the boot switch, if I insert SD card BBB will start flashing emmc and after about 45 minutes all four User LEDs will lit continuously. I did point 2 several times, every time after 45 minutes the four LEDs will lit solidly but if it press POWER button turn off BBB, remove SD card and again power on BBB, it will not boot. Instead four User LEDs will simply blink at a continuous pattern. I mean four LEDs will blink at once every second, in BBB irc someone said that after flashing it can take up to 30 minutes to boot, but I kept connected the board yesterday night completely for more than 8 hours still no luck. Is this hardware problem or software problem? Also, When I used https://s3.amazonaws.com/angstrom/demo/beaglebone/Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.08.21.img.xz image it booted properly from SD card, AGAIN I DID NOT PRESS BOOT BUTTON. I am worried about two things, 1. Why pressing BOOT button is not working as expected, in all docs this point is mentioned. Why it flashes or boots from sd card only without pressing boot button. 2. Why I am not able to flash emmc with default Angstrom linux. Thanks, Anantha Krishnan On Sunday, November 24, 2013 9:07:01 AM UTC+5:30, Anantha Krishnan wrote: Thanks Gerald, I will try flashing the eMMC device. Thanks, Anantha Krishnan On Sunday, November 24, 2013 6:49:10 AM UTC+5:30, Gerald wrote: Sounds like you unplugged the board without turning it off frist. Result could be a corrupted eMMC device. http://elinux.org/Beagleboard:Updating_The_Software http://www.google.com/url?q=http%3A%2F%2Felinux.org%2FBeagleboard%3AUpdating_The_Softwaresa=Dsntz=1usg=AFQjCNF4eJoC6vrx867iWx5rZpmB7Ejpiw Gerald On Sat, Nov 23, 2013 at 8:45 AM, Anantha Krishnan ananthakr...@gmail.com wrote: Hello, Today I bought new BBB, initially when I tried connecting it to my laptop using the provided USB cable everything went fine, I was able to login into it and access Angstrom. Suddenly after sometime I couldn't connect my BBB successfully. Whenever I connect it via USB the power light is on whereas user LEDs are off. Even windows 7 is not recognizing as mass storage device, instead it shows AM335x USB under 'Other devices' category in Device Manager. In between I remember of trying to connect from ubuntu virtual machine from windows 7 host. Could this have cause any problem to the board? Thanks, Anantha Krishnan -- For more options, visit http://beagleboard.org/discuss http://www.google.com/url?q=http%3A%2F%2Fbeagleboard.org%2Fdiscusssa=Dsntz=1usg=AFQjCNEpMSpbklk_hXqEMMJhBr1sf-iMfQ --- 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/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/d/optout.
[beagleboard] Hello, can i ask for some advice on bonescript?
I'm trying to use my beagle bone black (rev. c) as a web server with apache2 but it seems to be the default port for apache2 is set to 8080 and from my research, port 80 is taken by node.js which is activated by bonescript. what i want to do is switch two ports; 8080 for bonescript for my later projects. 80 for apache2 for my blog. i tried to uninstall node.js and was able to run apache2 on port 80 but i also want to keep node.js on 8080. how can i make bonescript run on port 8080? thank you for reading and answers would be greatly appreciated. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Beaglebone Black Rev. C: Protecting GPIO pins during boot until SYS_RESETn signal is HI
Power the sensor from the 3.3V rail or use the reset pin as described on the Wiki. http://www.elinux.org/Beagleboard:BeagleBoneBlack#Expansion_Header_Usage Gerald On Wed, Aug 13, 2014 at 8:52 AM, Paul cory.pric...@gmail.com wrote: What kind of solutions are others out there using to protect GPIO pins during boot? I have a sensor connected that is loop powered so it will be applying voltage at all times to the BBB. My thought is to use some sort of FET bus to protect the board. Ideas or thoughts? Thanks. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Problem writing to ttyO1
Hello all;
I seem to be having a problem writing to ttyO1.
Here is the really simple code and the result on the console:
Code:
var data
var serialPort, sp;
var serialPort = require(serialport).SerialPort;
var sp = new serialPort(/dev/ttyO1, { baudrate: 9600 });
sp.on(open,function(){
console.log(Hello World the Comm Port is Open);
});
function sp_write(data){
sp.write(data,function(err, results) {
console.log('err ' + err + ' What happened? ' + results);
});
}
togglepin();
function togglepin(){
// High and low parts of the frame length (not counting checksum)
sp_write(Hello Again):
//sp_write(0x0);
//sp_write(0x10);
}
And here is the console Output:
Error: Serialport not open. What happened? undefined
Hello World the Comm Port is Open
Anyone got any ideas ??
Bill
No one could make a greater mistake than he who did nothing because he
could do only a little.
All that is necessary for the triumph of evil is that good men do nothing
Edmond Burke (1729 - 1797)
http://www.packtpub.com/building-a-home-security-system-with-beaglebone/boo
k
http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book
--
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] Problem wtiting to ttyO1 - Update -
Hello All;
I apologize for starting a new thread, but I seem to have lost the last one
L
Basically, after some Google-ing I realized that I have to wait for the
serial port to be open before reading from or writing to it.
This is because it communicates asynchronously.
So here is my new code, and naturally a new error:
From: https://www.npmjs.org/package/serialport
var data
var serialPort, sp;
var serialPort = require(serialport).SerialPort;
var sp = new serialPort(/dev/ttyO1, { baudrate: 9600 });
sp.on(open,function(){
console.log(Hello World the Comm Port is Open);
});
function sp_write(data){
sp.on(open, function () {
sp.write(ls\n, function(err, results) {
console.log('err ' + err);
console.log('results ' + results);
});
});
}
togglepin();
function togglepin(){
// High and low parts of the frame length (not counting checksum)
sp_write(Hello Again);
//sp_write(0x0);
//sp_write(0x10);
}
Hello World the Comm Port is Open
err undefined
results 3
sigh
I still need some help L
Bill
No one could make a greater mistake than he who did nothing because he
could do only a little.
All that is necessary for the triumph of evil is that good men do nothing
Edmond Burke (1729 - 1797)
http://www.packtpub.com/building-a-home-security-system-with-beaglebone/boo
k
http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book
--
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] mma7455l - I2C Issue
Hey Guys, So I have a MMA7455L accelerometer (Data Sheet) http://www.parallax.com/sites/default/files/downloads/28526-Freescale-MMA7455L-Device-Documentation.pdf and hooked it up to the Beaglebone black via I2C. To test that I could read the registers I used the linux I2C tools. I used the following command to display the values from the registers: *sudo i2cdump 1 0x1d* By using this command I should get a table with different values pertaining to different registers. Unfortunately, here is my result: https://lh4.googleusercontent.com/-eMkyN4M99jQ/U-uyN3J5wrI/ARU/fubdNThL1RA/s1600/Screen%2BShot%2B2014-08-13%2Bat%2B11.44.37%2BAM.png According to the data sheet the following registers should contain their corresponding pieces of information: x06 = 8 bit value for x x07 = 8 bit value for y x08 = 8 bit value for z But they are not there. As you have probably noticed, I do get the following values: x0d = I2C Device Address x0e = User Information x0f = Who am I value Does anybody know why I am not getting any information in x06...etc. ? -- 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: 3 proposed patches for next 3.8.13-bone5x update
Alexander: Short answer: It works for me. :-) It turns out that a colleague has an Element-14 4.3 LCD cape here at work. I just booted up after changing uEnv.txt. Hard to work on the BBB at that screen resolution, but I don't have the image compression that you experienced. I'm not at the most recent tag on Robert's tree, but I could test it later this week. But given that the E-14 4.3 LCD cape works, it makes me wonder if the problem isn't with the DTB's pixel and dot clocking params? Now, I'll admit that I compiled my kernel with the 4.7.3 20130328 prerelease compiler, so that could have made a difference if there were a compiler bug: [0.00] Linux version 3.8.13-bone53 (-@) (gcc version 4.7.3 20130328 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #40 SMP Fri May 30 13:18:49 PDT 2014 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] On node 0 totalpages: 130816 [0.00] free_area_init_node: node 0, pgdat c0880640, node_mem_map c08fb000 [0.00] Normal zone: 1024 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 129792 pages, LIFO batch:31 [0.00] AM335X ES2.1 (l2cache sgx neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0d0b000 s14080 r8192 d14592 u36864 [0.00] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 drm.debug=0x05 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-VIEW-LCD4-01 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd I'm also using fbdev for the X server: [11.250] X Protocol Version 11, Revision 0 [11.251] Build Operating System: Linux 3.2.0-4-mx5 armv7l Debian [11.251] Current Operating System: Linux beaglebone 3.8.13-bone53 #40 SMP Fri May 30 13:18:49 PDT 2014 armv7l [11.253] Kernel command line: console=tty0 console=ttyO0,115200n8 drm.debug=0x05 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-VIEW-LCD4-01 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd [11.256] Build Date: 17 December 2013 08:51:06PM [11.256] xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau jcris...@debian.org) [11.256] Current version of pixman: 0.26.0 [11.258]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [11.258] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [11.264] (==) Log file: /var/log/Xorg.0.log, Time: Wed Apr 23 13:20:01 2014 [11.292] (==) Using config file: /etc/X11/xorg.conf [11.293] (==) Using system config directory /usr/share/X11/xorg.conf.d [11.312] (==) ServerLayout Builtin Default Layout [11.313] (**) |--Screen Builtin Default fbdev Screen 0 (0) [11.313] (**) | |--Monitor Builtin Default Monitor [11.317] (**) | |--Device Builtin Default fbdev Device 0 [11.318] (==) Automatically adding devices -scooter On Wed, Aug 13, 2014 at 7:40 AM, Alexander Hayman misterhay...@gmail.com wrote: I can arrange to have one of the 4D Systems 4 LCD's sent to you. If that would help. I could also do the kernel testing here to help isolate the offender. I should be able to apply the patches one at a time and do a quick partial recompile after each patch is applied? To answer your question about the DTB, I was just using whatever DTB's are used in the Debian build generated via Robert Nelson's omap-image-builder. Alex On 8/13/2014 12:44 AM, B. Scott Michel wrote: Robert: I'll try to get my hands on the Element-14 4 LCD to see if it happens with that LCD. I have the same company's 7 LCD cape -- should be able to narrow it down to either the board DTB or a compiler bug. -scooter Sent from my iPad On Aug 12, 2014, at 5:14 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Aug 12, 2014 at 7:06 PM, Scott Michel scooter@gmail.com wrote: Alexander: I apologize for the delayed response -- I've been on travel for a customer with more customers keeping me tied up in meetings yesterday and today. I was going to ask which DTB you were using because your description sounded as if pixel timings were off. Sounds like Robert found the issue (were they my patches??) My suspicion, it might be a compiler bug.
[beagleboard] USB ports swapped, USB0 will not enumerate
Hello, I have a custom board based on the Beaglebone Black, I'm trying to get the board to boot from USB, with nothing programmed on or SD card. I'm expecting to get the AM335 RNDIS to initiate as an Ethernet device. On our board (compared to the Beaglebone Black), we're using USB0 with the OTG circuitry (instead of USB1) and forcing USB0 into device mode. The board is detected by the Linux PC, however, It will not enumerate. The following is the dmesg I was able to get (running Ubuntu 12.04): [424595.900132] usb 5-2: new full-speed USB device number 4 using uhci_hcd [424596.075024] usb 5-2: unable to read config index 0 descriptor/all [424596.075032] usb 5-2: can't read configurations, error -71 [424596.188220] usb 5-2: new full-speed USB device number 5 using uhci_hcd [424596.251145] usb 5-2: unable to read config index 0 descriptor/all [424596.251158] usb 5-2: can't read configurations, error -71 [424596.364184] usb 5-2: new full-speed USB device number 6 using uhci_hcd [424596.422150] usb 5-2: unable to read config index 0 descriptor/all [424596.422164] usb 5-2: can't read configurations, error -71 [424596.423023] hub 5-0:1.0: unable to enumerate USB device on port 2 The board hardware has been modified slightly from the Beaglebone Black. First, we are using a type A usb connector, second, USB0 is now connected to the (USB1) OTG hardware, with USB0_ID pin floating (no access to USB1). Are there any other modifications to hardware required to get this working? Thanks -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: PRU FAQ 2013-05-15
Hi, I want to use the DCAN interface on PRU-ICSS to send/receive data present on DDR RAM at a fixed physical address. - Address of DDR is 0x8000_ to 0x9000_(256MiB) - My buffer is present at 0x8FF0_ to 0x9000_ (1MiB) As soon as I access the hardware address 0x8FF0_ the PRU-ICSS goes into some faulty state and becomes unresponsive. Is there some other way to access DDR from PRU-ICSS ? Rakesh On Thursday, May 16, 2013 2:42:39 AM UTC+5:30, Jason Kridner wrote: Frequently asked questions regarding PRU: - What is a PRU? - PRU stands for Programmable Real-time Unit. The overall subsystem is typically called the ICSS, PRU-ICSS or PRUSS. ICSS stands for Industrial Communications Subsystem and PRUSS stands for Programmable Real-time Unit Subsystem. - What does a PRU do? - A PRU is a 200MHz microcontroller that is really useful at bitbanging and has some peripherals attached to it that make it well suited for building real-time interfaces to all types of digital electronics. - What are the processing elements within the AM33xx PRUSS used on BeagleBone and BeagleBone Black? - 2 32-bit 200MHz PRU cores - Each with 8KB of program memory - Direct access to general purpose I/O - Single cycle operations without cache or pipelines (instructions *always* 5ns) - Shared 12KB data memory - Scratch pad registers - Parallel and serial capture modes - 32-bit port to memory and other peripherals outside of the PRUSS, including external memory - What are some example things built out of PRUs? - DMX512 lighting protocol: http://beagleboard.org/CapeContest/entries/BeagleBone+DMX+Cape/ - 6502 memory interface: http://elinux.org/images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf - Emulated memory interface on an Atari 600XL with BeagleBone decoding video directly into Atari 600XL display memory: http://www.youtube.com/watch?v=1irR4TQ5aMA - Nixie tube interface: https://github.com/mranostay/beagle-nixie - Software UART: http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide - Sine wave generator using PWMs: http://elinux.org/ECE497_BeagleBone_PRU - 3D printer stepper motor driver: http://hipstercircuits.com/pypruss-a-simple-pru-python-binding-for-beaglebone/ - Camera interface: http://www.hitchhikeree.org/beaglebone_capes/interacto/ - Where do I get some more details? - https://github.com/beagleboard/am335x_pru_package is the official location for documentation and tools for the PRUSS on BeagleBone and BeagleBone Black. - http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page. -- 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] Accessing DDR from PRU-ICSS
Hi, I want to use the DCAN interface on PRU-ICSS to send/receive data present on DDR RAM at a fixed physical address. - Address of DDR is 0x8000_ to 0x9000_(256MiB) - My buffer is present at 0x8FF0_ to 0x9000_ (1MiB) As soon as I access the hardware address 0x8FF0_ the PRU-ICSS goes into some faulty state and becomes unresponsive. Is there some other way to access DDR from PRU-ICSS ? Rakesh -- 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 boot failure, Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Hi, Background: I have a BBB that I am setting up to run with machinekit to drive a mill. I have been testing with an early machine kit image, and then I updated to the most recent image. Upon updating I started to have problems where the cape manager stopped working and the pru was not recognized. Ok, to narrow down the cause I reloaded the original (possibly updated?) emmc image and reflashed it to the BBB. (BBB-eMMC-flasher-2013.09.04.img ) Now the board will not boot to Angstrom. The serial console log of the boot attempt is attached. The key part seems to be: U-Boot SPL 2013.04-dirty (Jul 10 2013 - 14:02:53) timed out in wait_for_pin: I2C_STAT=0 Could not probe the EEPROM; something fundamentally wrong on the I2C bus. Could not get board ID. Unknown board, assuming Beaglebone LT/Black.musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) Is there a way to determine if this is a hardware error with the I2C bus, or an EEPROM that needs to be reloaded? BBB PCBrevB5 No capes Thanks Dan G. -- 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. U-Boot SPL 2013.04-dirty (Jul 10 2013 - 14:02:53) timed out in wait_for_pin: I2C_STAT=0 Could not probe the EEPROM; something fundamentally wrong on the I2C bus. Could not get board ID. Unknown board, assuming Beaglebone LT/Black.musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 mmc_send_cmd : timeout: No status update reading u-boot.img reading u-boot.img U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled timed out in wait_for_pin: I2C_STAT=0 Could not probe the EEPROM; something fundamentally wrong on the I2C bus. Could not get board ID. NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 1 0 gpio: pin 53 (gpio 53) value is 1 Card did not respond to voltage select! mmc0(part 0) is current device Card did not respond to voltage select! No micro SD card found, setting mmcdev to 1 mmc_send_cmd : timeout: No status update mmc1(part 0) is current device mmc_send_cmd : timeout: No status update gpio: pin 54 (gpio 54) value is 1 SD/MMC found on device 1 reading uEnv.txt 26 bytes read in 3 ms (7.8 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... gpio: pin 55 (gpio 55) value is 1 4385024 bytes read in 768 ms (5.4 MiB/s) gpio: pin 56 (gpio 56) value is 1 24808 bytes read in 54 ms (448.2 KiB/s) Booting from mmc ... ## Booting kernel from Legacy Image at 80007fc0 ... Image Name: Angstrom/3.8.13/beaglebone Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4384960 Bytes = 4.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 80f8 Booting using the fdt blob at 0x80f8 XIP Kernel Image ... OK OK Using Device Tree in place at 80f8, end 80f890e7 Starting kernel ... Uncompressing Linux... done, booting the kernel. [1.156063] omap_i2c 44e0b000.i2c: controller timed out [1.156111] tps65217 0-0024: Failed to read INT reg [1.156131] tps65217 0-0024: Failed to probe pwr_but [2.156059] omap_i2c 44e0b000.i2c: controller timed out [3.159963] omap_i2c 44e0b000.i2c: controller timed out [3.192958] omap2_mbox_probe: platform not supported [4.262707] omap_i2c 44e0b000.i2c: controller timed out [5.272231] omap_i2c 44e0b000.i2c: controller timed out [6.785894] omap_i2c 44e0b000.i2c: controller timed out [7.797839] omap_i2c 44e0b000.i2c: controller timed out [9.311295] omap_i2c 44e0b000.i2c: controller timed out [ 10.323165]
[beagleboard] Re: i wanna 8bit gpio control
Hi Brandon,
I'm currently using mmap (in Python) to achieve register wide GPIO. I'm
concerned though, that the kernel still thinks it owns that memory and
might inadvertently write to it (for ex: if you forget to disable the
heartbeat trigger). Do you know of a way to disable the sysfs interface /
claim those pins as being in use so that you can safely manipulate the mmap
either through software or a device tree overlay?
Thanks for your help.
On Tuesday, July 29, 2014 3:09:08 PM UTC-4, Brandon I wrote:
That's still one bit control. There's going to be some unknown time
between the bits that will depend on cpu usage. For true 8 bit, you need to
use mmap to get a pointer to the gpio control block and modify the
registers directly.
Each gpio block has 32 pins, and each gpio block has a set and clear
register that's 32 bits wide, one bit for each pin. Setting a bit in the
set register will set the pin. Setting a bit in the clear register will
clear the pin. So, to set 8 pins at once, you would write the 8 bits to the
set, then to clear all 8, you would write those 8 bits to the clear
register. This will truly be at once, at least to the capabilities of the
hardware.
Sysfs has some pretty absurd overhead, so you'll get a few hundred kHz at
most. With the the register manipulation using mmap, you'll end up with ~4
MHz for a toggle like that.
On Sunday, July 27, 2014 4:09:56 AM UTC-7, kthab...@gmail.com wrote:
/sys/class/gpio/export this driver file i have used.
but this control only one bit. so, i try to 8bit control like this
#include bb_gpio.h
#include stdio.h
#include sys/time.h
//#include string.h
void main(void)
{
gpio_export(p9_11); gpio_export(p9_12);
gpio_export(p9_13); gpio_export(p9_14);
gpio_export(p9_15); gpio_export(p9_16);
gpio_export(p9_17); gpio_export(p9_18);
gpio_direction(p9_11,out); gpio_direction(p9_12,out);
gpio_direction(p9_13,out); gpio_direction(p9_14,out);
gpio_direction(p9_15,out); gpio_direction(p9_16,out);
gpio_direction(p9_17,out); gpio_direction(p9_18,out);
while(1){
pin_write(p9_11,1); pin_write(p9_12,1);
pin_write(p9_13,1); pin_write(p9_14,1);
pin_write(p9_15,1); pin_write(p9_16,1);
pin_write(p9_17,1); pin_write(p9_18,1);
sleep(1);
pin_write(p9_11,0); pin_wirte(p9_12,0);
pin_write(p9_13,0); pin_wirte(p9_14,0);
pin_write(p9_15,0); pin_wirte(p9_16,0);
pin_write(p9_17,0); pin_wirte(p9_18,0);
sleep(1);
};
}
#include bb_gpio.h
#ifndef BB_GPIO_H_
#define BB_GPIO_H_
#include stdio.h
#include string.h
/
* BB_GPIO headerfile
* This file only used to gpio control
* other feature using device-tree-overlay
* when using GPIO, the pin work to MODE7
*=formula==
* GPIO N1[N2]
* gpio_number = (32 x N1) + N2
*==
*/
#define out 1
#define in 0
#define export_PATH /sys/class/gpio/export
#define value_PATH /sys/class/gpio/gpio%d/value
#define direction_PATH /sys/class/gpio/gpio%d/direction
#define unexport_PATH /sys/class/gpio/unexport
//*P9***
#define p9_11 30
#define p9_12 60
#define p9_13 31
#define p9_14 50
#define p9_15 48
#define p9_16 51
#define p9_17 5
#define p9_18 4
//#define p9_19 13
//#define p9_20 12
#define p9_21 3
#define P9_22 2
#define p9_23 49
#define p9_24 15
#define p9_25 117
#define p9_26 14
#define p9_27 115
//#define p9_28 113
//#define p9_29 111
#define p9_30 112
//#define p9_31 110
#define p9_41 20
//#define p9_41 116
//#define p9_42 114
#define p9_42 7
//*
//*P8***
//*
//**function*
int gpio_export(int);
int gpio_unexport(int);
int gpio_direction(int, int);
int pin_write(int, int);
int pin_read(int);
//***
#endif /*BB_GPIO_*/
int gpio_export(int gpio_number)
{
FILE* fp=0;
if((fp = fopen(export_PATH,w))==NULL){
printf(Cannot open export file(%s).\n, export_PATH);
return -1;
}
fprintf(fp,%d,gpio_number);
fclose(fp);
}
int gpio_unexport(int gpio_number)
{
FILE* fp;
if((fp = fopen(unexport_PATH,w))==NULL){
printf(Cannot open unexport file(%s).\n, unexport_PATH);
return -1;
}
fprintf(fp,%d,gpio_number);
fclose(fp);
}
int gpio_direction(int gpio_number,int direction)
{
FILE* fp;
char set_value[4]={0};
char dir_path[50]={0};
sprintf(dir_path, direction_PATH, gpio_number);
if((fp = fopen(dir_path,w))==NULL){
printf(Cannot open direction file(%s).\n,dir_path);
return -1;
}
rewind(fp);
if(direction == out){
strcpy(set_value,out);
fwrite(set_value,sizeof(char),3,fp);
fclose(fp);
} else if(direction == in){
strcpy(set_value,in);
Re: [beagleboard] Re: i wanna 8bit gpio control
I believe the only way is to remove them from the main device tree overlay
since that will be loaded before anything else you can do. Decompile the
dtbo, remove the usr led entries in the resulting dts, and recompile to
dtbo (at least this is how it used to work).
On Wed, Aug 13, 2014 at 3:10 PM, Patrick Sheridan sher...@gmail.com wrote:
Hi Brandon,
I'm currently using mmap (in Python) to achieve register wide GPIO. I'm
concerned though, that the kernel still thinks it owns that memory and
might inadvertently write to it (for ex: if you forget to disable the
heartbeat trigger). Do you know of a way to disable the sysfs interface /
claim those pins as being in use so that you can safely manipulate the mmap
either through software or a device tree overlay?
Thanks for your help.
On Tuesday, July 29, 2014 3:09:08 PM UTC-4, Brandon I wrote:
That's still one bit control. There's going to be some unknown time
between the bits that will depend on cpu usage. For true 8 bit, you need to
use mmap to get a pointer to the gpio control block and modify the
registers directly.
Each gpio block has 32 pins, and each gpio block has a set and clear
register that's 32 bits wide, one bit for each pin. Setting a bit in the
set register will set the pin. Setting a bit in the clear register will
clear the pin. So, to set 8 pins at once, you would write the 8 bits to the
set, then to clear all 8, you would write those 8 bits to the clear
register. This will truly be at once, at least to the capabilities of the
hardware.
Sysfs has some pretty absurd overhead, so you'll get a few hundred kHz at
most. With the the register manipulation using mmap, you'll end up with ~4
MHz for a toggle like that.
On Sunday, July 27, 2014 4:09:56 AM UTC-7, kthab...@gmail.com wrote:
/sys/class/gpio/export this driver file i have used.
but this control only one bit. so, i try to 8bit control like this
#include bb_gpio.h
#include stdio.h
#include sys/time.h
//#include string.h
void main(void)
{
gpio_export(p9_11); gpio_export(p9_12);
gpio_export(p9_13); gpio_export(p9_14);
gpio_export(p9_15); gpio_export(p9_16);
gpio_export(p9_17); gpio_export(p9_18);
gpio_direction(p9_11,out); gpio_direction(p9_12,out);
gpio_direction(p9_13,out); gpio_direction(p9_14,out);
gpio_direction(p9_15,out); gpio_direction(p9_16,out);
gpio_direction(p9_17,out); gpio_direction(p9_18,out);
while(1){
pin_write(p9_11,1); pin_write(p9_12,1);
pin_write(p9_13,1); pin_write(p9_14,1);
pin_write(p9_15,1); pin_write(p9_16,1);
pin_write(p9_17,1); pin_write(p9_18,1);
sleep(1);
pin_write(p9_11,0); pin_wirte(p9_12,0);
pin_write(p9_13,0); pin_wirte(p9_14,0);
pin_write(p9_15,0); pin_wirte(p9_16,0);
pin_write(p9_17,0); pin_wirte(p9_18,0);
sleep(1);
};
}
#include bb_gpio.h
#ifndef BB_GPIO_H_
#define BB_GPIO_H_
#include stdio.h
#include string.h
/
* BB_GPIO headerfile
* This file only used to gpio control
* other feature using device-tree-overlay
* when using GPIO, the pin work to MODE7
*=formula==
* GPIO N1[N2]
* gpio_number = (32 x N1) + N2
*==
*/
#define out 1
#define in 0
#define export_PATH /sys/class/gpio/export
#define value_PATH /sys/class/gpio/gpio%d/value
#define direction_PATH /sys/class/gpio/gpio%d/direction
#define unexport_PATH /sys/class/gpio/unexport
//*P9***
#define p9_11 30
#define p9_12 60
#define p9_13 31
#define p9_14 50
#define p9_15 48
#define p9_16 51
#define p9_17 5
#define p9_18 4
//#define p9_19 13
//#define p9_20 12
#define p9_21 3
#define P9_22 2
#define p9_23 49
#define p9_24 15
#define p9_25 117
#define p9_26 14
#define p9_27 115
//#define p9_28 113
//#define p9_29 111
#define p9_30 112
//#define p9_31 110
#define p9_41 20
//#define p9_41 116
//#define p9_42 114
#define p9_42 7
//*
//*P8***
//*
//**function*
int gpio_export(int);
int gpio_unexport(int);
int gpio_direction(int, int);
int pin_write(int, int);
int pin_read(int);
//***
#endif /*BB_GPIO_*/
int gpio_export(int gpio_number)
{
FILE* fp=0;
if((fp = fopen(export_PATH,w))==NULL){
printf(Cannot open export file(%s).\n, export_PATH);
return -1;
}
fprintf(fp,%d,gpio_number);
fclose(fp);
}
int gpio_unexport(int gpio_number)
{
FILE* fp;
if((fp = fopen(unexport_PATH,w))==NULL){
printf(Cannot open unexport file(%s).\n, unexport_PATH);
return -1;
}
fprintf(fp,%d,gpio_number);
fclose(fp);
}
int gpio_direction(int gpio_number,int direction)
{
FILE* fp;
char set_value[4]={0};
char dir_path[50]={0};
Re: [beagleboard] Re: PRU FAQ 2013-05-15
You have to enable the ocp master port (section 10.1.2) to access main memory. Here's an explanation http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru . And, the resulting code is (if you want to do it in the pru): // clear STANDBY_INIT bit in syscfg register so memory between pru - system can be accessed (enable ocp master) LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 See section 3.1.2 in the pru reference https://github.com/beagleboard/am335x_pru_package for limitations (accessing memory below main memory 0x0008 requires enabling an offset, section 10.1.10). On Wed, Aug 13, 2014 at 2:02 PM, rakesh.safir rakesh.sa...@gmail.com wrote: Hi, I want to use the DCAN interface on PRU-ICSS to send/receive data present on DDR RAM at a fixed physical address. - Address of DDR is 0x8000_ to 0x9000_(256MiB) - My buffer is present at 0x8FF0_ to 0x9000_ (1MiB) As soon as I access the hardware address 0x8FF0_ the PRU-ICSS goes into some faulty state and becomes unresponsive. Is there some other way to access DDR from PRU-ICSS ? Rakesh On Thursday, May 16, 2013 2:42:39 AM UTC+5:30, Jason Kridner wrote: Frequently asked questions regarding PRU: - What is a PRU? - PRU stands for Programmable Real-time Unit. The overall subsystem is typically called the ICSS, PRU-ICSS or PRUSS. ICSS stands for Industrial Communications Subsystem and PRUSS stands for Programmable Real-time Unit Subsystem. - What does a PRU do? - A PRU is a 200MHz microcontroller that is really useful at bitbanging and has some peripherals attached to it that make it well suited for building real-time interfaces to all types of digital electronics. - What are the processing elements within the AM33xx PRUSS used on BeagleBone and BeagleBone Black? - 2 32-bit 200MHz PRU cores - Each with 8KB of program memory - Direct access to general purpose I/O - Single cycle operations without cache or pipelines (instructions *always* 5ns) - Shared 12KB data memory - Scratch pad registers - Parallel and serial capture modes - 32-bit port to memory and other peripherals outside of the PRUSS, including external memory - What are some example things built out of PRUs? - DMX512 lighting protocol: http://beagleboard. org/CapeContest/entries/BeagleBone+DMX+Cape/ http://beagleboard.org/CapeContest/entries/BeagleBone+DMX+Cape/ - 6502 memory interface: http://elinux.org/ images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf http://elinux.org/images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf - Emulated memory interface on an Atari 600XL with BeagleBone decoding video directly into Atari 600XL display memory: http://www.youtube.com/watch?v=1irR4TQ5aMA http://www.youtube.com/watch?v=1irR4TQ5aMA - Nixie tube interface: https://github.com/mranostay/beagle-nixie - Software UART: http://processors.wiki.ti.com/index.php/Soft-UART_ Implementation_on_AM335X_PRU_-_Software_Users_Guide http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide - Sine wave generator using PWMs: http://elinux.org/ ECE497_BeagleBone_PRU - 3D printer stepper motor driver: http:// hipstercircuits.com/pypruss-a-simple-pru-python-binding-for- beaglebone/ http://hipstercircuits.com/pypruss-a-simple-pru-python-binding-for-beaglebone/ - Camera interface: http://www.hitchhikeree.org/beaglebone_ capes/interacto/ - Where do I get some more details? - https://github.com/beagleboard/am335x_pru_package is the official location for documentation and tools for the PRUSS on BeagleBone and BeagleBone Black. - http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page. -- 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/u28ytaoNenU/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
