[beagleboard] Re: Connecting a flow sensor directly to BBB
Looks like there's a 1 wire driver that you can use: http://webshed.org/wiki/RaspberryPI_DS1820#Software On Thursday, April 2, 2015 at 7:13:51 PM UTC-7, Geoffrey Carson wrote: I am trying to connect a flow sensor directly to my BBB revC running Ubuntu trusty. I Have Strangebrew Elsinore up and running with 8 DS18B20 i-wire sensors. I want to utilize a hall sensor based flow sensor without having to get Arduino involved if possible. I am suffering sensory overload with this simple, I hope, task. Any help would be appreciated or even pointing me in the general direction. -- 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: Seriously Confused
I'm not sure the kernel source would be beneficial. If you want to understand how the ADC works or get it going manually, with all the clock domain setup and whatnot, then read the reference manual. The kernel source will be doing all of this, in an abstracted and not so easy to understand way. The driver/sysfs interface wont load up until the device tree overlay (that describes the ADC) is loaded. Is the BB-ADC overlay loaded? http://analogdigitallab.org/articles/using-adc-beaglebone-black On Thu, Nov 6, 2014 at 7:41 AM, Curt Carpenter 1cjcarpen...@att.net wrote: Thanks Brandon. Alas, the path used in the c_adc.c software just doesn't seem to exist in the Debian I'm using -- one of the big sources of confusion for me. I'm starting to think the only solution is to try to dig into the kernel source as Joshua suggests -- but that sounds like it might take more years than I have left :-) On Wednesday, November 5, 2014 4:24:01 PM UTC-6, Brandon I wrote: https://github.com/adafruit/adafruit-beaglebone-io-python/ blob/master/source/c_adc.c The adc source for bbio should be useful. Keep in mind that these sysfs interfaces are incredibly slow compared to memory poking since each operation requires opening, reading/writing and closing the file. For example, with GPIO, you're limited to a few hundred khz (regardless of language since it's just file operations). With mmap and python, you can toggle at 3Mhz. C a bit faster. Kernel, 12Mhz. There are python and closing libraries that handle all of the memory poking. Also, check out libpruio. It will setup the pin muxing, and provides quick adc and GPIO support. -- 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/9IRWOZ8b2n4/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.
[beagleboard] Re: Seriously Confused
https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/c_adc.c The adc source for bbio should be useful. Keep in mind that these sysfs interfaces are incredibly slow compared to memory poking since each operation requires opening, reading/writing and closing the file. For example, with GPIO, you're limited to a few hundred khz (regardless of language since it's just file operations). With mmap and python, you can toggle at 3Mhz. C a bit faster. Kernel, 12Mhz. There are python and closing libraries that handle all of the memory poking. Also, check out libpruio. It will setup the pin muxing, and provides quick adc and GPIO 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] Re: color ball tracking with opencv on BBB
Seems like a lot of work! Use an indirect internet connection to your beaglebone using the USB to your computer, then set up a bridge between your internet and the USB connection. On Wed, Oct 29, 2014 at 11:47 PM, Lingesh Waran radhaling...@gmail.com wrote: Hi all...I want to perform Image processing tasks in BBB which runs Debian Linux... so I need to install *OpenCV* on BBB.. It seems i should install *cmake * in prior... I dont have direct internet connection to my BBB.. I tried to download OpenCV from github.com http://www.google.com/url?q=http%3A%2F%2Fgithub.comsa=Dsntz=1usg=AFQjCNFCNLSjW9vNIlZmNtEh3Pi8fjEOSw as a ZIP file and i copied it to BBB using pendriveCan anyone please guide me how to install cmake on BBB?? i tried to download cmake and ended up in incomplete build please help me your ideas will be really appreciated Thanks in advance :) -- 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/fTan4VKv1no/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.
[beagleboard] how to gate input GPIO during powerup? also BBB SRM problems
For the external source, if your BB loses power, then you'll be powering it up through the esd does in the pin connected to that external power source. It probably won't survive. A general rule is to never apply voltage to a devices pin unless that device is powered up, unless it is in the devices design (rare). (typing with phone sucks) -- 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] Running Python on PC to simulate Beaglebone Python
Use one of the many remote python libraries. Rpyc could do it. Have the code accessible from a shared drive, use module reload, and run the functions and play with the objects as if they were local. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] PRU Assembly Questiony.
All pru GPIO are accessible via a single register, so it's one tick,just like any other register (two for loading a 32 bit immediate value). Arm GPIO are never accessible in a single tick since there way outside the Pru and have to go over the OCP bus. See http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru -- 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: Read register or memory location
If you just want to poke around, you can compile devmem2: http://free-electrons.com/pub/mirror/devmem2.c If you want proper high speed access, see the devmem2 source, or do the equivalent in python http://www.alexanderhiam.com/tutorials/beaglebone-io-using-python-mmap/, or any other language that supports mmap. On Wednesday, October 1, 2014 1:49:19 PM UTC-7, vescov...@gmail.com wrote: Is there an easy way to just read a memory location (or AM335x register) under Debian? Not from u-boot but after fully booted? -- 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 MultiCast
First google result seems useful: http://stackoverflow.com/questions/16374670/why-i-can-not-disable-multicast-request On Tuesday, September 16, 2014 7:14:10 AM UTC-7, Mickae1 wrote: I've tried to deactivate the Multicast with : ifconfig eth0 -multicast But when i check with this command, I can still see : ip maddr show 2: eth0 link 33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:9a:05:07 *inet 224.0.0.1* inet6 ff02::1:ff9a:507 inet6 ff02::1 Which is not good for me ! i've tried : debian@beaglebone:/Distrib/Scripts$ sudo ip -r maddr delete 224.0.0.1 dev eth0 ioctl: No such file or directory I also tried to ping 224.0.0.1 from an another device . And with the command tcpdump I can see that I'm receiving multicast packet : debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 224.0.0.1 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:09:28.679257 IP *190.190.167.1 224.0.0.1*: ICMP echo request, id 1, seq 1913, length 40 Why ? I really don't know what to do about it, My idea is to deactivate multicast in the kernel build config . Does it sounds good for you ? Thank you, Micka. -- 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: registering asynchronous events on kernel thread in user space
OK, one more time. All userspace interrupts work the same, pru, network driver, *anything*. The process blocks until the interrupt handler unblocks the process with a semaphore or completion in the kernel. For example, when you read data for a socket connection, it blocks. When data comes in, the data is copied to userspace, the read function unblocks. Again, this is all explained in that LDD3 chapter I linked. There's no other way to do it, except going around the kernel and polling memory. 1. This isn't a realtime kernel. You will always have jitter. Does it matter? I don't know what you're doing. You don't need to use polling. UIO and select doesn't use polling. 2. Using select (and even poll() since it's just a wrapper for select()) on the gpio doesn't poll. It's interrupt driven. Same method as described. 3. Same method as described. If you use the PRU, it will be the same method to notify your userspace application with the same shortcomings, unless you put all of your code into the pru. If you want deterministic timing, you either need a realtime kernel, or put all your code on the pru. But, I can guarantee you don't need deterministic timing, and I can guess that you're worrying about nothing Seriously, do some benchmarks with sysfs. It's only a few lines of code. And, there are all sorts of userspace hardware drivers that use userspace interrupts out there including graphics and network. If you only need to know when a gpio event happened, and process it later (it will always be later since this isn't a realtime kernel or in the pru), you can timestamp the event. I believe you can do this with the enhanced timers, and I know you can do this in the pru. So it would go, event happens, pru/etimer hardware timestamps the event, sends interrupt, userspace gets interupt using the only way possible, userspace reads timestamp from hardware, pretends that the event happened at the timestamp for any calculations. If you explained what you were doing, we could advise you better. Good luck! On Thursday, September 11, 2014, neo prag.in...@gmail.com wrote: Hi Brandon 1. I agree with jitter involved with processing interrupts and 100% cpu usage during polling for the same, so is there no way to let the user-space know that interrupt has occurred apart from polling ? 2. The reason why i said pseudo-interrupt is because we are polling and waiting there which is same as watching a flag in a UART register for RX flag to set. 3. I am curious as to how interrupts for Ethernet and usb are written. I am guessing that the ISR will use the DMA to transfer bytes to user-space. But even in that case the userspace should know that a new data has arrived. Then hoe to synchronize the kernel space and user-space if there are to share a data ? Thanks... On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote: pseudo-interrupt from user space There's nothing pseudo about it. Again, any usual way to have a userspace application respond to an interrupt will be the exact same. The kernel will block the userspace process until the interrupt is seen. The only real alternative is burning up the cpu with memory polling, which appears to be what the BBIOlib method uses. So, your latency is limited to your poll speed (which can be faster than interrupts). But, if you have a constant poll for minimum latency, lets hope you're not trying to do something important elsewhere since your cpu usage will be at 100%, and you'll be maximizing process to process context switching! For 4, The only difference between a userspace and kernel space interrupt handler is where the code is that responds to the interrupt. You will only benefit from writing your own interrupt handler if you put all of your code that does something with that interrupt in the kernel. Otherwise, you're back to process blocked by kernel, interrupt occurs, kernel unblocks process, process does something after seeing the interruptback to the sysfs/UIO method. I would try some benchmarks. See if the regular UIO/sysfs interrupt method gives you sufficient performance. And definitely keep in mind John's statement. You're going to see a massive amount of jitter for anything in userspace or kernel space (better jitter since you can disable interrupts and whatnot, but if you don't finish quickly in kernel space, you'll crash the kernel). If something like a precise timestamp is needed for an async event, then there are other ways to approach this. If you're looking for fixed low latency, you're doomed. On Wed, Sep 10, 2014 at 5:13 AM, neo prag@gmail.com wrote: pseudo-interrupt from user space -- 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/eNX0CU7-noE/unsubscribe
Re: [beagleboard] Re: color ball tracking with opencv on BBB
Or, cpufreq-set -f 1GHz On Thu, Sep 11, 2014 at 4:39 PM, William Hermans yyrk...@gmail.com wrote: Oh, and for the uninitiated . . . setting your governor to performance / 1Ghz _all_the_time_ may not be a very good idea. For instance it has been in the mid to upper 80's F outdoor ambient here, and I've noticed my BBB getting pretty warm. On Thu, Sep 11, 2014 at 4:34 PM, William Hermans yyrk...@gmail.com wrote: From memory setting profile limits would be like this You change to a profile via $ sudo cpufreq-set -g govenor_name Check profile limits $ sudo cpufreq-info -p Change minimum profile range $ cpufreq-set -d 100 /*set minimum processor freq for active profile to 1 GHz */ I do not know if these setting persist across reboots, but I think not. At least it did not see that was for me. Also settings seem to be a bit quirky. On one of my Linux support system for instance, manually changing anything did not work as expected. I could change profiles, governors etc, but actual frequency always stayed the same. Then with BBB when you set minimum ondemand profile to 1Ghz, it does not take. But when changing to performance profile, minimum freq is 300Mhz, but when you check actual processor freq it is 1Ghz . . . So yeah, anyhow the program is quirky. On Thu, Sep 11, 2014 at 4:26 PM, William Hermans yyrk...@gmail.com wrote: $ cpufreq-set --help. You may need to set you profile limits/ performance is default 300MHz to 1Ghz just like ondemand, but for some reason it is always 1GHz whenever I look. On Thu, Sep 11, 2014 at 3:47 PM, John Syn john3...@gmail.com wrote: From: janszymanski12...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Thursday, September 11, 2014 at 3:35 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: color ball tracking with opencv on BBB I was able to build and install the same version of openCV (2.4.9) on BBB debian as on my desktop Ubuntu by using an external USB memory stick. Now I have a problem with changing CPU frequency (as I would like to increase it from 300MHz to 1GHz) debian@beaglebone:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: generic_cpu0 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor ondemand may decide which speed to use within this range. * current CPU frequency is 300 MHz.* cpufreq stats: 300 MHz:97.20%, 600 MHz:0.20%, 800 MHz:0.06%, 1000 MHz:2.55% (35) debian@beaglebone:~$ sudo cpufreq-set -g GOV *Error setting new values*. Common errors: - Do you have proper administration rights? (super-user?) - Is the governor you requested available and modprobed? - Trying to set an invalid policy? - Trying to set a specific frequency, but userspace governor is not available, for example because of hardware which cannot be set to a specific frequency or because the userspace governor isn't loaded? debian@beaglebone:~$ William just explained how to do this earlier today: *sudo cpufreq-set -g performance* Regards, John What am I doing wrong? Jan On Wednesday, 10 September 2014 12:52:11 UTC+10, Brandon I wrote: And, here are some compile flags you'll want to include/force: http://www.eliteraspberries.com/blog/2013/09/cflags-for-numerical- computing-on-the-beaglebone-black.html On Tue, Sep 9, 2014 at 7:16 PM, Brandon I brando...@gmail.com wrote: I'm not sure that newer open cv can be compiled on the raspberry or beaglebone due to the limited ram. You'll probably have to cross compile. On Tue, Sep 9, 2014 at 5:56 PM, janszyma...@gmail.com wrote: Thanks for that link, it is very usefull. In a meantime my attempt to install a newer version of opencv (following the instructions from here http://robertcastle.com/2014/ 02/installing-opencv-on-a-raspberry-pi/0) has failed firstly with cmake-curses-gui not working (empty database?) and after that (using command line cmake) the building stopped with a error message of not enough memory. Jan On Tuesday, September 9, 2014 11:03:58 AM UTC+10, janszyma...@gmail.com wrote: Hi, I need to implement tracking of color ball with opencv on BBB. I have a rev.C BBB with latest (default Debian) including opencv 2.3.1 On my desktop Ubuntu I have installed opencv 2.4.9 To check the initial performance I used the example webcam program from the book Practical OpenCV listing 4-4 p.34 playing the video from USB
Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space
pseudo-interrupt from user space There's nothing pseudo about it. Again, any usual way to have a userspace application respond to an interrupt will be the exact same. The kernel will block the userspace process until the interrupt is seen. The only real alternative is burning up the cpu with memory polling, which appears to be what the BBIOlib method uses. So, your latency is limited to your poll speed (which can be faster than interrupts). But, if you have a constant poll for minimum latency, lets hope you're not trying to do something important elsewhere since your cpu usage will be at 100%, and you'll be maximizing process to process context switching! For 4, The only difference between a userspace and kernel space interrupt handler is where the code is that responds to the interrupt. You will only benefit from writing your own interrupt handler if you put all of your code that does something with that interrupt in the kernel. Otherwise, you're back to process blocked by kernel, interrupt occurs, kernel unblocks process, process does something after seeing the interruptback to the sysfs/UIO method. I would try some benchmarks. See if the regular UIO/sysfs interrupt method gives you sufficient performance. And definitely keep in mind John's statement. You're going to see a massive amount of jitter for anything in userspace or kernel space (better jitter since you can disable interrupts and whatnot, but if you don't finish quickly in kernel space, you'll crash the kernel). If something like a precise timestamp is needed for an async event, then there are other ways to approach this. If you're looking for fixed low latency, you're doomed. On Wed, Sep 10, 2014 at 5:13 AM, neo prag.in...@gmail.com wrote: pseudo-interrupt from user space -- 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: registering asynchronous events on kernel thread in user space
See UIO: https://www.kernel.org/doc/htmldocs/uio-howto/ The uio_pruss.c driver that comes with the pru package is a good example. I have written a kernel module that registers interrupts on the rising edge on a GPIO pin and want to relay this message to user space. The sysfs gpio interface already does this. Check out the code. On Thursday, August 28, 2014 2:44:12 AM UTC-7, sid...@gmail.com wrote: I have read online that we can't handle interrupts from user space. Instead - 1) We can write a kernel thread and have that thread wait on an event. 2) Once the interrupt occurs, send one asynchronous event from the kernel module/driver to user space where we will have one signal handler with FASYNC to tackle this I have written a kernel module that registers interrupts on the rising edge on a GPIO pin and want to relay this message to user space. How do I go about implementing the above? 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: color ball tracking with opencv on BBB
You're desktop PC is 10 times faster than the Beaglebone processor. This may help: How to Achieve 30 fps with BeagleBone Black http://blog.lemoneerlabs.com/3rdParty/Darling_BBB_30fps_DRAFT.html On Monday, September 8, 2014 6:03:58 PM UTC-7, janszyma...@gmail.com wrote: Hi, I need to implement tracking of color ball with opencv on BBB. I have a rev.C BBB with latest (default Debian) including opencv 2.3.1 On my desktop Ubuntu I have installed opencv 2.4.9 To check the initial performance I used the example webcam program from the book Practical OpenCV listing 4-4 p.34 playing the video from USB camera (Logitech C920) I need a resolution of 640x480. The problem is with a speed on BBB, having a significant delay. It's good on a desktop PC. I would like to ask for advice how to improve the performance on BBB if possible. Jan -- 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] Is it possible to command a beaglebone black over Ethernet.
Ethernet will work without any configuration if you have dhcp on your network. If not, you'll have to configure a static ip. If you do have dhcp (you probably do) you can just change the hostname ( https://wiki.debian.org/HowTo/ChangeHostname) to something nice, then use that instead of an ip for ssh, avoiding the insanity of a static ip. On Monday, September 8, 2014 12:14:17 PM UTC-7, William Hermans wrote: Yes you can. You did not mention which distro you're using on the beaglebone black though. Assuming Debian . . . https://wiki.debian.org/NetworkConfiguration On Mon, Sep 8, 2014 at 11:47 AM, dev@gmail.com javascript: wrote: I want to use the single usb port on beaglebone black for a usb webcam, so can i avoid using the usb and control the beaglebone through the Ethernet?, I don’t have a monitor either for the beaglebone black. -- 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. -- 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] Is it possible to command a beaglebone black over Ethernet.
I saw the link to the reference, but I didn't see an answer to his question. On Tue, Sep 9, 2014 at 2:47 PM, William Hermans yyrk...@gmail.com wrote: Brandon, I guess you did not look at the link I gave. It covers every aspect of configuring an eth device on Debian. That is when using /etc/network/interfaces On Tue, Sep 9, 2014 at 1:21 PM, Brandon I brandon.ir...@gmail.com wrote: Ethernet will work without any configuration if you have dhcp on your network. If not, you'll have to configure a static ip. If you do have dhcp (you probably do) you can just change the hostname ( https://wiki.debian.org/HowTo/ChangeHostname) to something nice, then use that instead of an ip for ssh, avoiding the insanity of a static ip. On Monday, September 8, 2014 12:14:17 PM UTC-7, William Hermans wrote: Yes you can. You did not mention which distro you're using on the beaglebone black though. Assuming Debian . . . https://wiki.debian.org/NetworkConfiguration On Mon, Sep 8, 2014 at 11:47 AM, dev@gmail.com wrote: I want to use the single usb port on beaglebone black for a usb webcam, so can i avoid using the usb and control the beaglebone through the Ethernet?, I don't have a monitor either for the beaglebone black. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/XbVuaXA9qYQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: color ball tracking with opencv on BBB
I'm not sure that newer open cv can be compiled on the raspberry or beaglebone due to the limited ram. You'll probably have to cross compile. On Tue, Sep 9, 2014 at 5:56 PM, janszymanski12...@gmail.com wrote: Thanks for that link, it is very usefull. In a meantime my attempt to install a newer version of opencv (following the instructions from here http://robertcastle.com/2014/02/installing-opencv-on-a-raspberry-pi/0) has failed firstly with cmake-curses-gui not working (empty database?) and after that (using command line cmake) the building stopped with a error message of not enough memory. Jan On Tuesday, September 9, 2014 11:03:58 AM UTC+10, janszyma...@gmail.com wrote: Hi, I need to implement tracking of color ball with opencv on BBB. I have a rev.C BBB with latest (default Debian) including opencv 2.3.1 On my desktop Ubuntu I have installed opencv 2.4.9 To check the initial performance I used the example webcam program from the book Practical OpenCV listing 4-4 p.34 playing the video from USB camera (Logitech C920) I need a resolution of 640x480. The problem is with a speed on BBB, having a significant delay. It's good on a desktop PC. I would like to ask for advice how to improve the performance on BBB if possible. Jan -- 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/fTan4VKv1no/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space
Before you jump into the kernel hole, is there a reason that you're not using the existing sysfs gpio interface ( https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) for the interrupts? Using this, if you set the gpio up as an interrupt with the sysfs interface, you poll() the value file and it will block until there's an interrupt. When it unblocks, you can read the current value. Or, you can make the gpio look like an event/button: http://bec-systems.com/site/281/how-to-implement-an-interrupt-driven-gpio-input-in-linux Any sane way you do it will be the same at the low level. You'll have a read or ioctl function on the kernel device file that blocks in the kernel using a completion/semaphore, putting your process/thread to sleep. When the interrupt fires, the interrupt handler function is called to release the completion/semaphore, unblocking your process/thread and allowing it to continue executing. This unblocking is how the userspace program is signaled. So, if you *want* to reinvent the wheel, for understanding, then that's fine. But, there's an existing interface that exists, only a few lines of code away. --Brandon On Tue, Sep 9, 2014 at 7:10 PM, neo star prag.in...@gmail.com wrote: Hi Brandon I read through the link, very informative thanks.I can create a thread to do the polling and signal me when its ready. But how to really write an ISR in arm. I see a lot of guides but they say that it will work in Intel processors but they are not sure about ARM. For sure from my readings i see that i need a kernel object to handle an ISR, But how to really do that. One example about how to handle interrupts is in http://stackoverflow.com/questions/15245626/simple-interrupt-handler-request-irq-returns-error-code-22 The other one is request_threaded_irq() as mentioned by Kavita in the above post. Is there any How to and guide to writing one. Any links. Thanks. On Wednesday, September 10, 2014 12:59:08 AM UTC+5:30, Brandon I wrote: See UIO: https://www.kernel.org/doc/htmldocs/uio-howto/ The uio_pruss.c driver that comes with the pru package is a good example. I have written a kernel module that registers interrupts on the rising edge on a GPIO pin and want to relay this message to user space. The sysfs gpio interface already does this. Check out the code. On Thursday, August 28, 2014 2:44:12 AM UTC-7, sid...@gmail.com wrote: I have read online that we can't handle interrupts from user space. Instead - 1) We can write a kernel thread and have that thread wait on an event. 2) Once the interrupt occurs, send one asynchronous event from the kernel module/driver to user space where we will have one signal handler with FASYNC to tackle this I have written a kernel module that registers interrupts on the rising edge on a GPIO pin and want to relay this message to user space. How do I go about implementing the above? Thanks! -- 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/eNX0CU7-noE/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: color ball tracking with opencv on BBB
And, here are some compile flags you'll want to include/force: http://www.eliteraspberries.com/blog/2013/09/cflags-for-numerical-computing-on-the-beaglebone-black.html On Tue, Sep 9, 2014 at 7:16 PM, Brandon I brandon.ir...@gmail.com wrote: I'm not sure that newer open cv can be compiled on the raspberry or beaglebone due to the limited ram. You'll probably have to cross compile. On Tue, Sep 9, 2014 at 5:56 PM, janszymanski12...@gmail.com wrote: Thanks for that link, it is very usefull. In a meantime my attempt to install a newer version of opencv (following the instructions from here http://robertcastle.com/2014/02/installing-opencv-on-a-raspberry-pi/0) has failed firstly with cmake-curses-gui not working (empty database?) and after that (using command line cmake) the building stopped with a error message of not enough memory. Jan On Tuesday, September 9, 2014 11:03:58 AM UTC+10, janszyma...@gmail.com wrote: Hi, I need to implement tracking of color ball with opencv on BBB. I have a rev.C BBB with latest (default Debian) including opencv 2.3.1 On my desktop Ubuntu I have installed opencv 2.4.9 To check the initial performance I used the example webcam program from the book Practical OpenCV listing 4-4 p.34 playing the video from USB camera (Logitech C920) I need a resolution of 640x480. The problem is with a speed on BBB, having a significant delay. It's good on a desktop PC. I would like to ask for advice how to improve the performance on BBB if possible. Jan -- 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/fTan4VKv1no/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can allocated pins on BBB be used as GPIOs ?
halfbrain, - If I used the EMMC pins I would need to boot from SD Card everytime? Correct. You'll use the beaglebone white/sd card images. The beaglebone will automatically boot from the SD card since it wont be able to find the EMMC. - And if I used the HMDI Pins it wouldn't be possible to connect the uHdmi Cable to the bbb and connect some screen to it? Because they are connected to the same pins? No HDMI if you disable HDMI, but you can still ssh/vnc in. The way I'm suggesting is the proper way to disable built in overlays that are loaded at boot. For some reason, only the hdmi and emmc interfaces are added as overlays that can be disabled at boot. i2c and the likes are hard coded in the dts file. Why? I don't know. Maybe there's a good reason, probably not. --Brandon On Thu, Sep 4, 2014 at 7:28 AM, halfbrain adrian.mitev...@gmail.com wrote: Thanks for your Answer Brandon Just a few questions for my Information: - If I used the EMMC pins I would need to boot from SD Card everytime? - And if I used the HMDI Pins it wouldn't be possible to connect the uHdmi Cable to the bbb and connect some screen to it? Because they are connected to the same pins? The way you unallocated the pins and the way john recommend me to unallocate the pins seem to be very different. To be honest I don't understand the difference of the two ways. Which way is the easier one and can this way be used to unallocate every pin on the bbb? I just wan't to make things trickier than they are :-) But i'm very thankful for your help so far ;-) Am Mittwoch, 3. September 2014 22:00:16 UTC+2 schrieb Brandon I: halfbrain, I forgot to mention, you should tie the eMMC cmd and clock pins low on P8.20 and P8.21, as suggested by the wiki: http://elinux.org/ Beagleboard:BeagleBoneBlack#Onboard_eMMC On Wednesday, September 3, 2014 12:58:09 PM UTC-7, Brandon I wrote: halfbrain, If you're using angstrom or debian, you can disable the emmc by adding this to the optargs in uEnv.txt on the usb mass storage partition: capemgr.disable_partno=BB-BONE-EMMC-2G If you're not using hdmi, you can free up those too: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT- HDMIN,BB-BONE-EMMC-2G On Saturday, August 23, 2014 1:11:22 AM UTC-7, halfbrain wrote: Would be nice if you could explain how to disable eMMC on debian. I ran out of GPIO's in my project. Tried to use P9_19 and P9_20 (both I2C's) in the device tree overlay but since i did that the overlay doesn't work correctly anymore. Am Sonntag, 18. Mai 2014 22:19:16 UTC+2 schrieb john3909: From: Dhruv Vyas dhruv@gmail.com Reply-To: beagl...@googlegroups.com Date: Sunday, May 18, 2014 at 2:42 AM To: beagl...@googlegroups.com Subject: [beagleboard] Can allocated pins on BBB be used as GPIOs ? Hello, I recently started working on my BBB A6A. I went through necessary getting started guides and it works like a charm. Now as a part of my project, I need to use some of the GPIOs on P8/P9 header. While googling how to use them as a GPIO, and how to set pinmux and etc, I went through this guide. http://derekmolloy.ie/gpios- on-the-beaglebone-black-using-device-tree-overlays/ and he explained everything very clearly. Now my question is : is there any way i can use allocated pins as GPIOs other than available pins ? If yes, how ? If no, why ? For example, P9_19 and P9_20 are Allocated to (Group: pinmux_i2c2_pins) and hence it can not be used as GPIOs ? If pins are also connected to circuitry on the board that cannot be disabled then you cannot use those pins for GPIO. For example, pins used for the eMMC can be used for GPIO as long as eMMC is disabled. Same for LCD pins, but then you cannot use LCD or HDMI. I2C2 isn't connected to other circuity on the board so you can use it for GPIO. Regards, John 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. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/amEtmzQoyyc/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can allocated pins on BBB be used as GPIOs ?
halfbrain, If you're using angstrom or debian, you can disable the emmc by adding this to the optargs in uEnv.txt on the usb mass storage partition: capemgr.disable_partno=BB-BONE-EMMC-2G If you're not using hdmi, you can free up those too: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G On Saturday, August 23, 2014 1:11:22 AM UTC-7, halfbrain wrote: Would be nice if you could explain how to disable eMMC on debian. I ran out of GPIO's in my project. Tried to use P9_19 and P9_20 (both I2C's) in the device tree overlay but since i did that the overlay doesn't work correctly anymore. Am Sonntag, 18. Mai 2014 22:19:16 UTC+2 schrieb john3909: From: Dhruv Vyas dhruv@gmail.com Reply-To: beagl...@googlegroups.com Date: Sunday, May 18, 2014 at 2:42 AM To: beagl...@googlegroups.com Subject: [beagleboard] Can allocated pins on BBB be used as GPIOs ? Hello, I recently started working on my BBB A6A. I went through necessary getting started guides and it works like a charm. Now as a part of my project, I need to use some of the GPIOs on P8/P9 header. While googling how to use them as a GPIO, and how to set pinmux and etc, I went through this guide. http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/ and he explained everything very clearly. Now my question is : is there any way i can use allocated pins as GPIOs other than available pins ? If yes, how ? If no, why ? For example, P9_19 and P9_20 are Allocated to (Group: pinmux_i2c2_pins) and hence it can not be used as GPIOs ? If pins are also connected to circuitry on the board that cannot be disabled then you cannot use those pins for GPIO. For example, pins used for the eMMC can be used for GPIO as long as eMMC is disabled. Same for LCD pins, but then you cannot use LCD or HDMI. I2C2 isn’t connected to other circuity on the board so you can use it for GPIO. Regards, John 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. 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] Can allocated pins on BBB be used as GPIOs ?
halfbrain, I forgot to mention, you should tie the eMMC cmd and clock pins low on P8.20 and P8.21, as suggested by the wiki: http://elinux.org/Beagleboard:BeagleBoneBlack#Onboard_eMMC On Wednesday, September 3, 2014 12:58:09 PM UTC-7, Brandon I wrote: halfbrain, If you're using angstrom or debian, you can disable the emmc by adding this to the optargs in uEnv.txt on the usb mass storage partition: capemgr.disable_partno=BB-BONE-EMMC-2G If you're not using hdmi, you can free up those too: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G On Saturday, August 23, 2014 1:11:22 AM UTC-7, halfbrain wrote: Would be nice if you could explain how to disable eMMC on debian. I ran out of GPIO's in my project. Tried to use P9_19 and P9_20 (both I2C's) in the device tree overlay but since i did that the overlay doesn't work correctly anymore. Am Sonntag, 18. Mai 2014 22:19:16 UTC+2 schrieb john3909: From: Dhruv Vyas dhruv@gmail.com Reply-To: beagl...@googlegroups.com Date: Sunday, May 18, 2014 at 2:42 AM To: beagl...@googlegroups.com Subject: [beagleboard] Can allocated pins on BBB be used as GPIOs ? Hello, I recently started working on my BBB A6A. I went through necessary getting started guides and it works like a charm. Now as a part of my project, I need to use some of the GPIOs on P8/P9 header. While googling how to use them as a GPIO, and how to set pinmux and etc, I went through this guide. http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/ and he explained everything very clearly. Now my question is : is there any way i can use allocated pins as GPIOs other than available pins ? If yes, how ? If no, why ? For example, P9_19 and P9_20 are Allocated to (Group: pinmux_i2c2_pins) and hence it can not be used as GPIOs ? If pins are also connected to circuitry on the board that cannot be disabled then you cannot use those pins for GPIO. For example, pins used for the eMMC can be used for GPIO as long as eMMC is disabled. Same for LCD pins, but then you cannot use LCD or HDMI. I2C2 isn’t connected to other circuity on the board so you can use it for GPIO. Regards, John 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. 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] Tri-state GPIOs?
As a side note, you can also emulate open drain. Set the pin output state to 0, then enable/disable the output driver. And, for performance, writing to the gpio registers rather than doing file operations with sysfs is 30 times faster. And, pin muxing (pullups/down and input receiver enable for reading pin state) is separate from the gpio operations (output driver enable/disable, reading physical pin state, setting output driver level). On Wednesday, August 27, 2014 12:02:11 PM UTC-7, Gerald wrote: But, you have to watch the pullups and pull downs when you do that. Gerald On Tue, Aug 26, 2014 at 8:20 PM, John Syn john...@gmail.com javascript: wrote: From: Gerald Coley ger...@beagleboard.org javascript: Reply-To: beagl...@googlegroups.com javascript: beagl...@googlegroups.com javascript: Date: Tuesday, August 26, 2014 at 1:06 PM To: beagl...@googlegroups.com javascript: beagl...@googlegroups.com javascript: Subject: Re: [beagleboard] Tri-state GPIOs? No. You can emulate tristate by changing GPIO outputs to GPIO inputs. Regards, John Gerald On Tue, Aug 26, 2014 at 4:36 AM, david.b...@gmail.com javascript: wrote: Hey Guys Has the Beaglebone black *tri-state gpios*? When yes, how can I set up them? 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/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. 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] Setting the Bitrate of I2C2 on the Beaglebone Black
I think this can only mean that a device isn't responding to the address you're providing. Did you set the i2c device address to the same value used with i2ctest? On Thu, Aug 14, 2014 at 10:09 AM, Akhil Panyamparambil akhilpana...@gmail.com wrote: Hi all. Can you guys help me.I am using beaglebone black i2c2 pin 19 and 20 of p9. Somewhere in the net it was told i2c2 has told accessed with i2c-1 in /dev folder. I am booting default amstrom linux from emmc. Hardware is completely checked and verified. I have connected 3 io expansion modules to i2c bus. I can communicate to them by i2ctest commands from command line. But the problem is with the file writes. I cant write to /dev/i2c-1 file with write function. The file descriptor doeant have an error. Also the ioctl calls doest make any errors. But the write function is having problem. And thus I cant access i2c bus in application layer. -- 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/vbuM-4oShS8/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: 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};
sprintf
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.
Re: [beagleboard] long term BBB based art installation
You can do read only with stock debian using this approach: http://ecloud.org/index.php?title=Debian_on_read-only_media This is very important for long term installs with flash media. If you do need to write, use a usb flash disk that the customer can get to and replace when needed, because it will eventually fail. On Sat, Aug 2, 2014 at 9:46 PM, Daniel Pickford dpickf...@gmail.com wrote: Matty, Sounds like a fun project! My issues with the BBBs historically have all been power related and SD card related. I can't say I've ran one for longer that a few months without rebuilding it, but it's the first few months that generally present the hardware problems. In regards to a long term BBB install, the duty cycle on the SD card is of significant concern (if you have a high quality power supply). I'm seeing uSD cards start to fail with 10K's of block rewrites on professional grade microsd's right now. There are MLC/SLC industrial cards out there, but they are pretty expensive. The idea of throwing any logs or writes onto a ramdisk is solid. I don't have experience with the long term reliability of the onboard eMMC (in general I find the r/w speeds a little slow and I like keeping a default bootable image around in case sd card starts dying (see previous paragraph...)) but if you can get rid of every last block rewrite regardless of what flash storage type, it'll be worth it. If you concerned about boot times, check out systemd, super easy to get working on the current debian stable. I spend more time waiting for USB peripherals to boot up than the OS services nowadays. https://wiki.debian.org/systemd. You just have to pass the systemd kernel parameter in uEnv.txt. If it's autobootable by OSX you are likely running fat32 on the /boot volume. It's not that robust of a filesystem, and is a little long in the tooth. You might want to switch to ext2+. Because of the aforementioned flash duty cycle issues, I try to leave the boot volume alone and effectively read only. The file being interpreted as a binary is a nasty one - it actually sounds like the file could be getting corrupted. I'd use the file command on the scripts you are having problems with, it basically checks to see if you have any non-null bytes. How do you fix it? Delete the file and copy a new one? On Aug 2, 2014, at 9:01 PM, Matt Pinner mpin...@gmail.com wrote: tldr: im using 2x beagle bone in a long term install and hope to enable anyone to update the configurations. Thanks for all the great advice thus far. i'm starting to feel confident about a few things. ok, im not sure im ready for the read-only mount. i like using the eMMC. are there advantages wrt stability. i aim to keep the debian as close to stock as possible. im considering upgrading to the 4gb bbb's in an effort to avoid disk issues and get the stock os. i quite like being able to mount the beagle eMMc /boot/uboot as a removeable drive on my mac. exposing this usb drive can potentially enable a complete noob to update configurations. i put im having all scripts source /boot/uboot/env.sh by default to enable some global values. when i move and edit files on /boot/uboot/ when mounted as a drive on my mac, occasionally, the file will become unexecutable as bash script and become interrupted as binary? know what causing that? i've roughly put my latest configuration in https://github.com/mpinner/Active --matt On Tue, Jul 29, 2014 at 1:19 PM, Brandon I brandon.ir...@gmail.com wrote: Don't forget, read only mount! Flash has limited writes and is can easily be corrupted/damaged from power failure. On Tuesday, July 29, 2014 9:02:52 AM UTC-7, Ben Gamari wrote: Matt Pinner mpi...@gmail.com writes: tldr: can i run a BBB for three years? Sure! I'm about to fly a BBB (w the latest debian) high into the rafters at a space in Denver. Awesome! It will control 1440 leds over SPI from pixel data sent over UDP via OPC. What is OPC? Presumably this isn't OLE for Process Control? This is all very exciting for me and things have been running fairly smoothly and the community support and blogs have been enormously helpful. Now i'm kind of freaking out bc this thing should ideally run as stably as any light fixture and i'm not sure a good way to really test that kind of thing. Indeed it's not easy to test for stability. I've found the BBB hardware to be rock solid but YMMV. The obvious place to start would be just to let the board sit running your code for as long as you can. the sub one-minute boot up time seems acceptible enough, so the client can always reboot it, but then what does that do the filesystem? i've started looking into logrotate to keep the disk cleared, but there is still the question how many read/write cycles will the eMMC accept before drama happens? If at all possible I would try to keep the root file system mounted as read-only
Re: [beagleboard] Re: Maximum current on GPIO?
Serge, I was talking about the pin driver circuit inside the package (something like this http://i.stack.imgur.com/f3Dz6.png) not an external connection to 3.3V or ground, but I totally agree for external connections. Always make sure the current in and out of the pin, in any oops type configuration, will be limited to what the pin can handle. On Wed, Jul 30, 2014 at 10:37 PM, serge.ns...@gmail.com wrote: On Thursday, July 31, 2014 12:39:42 AM UTC+6, Brandon I wrote: The gpio are push pull/pseudo open drain, so there's a transistor/switch going from 3.3V to the pin,... At boot time the respective Sitara pins become outputs high/low level as needed. Then, please never assume your GPIO is tri-state. In theory you may connect 3.3v power line direct to the pin if: 1) you are sure it is not used at boot time as the output 2) it is 3.3v domain power related pin. Feel free to ground the pin if: 1) you are sure it is never used at boot time as an output, and you never drive it High. To live safe and feel happy always add pulling resistors, never connect pin to the VCC or GND dorectly. -- 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/cWGCEtg9syY/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Maximum current on GPIO?
The gpio are push pull/pseudo open drain, so there's a transistor/switch going from 3.3V to the pin, and a transistor going from ground to the pin. When you set the pin high, you're turning on only the transistor to 3.3V, so it's sourcing the current from 3.3V, through the transistor, out of the pin. When you set it low, you're turning on the transistor to ground, so it's sinking the current into the pin, through the transistor, and to ground. If you have both off (high impedance), there isn't any significant current going anywhere (I think it's some nA). On Wed, Jul 30, 2014 at 6:11 AM, k...@cranehome.info wrote: A GPIO configured as an input will not draw substantial current from the line it's connected to. It is sensitive to the charge level on the line and will not draw current from it (exempting the gate capacitor charge-up). A GPIO that is set to OUTPUT a high signal is now a potential source of current. If you hook that up to the + end of a motor it will try to power the motor with the output. In that case you MUST insure that your circuit limits the current to a maximum of 6mA. The same is true if you OUTPUT a low signal. Hook that to the - lead on a motor and the + lead to supply and the CPU is now trying to absorb all the current from that motor and will go poof. So if you were to connect directly to the positive supply and say somehow that pin ever becomes an output that is low you now have a dead short through the I/O pin and at best you'll fry that pin or its whole bank, you'll likely kill the whole chip. Since the I/O on these devices is programmatic I never like to connect a pin directly to the supply rails. -- 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/cWGCEtg9syY/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Maximum current on GPIO?
Source 6mA, sink 8mA, with the following pins limited to sourcing 4mA: P9_19 gpio0[13] · P9_20 gpio0[12] · P9_24 gpio0[15] · P9_26 gpio0[14] · P9_41 gpio0[20] · P9_42 gpio0[7] On Monday, July 28, 2014 7:24:52 AM UTC-7, Gerald wrote: 6mA. No. Gerald On Mon, Jul 28, 2014 at 9:03 AM, PLyttle rkst...@gmail.com javascript: wrote: This question has been asked and answered before. There is a search box with a big blue button marked Search next to it. I suggest you use it. The document you need is the processor data sheet. (SPRS717F) table 2.7 On Monday, July 28, 2014 8:26:48 AM UTC+2, ope...@gmail.com wrote: Hi, I already searched trough TI AM3358 TRM and BBB manual but with no success, so I'll have to ask it here: what ist the maximum current one can pull out of an GPIO pin? And does the CPU/the related pin die in case of short-circuit of a GPIO or is there an internal protection mechanism? Cheers Jim -- 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. -- 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: i wanna 8bit gpio control
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);
fwrite(set_value,sizeof(char),2,fp);
fclose(fp);
} else{
printf(invalue pin mode(%d)\n,direction);
return -1;
}
fclose(fp);
return 1;
}
int pin_write(int gpio_number,int value)
{
FILE* fp;
char val_path[50]={0};
char set_value[2]={0};
sprintf(val_path, value_PATH, gpio_number);
if((fp = fopen(val_path,w))==NULL){
printf(Cannot open value file(%s).\n,val_path);
return -1;
}
rewind(fp);
if(value == 1){
strcpy(set_value,1);
}
else if(value == 0){
strcpy(set_value,0);
}
else {
printf(invalid value pin(%d)(%d)\n, gpio_number, value);
Re: [beagleboard] long term BBB based art installation
Don't forget, read only mount! Flash has limited writes and is can easily be corrupted/damaged from power failure. On Tuesday, July 29, 2014 9:02:52 AM UTC-7, Ben Gamari wrote: Matt Pinner mpi...@gmail.com javascript: writes: tldr: can i run a BBB for three years? Sure! I'm about to fly a BBB (w the latest debian) high into the rafters at a space in Denver. Awesome! It will control 1440 leds over SPI from pixel data sent over UDP via OPC. What is OPC? Presumably this isn't OLE for Process Control? This is all very exciting for me and things have been running fairly smoothly and the community support and blogs have been enormously helpful. Now i'm kind of freaking out bc this thing should ideally run as stably as any light fixture and i'm not sure a good way to really test that kind of thing. Indeed it's not easy to test for stability. I've found the BBB hardware to be rock solid but YMMV. The obvious place to start would be just to let the board sit running your code for as long as you can. the sub one-minute boot up time seems acceptible enough, so the client can always reboot it, but then what does that do the filesystem? i've started looking into logrotate to keep the disk cleared, but there is still the question how many read/write cycles will the eMMC accept before drama happens? If at all possible I would try to keep the root file system mounted as read-only. It can be difficult to predict the rate of disk writes (e.g. logging rate) on a running system and I wouldn't want to risk it just for log files. This is especially true if you may have flaky power (SD cards have been known to die when power is removed at the wrong point in a write operation). My first instinct would be to play it safe and put /var on a tmpfs. I plan to have a private network running so i should be able to login to the BBB for some kind of maintenance and troubleshooting. do i run a long (100ft) serial cable? and usb cable as well? It certainly wouldn't hurt to have something like this in place, especially at first. im tempted to put it online so i can check from afar, but i feel that invites all kinds of new room for disaster and abuse. If you firewall all but port 22 and configure sshd securely (either a particularly strong password or exclusively key-based authentication) I'd say the risk is pretty low. Let us know how it goes and don't hesitate to ask more questions! Cheers, - Ben -- 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: C Code to send UDP packets using Ethernet
There's nothing Beaglebone about this question, really. Just google send udp packets c posix. On Thursday, July 17, 2014 3:46:18 AM UTC-7, msc.a.f...@googlemail.com wrote: Hi everyone, I am new with the Beaglebone black and I would like to make a little program in C to send UDP packets using Ethernet. Can someone please tell me where I can find some code to do this or to point in the right direction to do this? Thank you for the help -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: PRU Pin Mux
I don't believe the reads/writes to the GPIO registers would have worked without the OCP master being enabled. Thanks, I'll check out the library to see what magic is missing from that code. On Jun 21, 2014 8:20 AM, TJF jeli.freih...@gmail.com wrote: A miss click and a miss post ... The PRUSS can access the Control Modul pin mux registers. It's working for a lot of libpruio users. Did you enable the OCP master port? -- 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/ukPLH3-1hbA/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: PRU Pin Mux
You have 100% full control over anything the PRU can access. This pru code seems to disproves this. The PRU cannot modify the configuration registers. // enable ocp master. LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 // turn on gpio mov r1, 0x4000 mov r0, 0x44E07194 SBBO b, a, 0, 4 // readback LBBO b, a, 0, 4 // gpio off mov b, 0x4000 mov a, 0x44E07190 SBBO b, a, 0, 4 // readback LBBO b, a, 0, 4 On Monday, May 19, 2014 2:36:51 PM UTC-7, Charles Steinkuehler wrote: On 5/19/2014 4:06 PM, Brandon I wrote: The pin mux registers require privileged memory access, which is why the kernel space is usually required. The pru can write these!? Of course. The PRU is directly wired into the on-chip bus, and bypasses all ARM side sanity checks like memory page access restrictions. You have 100% full control over anything the PRU can access, which is just about every significant chunk of hardware on the die except for: * SGX-530 GPU * AES SHA crypto accelerator * USB * MMC Details are in the Interconnects section of the TRM (section 10), and remember: With great power comes great responsibility! -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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: PRU Pin Mux
I apologize, a miss click posted that...full code below. *// enable ocp master.*LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 *// try to set gpio address* *// gpio on*mov r1, 0x4000# gpio 0, bit 14, p9.29 mov r0, 0x44E07194 # gpio 0 set register SBBO r1, r0, 0, 4 *// led on p9.26 light up here, devmem2 shows this address was set* *// readback*LBBO r1, r0, 0, 4 *// readback matches!* *// gpio off*mov r1, 0x4000 # bit 14, p9.29 mov r0, 0x44E07190 # gpio 0 clear register SBBO r1, r0, 0, 4 *// led on p9.26 shuts off here, devmem2 shows this address was set* LBBO r1, r0, 0, 4 *// readback matches* *// try to set config address, P8.40*mov r1, 0x25 mov r0, 0x44E108B8 *// devmem 2 says 0x44E108B8 = 0x5 (what i have it set to in dts)*SBBO r1, r0, 0, 4 *// devmem 2 says 0x44E108B8 is still 0x5!* LBBO r1, r0, 0, 4 *// readback doesn't match! r1 is now 0x5!* You had me excited, even though I'd tested this before, and have read in multiple places that it's not possible. :( --Brandon On Saturday, June 21, 2014 1:24:32 AM UTC-7, Brandon I wrote: You have 100% full control over anything the PRU can access. This pru code seems to disproves this. The PRU cannot modify the configuration registers. // enable ocp master. LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 // turn on gpio mov r1, 0x4000 mov r0, 0x44E07194 SBBO b, a, 0, 4 // readback LBBO b, a, 0, 4 // gpio off mov b, 0x4000 mov a, 0x44E07190 SBBO b, a, 0, 4 // readback LBBO b, a, 0, 4 On Monday, May 19, 2014 2:36:51 PM UTC-7, Charles Steinkuehler wrote: On 5/19/2014 4:06 PM, Brandon I wrote: The pin mux registers require privileged memory access, which is why the kernel space is usually required. The pru can write these!? Of course. The PRU is directly wired into the on-chip bus, and bypasses all ARM side sanity checks like memory page access restrictions. You have 100% full control over anything the PRU can access, which is just about every significant chunk of hardware on the die except for: * SGX-530 GPU * AES SHA crypto accelerator * USB * MMC Details are in the Interconnects section of the TRM (section 10), and remember: With great power comes great responsibility! -- Charles Steinkuehler cha...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: changing the triggers of gpio pins
If you want to use the triggers provided by the led interface, use the led interface. The pin will go high or low voltage with the led interface or gpio interface. GPIO is for general purpose io, so it's not going to have fancy patterns or anything, just on, off, in, out. On Tuesday, June 17, 2014 1:32:45 PM UTC-7, ÖMER KARATAŞ wrote: Hi everyone, I am experiencing beaglebone black and using it on Debian. I figured out that there are directories for gpio pins and leds. When i am in these directory by changing value and direction field i can use it as what i want. But i want to be use gpio pins as same as led pins. Means that, there is no any trigger for gpio pins but i wannt to add like heartbeat trigger to any pins,non-leds. Is there anyway to get it? Or i also figured out device tree overlay structure during my web searching like here https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays, there are some sample of .dts files but i can not find that how can be done adding trigger to any pins in means of syntax. How can i use any pins that triggered by heartbeat,cpu0 etc? Thanks a lot, ömer -- 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: Raw device on I2C bus
The first result https://github.com/kelly/node-i2c for i2c with bonescript refers to node-i2c. That link has some examples. There are many good tutorials on i2c. Your transactions will contain a device address and some number of bytes to read or write. What those bytes are is specific to each device, so you'll have to read your devices datasheet/documentation. What's the device? On Tuesday, June 17, 2014 11:35:06 AM UTC-7, Chriskner wrote: Hi Helmut, I'm afraid that I can't help with BoneScript. Perhaps a good solution does exist (and other will chime in). However, another option would be to use Python. I am doing this now, and talking to my I2C devices is working fine. For Python, one needs to install 'smbus': apt-get install python-smbus Regards, Chris On Tuesday, June 17, 2014 9:16:47 AM UTC-4, Helmut Friederici wrote: Hi folks, I have a hardware circuit (internally named SAL) based on a MSP430 microcontroller which should be connected via I2C to the BBB. After physically connecting the SAL via I2C to the BBB it responds to i2cdetect correctly and I am able to start some actions via i2cget because my SAL software interprets register numbers as internal commands - not nice but it works (partially). But what I really want is to start actions by executing scripts based on BoneScript. As far as I understand there is a suitable driver needed for this device which obviously doesn't exist. Am I right? Or could the dummy driver be used in any way and how? In Bonescript I can create a new dummy device at a given address and I can read and write files but are there any files connected to the dummy driver which I can read/write to communicate with my device? Sorry for those basic questions but I have never done anything with I2C. Any help/hint is appreciated Helmut -- 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] SD Card containing OS and apps dead after three months use
I assumed that everything is the same (flash technology, memory block size, memory block life, etc) between the 4Gb and 16Gb card, except the number of memory blocks. The more free memory blocks there are, the more blocks the wear leveler can touch before cycling through all of them. I assumed you had 2Gb of free space on your old card, so, scaling the time by the extra memory blocks available: 3months * 14Gb/2Gb = 21 months. Flash is crazy dense and cheap to make, but the eventual failure is the price you pay for, literally, shooting electrons through glass. :) On Fri, Jun 13, 2014 at 8:37 AM, Fred Basset fredbasset1...@gmail.com wrote: Brandon, I'm curious as to how you calculated a lifetime of 2 yrs for the 16Gb card with 2Gb free? On Thu, Jun 12, 2014 at 11:55 AM, Brandon I brandon.ir...@gmail.com wrote: With a 16Gb card, you'll most likely get about 2 years use before the card fails, assuming you had 2gb free on your failing cards card, the 16Gb card has the same number of writes until failure for the memory blocks, and the same disk activity. This assumes that you're have a perfect power supply that never shuts off during a write (which will damage the memory cells) or unflushed operation (which can corrupt the filesystem). If you're writing to flash media, it will eventually fail. :-\ Ideally, you would have your os disk read only (read only partition doesn't necessarily work due to sd card wear leveling controller not being aware of partitions), and log files logged elsewhere where your software could gracefully handle the eventual failure of the log file flash disk. Have this log file disk easily accessible for customers to change. You could not flush your log file writes until some sort of failure or buffer size, so that you're not writing whole erase blocks for a sentence worth of log message. And, of course, turn off all the access time capabilities with your mount options (noatime, nodiratime). The only solution is to reduce the number of writes each memory block is seeing in a day, and be aware that eventual failure can't be avoided if writing anything. On Thursday, June 12, 2014 7:24:14 AM UTC-7, RobertCNelson wrote: On Thu, Jun 12, 2014 at 9:14 AM, Frank Talamy tala...@gmail.com wrote: Hi everyone, I've been using the BeagleBone Black for a while now. I got my apps running just fine for like 2-3 months straight, not a single problem. OS : Debian Wheezy installed on Samsung 4GB µSD card. Cross compilation platform : ELDK (armv7-hf) I've tested my apps on different brands of SD Cards (Kingston, samsung, sandisk ...) and have killed several Kingston cards in a matter of days. By killing, I mean the BeagleBone wasn't booting on them anymore and they were no longer mounted when plugged via a USB-Card-reader. I had this kind of dmesg output (the [...] here means a lot of the same 7 lines in a loop): [626903.528266] sd 11:0:0:0: [sdd] Device not ready [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.528287] end_request: I/O error, dev sdd, sector 0 [626903.528290] Buffer I/O error on device sdd, logical block 0 [626903.530266] sd 11:0:0:0: [sdd] Device not ready [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.530287] end_request: I/O error, dev sdd, sector 0 [626903.530290] Buffer I/O error on device sdd, logical block 0 [626903.532391] sd 11:0:0:0: [sdd] Device not ready [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 [626903.532412] end_request: I/O error, dev sdd, sector 8 [...] [626903.812724] sd 11:0:0:0: [sdd] Device not ready [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.812740] end_request: I/O error, dev sdd, sector 0 [626903.814725] sd 11:0:0:0: [sdd] Device not ready [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current
[beagleboard] Re: Two BBBs on same host's USB
I'm not sure you're ending up with a sane network configuration using the same subnet mask for each, but did you change the udhcpd config file to give the host a different ip for each usb connection? The host gets its ip from the beaglebone's dhcp server. I say not sane, because the beaglebone's wont be able to communicate with each other because there's no route between them. For a more proper (?) configuration, you could use use the 192.168.7.2, subnet 255.255.255.252, host ip range of 192.168.7.1 (start and stop in the udhcpd config file). For the other (looking at this subnet calculator http://www.subnet-calculator.com/), 192.168.7.6, subnet 255.255.255.252, host ip 192.168.7.5 (start and stop in its udhcpd config file). I ended up making a python script to set the usb ip based on the hash of the board id stored in eeprom so I wouldn't have to worry (too much, only 14 bits) about any two beaglebone's clashing --Brandon On Tuesday, June 10, 2014 11:58:10 AM UTC-7, ec1...@gmail.com wrote: Hi, I have two BBBs, and each can connect to a host via USB0 with no problems. One as IP 192.168.7.2 and subnet mask 255.255.255.0 (changed from ...252) and another on 192.168.7.7. For some reason they both cannot connect at the same time as PuTTY gives me a conn timeout. Is there a way to have more than one BBB on a single USB host network? Thanks! E C -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] SD Card containing OS and apps dead after three months use
With a 16Gb card, you'll most likely get about 2 years use before the card fails, assuming you had 2gb free on your failing cards card, the 16Gb card has the same number of writes until failure for the memory blocks, and the same disk activity. This assumes that you're have a perfect power supply that never shuts off during a write (which will damage the memory cells) or unflushed operation (which can corrupt the filesystem). If you're writing to flash media, it will eventually fail. :-\ Ideally, you would have your os disk read only (read only partition doesn't necessarily work due to sd card wear leveling controller not being aware of partitions), and log files logged elsewhere where your software could gracefully handle the eventual failure of the log file flash disk. Have this log file disk easily accessible for customers to change. You could not flush your log file writes until some sort of failure or buffer size, so that you're not writing whole erase blocks for a sentence worth of log message. And, of course, turn off all the access time capabilities with your mount options (noatime, nodiratime). The only solution is to reduce the number of writes each memory block is seeing in a day, and be aware that eventual failure can't be avoided if writing anything. On Thursday, June 12, 2014 7:24:14 AM UTC-7, RobertCNelson wrote: On Thu, Jun 12, 2014 at 9:14 AM, Frank Talamy tala...@gmail.com javascript: wrote: Hi everyone, I've been using the BeagleBone Black for a while now. I got my apps running just fine for like 2-3 months straight, not a single problem. OS : Debian Wheezy installed on Samsung 4GB µSD card. Cross compilation platform : ELDK (armv7-hf) I've tested my apps on different brands of SD Cards (Kingston, samsung, sandisk ...) and have killed several Kingston cards in a matter of days. By killing, I mean the BeagleBone wasn't booting on them anymore and they were no longer mounted when plugged via a USB-Card-reader. I had this kind of dmesg output (the [...] here means a lot of the same 7 lines in a loop): [626903.528266] sd 11:0:0:0: [sdd] Device not ready [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.528287] end_request: I/O error, dev sdd, sector 0 [626903.528290] Buffer I/O error on device sdd, logical block 0 [626903.530266] sd 11:0:0:0: [sdd] Device not ready [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.530287] end_request: I/O error, dev sdd, sector 0 [626903.530290] Buffer I/O error on device sdd, logical block 0 [626903.532391] sd 11:0:0:0: [sdd] Device not ready [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 [626903.532412] end_request: I/O error, dev sdd, sector 8 [...] [626903.812724] sd 11:0:0:0: [sdd] Device not ready [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.812740] end_request: I/O error, dev sdd, sector 0 [626903.814725] sd 11:0:0:0: [sdd] Device not ready [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.814735] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.814747] end_request: I/O error, dev sdd, sector 0 [626903.820536] sdd: detected capacity change from 3947888640 to 0 That's why I chose to use Samsung sd cards instead. Everything was fine for 2-3 whole months, but now I had one of my systems getting the exact same symptoms as when using the Kingston cards. Did anyone experience this kind of problem using his beagle bone so far ? Does anyone have an idea of something that could damage the SD card so much which is or isn't directly related to the use of a beagle bone black (Heat, compulsive logging, ...)
Re: [beagleboard] Using GPIO's as SPI
but you can't run the clock much faster than 1 KHz using a user-space program under Linux. Not true at all! You can get over 3MHz just fine with mmap to the gpio registers. If you try to open and close a file each gpio toggle, like the insanely inefficient sysfs interface, then yeah...you'll be severely limited, but still much faster than 1kHz. Did you google? http://e2e.ti.com/support/arm/sitara_arm/f/791/t/296484.aspx On Thursday, June 5, 2014 8:31:24 AM UTC-7, William Hermans wrote: Sounds like fun. Good luck :) On Wed, Jun 4, 2014 at 2:17 PM, swapn...@gmail.com javascript: wrote: Hey William... I do know that the Chip Select line can be used to toggle between different SPI units... But I need data to be collected simultaneously from multiple sensors... As of now I have 32 sensors - I have clubbed them into groups of 4 and so I have 8 sets of SPI units that I want to communicate with simultaneously... On Wednesday, June 4, 2014 11:46:21 AM UTC-4, William Hermans wrote: It sounds as though you need to read more concerning what SPI actually *is*. *Devices communicate in master/slave mode where the master device initiates the data frame. Multiple slave devices are allowed with individual slave select lines. Sometimes SPI is called a four-wire serial bus, contrasting with three-, two-, and one-wire serial buses. SPI is often referred to as SSI (Synchronous Serial Interface).* http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus What does this mean ? Multiple devices can share the same data bus, and only CS( chip select ) needs be different for each device. CS only needs to go high, or low, which hey remarkably is exactly what GPIO pins do ! :) On Wed, Jun 4, 2014 at 7:37 AM, swapn...@gmail.com wrote: I am trying to run multiple SPI modules (more than the two available on the BBB) to try and read data from a bunch of accelerometers (LSM303D). I was therefore wondering if it would be possible to implement the SPI module using code (preferably C/C++) on the abundant GPIO pins. I have been scanning through a lot of documentation but I cant seem to find anything that fits the bill. Please help --- getting desperate... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Beaglebone Black libraries for GPIO access in C/C++?
Two other features of going low level with mmap: Open drain output: By controlling the output enable registers, you can do open drain by setting the output to drive 0, then enable output to pull low, disable output to for high (with external pullup or internal through pin muxing). Simultaneous toggling: You can set the pin states of a whole gpio bank at once. This is nice if you're bit banging. 2.8MHz seems slow. I was at 4MHz through an mmap in *Python*. Make sure you're using the set registers rather than doing a read-modify-write and only opening the mmap once...and I suppose your clock scaling will matter too, so maybe it's the same. --Brandon On Wednesday, June 4, 2014 2:26:32 PM UTC-7, john3909 wrote: From: Tony DiCola to...@tonydicola.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Wednesday, June 4, 2014 at 8:29 AM To: beagl...@googlegroups.com javascript: Subject: Re: [beagleboard] Beaglebone Black libraries for GPIO access in C/C++? Thanks for the replies everyone--looks like some nice libraries to check out. Regarding memory mapped GPIO, check out this nice blog post for more info: http://vabi-robotics.blogspot.com/2013/10/register-access-to-gpios-of-beaglebone.html You can effectively map the GPIO registers to a process' memory space and directly access them so there's no overhead of making the system calls to read, write, etc. the sysfs-based GPIO. I actually just tried out a couple quick tests and saw toggling a pin high and low in a tight loop with sysfs is pretty slow, only a few hunded khz. However using memory mapped GPIO registers it's much, much faster. I'm seeing around 2.8 mhz toggling a pin with this approach. Now neither approach is technically going to ever give you a real time guarantee of course, but it's nice to have the ability to read and write GPIO fairly quickly in some cases with memory mapped GPIO. The downside is you cannot support GPIO interrupts. Regards, John On Wed, Jun 4, 2014 at 5:00 AM, Micka micka...@gmail.com javascript: wrote: William Hermans, how did you controlled the GPIO ? The only way that I know is with : /sys/class/gpio/gpio%d/value but you talk about mmap ? How did you use it with this /sys/class/gpio/gpio%d/value ? Thx you, Micka, On Tue, Jun 3, 2014 at 11:57 PM, William Hermans yyr...@gmail.com javascript: wrote: sysfs, and mmap. I've seen mention of both on the web ( including for the BB white ). *wiringPi* Whats this ? The Arduino IDE for the rPI ? Nothing like this exists for the BBB that I am aware of. On Tue, Jun 3, 2014 at 2:45 PM, Jacek Radzikowski jacek.ra...@gmail.com javascript: wrote: shameless plug https://github.com/piranha32/IOoo /shameless plug j. On Tue, Jun 3, 2014 at 5:42 PM, Tony DiCola to...@tonydicola.com javascript: wrote: Sorry if this is a common question, but I've searched around the web and the forum here and am curious are there any somewhat mature or popular libraries for simple digital GPIO access on the Beaglebone Black in C/C++? I'm curious if there's anything like wiringPi or similar for the BBB yet. If not, are folks just rolling their own thing with access to sysfs or mmap? -- 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. -- Given a choice between two theories, take the one which is funnier -- 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. -- 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. -- 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/Mef65w6PZ7s/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/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this
Re: [beagleboard] Re: PRU FAQ 2013-05-15
And a quick google search pru ethercat am335x provides a nice overview: http://www.ti.com/lit/wp/spry187c/spry187c.pdf On Tue, Jun 3, 2014 at 6:05 AM, Gerald Coley ger...@beagleboard.org wrote: That is all covered in the datasheet for the processor. http://www.ti.com/product/am3358 Gerald On Tue, Jun 3, 2014 at 7:05 AM, euerka crazyintermi...@gmail.com wrote: Dear Gerald, Thanks for your reply. Sorry that i am not very clear about Signals are missing on the expansion headers? you means the signals suppose to link to Ethernet PHY, now link to expansion headers(P8,P9)? if so it means it possible rewire the signals? Because i saw this https://www.youtube.com/watch?v=M1LxQBjttWg , please take a look; it seems Sascha rewire it. Even though it is impossible to implement this, may i know what signals i need if i want to implement etherCat Master by PRU on BBB, which signals are missing now? Any clues, documentations, links will be appreciated. Thank very very much! On Monday, 2 June 2014 20:15:28 UTC+8, Gerald wrote: No. It is not possible.Signals are missing on the expansion headers to implement ether-cat. It cannot be done. Gerald On Sun, Jun 1, 2014 at 11:21 PM, euerka crazyin...@gmail.com wrote: Dear all, As i understand it is impossible to implement PRU, ethercat slave on Beagleboard, since i refer to ( https://groups.google.com/ forum/#!searchin/beagleboard/ethercat|sort:relevance/ beagleboard/EiiZ4rwo9q0/ZvqUXIKAS28J ) and ( https://groups.google.com/ forum/#!searchin/beagleboard/ethercat|sort:relevance/ beagleboard/1_yqmvkguZY/y-mrwkY7IJsJ). *I am still wondering that is it possible to use PRU as ethercat or powerlink master on Beagleboard?* Because in my opinion, i can purchase commercial motor driver such as yaskawa or panasonic as slave? Any ideas? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to 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.
Re: [beagleboard] Can the BBB get damaged due to a hard power down?
For the damage question, yes, with all flash media, if you're not using a read only mount: http://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf Btw, you're crazy if you're not using a read only mount (or guaranteeing no writes) for the rootfs of an appliance. ;) On Tuesday, May 27, 2014 7:46:07 AM UTC-7, stino wrote: Hi Gerald, Look I'm sorry if you took offence by my comment. It’s an awesome board, don’t let anybody convince you otherwise It's just that I've not seen it being mentioned anywhere that a correct power down procedure is required. If it was a deliberate design choice not to provide some kind of fail-safe, I personally would have definitely made this clear to every buyer. I work hands-on with computer equipment of various makes and models on a daily basis and I honestly can’t remember the last time a box got bricked due to a power outage. I myself, and as I suspect many others, am thinking about turning the BBB into an embedded appliance which makes the power button inaccessible. Can you suggest how we can extend the powerbutton of from the board? Op dinsdag 27 mei 2014 15:27:21 UTC+2 schreef Gerald: This is why there is a power button. I suggest that you go to your PC and yank the power cord. Whether it is running Linux or Windows, I suspect it won't like it. If you can't use the power button, then yes you can design a cape that will let it gracefully shutdown properly. When I designed the board I felt that a button was less expensive that all the other stuff you would need to put on the cape. Not to mention the small form factor of the board made it tough to fit all that onto the board. And yes, in a small number of instances, we have seen that yanking the power may cause damage to the processor because the PMIC does not have enough time to power down the processor in the correct voltage sequence. So, use the power button. Gerald On Mon, May 26, 2014 at 10:37 AM, William Hermans yyr...@gmail.comwrote: What happens, or *can* happens when you just yank the power on a PC running Linux ? 1) You can make teh file system read only. 2) You can design or create a power cape that shutdown gracefully when power goes missing. ...) ??? On Mon, May 26, 2014 at 6:32 AM, stino stijnd...@gmail.com wrote: I read over at another forum that the BBB could get damaged if it recieved an unexpected hard power down.., is this true, what can we do about this? Seems like a serious design flaw to me. One can't expect a power source to be 100% stable and especially with a development board which is likely to used for embedded appliances this is a reall issue.. 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. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: PRU FAQ 2013-05-15
You can access all regular gpio, but those will be slower than the one tick pru gpio access. Check out the PRU documentation at https://github.com/beagleboard/am335x_pru_package , it explains how to use R30 and R31, section 5.2.2. Here's an explanation on accessing main memory from the pru: http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru To control the regular gpio blocks, you would access them through their registers. You can find the gpio registers and their addresses in the processor manual at http://www.ti.com/lit/pdf/SPRUH73 , section 2.1 for addresses of gpio blocks, and section 25 for offsets of the different gpio registers for each block. On Tue, May 27, 2014 at 6:18 AM, karlkarpfe...@gmail.com wrote: Am Mittwoch, 2. Oktober 2013 22:03:29 UTC+2 schrieb Charles Steinkuehler: Each PRU has it's own r30, which drives the direct outputs (assuming you have the pinmux setup properly). You can only drive a limited number of the BeagleBone header pins using PRU direct I/O, and a lot of the pins are shared with the LCD/HDMI interface. I afraid this is the part I didn't understand with PRU. Assumed Pin-Mux is correct for usage of plain GPIOs - is PRU able to access all of them? If not: which ones are accessible? And I already stumbled upon this r30 thingy...how can I set/read GPIOs with it? Thanks for helping me with these stupid questions! -- 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.
Re: [beagleboard] 4G eMMC Durability?
MLC NAND enables around 10k write cycles SLC NAND enables more than 100k write cycles. And, of course, these are the number of cycles for whole erase blockshttp://en.wikipedia.org/wiki/Flash_memory#Block_erasure. If you write one byte and flush the operation to your flash disk, you're actually writing the erase block size (say 4MB's), resulting in some write amplification factor. So, many continuous small writes, that are flushed to disk, can very quickly touch all of the remaining erase blocks on your disk. For log file messages a few hundred bytes each, each flushed to disk as most log messages are, with a best case memory controller that touches the least used block next, and a 4MB erase block size, you'll have written 4GB to your card after 1024 messages. So you get 10 million log file writes if you have a card with 4GB of free space. If your OS partition is using 2GB then you get around 5 million. If you're writing to flash of any kind, you cannot think of it as will my product fail. You *must* think of it as when will my product fail, because that's the nature of the medium. Sometimes it's many years. In our case, it was many weeks. Then we reduced the log messages making it months. Now, we use a read only mount, so it's based on the read disturbhttp://en.wikipedia.org/wiki/Flash_memory#Read_disturb. But, even though it's a read only, it will still eventually fail. But, that'll be long past our support life. The undeniable rule of flash: Your flash storage will eventually fail, because you're destructively blasting electrons through glasshttp://en.wikipedia.org/wiki/Hot_carrier_injection#Reliability_impact (oxide). On Thursday, May 22, 2014 12:39:44 AM UTC-7, lisarden wrote: eMMC and SD cards are almost the same as Gerald said. eMMC is based on MLC NAND MLC NAND enables around 10k write cycles SLC NAND enables more than 100k write cycles. That is why we use only SLC in our industrial products. I'm sure when you supply products with 5 year warranty you don't want to discuss eMMC/MLC reliability. Less risks - less profit lost. 2014-05-22 11:13 GMT+04:00 Willem Buitendyk wil...@pcfish.cajavascript: : I wasn't seeing data corruption due to Linux but from the cards going completely kaput. No amount of effort seemed to restore them. I was under the impression the eMMC used MLC rather than TLC or MBC? That would imply a different controller and ideally a much longer lifespan. On Wednesday, May 21, 2014 12:27:28 PM UTC-7, Gerald wrote: Reliability at the cell level is the exactly the same. he controller is exactly the same. However, having more unused space enhances the wear leveling where cells get used less often. It does not however prevent issues with data corruption for any Linux issues. Gerald On Wed, May 21, 2014 at 2:21 PM, Willem Buitendyk wil...@pcfish.cawrote: I have about 150 beaglebone's running wild over a large geographical area, basically all over British Columbia. When I first deployed them last year they all started failing within about a month. That amounted to a lot of needless driving, hair pulling, forehead banging and just general over anxiety - its a wonder I'm still alive. I eventually ended up using two uSD cards, one with a read only mounted filesystem and the other used for writing data (ext4). My beaglebone's are paired with a msp430 so I have managed to ensure they also receive a nice, clean power down. So far its been about a year and I'd say well over 95% are still working fine. However, I recently talked with a tech support from an industrial SD card manufacturer and he informed me that SD cards that are only ever read to can also fail eventually. He suggested that you write a little bit once in a while to activate the wear levelling mechanism. As things seem to be working (for now) I haven't drummed up the courage to try writing again. Now we have the beaglebone black with 4G eMMC and I'm wondering just how much more reliable eMMC is compared to the stock Kingston 4GB cards in read only mode that came with the Beaglebone. I know eMMC is supposed to be much improved having an integrated controller but wonder if in a read-only scenario it makes any difference? Furthermore, I wonder if others on here can offer any experiences or comparisons of eMMC to say SLC memory? 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. 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
Re: [beagleboard] User LED forward to GPIO
I use this: https://github.com/nomel/beaglebone/tree/master/led-header Makes setting up leds super easy. On Thursday, May 8, 2014 9:35:31 AM UTC-7, Charles Steinkuehler wrote: The way these systems are configured, I don't know if you can do what you want without generating a custom device tree. The leds class has a trigger function and can be tied to various GPIO pins, but I believe that conflicts with exporting that same GPIO pin. If anyone knows of a way to do this without requiring customizing a device tree to move GPIO pins from /sys/class/gpio to /sys/class/leds/ entries, or if there's a way to have both for the same pin, I'd love to hear it! On 5/8/2014 10:49 AM, Hannes Hörting wrote: Hello John! Thank you! I`m using Debian and also the universal device tree from Charles: https://github.com/cdsteinkuehler/beaglebone-universal-io Not sure if its there also available? I doesnt find an information about heartbeat and cpu for user led on the GPIO. Thank you! Am Mittwoch, 7. Mai 2014 20:58:10 UTC+2 schrieb john3909: On 5/7/14, 11:32 AM, Hannes Hörting fai...@gmail.com javascript: wrote: Hello! Can I forward the User Led to the GPIO? I want to build my own Expansion Board and need this LED. OR is this function already connectet to some GPIO? Thank you! You can change the GPIO for the User LED by modifying the BBB device tree. Look at arch/arm/boot/dts/am335x-bone-common.dtsi Regards, John -- 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. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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] Debian images
In all seriousness, is there a donation link you could post so we could send you some thanks? On Sunday, May 4, 2014 10:56:40 AM UTC-7, RobertCNelson wrote: On May 4, 2014 4:43 AM, Timbo tim...@gmail.com javascript: wrote: Thanks for the info, Robert, and thanks for making these images, installation scripts, and so on. BTW is this a solo effort, or are other people involved in Beagle Debian? The major extras in the official image seem to include lxde, wicd, compilation utilities, audio utilities, and probably a lot of other stuff I didn't recognise. Apart from the extra packages, are there any particular differences in kernel, configuration, etc? No! That would mean more work, and I'm pretty lazy! -- 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. -- 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] power up using +5 volt jack
The beaglebone had a power up issue. Rev A6A fixed it: From the wikihttp://www.elinux.org/Beagleboard:BeagleBoneBlack#Revision_A6A : Changed C24 to a 2.2uF capacitor. This extends the reset signal to solve an issue where some boards would not boot on power up. I have around 40 beaglebones running and this was a pretty serious problem for us. Our users guides have a somewhat embarrassing If the board doesn't boot, unplug the power and wait 10 seconds. I have around 20 Rev. B boards, and I haven't seen one fail to power up. You could always rework the board yourself! :D On Friday, May 2, 2014 5:14:03 AM UTC-7, Gerald wrote: Sounds like you may have an issue with your board. You can always send it in on an RMA and we can look at it. Gerald On Thu, May 1, 2014 at 10:51 PM, DLF dumb.lo...@gmail.com javascript:wrote: Hi and thanks for your reply Well this is not true for me (my BBB won't boot directly with DC (Rev A5C))... but it is not a deal breaker for me. As this is Richard's thread I'll back out now I don't want to be a budinski. BTW, Gerald Robert, a friendly thank-you for all the work with BBB. I've learned a few things along the way and I appreciate your efforts. merci, On Tuesday, 29 April 2014 19:39:03 UTC+2, Gerald wrote: Do not touch the power button unless you plan to turn it off. The SRM is correct. To power on all you have to do is plug in the power, either USB or DC. Gerald On Tue, Apr 29, 2014 at 12:35 PM, DLF dumb.lo...@gmail.com wrote: Hi, now I am confused because I thought it was normal procedure to hold the power button after inserting the 5V jack. (as noted by Richard-tx) I always have to hold the power button after inserting the jack. When I insert the jack, I see a brief blue light from the pwr LED next to the 5V connector and then nothing. If I hold the power button it boots. - every time. This thread lead me to believe the power button was the right way to do it !https://groups.google.com/forum/#!topic/beagleboard/FGeL6jzOcB0 however the SRM indicates otherwise :( 7. Booting the Board As soon as the power is applied to the board, it will start the booting up process. When the board starts to boot the LEDs will come on in sequence as shown in Figure 15 below. It will take a few seconds for the status LEDs to come on, so be patient. The LEDs will be flashing in an erratic manner as it boots the Linux kernel. It is not the end of the world for me, but just interested all the same. cheers, On Monday, 28 April 2014 14:17:43 UTC+2, Gerald wrote: It is supposed to power up automatically when you plug in the DC cable. Gerald On Sun, Apr 27, 2014 at 10:20 AM, Richard-tx rich.a...@gmail.comwrote: The way my BBB works is like this: To power up the BBB from OFF when powered from the 5 v jack, I have to press the power button. To power up using the mini-usb connector, all I have to do is turn on the USB power. My question is this. Is there a way to have the BBB automatically power up when power is applied to the +5 jack? . -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: What went wrong
This is incorrect. There's nothing wrong with applying power through USB and VDD_5V (DC plug) at the same time, from the reference manual: The selection of either the 5VDC or the USB as the power source is handled internally to the TPS65217C and automatically switches to 5VDC power if both are connected. On Wednesday, April 9, 2014 1:47:10 PM UTC-7, Gunjan Gupta wrote: Hi, You have used both the 5V power source and the mini usb cable. I guess thats why your board got fried up. Use only one of them for the next time. Regards viraniac On Tuesday, April 8, 2014 2:36:29 AM UTC+5:30, A M Kent wrote: I've recently purchased the BBB and over the weekend I went through setting it up. I have to say I'm thoroughly impressed with the setup and the size. I followed the supplied instructions of connecting the device to my computer using the USB cable connecting it from the micro USB port to a port on my laptop, installing the necessary files to communicate with the device. My issue occurred when I connected the BB in the following manner. 1. From micro HDMI port to HDMI port on monitor. 2. Connected the 5V power source into the BB 3. Connected a USB cable from the USB jack on the BB to my 4 port powered USB hub. 4. Connected the micro USB cable into the 4 port hub. 5. Inserted wireless keybrd/mouse dongle into the 4 port hub. When I applied power to the BB within 1 minute of doing so I hear a faint high pitch tone and shortly thereafter I see a spark coming from the board. Based on the setup described what could have gone 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: python gui?
Could always use python as a web back end and render the gui in the browser. ;) On Wednesday, April 9, 2014 3:28:56 AM UTC-7, Eric Palmer wrote: In my day job I erite backend code. Not gui stuff. I'm building a large robot and will use a BBB and display for data display and more. I would like to use python. What gui tools work with python on the BBB? I could also do this with node.js o some other web server. But python might be fun. -- Eric Palmer -- 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: I2C2: Bad address, without checking
Do you have a pullup on the i2c line? On Monday, March 31, 2014 1:59:46 AM UTC-7, Rafael Fiebig-Bindner wrote: Hi community, I am currently trying to access a temperature sensor via I2C. The problem is whenever I want to send data I get the error message: Bad address, but the BBB doesn't even check for the address on the I2C bus. The address is 0x48 so it is free for use. I want to use the Pins P9,17 and P9,18. The BBB is running Angstrom. I am using C++ and i2c-dev.h to access the built in i2c-1 device file. I hope someone has some ideas how to solve this. Best regards Rafael Fiebig-Bindner -- 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: eMMC data corruption due to power removal?
That's because your phone uses a sane filesystems that takes into account this use case and isn't writing constantly (write one byte, the disk writes a whole erase block). This doesn't protect you from eventual disk corruption. The wear leveling bad-block type tables will eventually corrupt/run out of memory lng before your disk space is eaten by bad blocks. http://arstechnica.com/information-technology/2010/12/ext4-filesystem-hits-android-no-need-to-fear-data-loss/ Most Android devices currently use YAFFS, a lightweight filesystem that is optimized for flash storage and is commonly used in mobile and embedded devices. My production Beaglebone image does not support this. Developers who are accessing the filesystem directly will have to be mindful about Ext4's buffering behavior and make sure that the data is actually reaching persistent storage in a timely manner so that it won't be lost in the event of a system failure. It is now an issue with Android! T'so says that there isn't much need for concern. Google and the handset makers will catch platform-level filesystem reliability issues, ensuring that the high-level storage APIs are safe. Is the API you use for disk writes safe? Nope. -Brandon On Thu, Mar 27, 2014 at 10:26 AM, rh_ richard_hubb...@lavabit.com wrote: On Thu, 27 Mar 2014 07:41:11 -0500 Charles Steinkuehler char...@steinkuehler.net wrote: On 3/26/2014 10:22 PM, Yiling Cao wrote: Thanks Brandon for your experience. I do agree with that better to put whole disk read only. But how do iPhone and Android survive? Esp for those Android phones? They are very prone to sudden power removal as well. What? These devices are battery powered, and other than opening the case and physically removing the battery they are guaranteed enough power to do a proper and orderly shutdown. I pull the battery on my android frequently doing devel. Never had any problems. I pull the plug on my BBB all the time too, at least once/day. No problems. For people having issues I would suspect a problem elsewhere. -- 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/dV0ctlQykYI/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.
[beagleboard] Re: First one, then two, then three....
The only thing I wish for is the ability to change I2C bus speeds on the fly. You can do anything with a kernel module and some memory pokes. ;) On Thursday, March 27, 2014 2:47:10 AM UTC-7, Richard-tx wrote: I bought a BBB about 3 weeks ago. Was impressed enough that I bought two more. I have a few Rpis is use around the house as well so I have a little experience with SBCs Anyway. all three BBB has been flawless. No problems at all. I did discover one thing. Of all the Linux distros out there, I like Ubuntu the best. I found that Ubuntu does not suffer as badly from creeping featurism or from a lack of essential packages. I tried Angstrom first. It got flushed. Then I tried Arch and Debian. Didn't like Arch at all. Debian was tolerable. Lastly I tried Ubuntu. Ubuntu seems to be the easiest to get configured and running. I was porting code in under an hour. I don't use a GUI so Ubuntu might not be for everyone. The really nice part about the BBB is the fact that it boots without a SD card. That leaves the SD card slot available for extra file storage. SInce I do some software development as well as create various appliance-like things, the added hot-plugable storage is wonderful. The only thing I wish for is the ability to change I2C bus speeds on the fly. All in all, I am very happy with the BBB. Well done! Richard . -- 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: eMMC data corruption due to power removal?
Rh, my earlier reply was to you, and that link shows that it is now a problem with androids use of ext4. On Thu, Mar 27, 2014 at 4:55 PM, rh_ richard_hubb...@lavabit.com wrote: On Thu, 27 Mar 2014 13:41:24 -0500 Charles Steinkuehler char...@steinkuehler.net wrote: On 3/27/2014 12:26 PM, rh_ wrote: On Thu, 27 Mar 2014 07:41:11 -0500 Charles Steinkuehler char...@steinkuehler.net wrote: On 3/26/2014 10:22 PM, Yiling Cao wrote: Thanks Brandon for your experience. I do agree with that better to put whole disk read only. But how do iPhone and Android survive? Esp for those Android phones? They are very prone to sudden power removal as well. What? These devices are battery powered, and other than opening the case and physically removing the battery they are guaranteed enough power to do a proper and orderly shutdown. I pull the battery on my android frequently doing devel. Never had any problems. I pull the plug on my BBB all the time too, at least once/day. No problems. Yes, but are you writing to the flash when you pull the power? Don't know. But it's possible. How would I know? If it doesn't boot? For android there's JAFFS (or is it YAFFS) so it's more robust than ext4 I guess. There is a huge difference between it works for me and *RELIABLY* avoiding data corruption when power is unexpectedly removed with significant write activity in-progress. Ok, but I haven't encountered a problem yet, and I'm never that lucky. With the millions and millions (billions?) of handsets I would think data corruption would be a much more visible problem. I haven't seen it happen yet over many phones and many years. -- 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/dV0ctlQykYI/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] eMMC data corruption due to power removal?
Here's a good read: http://www.embeddedarm.com/about/resource.php?item=459 I had a lng discussion about this with a colleague of mine after we started seeing boards die. Basically you're eventually doomed unless you mount the whole disk as read only since the wear leveling algorithms in the flash have no knowledge of what a partition is and will eventually end up with suppesed-to-be-read-only data mixed in with the writable partition erase blocks. If you're writing to flash, it will eventually fail by unfortunate design. It tooks his previous company 6 months of fighting to come to terms with this in their last product. They had to write data, so eventually used usb flash that the customer could easily replace when things eventually died. They tried every flash card they could get their hands on, read only partitions, etc and eventually had to give up. Use the SD card you say! Any micro SD card you can put in the slot is absolutely not meant for continuous writing. The SD card spec has a very specific use case in mind (video and images), and logging or using it as a sparse write file system goes completely against the intended SD card design specs. Industrial grade write-tolerant flash will cost you hundreds of dollars more than something on Amazon. With our current product, I told my boss that I was worried about corruption and that we would eventually go to read only once we debugged the boards. Within two weeks of only log messages, all of our boards started dyeing. The next day, all disks were mounted as read only and issues are debugged with the in-memory log files. We haven't seen any failures in 6 months now. The easy solution is trying to force the answer of why are you writing anything to persistent storage? to be there's no good reason since it eventually bricks our product. If you want something that will last forever, you will not write to standard flash media. If you can't, then maybe use a usb flash drive (MUCH better life than a micro sd card) and count the days until it corrupts or someone pulls the power at an inopportune time. You could always use a battery backup to get rid of the power off issue. :-\ This is all doom and gloom, but it's a consequence of inconsistent power, buffers, and the destruction nature of quantum tunneling. -Brandon On Wednesday, March 26, 2014 2:45:57 PM UTC-7, Sungjin Chun wrote: How about making system partition be mounted as read-only and data partition be mounted after booting and checking? In this case, only data partition has possibility of corruption. Sent from my iPad On Mar 26, 2014, at 9:53 PM, Yiling Cao yilin...@gmail.com javascript: wrote: Hi I have some my products deployed with am335x with Micron eMMC 2GB, but my products allow users to unplug power as they wish. My linux app very rarely writes to the eMMC. and my /etc/fstab specifies /var/log and /tmp to tempfs; fstab mount all partitions with noatime properties. But around 2 months of deployment, I found that around 1-2% am335x machines, have some sort of data corruption, resulting fail to boot up. Can anyone share some thoughts/ experience about how to resolve this issue? In real life product, whats the best practice? -- 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. -- 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: Kernel headers for Linux beaglebone 3.13.6-bone8
For Angstrom, you can install the kernel-dev and kernel-headers packages. This will be enough to compile kernel modules. There have been times in the past where the packages where out of sync with the actual kernel being used. Not sure what the current state is. Check the stable branch...lol, just kidding. On Saturday, March 22, 2014 4:35:25 AM UTC-7, Vlad Ungureanu wrote: Anybody has a clue where can I get the kernel headers? https://raw.github.com/gkaindl/beaglebone-ubuntu-scripts/master/bb-get-rcn-kernel-source.shdoes not work. Best, /vvu -- 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: Encouragement for the disencouraged
My only real issue that I have no idea what the Angstrom is really capable of and what really comes with it. I think the biggest hurdle for people is they have some embedded mindset with talk of processors and whatnot. Think of this as it is, a resource limited general purpose Linux computer in a small form factor. You develop for it just like you would a normal desktop computer. Don't think of it as what Angstrom is really capable of because Angstrom has nothing to do with it. Install Debian if you want and you'll be able to accomplish the same (maybe with less free RAM) using almost identical code. The biggest hurdle I had was to do things right the Linux way, as in using the abstracted to infinity drivers and sysfs interfaces to do something like access a single register for some hard ip. You can go bang registers and be done with it, but the whole point is that you don't have to care about the specific platform if you use the standard interfaces allowing you to port your code to some other future embedded (or not) system. 2 ranty cents for you. On Thursday, March 20, 2014 3:05:17 PM UTC-7, Thorsten Gonschior wrote: Hi to you all out there, new to the BBB, new to Linux, new to whatever? This is no request for a particular solution but somehow a thought to whats wrong with me, ... or some of the others? Never worked with Linux or Unix, never did anything else than windows and TI embedded stuff. I would think of me as a professional senior engineer for embedded systems, automotive and industrial control. Now, I entered the embedded Linux world and I am thrilled and frustrated at the same time. Before some days system and software engineering was somehow deterministic to me, something you plan and do. yea, welcome to waynes world. After reading some hundred hours in the internet, peeking through about 12 new books I bought like hands on the beagle bone black for hyperdummies down to realtime driver development in subatomicmicrokernels I am almost as clueless as before. almost ;) After trying to do some really complex stuff like hello world on a php web page I am beginning to understand that I have to let go some very basic principles of thinking like an engineer if I want to act in and survive this new scene. My first impression on the BBB was somehow, oh wow now I can do everything I always wanted for free. Today I am more on the way of thinking what I could do if noone or nothing unavoidably unseen screws me up, kicks me in the back and stabs me with a fork in my ass (in my sleep). After this esotheric discourse for all you out there finding yourself here I will come to the encouragement thing I promised. You cannot make it run? its not there? dont know where, why, how or when? Its there and it is quite simple and so much more complex you will ever imagine. Know what? give a damn, go get it and make it any way you can. Newbie/Noob Rule 1: there is no correct way, there ist never only one way, and what ever way you find out, if ever, its the wrong one anyway. Newbie/Noob Rule 2: dont do it on your own. its already there. dont even start thinking how you can solve a subtask. just go and get your component out of the internet. talking caipirinha serving robots doing your laundry, just call for it. it will never be a 100% solution. be happy if it works just good enough, more or less. On the other hand, if you do it on your own, how perfect would you think you would do it, after endless doing your stuff . There is just nothing you can do on your own against the 10.000 man years of productive work you buy with your cellphone ;) Newbie/Noob Rule 3: dont believe in all the creeps out there. my impression is that there are seemingly 50 people out there not talking crap. they are easy to find. Newbie/Noob Rule 4: if you are confronted with the fishermans feed fish and net crap, skip the page, its not with it. Newbie/Noob Rule 5: I dont know how, but all the people out there managed to make it somehow. even if you have no Idea what you are doing, in the end it works. you dont know why, or for how long, but it does. thanks and regards to all of you out there contributing to this vast community. With the stuff you do and how you do it, you would not have survived in any kind of industrial working environment. On the other hand this so professional industrial working environment is just loosing the edge against you. And that feels great :D In direct words to the BBB and my experiences of the first days: after two days of stumbling around to understand how to get ubuntu on my BBB I was able to set up my SD Card and power up the ubuntu. Just early enough to undertsand that Angstrom ist not half as bad as everybody tries to state. Now I am back to angstrom and I like it (today). After endless discussions from guys who tried to provide the perfect way of setting up a so much better web
Re: [beagleboard] Re: BBB PRU input test
I think I see the problem. You have the pin muxed for pru gpio in the
device tree overlay, but you're trying to read the arm gpio block. PRU gpio
is accessed directly with register r30 for output and r31 for input
(section 5.2.2.3 in the somewhat terrible pru reference
guidehttps://github.com/beagleboard/am335x_pru_package/blob/master/am335xPruReferenceGuide.pdf
).
On Tuesday, March 11, 2014 7:49:47 AM UTC-7, Manu wrote:
I read your last email with attention by still I can't understad why my
code is not working. I a few words:
The code works when properly when I comment the line WBS r31.t15 //Wait
til GPIO-15-in is high... P9_24
*PINMUX DTS:*
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-W;
version = 00A0;
exclusive-use = P9.24;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins =
0x184 0x36 /* P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | PULLUP |
MODE6 | INPUT */
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
};
fragment@2{
target = pruss;
__overlay__ {
status = okay;
};
};
};
*PIN MUX STATUS:*
# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep pin 97
pin 97 (44e10984) 0036 pinctrl-single
*UNAME +DIST:*
# uname -a
Linux don-t001 3.8.13-bone30 #1 SMP Thu Nov 14 11:19:20 UTC 2013 armv7l
armv7l armv7l GNU/Linux
# cat /etc/issue
Ubuntu 12.04.3 LTS \n \l
*ASM CODE:*
.origin 0
.entrypoint START
#define PRU0_ARM_INTERRUPT 19
#define AM33XX
#define GPIO1 0x4804c000
#define GPIO_CLEARDATAOUT 0x190
#define GPIO_SETDATAOUT 0x194
START:
//Enable OCP master port
LBCO r0, C4, 4, 4
CLR r0, r0, 4 // Clear SYSCFG[STANDBY_INIT] to enable OCP master port
SBCO r0, C4, 4, 4
MOV r1, 1000 //# cycles
INPUTTEST:
WBS r31.t15 //Wait til GPIO-15-in is high... P9_24
SUB r1, r1, 1 //Subtract from counter
QBNE INPUTTEST, r1, 0 //Loop if counter not at zero
// Send notification to Host for program completion
MOV R31.b0, PRU0_ARM_INTERRUPT+16
MOV r1, 0
HALT
*INIT PROGRAM USING PyPRUSS:*
#!/usr/bin/python
''' ddr_write.py - Finds the DDR address and size, passes that info to the
PRU0
data memory, executes a program and reads back data from the first and
last banks'''
import pypruss
import mmap
import struct
pypruss.modprobe()
ddr_addr = pypruss.ddr_addr()
ddr_size = pypruss.ddr_size()
print DDR memory address is 0x%x and the size is 0x%x%(ddr_addr,
ddr_size)
ddr_offset = ddr_addr-0x1000
ddr_filelen = ddr_size+0x1000
ddr_start = 0x1000
ddr_end = 0x1000+ddr_size
pypruss.init() # Init the PRU
pypruss.open(0) # Open PRU event 0 which is PRU0_ARM_INTERRUPT
pypruss.pruintc_init() # Init the interrupt controller
pypruss.pru_write_memory(0, 0, [ddr_addr, ddr_addr+ddr_size-4]) # Put the
ddr address in the first region
pypruss.exec_program(0, ./ddr_write.bin) # Load firmware
ddr_write.bin on PRU 0
pypruss.wait_for_event(0) # Wait for event 0 which is connected to
PRU0_ARM_INTERRUPT
pypruss.clear_event(0) # Clear the event
pypruss.exit() # Exit PRU
with open(/dev/mem, r+b) as f: # Open the physical memory device
ddr_mem = mmap.mmap(f.fileno(), ddr_filelen, offset=ddr_offset) # mmap the
right area
read_back = struct.unpack(L, ddr_mem[ddr_start:ddr_start+4])[0] # Parse
the data
print The first 4 bytes of DDR memory reads +hex(read_back)
ddr_mem.close() # Close the memory
f.close() # Close the file
No way to read the P9_24 PIN From BBB using PRUSS
May be the *WBS *does no work as I think . a week working on that and
still nothing.
El martes, 11 de marzo de 2014 00:40:04 UTC-3, Brandon I escribió:
When I do an interruput up or down the ASM keeps waiting and nothing
Read my previous email. Your code will not work as is.
On Mon, Mar 10, 2014 at 8:11 PM, Manu manuelbe...@gmail.com wrote:
My DTS is:
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-W;
version = 00A0;
exclusive-use = P9.24;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins =
0x184 0x16 /* P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | PULLUP |
MODE6 | INPUT */
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names
[beagleboard] Re: BBB PRU input test
Along with what the others have described, since you're the arm processor gpio rather than a pru gpio, meaning you're going all the way out to system memory, you have to connect the pru to system memory. Here's an example of accessing system memory with the pru: http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru To set the pin mux for arm gpio, you can use one of these gpio overlays. Just follow the instructions: https://github.com/nomel/beaglebone/tree/master/gpio-header Also, there are a few pru debuggers out there now so you can view/step pru execution. -Brandon On Sunday, March 9, 2014 6:37:09 PM UTC-7, Manu wrote: I was trying a few days to enable PRU (BBB Ubuntu 12.04) and run a input testing code using the pin P9_24. MUX = pin 97 (44e10984) 0006 pinctrl-single (SET to MODE 6) P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | MODE6 | INPUT Nothing happens when I put the pin to 1.8 or GND The ASM code is: .origin 0 .entrypoint START #define PRU0_ARM_INTERRUPT 19 #define AM33XX #define GPIO1 0x4804c000 #define GPIO_CLEARDATAOUT 0x190 #define GPIO_SETDATAOUT 0x194 START: // clear that bit LBCO r0, C4, 4, 4 CLR r0, r0, 4 SBCO r0, C4, 4, 4 MOV r0, 10 //# cycles INPUTTEST: WBS r31.t15 //Wait til GPIO-15-in is high... P9_24 SUB r0, r0, 1 //Subtract from counter QBNE INPUTTEST, r0, 0 //Loop if counter not at zero // Send notification to Host for program completion MOV R31.b0, PRU0_ARM_INTERRUPT+16 MOV r0, 0 HALT I don't know what I am doing wrong and in Internet are not examples for INPUT tests. -- 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: BBB PRU input test
When I do an interruput up or down the ASM keeps waiting and nothing
Read my previous email. Your code will not work as is.
On Mon, Mar 10, 2014 at 8:11 PM, Manu manuelberromad...@gmail.com wrote:
My DTS is:
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-W;
version = 00A0;
exclusive-use = P9.24;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins =
0x184 0x16 /* P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | PULLUP |
MODE6 | INPUT */
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = mygpio;
status = okay;
};
};
};
fragment@2{
target = pruss;
__overlay__ {
status = okay;
pinctrl-names = default;
pinctrl-0 = mygpio;
};
};
};
and the
cat /sys/devices/bone_capemgr.*/slots
0: 54:PF---
1: 55:PF---
2: 56:PF---
3: 57:PF---
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-W
cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep pin 97
pin 97 (44e10984) 0037 pinctrl-single BEFORE
root@donkeytom-t001:/texka/pinmux# echo BB-BONE-W
/sys/devices/bone_capemgr.9/slots
root@donkeytom-t001:/texka/pinmux# cat
/sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep pin 97
pin 97 (44e10984) 0016 pinctrl-single AFTER
When I do an interruput up or down the ASM keeps waiting and nothing
Thank you!
Manuel
El lunes, 10 de marzo de 2014 23:36:42 UTC-3, Charles Steinkuehler
escribió:
Provide the *.dts source for the overlay you are trying to load, and the
contents of /sys/devices/bone_capemgr.*/slots, and maybe we can figure
out what's going wrong. It looks like something has already grabbed the
pin you want to use.
Note the pruss: failed to hardreset always shows up and doesn't
indicate a problem (or at least not the problem you're having). Your
issue is presumably the pin overlay that fails to load.
On 3/10/2014 9:20 PM, Manu wrote:
I was finding what is wrong and finally I got it. The thing is that I
don't
know how to fix it.
My BBB is Ubuntu last 12.04 version with 3.8 kernel by nelson.
The error is here:
*706.650640] omap_hwmod: pruss: failed to hardreset*
[ 706.682785] pinctrl-single 44e10800.pinmux: pin 44e10984 already
requested by helper.12; cannot claim for 4a30.pruss
[ 706.694442] pinctrl-single 44e10800.pinmux: pin-97 (4a30.pruss)
status -22
[ 706.702096] pinctrl-single 44e10800.pinmux: could not request pin 97
on
device pinctrl-single
[ 706.738323] pruss_uio 4a30.pruss: pins are not configured from
the
driver
[ 706.765286] bone-capemgr bone_capemgr.9: slot #7: Applied #3
overlays.
El lunes, 10 de marzo de 2014 20:10:55 UTC-3, Brandon I escribió:
Along with what the others have described, since you're the arm
processor
gpio rather than a pru gpio, meaning you're going all the way out to
system
memory, you have to connect the pru to system memory. Here's an
example of
accessing system memory with the pru:
http://nomel.tumblr.com/post/30006622413/beaglebone-
tutorial-accessing-main-memory-from-the-pru
To set the pin mux for arm gpio, you can use one of these gpio
overlays.
Just follow the instructions:
https://github.com/nomel/beaglebone/tree/master/gpio-header
Also, there are a few pru debuggers out there now so you can view/step
pru
execution.
-Brandon
On Sunday, March 9, 2014 6:37:09 PM UTC-7, Manu wrote:
I was trying a few days to enable PRU (BBB Ubuntu 12.04) and run a
input
testing code using the pin P9_24.
MUX = pin 97 (44e10984) 0006 pinctrl-single (SET to MODE 6)
P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | MODE6 | INPUT
Nothing happens when I put the pin to 1.8 or GND
The ASM code is:
.origin 0
.entrypoint START
#define PRU0_ARM_INTERRUPT 19
#define AM33XX
#define GPIO1 0x4804c000
#define GPIO_CLEARDATAOUT 0x190
#define GPIO_SETDATAOUT 0x194
START:
// clear that bit
LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4
MOV r0, 10 //# cycles
INPUTTEST:
WBS r31.t15 //Wait til GPIO-15-in is high... P9_24
SUB r0, r0, 1 //Subtract from counter
QBNE INPUTTEST, r0, 0 //Loop if counter not at zero
// Send notification to Host for program completion
MOV R31.b0, PRU0_ARM_INTERRUPT+16
MOV r0, 0
HALT
I don't know what I am doing wrong and in Internet are not examples
for
INPUT tests.
--
Charles Steinkuehler
cha
Re: [beagleboard] Re: problem with creating a kernel module program for angstrom os
Just a regular kernel type makefile. For examlpe, here's mine for a file phyaccess.c BEAGLEBONE_PROJ=/systems/Projects/beaglebone/workspace/Beaglebone MDIO_ROOT=$(BEAGLEBONE_PROJ)/local/MDIODriver # http://stackoverflow.com/questions/10176238/how-do-i-add-an-include-path-for-kernel-module-makefile # for kernel module make uses kbuild. Paths have to be absolute, not relative. EXTRA_CFLAGS+=-I$(MDIO_ROOT)/include -I$(MDIO_ROOT) -I$(BEAGLEBONE_PROJ)/include -I$(BEAGLEBONE_PROJ)/Interface/local/include -Werror obj-m += phyaccess.o all: make -C $(KERNELDIR) M=$(PWD) modules clean: make -C $(KERNELDIR) M=$(PWD) clean On Fri, Mar 7, 2014 at 10:57 PM, siva kumar boopathisivaku...@gmail.comwrote: thanks for your reply yes , u r right i compiled the module against arm-angstrom-linux-gnueabi-gcc but my angstrom os comes with Linaro gcc root@beaglebone:~# opkg list_installed | grep gcc *gcc - linaro-4.7-r9.2* gcc-symlinks - linaro-4.7-r9.2 libgcc-s-dev - linaro-4.7-r9.0 libgcc1 - linaro-4.7-r9.0 perl-module-extutils-cbuilder-platform-windows-gcc - 5.14.2-r13.1 root@beaglebone:~# dmesg | head [ 0.00] Booting Linux on physical CPU 0×0 [ 0.00] Initializing cgroup subsys cpu *[ 0.00] Linux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Tue Jun 18 02:11:09 EDT 2013* [ 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 c0688d80, node_mem_map c06e4000 [ 0.00] Normal zone: 1024 pages used for memmap i done the following steps to update my modules for my board .but it says my kernel headers are up to date. *root@beaglebone:~# opkg install kernel-headers* *Package kernel-headers (3.8.13-r23a.22) installed in root is up to date.* [1] what should i do to get my modules to work with?? On Saturday, 8 March 2014 02:42:31 UTC+5:30, Brandon I wrote: dmesg will give you more details. This usually means you compiled the kernel modules against a different build of the kernel. So, the kernel source you used didn't match what was on the beaglebone. You can install the kernel-headers and kernel-dev packages and build directly on the beaglebone. For some time, these packages weren't in sync with the actual kernel installed...as always, good luck with Angstrom. On Thursday, March 6, 2014 10:30:41 PM UTC-8, siva kumar wrote: hello, i recently purchased beagle bone black . my bbb come with pre compiled angstrom os( Angstrom v2012.12 - Kernel 3.8.13) still i didn't updated my os i try to test my board with simple hello module program . but when i insert a module i got the error message root@beaglebone:~# insmod hello.ko Error: could not insert module hello.ko: Invalid module format root@beaglebone:~# i compiled the module program from my host pc against arm-angstrom-linux-gcc compiler..and i transferred the hello.ko file via scp protocol. my question is [1] Is it possible to add a module program with my available angstrom os..if yes what should i do to insert modules [2] what are all the basic things needed to insert a module?? help me to better understand the beagle bone black -- 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/fIJ5YE_fJpg/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: problem with creating a kernel module program for angstrom os
Missed first line on that copy paste. Should be KERNELDIR := /usr/src/kernel On Sat, Mar 8, 2014 at 1:21 AM, Brandon I brandon.ir...@gmail.com wrote: Just a regular kernel type makefile. For examlpe, here's mine for a file phyaccess.c BEAGLEBONE_PROJ=/systems/Projects/beaglebone/workspace/Beaglebone MDIO_ROOT=$(BEAGLEBONE_PROJ)/local/MDIODriver # http://stackoverflow.com/questions/10176238/how-do-i-add-an-include-path-for-kernel-module-makefile # for kernel module make uses kbuild. Paths have to be absolute, not relative. EXTRA_CFLAGS+=-I$(MDIO_ROOT)/include -I$(MDIO_ROOT) -I$(BEAGLEBONE_PROJ)/include -I$(BEAGLEBONE_PROJ)/Interface/local/include -Werror obj-m += phyaccess.o all: make -C $(KERNELDIR) M=$(PWD) modules clean: make -C $(KERNELDIR) M=$(PWD) clean On Fri, Mar 7, 2014 at 10:57 PM, siva kumar boopathisivaku...@gmail.comwrote: thanks for your reply yes , u r right i compiled the module against arm-angstrom-linux-gnueabi-gcc but my angstrom os comes with Linaro gcc root@beaglebone:~# opkg list_installed | grep gcc *gcc - linaro-4.7-r9.2* gcc-symlinks - linaro-4.7-r9.2 libgcc-s-dev - linaro-4.7-r9.0 libgcc1 - linaro-4.7-r9.0 perl-module-extutils-cbuilder-platform-windows-gcc - 5.14.2-r13.1 root@beaglebone:~# dmesg | head [ 0.00] Booting Linux on physical CPU 0×0 [ 0.00] Initializing cgroup subsys cpu *[ 0.00] Linux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Tue Jun 18 02:11:09 EDT 2013* [ 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 c0688d80, node_mem_map c06e4000 [ 0.00] Normal zone: 1024 pages used for memmap i done the following steps to update my modules for my board .but it says my kernel headers are up to date. *root@beaglebone:~# opkg install kernel-headers* *Package kernel-headers (3.8.13-r23a.22) installed in root is up to date.* [1] what should i do to get my modules to work with?? On Saturday, 8 March 2014 02:42:31 UTC+5:30, Brandon I wrote: dmesg will give you more details. This usually means you compiled the kernel modules against a different build of the kernel. So, the kernel source you used didn't match what was on the beaglebone. You can install the kernel-headers and kernel-dev packages and build directly on the beaglebone. For some time, these packages weren't in sync with the actual kernel installed...as always, good luck with Angstrom. On Thursday, March 6, 2014 10:30:41 PM UTC-8, siva kumar wrote: hello, i recently purchased beagle bone black . my bbb come with pre compiled angstrom os( Angstrom v2012.12 - Kernel 3.8.13) still i didn't updated my os i try to test my board with simple hello module program . but when i insert a module i got the error message root@beaglebone:~# insmod hello.ko Error: could not insert module hello.ko: Invalid module format root@beaglebone:~# i compiled the module program from my host pc against arm-angstrom-linux-gcc compiler..and i transferred the hello.ko file via scp protocol. my question is [1] Is it possible to add a module program with my available angstrom os..if yes what should i do to insert modules [2] what are all the basic things needed to insert a module?? help me to better understand the beagle bone black -- 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/fIJ5YE_fJpg/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: problem with creating a kernel module program for angstrom os
Did you install the kernel-dev package? On Saturday, March 8, 2014, siva kumar boopathisivaku...@gmail.com wrote: hai, thank u!! but my folder structure from my board looks like *root@beaglebone:/usr/src# ls* *backfire linux-3.8.13* *root@beaglebone:/usr/src# cd linux-3.8.13/* *root@beaglebone:/usr/src/linux-3.8.13# ls* *include* *root@beaglebone:/usr/src/linux-3.8.13/include# ls* *asm asm-generic drm linux mtd rdma scsi sound uapi video xen* *root@beaglebone:/usr/src/linux-3.8.13/include/linux# ls* *byteorder dvb isdnnetfilter_arp netfilter_ipv6 spi tc_ematch* *caif hdlc mmcnetfilter_bridge nfsd sunrpc usb* *can hsi netfilter netfilter_ipv4raid tc_act wimax* *root@beaglebone:/usr/src/linux-3.8.13/include/linux# * this info shows that my board shipped with no module support by default ..!!! now question is [1] still i didn't update or upgraded my angstrom os ..shall i need to do or is there any other way to insert my hello_world.ko module into my board?? i found 1 more link for installing the module libs sturcture and soure into the running os . here the link http://wiki.replicape.com/index.php?title=Compiling_the_kernel will this link help me to insert also to create a modules without fail .. can you suggest your opinion..pls.. regards siva On Saturday, 8 March 2014 14:52:49 UTC+5:30, Brandon I wrote: Missed first line on that copy paste. Should be KERNELDIR := /usr/src/kernel On Sat, Mar 8, 2014 at 1:21 AM, Brandon I brando...@gmail.com wrote: Just a regular kernel type makefile. For examlpe, here's mine for a file phyaccess.c BEAGLEBONE_PROJ=/systems/Projects/beaglebone/workspace/Beaglebone MDIO_ROOT=$(BEAGLEBONE_PROJ)/local/MDIODriver #http://stackoverflow.com/questions/10176238/how-do-i- add-an-include-path-for-kernel-module-makefile # for kernel module make uses kbuild. Paths have to be absolute, not relative. EXTRA_CFLAGS+=-I$(MDIO_ROOT)/include -I$(MDIO_ROOT) -I$(BEAGLEBONE_PROJ)/include -I$(BEAGLEBONE_PROJ)/Interface/local/include -Werror obj-m += phyaccess.o all: make -C $(KERNELDIR) M=$(PWD) modules clean: make -C $(KERNELDIR) M=$(PWD) clean On Fri, Mar 7, 2014 at 10:57 PM, siva kumar boopathi...@gmail.comwrote: thanks for your reply yes , u r right i compiled the module against arm-angstrom-linux-gnueabi-gcc but my angstrom os comes with Linaro gcc root@beaglebone:~# opkg list_installed | grep gcc *gcc - linaro-4.7-r9.2* gcc-symlinks - linaro-4.7-r9.2 libgcc-s-dev - linaro-4.7-r9.0 libgcc1 - linaro-4.7-r9.0 perl-module-extutils-cbuilder-platform-windows-gcc - 5.14.2-r13.1 root@beaglebone:~# dmesg | head [ 0.00] Booting Linux on physical CPU 0×0 [ 0.00] Initializing cgroup subsys cpu *[ 0.00] Linux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Tue Jun 18 02:11:09 EDT 2013* [ 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 c0688d80, node_mem_map c06e4000 [ 0.00] Normal zone: 1024 pages used for memmap i done the following steps to update my modules for my board .but it says my kernel headers are up to date. -- 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/fIJ5YE_fJpg/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/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/fIJ5YE_fJpg/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.comjavascript:_e(%7B%7D,'cvml','beagleboard%2bunsubscr...@googlegroups.com'); . For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: problem with creating a kernel module program for angstrom os
dmesg will give you more details. This usually means you compiled the kernel modules against a different build of the kernel. So, the kernel source you used didn't match what was on the beaglebone. You can install the kernel-headers and kernel-dev packages and build directly on the beaglebone. For some time, these packages weren't in sync with the actual kernel installed...as always, good luck with Angstrom. On Thursday, March 6, 2014 10:30:41 PM UTC-8, siva kumar wrote: hello, i recently purchased beagle bone black . my bbb come with pre compiled angstrom os( Angstrom v2012.12 - Kernel 3.8.13) still i didn't updated my os i try to test my board with simple hello module program . but when i insert a module i got the error message root@beaglebone:~# insmod hello.ko Error: could not insert module hello.ko: Invalid module format root@beaglebone:~# i compiled the module program from my host pc against arm-angstrom-linux-gcc compiler..and i transferred the hello.ko file via scp protocol. my question is [1] Is it possible to add a module program with my available angstrom os..if yes what should i do to insert modules [2] what are all the basic things needed to insert a module?? help me to better understand the beagle bone black -- 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: Writing 8-bit data to GPIO pins - does one have to do it a bit at a time?
When you use user space drivers, you no longer have that protection. Since this is so off topic I'll just say, anyone interested about this topic, there is plenty of tutorials and articles about sane user space device drivers, along with production quality open source drivers. The acceptance of the concept is somewhat new, and there are many misconceptions. On Fri, Mar 7, 2014 at 2:02 PM, John Syn john3...@gmail.com wrote: From: Brandon I brandon.ir...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Friday, March 7, 2014 at 1:27 PM To: beagleboard@googlegroups.com Cc: c...@isbd.net Subject: [beagleboard] Re: Writing 8-bit data to GPIO pins - does one have to do it a bit at a time? user space should not know how you talk to it physically I don't think this is generally accepted, otherwise user space device drivers wouldn't exist: http://www.embedded.com/design/operating-systems/4401769/Device-drivers-in-user-space With user space device drivers, you're free to push as little or as much into the kernel as you like. The normal practice is that a badly behaving user space application should not kill your complete system. Only the user space app should die. When you use user space drivers, you no longer have that protection. User space drivers are generally not a good idea unless you want to avoid the user/kernel switching delays. Regards, John -Brandon On Thursday, March 6, 2014 12:06:43 PM UTC-8, robert.berger wrote: Hi, On Thursday, March 6, 2014 11:25:14 AM UTC+2, c...@isbd.net wrote: All the examples and libraries (Python mostly) that I can find for doing IO to the GPIO pins seem to handle only a bit at a time. This is fine for things like driving relays and LEDs but makes little sense for 8-bit data. Taking your example. If we are talking about a device you want to connect to your beagle user space should not know how you talk to it physically and whether it's 8-bit data or i2c or something else underneath. Having said that there was/is some attempt to do what you want in kernel space [1] and it's called block GPIO [2] but I don't think it made it into mainline. Regards, Robert [1] http://lwn.net/Articles/533632/ [2] http://lwn.net/Articles/533557/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/91ikp6Mxi0s/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Need 16 GPIOs Next to each other on P8
Provided, you don't interfere with their settings during power up as they are also the boot pins. He's saying you shouldn't interfere with their state at boot. No driving, pullup, or pull down on any of these pins (besides the those that configure the sysboot setting on the board). Relays wont flip, but there are 100k pullups on some of the pins, so they could be in a state you don't want. You could isolate these pins with something like a bilateral switch (or a Va = Vb type unidirectional level shifter) during boot. Attach the enable to 3v3_exp, and make sure whatever is on the world side of the isolator is in a known state when the pins are at high impedance (using pull ups or down). For any pins that you want to switch simultaneously (which requires memory writes), make sure they're in the same gpio bank. -Brandon On Sunday, March 2, 2014 2:04:25 PM UTC-8, Gerald wrote: As is indicated in the System Reference Manual, you can use the LCD pins as GPIO pins. Provided, you don't interfere with their settings during power up as they are also the boot pins. Gerald On Sun, Mar 2, 2014 at 1:32 PM, mharr...@gmail.com javascript: wrote: Hi, I would like to configure BBB P8 with 16 (2 rows of 8) GPIO pins next to each other. They just need to be able to be set to high or low. I see P7 through P18 but I need 4 more. I am not using any LCD screen. Is it possible to reconfigure the pins? I am a BBB newbie and would appreciate any help so I don't mess anything up. 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 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] How are the production BBB images built?
Maybe we can become free from SD cards in the near future for BBB development. Doesn't uboot support network boot already? On Thursday, February 27, 2014 11:29:23 PM UTC-8, jhg...@gmail.com wrote: Robert, Have you resolved any of these mysteries in the mean time? I got into this by trying to bitbake a simpler image, such as console-image, since I need no graphics or fancy webserver with node.js foo. So far I have failed to boot from the SD card with anything which has been made by the oebb.sh script or bitbake build system. Even Derek's 2-year-old instructionshttp://derekmolloy.ie/building-angstrom-for-beaglebone-from-source/seem not to work for console-image. After I succeed at booting the BBB with my own custom image, I plan on updating u-boot to allow fastboot, an feature more commonly supported by Android which allows one to boot or flash over USB, ethernet, etc. Maybe we can become free from SD cards in the near future for BBB development. Cheers, Joe On Friday, July 12, 2013 8:30:29 AM UTC-4, Robert P. J. Day wrote: On Fri, 12 Jul 2013, Chris Morgan wrote: On Friday, July 12, 2013, Koen Kooi wrote: Op 12 jul. 2013, om 13:46 heeft Robert P. J. Day rpj...@crashcourse.ca het volgende geschreven: On Fri, 12 Jul 2013, Koen Kooi wrote: It's all in the SRM, but for people too lazy to read that: � � �Read http://www.angstrom-distribution.org/building-angstrom and follow the steps outlined there. �gaah ... i am not interested in the general philosophy of how to build angstrom, that's *not* the question on the table. the question is, which *particular* configuration of angstrom is the one that matches what is currently shipping on the BBB? The one I linked above. There is only one configuration of angstrom per release and the above matches the release that ships with the bones. Hello. I followed those instructions and, although I had selected the yocto 2013 release, I ended up with the component files in the deploy/ directory but as rootfs and ubi files, not card images. The information yesterday about the emmc-prepare.sh and other scripts has helped informationaly, I think I'll be able to build a sd card image today using those steps, but at this point it seems like a multi step process after following the angstrom build steps. actually, that's what i would have expected ... the primary purpose of OE/yocto is to build the fundamental images or objects, not so much to create the final bootable SD card image based on them, since some people might not want an SD card, they might be, say, trying to populate a TFTP or NFS server with those images. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- 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: How to turn on/off GPIOs in BBB
Pad control registers can only be changed in kernel space. You could write a kernel driver or do it the right way and use device tree. See https://github.com/nomel/beaglebone/tree/master/gpio-header If you don't want to use it directly, you can use the generated files as an example. -- 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 Black backordered everywhere
At arrow, I just asked, and they have an old A53 datasheet up, so the guy told me it was a rev A5B. Are the arrow boards A6A? On Monday, January 27, 2014 4:38:26 PM UTC-8, smith.wi...@gmail.com wrote: On Monday, January 27, 2014 2:18:04 PM UTC-5, Gerald wrote: Arrow is showing 500 boards in stock. We have people buying boards to go into products, something we cannot plan for. When will that be fixed? I have no idea. We cannot plan for something we don't know about. Thank you! I've had them backorderd at both Digikey and Newark for weeks now. Arrow have already shipped my order. They still have 436 in stock. -- 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: PRU I/O
Here's mine:
/dts-v1/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
part-number = AQ-PRU-MDIO;
exclusive-use = P8.43, P8.44, P8.45, P8.46, P8.39, P8.40,
P8.41, P8.42, P8.27, P8.28, P8.29, P8.30, pru1;
fragment@0 {
target = 0xdeadbeef;
__overlay__ {
pinmux_pru_mdio_pins {
pinctrl-single,pins = 0xa8 0xd 0xac 0xd 0xa0 0xd 0xa4 0xd 0xb8 0x35 0xbc
0x35 0xb0 0x35 0xb4 0x35 0xe0 0x36 0xe8 0x36 0xe4 0x36 0xec 0x36;
linux,phandle = 0x1;
phandle = 0x1;
};
};
};
fragment@1 {
target = 0xdeadbeef;
__overlay__ {
status = okay;
pinctrl-names = default;
pinctrl-0 = 0x1;
};
};
__symbols__ {
pru_mdio_pins = /fragment@0/__overlay__/pinmux_pru_mdio_pins;
};
__fixups__ {
am33xx_pinmux = /fragment@0:target:0;
pruss = /fragment@1:target:0;
};
__local_fixups__ {
fixup = /fragment@1/__overlay__:pinctrl-0:0;
};
};
I constructed mine by modifying one of the existing dts files on the
beaglebone. I'll admit I don't completely understand it, but you could
trimming it down to only your pins.
On Tuesday, January 21, 2014 6:56:41 PM UTC-8, Christopher Hopwood wrote:
Hello all,
I'm trying to use the PRU gpio pins, but cannot get them to work. I've
modified Doctor Yoder's device tree example to enable the PRU pins, but my
program is still not getting the input. What am I doing wrong?
Here is my overlay:
/dts-v1/;
/plugin/;
/{
compatible = ti,beaglebone, ti,beaglebone-black;
part-number = MAY-gpio-set;
version = 00A0;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
pinctrl_test: MAY-gpio-set {
pinctrl-single,pins =
0x0e4 0x36
0x0e0 0x36
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = pinctrl_test;
status = okay;
};
};
};
};
--
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: PRU FAQ 2013-05-15
In the pru, R31 is for input, so in that table you're looking for pin pr1_pru1_pru_r31_8. That's on P8.27, which is used by the HDMI framer. If you *need* to use this pin, instructions on disabling the hdmi framer can be found by searching this group. Of course you'll have to enable the receiver, otherwise the state of the pin couldn't be measured! Also, here's a easier to digest table for the pru header pins: https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c#gid=0 On Tue, Jan 21, 2014 at 6:08 PM, Christopher Hopwood rockybulwin...@gmail.com wrote: I need to make sure I'm understanding correctly. If I want to use PRU1's pin 8 as an input, should I use the address 0x8e0 or 0x0e0? Should I set the mode to 0x26 to use input and enable the receiver? Thanks for the help! On Wednesday, January 22, 2014 1:40:27 AM UTC, Charles Steinkuehler wrote: On 01/21/14 19:34, Christopher Hopwood wrote: Where can I find the correct pinmux settings for the PRU as well as which pru gpio port maps to which header bin? I don't see it on Derek Molloy's header table. The details are all in the TI manuals, or you can reference an excellent compilation from various official sources on github: https://github.com/selsinork/beaglebone-black-pinmux -- Charles Steinkuehler cha...@steinkuehler.net -- 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/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: bitcoin mining on BBB
What he means by that is, it'll cost you more in electricity to mine (with a crud cpu setup) than to just buy some with cash from an exchange. On Saturday, January 18, 2014 8:57:19 AM UTC-8, Michael Mullin wrote: I'm sure you can tweak cgminer to re-enable CPU based mining... But that feature was removed for a reason; it's pointless. Even with a high end intel i7 processor, you're wasting your time, electricity, and the usage of the beaglebone. The bbb can be used as a controller for other hardware specific to mining (aka ASIC hardware). -- 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] Forbidden pins on P8 and P9
And, you shouldn't rely on the pull up/down pins that are there now since they could change with the next beaglebone (as they did between the black and white). You can make them high impedance at boot by using something like a bilateral switch enabled with 3V3_EXP. On Tuesday, January 14, 2014 6:49:50 AM UTC-8, dl4mea wrote: Take care you don't change one of the SYSBOOT pin's value by your own pullup/pulldown. This happend on my cape, so that the automatic clock detection does not work and we're getting wrong system time. A kernel patch solves that, but it may become worse if touching others. Günter (dl4mea) -- 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: Has anybody tested the new Graphics SDK which should enable SGX on kernel 3.12?
I think everyone (that isn'in the group would On Wednesday, December 11, 2013 4:32:42 AM UTC-8, Giuseppe Iellamo wrote: Thank you this is a very good news for me! When I'll finish with RT part I'll try QT5 on BBB... Giuseppe Il giorno mercoledì 11 dicembre 2013 00:05:04 UTC+1, Daniel Nilsson ha scritto: Hi, I haven't tried the links you posted below, but I played around tonight with the latest bits in the arago project and now I have accelerated 3D graphics support on a beaglebone black. Using the beaglebone black BSP support in meta-ti, I get a 3.12.4 Linux kernel and then I built the arago-base-tisdk-image as root filesystem. Result is a beaglebone black which displays accelerated 3D graphics on the display connected over HDMI, so the SGX drivers are now available för the 3.12 kernel (in arago) but still not packaged nicely for the BBB I guess. Regards Daniel On Monday, December 9, 2013 10:38:10 AM UTC+1, Giuseppe Iellamo wrote: As the title states... has anybody tried? http://processors.wiki.ti.com/index.php/RN_5_00_00_01_alpha http://e2e.ti.com/support/arm/sitara_arm/f/791/p/298596/1072533.aspx#1072533 -- 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: Has anybody tested the new Graphics SDK which should enable SGX on kernel 3.12?
I think everyone in the group (who isn't headless) would love to see some benchmark results! On Wednesday, December 11, 2013 4:32:42 AM UTC-8, Giuseppe Iellamo wrote: Thank you this is a very good news for me! When I'll finish with RT part I'll try QT5 on BBB... Giuseppe Il giorno mercoledì 11 dicembre 2013 00:05:04 UTC+1, Daniel Nilsson ha scritto: Hi, I haven't tried the links you posted below, but I played around tonight with the latest bits in the arago project and now I have accelerated 3D graphics support on a beaglebone black. Using the beaglebone black BSP support in meta-ti, I get a 3.12.4 Linux kernel and then I built the arago-base-tisdk-image as root filesystem. Result is a beaglebone black which displays accelerated 3D graphics on the display connected over HDMI, so the SGX drivers are now available för the 3.12 kernel (in arago) but still not packaged nicely for the BBB I guess. Regards Daniel On Monday, December 9, 2013 10:38:10 AM UTC+1, Giuseppe Iellamo wrote: As the title states... has anybody tried? http://processors.wiki.ti.com/index.php/RN_5_00_00_01_alpha http://e2e.ti.com/support/arm/sitara_arm/f/791/p/298596/1072533.aspx#1072533 -- 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: Program for making sinewaves in real time with Analog inputs (any language)
Google beaglebone black adc for a bunch of examples. On Tuesday, November 26, 2013 9:24:14 PM UTC-8, Zain Dar wrote: Hi, just like in the title, I'm trying to make a program code for making sinewaves that work with the analog pins when I have analog accelerometers connected to it. Is there a code that can take the voltages from the sensors and plot them to a graph in real time? which language an if there are any tutorials or any candidate who has the idea for making it. Thanks to those to help, it will help me alot to finish my project. -- 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] gpio.h No such file or directory error
All of the gpio registers have dedicated set and clear registers so you don't have to do read-modify-write operations. There wont be an issue with collisions between separate gpio bits if you're just setting or reading pin states. On Sunday, November 24, 2013 11:13:21 PM UTC-8, rod calabio wrote: I copy that Dave. Yes, need to use masks, multiple registers, xors, ands, to toggle multiple bits quickly. I wonder how fast the mux switches also. Yes, would need to look at all the interrupts and momentarily turning some off when doing high speed gpio switching. I am making a 80 way network switch using the bbb and fpga cpld. Rocketrod -- 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: Is there a way to access the UART registers
You can find the memory offsets for the uart control, and then the offsets for the specific registers in that reference manual. From there, you can use an mmap to the registers in your program/script or use the devmem2 command to read/write the registers directly. *mmap example with gpio registers*: c\c++: http://stackoverflow.com/questions/13124271/driving-beaglebone-gpio-through-dev-mem python: http://www.alexanderhiam.com/tutorials/beaglebone-io-using-python-mmap/ *devmem2: *http://man.cx/devmem2(1) just uses an mmap to access memory. *read-modify-write:* concept is to read the current value, modify some bits in the read value, and then write back the modified value, preserving all of the bits you didn't want to change. Search for bitwise operations for your language. Make sure the bits you're trying to access aren't available with the sysfs and c interface first. On Friday, November 22, 2013 6:49:50 AM UTC-8, Andrei wrote: Hello, I have a problem, how can I access the UART registers on a BeagleBone Black? I need to change UART modes described in in: TI AM335x ARM A8 Microprocessors technical reference manual example of instructions. Disable the UART before accessing the UARTi.UART_DLL and UARTi.UART_DLH registers: Set the UART_MDR1[2:0] MODE_SELECT bit field to 0x7. 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/groups/opt_out.
Re: [beagleboard] Re: Setting the Bitrate of I2C2 on the Beaglebone Black
You don't need the kernel source. You can convert the compiled device tree blob to the text version, edit it, and the convert it back to the binary using dtc: # backup the original .dtb cp /boot/am335x-boneblack.dtb /boot/am335x-boneblack.dtb.orig # generate the dts from the dtb dtc -I dtb -O dts -o am335x-boneblack.dts /boot/am335x-boneblack.dtb # modify the dts with a text editor # generate the dtb from the modified dts dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts On Wednesday, November 20, 2013 6:18:53 AM UTC-8, cody wrote: If you have the kernel source it is located at arch/arm/boot/dts/am335x-bone-common.dtsi Then you will need to recompile the am335x-boneblack.dtb On Wed, Nov 20, 2013 at 4:04 AM, chai chaitra.m...@tismotech.netjavascript: wrote: hi, can i know where I can find the am335x-bone-common.dtsi? it is not present in /lib/firmware so where can i find 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...@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: Program C++ through putty using VI (Library installations needed?)
I was wondering if it is possible to write a c/c++ code in vi through SSH on Putty and then generate an output file and run directly on the beaglebone? I tried the simple helloworld.c program and it worked. I have a network share set up, accessible by the beaglebone. I also have the beaglebone set up as a network share, with samba. I edit my files in my favorite modern editor, but compile and run from the network shares, directly, on the beaglebone. Biggest benefit is, if I hose something on the beaglebone or the flash/sd card dies or whatever, I just plug in a new beaglebone, and and up and running after I cd to my development directory. Don't develop on the beaglebone flash without some sort of constant backup/source control. You will most likely break something at some point, like with a opkg upgrade and it's hard to get stuff off the emmc. but its my first time in Embedded Forget the embedded part, just think of it as a low end little Linux PC. That's the whole point of Linux, it's nearly identical regardless of the machine you're on. This one is no different than a supercomputer cluster, except you have somewhat constrained resources ;) and some unusual, kick butt, peripherals, like the PRUs. g++, gcc, python, perl, and node.js (probably forgetting some) are already installed. There are tens of thousands of tutorials on developing regular Linux applications, which is all you'll be doing (maybe accessing some interesting sysfs interfaces, but that's not unusual). With the kernel-dev and kernel-headers packages, you can even compile kernel modules right on the Beaglebone. For opkg, you need the exact name. Use opkg list to find the package. You can use wildcards to list packages, so opkg list *gcc*. On Monday, November 11, 2013 2:32:25 PM UTC-8, siddharth...@gmail.com wrote: Could give me a link with specific commands for this process? I tried installing G++ with opkg install g++ I get 3-4 error messages and there is no installation. Do I need to be in some kind of an administrator mode? I'm very new to Linux and to beaglebone. I have no clue how to do the things you guys told me in the previous replies. I'm familiar with FPGA programming but its my first time in Embedded On Monday, November 11, 2013 1:12:59 AM UTC-6, siddharth...@gmail.comwrote: I was wondering if it is possible to write a c/c++ code in vi through SSH on Putty and then generate an output file and run directly on the beaglebone? I tried the simple helloworld.c program and it worked. But I tried to write LED blink program and I'm getting error messages. I used the code by Derek Molley on his website: That uses FILE, fopen, fclose, sleep, NULL, etc. I'm getting errors about these. Am I supposed to install some kind of libraries or a arm-gnueabi compiler before I try to run programs that access the GPIOs and the LEDs ? Please also let me know the commands for installing the needed packages or an example LED code that would work this way. Also is there a better OS than Angstrom for beginners on BBB? How is the Ti SDK? Thank you -- 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] beagleboneblack don't restart after power fluctuation.
I've connected beagleboneblack to my car power supply with 24V to 5V step down. 24V power supply in a car? If this means you're this from the accessories circuit, you're doomed. Accessories are turned off while the car is being started, and a cap won't be enough to power the beaglebone, since they stay off as long as you're turning the engine. Another problem is, you'll corrupt the filesystem with an out-of-the-box beaglebone. You'll *have to* use a read only file system. You could tie the beaglebone directly to the battery (with a fuse of course) and use some circuit to monitor when to turn it on and off. On Tuesday, November 5, 2013 9:24:49 AM UTC-8, Wilfredo Nieves wrote: I think you should be fine as long as you don't use a value that is too high or too low. Too high may cause problems with rise time and too low may not keep enough power supplied for the board to stay powered up. Also caps aren't like batteries, the charge almost instantaneously where as batteries need time to fully charge so as long as you can get the cap charged fast enough the board should power up without any problems. -Wil On Nov 5, 2013 8:27 AM, satya gowtham kudupudi satyago...@gmail.comjavascript: wrote: Thank you. I will give a try. As per the post here https://groups.google.com/forum/#!msg/beagleboard/aXv6An1xfqI/mURD3LfQ5dMJ? the power source should have proper rise time. I'm afraid a capacitor will increase the rise time. Any way I'll give a try. -- 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.
Re: [beagleboard] beagleboneblack don't restart after power fluctuation.
A cap big enough should be able to handle that. Not sure if I did my math right, but for 2 seconds at 2W (beaglebone will be booting), and assuming his 24V to 5V regulator can regulate with an input voltage all the way down to 12V, that's around 20mF. I guess that's doable with $$$. It wouldn't be as simple as connecting the cap to the accessories line, since this would absolutely destroy your relay contacts from the inrush in charging this gigantic cap from 0V. And, you would have to throw a diode in so you didn't power *all* of your accessories with this cap. On Tue, Nov 5, 2013 at 9:15 PM, Wilfredo Nieves wilfred019...@gmail.comwrote: Not necessarily , my car is a 95 3kgt and it starts within 1-2 seconds of turning it over. A cap big enough should be able to handle that. As for the 24v idk how I didn't catch that, but then again who knows it is possible. -Wil On Nov 5, 2013 9:30 PM, Brandon I brandon.ir...@gmail.com wrote: I've connected beagleboneblack to my car power supply with 24V to 5V step down. 24V power supply in a car? If this means you're this from the accessories circuit, you're doomed. Accessories are turned off while the car is being started, and a cap won't be enough to power the beaglebone, since they stay off as long as you're turning the engine. Another problem is, you'll corrupt the filesystem with an out-of-the-box beaglebone. You'll *have to* use a read only file system. You could tie the beaglebone directly to the battery (with a fuse of course) and use some circuit to monitor when to turn it on and off. On Tuesday, November 5, 2013 9:24:49 AM UTC-8, Wilfredo Nieves wrote: I think you should be fine as long as you don't use a value that is too high or too low. Too high may cause problems with rise time and too low may not keep enough power supplied for the board to stay powered up. Also caps aren't like batteries, the charge almost instantaneously where as batteries need time to fully charge so as long as you can get the cap charged fast enough the board should power up without any problems. -Wil On Nov 5, 2013 8:27 AM, satya gowtham kudupudi satyago...@gmail.com wrote: Thank you. I will give a try. As per the post here https://groups.google.com/forum/#!msg/beagleboard/ aXv6An1xfqI/mURD3LfQ5dMJ? the power source should have proper rise time. I'm afraid a capacitor will increase the rise time. Any way I'll give a try. -- 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/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. -- 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/5toeq-9pcfU/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/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: Fast boot, no-GUI distro?
You can build angstrom without the gui. For some pre built images, check out the angstrom rootfs image at http://downloads.angstrom-distribution.org/demo/beaglebone/ On Monday, October 7, 2013 12:34:13 AM UTC-7, Rick M wrote: Hi. I'm getting started with my BBB, having done previous projects with RPi and smaller boards. I'm wondering if anyone's made an Angstrom distribution designed for fast boot, and that doesn't bother with any of the desktop and other graphical UI elements. I'm embedding this in a robot, don't really want those things, and the faster it boots, the better. It'd be nice if there was someone making a distro like this on a regular basis, keeping it up to date. It would be a lot faster to install. Anyway, I'm not much of a linux user per se, and don't really know what can be dumped Any pointers to projects would be much appreciated. 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/groups/opt_out.
Re: [beagleboard] Device Tree Overlay ? why do we need it?
2. Why is a DT used to define the HDMI Because this is a system-on-chip. The HDMI, gpio, gpu, pruss, etc are all peripherals of the cpu that are located on the chip, but still separate from the cpu. 3. If you just want to get gpio or leds working quickly, check out this post: https://groups.google.com/d/msg/beagleboard/75suL1Mhzao/FBZr4gPM2wkJ And, make sure you have the latest production image and check out the /lib/firmware path. I think there's a device tree overlay for about everything on chip now. On Sunday, October 6, 2013 12:19:55 AM UTC-7, Amalinda J' Gamage wrote: thank you Pedro and Przemek . I read through the materiel provided but I still have some doubts. 1. Do you know a place where a very beginner coming from TI microcontrolers (e.g. MSP430 and ARM Cortex M) can learn this embedded linux from the begining? can you provide a guidance? a series of videos or an extemely good book or some really good source? because I dont seem to get the hang of these stuff by going through posts and blogs because none start from scratch. I haven't taken any units on e linux in uni either. 2. Okay, I now get a little bigger picture that DTs are used to define external hardware that can be or are already connected to the ARM Cortex A. So, Why is a DT used to define the HDMI eMMC? It is because the new Linux kernel has not included any hardware definitions for HDMI and eMMC ? 3. Is it possible that GPIOs be programmed without doing anything with Device trees using the new Linux Kernel in the BBB? thank you a lot for responses. -- 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: PRU FAQ 2013-05-15
and a lot of the pins are shared with the LCD/HDMI interface. Which can be made available by disabling the hdmi framer by adding the following to uEnv.txt on the fat32 partition: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN On Wed, Oct 2, 2013 at 1:03 PM, Charles Steinkuehler char...@steinkuehler.net wrote: On 9/30/2013 8:40 AM, dthphon...@gmail.com wrote: Is it possible to use these two PRU (pru0 and pru1) simultaneously to control fast GPIO in direct PRU - output mode? If yes, how can we do that with only r30? Each PRU has it's own r30, which drives the direct outputs (assuming you have the pinmux setup properly). You can only drive a limited number of the BeagleBone header pins using PRU direct I/O, and a lot of the pins are shared with the LCD/HDMI interface. -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[beagleboard] Re: opkg upgrade=WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory
http://imgur.com/6W5zcb0.jpg On Wednesday, September 25, 2013 12:20:49 PM UTC-7, Steve French wrote: Hello! New to BBB, but lovin it so far...got two of them working on the same network...more to come... 1) So, I used this image BBB-eMMC-flasher-2013.09.04.img 2) In order for me to do a opkg update opkg upgrade without hundreds of opkg_download: Failed to download errors , I had to do the hack that Paul Tan referenced herehttps://groups.google.com/forum/#!topic/beagleboard/Kyq1NQOFSns . 3) After a seemingly successful completion of opkg upgrade, I noticed these warnings on both BBBs that I was upgrading at the same time. (Interestingly one of them had 4 warnings and the other had 6 warnings) QUESTION: Ignore it or fix it somehow? Thx! Final lines of opkg upgrade for root@VoltVision-BBB1: WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.builtin: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.builtin: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.builtin: No such file or directory Final lines of opkg upgrade for root@VoltVision-BBB2: WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.builtin: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.order: No such file or directory WARNING: could not open /lib/modules/3.8.13/modules.builtin: No such file or 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/groups/opt_out.
