Re: [beagleboard] Eclipse C and Remote Debugging
Hi On Thursday, June 5, 2014 9:35:03 AM UTC+3, Simon Platten wrote: Having thought about what is happening over night...I still don't understand why Remote debugging from host is 192.168.1.100 ??? I run Ubuntu 14.04 in Virtualbox on my Windows 7 x64 development system. The I/P addresses for the various components are as follows: Ubuntu, 10.1.174.100 --- how about a 192.168.1.x subnet? Windows 7,192.168.1.100 Beaglebone Black, 192.168.1.161 Did you ever try remote debugging without Eclipse as I already suggested? Regards, Robert -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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] Eclipse C and Remote Debugging
I must admit I haven't but I will try tonight. Sent from my iPhone On 5 Jun 2014, at 08:09, robert.berger robert.karl.ber...@gmail.com wrote: Hi On Thursday, June 5, 2014 9:35:03 AM UTC+3, Simon Platten wrote: Having thought about what is happening over night...I still don't understand why Remote debugging from host is 192.168.1.100 ??? I run Ubuntu 14.04 in Virtualbox on my Windows 7 x64 development system. The I/P addresses for the various components are as follows: Ubuntu, 10.1.174.100 --- how about a 192.168.1.x subnet? Windows 7,192.168.1.100 Beaglebone Black, 192.168.1.161 Did you ever try remote debugging without Eclipse as I already suggested? Regards, Robert -- 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/USEklgWaQkg/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] Eclipse C and Remote Debugging
Your virtualbox network is likely just using NAT, so to the BBB it will appear that the traffic is coming from the host computer. Agreeing with what Robert already said, I would start from the command line tools (gdb gdbserver) and work up. Regards, Jon On Thursday, 5 June 2014 07:35:03 UTC+1, Simon Platten wrote: Having thought about what is happening over night...I still don't understand why Remote debugging from host is 192.168.1.100 ??? I run Ubuntu 14.04 in Virtualbox on my Windows 7 x64 development system. The I/P addresses for the various components are as follows: Ubuntu, 10.1.174.100 Windows 7,192.168.1.100 Beaglebone Black, 192.168.1.161 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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] Apply a patch to 3.8.13-bone47 and recompile kernel
Hooray I managed to take a flasher SD card, mount it on a Linux box and apply the patched kernel using tools/install_kernel.sh The flasher then successfully writes to the target BBB internal SD :) Robert, did you recommend working on a non flashing image to allow more customisation, in order to create a form of golden master? Installing packages and the like? Thank you all so much for the help :) Tris On Wednesday, 4 June 2014 19:20:43 UTC+1, Tristan Phillips wrote: Thank you :) On Wednesday, 4 June 2014 19:15:03 UTC+1, RobertCNelson wrote: On Wed, Jun 4, 2014 at 1:12 PM, Tristan Phillips tris.p...@gmail.com wrote: Nice one :) Yeap, and for a hint. Take the current non-flashing debian image - OK with Ubuntu too? With this one: (it's the exact same rsync based script as in debian) http://elinux.org/BeagleBoardUbuntu#BeagleBone.2FBeagleBone_Black install your kernel - by running tools/installkernel.sh on the pc with the SD card plugged in? yeap, or if you get stuck, look at: http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-CopyKernelFiles for hints. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Network addressing
Hello I've flashed the eMMc with Angstrom but have booted off the SD card running Debian. I keep getting assigned the DHCP address of .23 instead of the static address of .15 that I've assigned in /etc/network/interfaces. What am I missing? auto lo auto eth0 iface eth0 inet static address 192.168.1.15 gateway 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 I've reloaded and rebooted the BBB, but to no avail. Thanks for you 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.
[beagleboard] Communication between Beagleboard-xm and LM3S8962
Hi all. I'm doing a project with Beagleboard-xm and I want to send data from BBXM to LM3S8962 board via I2C interface. I use TCA9406 http://www.ti.com/product/tca9406 as Voltage-Level translator. When I use i2cset 1 60 0 80 command (i2c-1 bus, LM3S8962's address is 0x3c, data address 0x0a, data 0x50), sometimes it can write but sometimes has Error: Write failed (ratio is about 50%). Does anyone know what the reason to cause the error? Thank you very much! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: running Programs off SDcard, in Debian
problem solved! sdcard was FAT format reformat to ext3 thanks everyone On Tuesday, June 3, 2014 10:48:45 PM UTC-7, dancat...@gmail.com wrote: hello, i have a beaglebone black with debian installed on the eMMC and i would like to write and run programs off the sdcard. but when i try to change a bash file to executable: chmod +x /media/45AA-4F26/myprogram(45AA-4F26 is the name of my sdcard) the file does show as an executable: ls -l /media/45AA-4F26/ ... -rw-r--r-- 1 debian debian99 May 28 20:24 myprogram any idea why this is? is there a permissions issue? Also, when i run ls -l, it shows debian even though im logged in as root thanks Dan -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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] How to install a custom PRU
Yes, I wrote my question incorrectly. I am new to beaglebone. I think you got what I was looking for. I give it a try. Thanks for the reply. Bo On Tuesday, June 3, 2014 2:12:54 PM UTC-7, Sungjin Chun wrote: Ah, and here is my code you can refer ;-) https://github.com/chunsj/nxctrl/blob/master/pru-test.c https://github.com/chunsj/nxctrl/blob/master/pru-test.p C code is for loading pru program. Sent from my iPad On Jun 3, 2014, at 4:49 PM, bo.h...@gmail.com javascript: wrote: I have been researching on how to load a custom pru on a beagle bone black. Is there somewhere for some guidance or a site that may have a tutorial or even a book on this topic. Thanks Bo -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Android Beaglebone black GPIO APK not functioning
Hi Everybody, We have with us a BeagleBone Black rev B. We have TI's pre-built JB 4.2.2 image running on it. We also have CCSv5 installed on our Ubuntu laptop, and are able to connect and load sample applications on the Bone, using SDK as well as NDK. For some reason, NDK(or JNI apps) aren't debuggable, in the sense that execution doesn't stop at inserted breakpoints. Now, to control the GPIO's, we need root access. I've read somewhere on this forum that the TI image is already rooted. Also, through ADB, if for eg ,we want to toggle an LED attached to GPIO, we have to type the following into ADB shell. root@android:/ # echo 53 /sys/class/gpio/export root@android:/ # echo out /sys/class/gpio/gpio53/direction for LED on root@android:/ # echo 1 /sys/class/gpio/gpio53/value for LED off root@android:/ # echo 0 /sys/class/gpio/gpio53/value We are trying to toggle an LED through an app i.e. apk file. Obviously, we are coding using the SDK. Attached is the app source code. We referred the source code of ToogleLED.apk available from http://olimex.wordpress.com/2013/05/23/a10s-olinuxino-android-gpio-control-led-toggle-app/ Both the files are zipped into one and available at 2 zip files http://www.fileconvoy.com/dfl.php?id=g608e889f70dd39da999512511291808fb6c275d70 which is also attached. We have written a very simple app, so that debugging is not a headache, optimization will be done later. Please see the source code now. We have the following doubts/queries: 1) In the Manifest file : uses-permission android:name=android.permission.HARDWARE_TEST / uses-permission android:name=android.permission.BLUETOOTH / These permissions are notified to the user while installing the App. DOES IT MEAN THAT THE APP NOW HAS ACCESS TO THE REQUESTED RESOURCES ? Or do we have to include some android/java libraries for explicit permission ? 2) The Android Doc for android.permission.HARDWARE_TEST says, from Android Manifest - Hardware http://developer.android.com/reference/android/Manifest.permission.html#HARDWARE_TEST Allows access to hardware peripherals. Intended only for hardware testing. Not for use by third-party applications. Is this permission enough for access to GPIO's ? 3) from the adb shell we see : root@android:/ # Does this mean that the image is rooted ? 4) Most imp. question : Why doesn't this code work ? Refer the functions : outputLow and outputHigh 5) Is there a way to access GPIO's through JNI, i.e. for eg, without using exec function(which consumes time) ? 6) Is there anyone here who has a fully functioning app written. Can you share the source code so that we can compare and learn ? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Using GPIO's as SPI
Thanks Guy Grotke... could you help me out with resources I can use to implement bit-banging... Also I have not worked on PRU's, will try reading up and get back to you... btw I dont think the MUXing will work, because I want all data to be collected simultaneously (at run-time)... On Wednesday, June 4, 2014 2:10:41 PM UTC-4, Guy Grotke wrote: You could bit-bang SPI Master using some GPIO pins, but you can't run the clock much faster than 1 KHz using a user-space program under Linux. With a custom driver, you could run faster but it would still be limited by the interrupt latency caused by other ISRs. You could do it using a PRU to bit-bang some GPIO pins, and it could run much faster. (Probably as fast as your SPI slave devices can run.) That kind of bit-banging a communications protocol is why the PRUs are in the chip. Each of the existing SPI modules have some provision for generating different SPI_CSN[n] signals, but as I recall you can only select four devices and maybe not all four SPI_CSN[n] signals are routed to a P8 or P9 pin? If you need to talk to more SPI slave devices, then you could add a little bit of external hardware so you can use a few GPIO outputs to steer your SPI_CSN signal to one of many SPI slave devices. Like a little 1=16 mux controlled by 4 GPIOs. Then you could just set the device address in your application before calling the standard SPI device API. On 6/4/2014 7:37 AM, swapn...@gmail.com javascript: 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 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] Re: Client-side file sharing (nfs/samba/cifs/sshfs) on Angstrom?
Dear Hogg, i m new , pls provide me steps how u have mounted windows network drives on Angstrom...i m trying but dont know what i m missing to do.. On Wed, Jun 4, 2014 at 7:59 PM, Wolfgang Hokenmaier hog...@gmx.net wrote: It got samba to work on Angstrom but I later switched to debian for other compatibility reasons. Hope this helps. On Jun 4, 2014, at 6:33 AM, ansarirah...@gmail.com wrote: Hogg brother...pls let me know how u did ? through Angstrom?? or any other...waiting for ur reply. On Thursday, January 9, 2014 1:46:42 AM UTC+5:30, Hogges wrote: Thanks. This worked for me with the latest Angstrom install. The hardest part was installing mkimage... On Thursday, December 19, 2013 3:02:16 PM UTC-5, David Marquart wrote: I know this post is old, but here is how I got CIFS working. -With Angstrom booted on eMMC I put mSD card with Robert Nelson's Ubuntu image on it into mmc slot. mkdir /mnt/sd1 mkdir /mnt/sd2 mount /dev/mmcblk1p1 /mnt/sd1 mount /dev/mmcblk1p2 /mnt/sd2 cd /mnt/sd1 mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n kernel -d ./zImage ./uImage cp uImage /boot cp -r /mnt/sd2/lib/modules /lib/ depmod -a Now I can mount folders on my Windows network with: mount -t cifs -o username=username,password= password //server/share /mnt/directory On Friday, August 30, 2013 9:49:57 AM UTC-5, Jim Bell wrote: Has anyone succeeded in getting a BeagleBone Black Angstrom to map a filesystem to any kind of server? NFS, CIFS/Samba, sshfs, other? Pointers? Thanks! -Jim -- 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/RE3I2uR1aL8/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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/RE3I2uR1aL8/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. -- *A. R. Ansari* -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Using GPIO's as SPI
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 javascript: 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 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 Ethernet Phy Not Detected on Boot.
Just found this thread, adding my 2cents. We are using kernel 3.8.13-bone30. We have seen many cases of ethernet issues, usually that the ethernet port does not come up at all (no lights). I would say it happens one out of every 20 boots. We are using a cape, but just to extend i/o and provide power. If anyone has any suggestions or kernel versions that work better, help would be greatly appreciated. I am currently working on a workaround to make the beaglebone detect the lack of ethernet and reboot itself, but this could lead to some really long boot times, and not having the problem at all would be much better! On Friday, May 30, 2014 4:40:50 AM UTC-7, pori...@gmail.com wrote: On Wednesday, March 19, 2014 8:52:36 PM UTC+1, RobertCNelson wrote: On Wed, Mar 19, 2014 at 2:47 PM, bko...@scanimetrics.com wrote: Does anyone happen to know if the 3.8 kernel compiled as per these instructions here http://eewiki.net/display/linuxonarm/BeagleBone+Black also contains the fix? I have a root file system already that I want to use but would like to update my kernel to fix this problem. Sorry, the fix is too generic of a term, therefore I can neither confirm nor deny it. Either way, that 3.8 branch listed is the one currently used in all debian/ubuntu images being shipped. I'm using 3.14.4 kernel (latest stable) - and 'the fix' doesn't seem to have been pushed there - could you give more information about what 'the fix' is? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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 Ethernet Phy Not Detected on Boot.
On Wed, Jun 4, 2014 at 4:20 PM, Eric ericpospi...@gmail.com wrote: Just found this thread, adding my 2cents. We are using kernel 3.8.13-bone30. We have seen many cases of ethernet issues, usually that the ethernet port does not come up at all (no lights). I would say it happens one out of every 20 boots. We are using a cape, but just to extend i/o and provide power. If anyone has any suggestions or kernel versions that work better, help would be greatly appreciated. I am currently working on a workaround to make the beaglebone detect the lack of ethernet and reboot itself, but this could lead to some really long boot times, and not having the problem at all would be much better! Well you should keep your 2cents if your running bone30, upgrade! ;) There's been a lot of fixes to the v3.8.x branch since Nov 2013. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not
John, You definitely make some good points, however... I don't really feel I missed the mark completely. So when you say 'developer', do you mean hobbyist or product developer. If you mean hobbyist, I understand your comments completely. If not, that's a totally different situation entirely. If you are developing a product for sale, then I have little sympathy / empathy / whatever for not wanting to deal with the technology required to build a product. It's not cheap, easy, simple, _ fill in any of a long list of adjectives to describe the difficultly of designing a product much less building a business around it to market and sell it. One is not entirely constrained by the BBB design in doing your own - see what comes below (When I say 'you' in my comments - it's not pointed at you John but a general you from the community standpoint) I personally don't see these as problems as I've been doing this my whole professional career. So, yes I'm probably trivializing some of this as I don't see any of these items as potential stumbling blocks. By the BBB statements of use - this is not for commercial use. Although I know from speaking with Gerald, that many are using this for commercial apps. That's also one of the reasons that the supply is being gobbled up. So for those of you out there that are complaining about not being able to get BBBs, blame those that are not following the licensing and terms of use and eating up the supply for their commercial needs versus developing their own board. Here's a thought for you Gerald, require your distributors/resellers to have a reverse discount model. So as the volume goes up, so does the price - this should discourage volume buys without the organization's consent, which you are suppose to have if using this product commercially, and would make the distributors happy by increasing their margins. Or would require a custom 'factory' price to get a volume purchase at a discount to get around this. This is done the other way around - via product/design registrations all the time in the electronics distribution model. Just a thought. So really it's suppose to be either for small non-commercial projects or using as a shortcut to figuring out what you need and don't to roll your own. It's not a one size fits all or trying to be everything to everybody - like a lot seem to think it is or should be. So really the capes and position of connectors, to me, are really a moot point as one is not suppose to be relying on this as a product platform. If it's not where you want or need for your product - roll your own. Embedded system design is not for the faint of heart. You need tools and a lot of patience to get it done - education, experience, and skill doesn't hurt either. If you don't have the tools or skills needed to leverage what Gerald and Co have done here, maybe as part of your business model, you should have some budget for tools and an engineer or hire a design house, um maybe like CircuitCo or another, to help fill the void. Just a thought. If you're just a hobbyist, then most of this discussion is moot, because you should just try to make what's available work or develop a much simpler cape to do what else you need. And if that doesn't work - you're back to roll your own - or find a different development platform that will support your needs. I even did a cape to vet out what I wanted to do before starting my design. So, use the resources available to you. Either using a SOM or not with this is probably not a project for a beginner. But this is also very far from the most complicated or demanding designs I've ever done. Even doing an I/O board is not trivial and that's the point I'm making. You still have a controlled impedance and probably controlled dielectric PCB to design and have fab'd. The I/O board will need to be a min of 4 layers to be able to control the impedances adequately and reliably. The diff pairs for the USB and Ethernet as well as the MII interface do require some work to get right - then there's the memory if you're not using the SOM. As far as the 3 mil min trace/space - the only part on their that needs this is the stupid eMMC. What a poor package design for this - following the JEDEC standard for the complete module was a poor choice - but I digress. I found a different package for my design so I didn't have to push the limits of reasonable board fabrication. My design is 5 mill trace / 4 mill space - could be 5 space if I wanted to spend a bunch more time working around the processor's BGA. But 5/4+ is good enough for me - some of that is legacy from leveraging the layout design / info from the BBB. My previous design was based on the BeagleBoard. That was a lot more complicated design the the BBB. But I rolled my own and went away from the POP and did a design that was 5/5 in 4 layers - so it is possible - just requires some effort. *Thanks Gerald
Re: [beagleboard] Apply a patch to 3.8.13-bone47 and recompile kernel
http://eewiki.net/display/linuxonarm/BeagleBone+Black On Thu, Jun 5, 2014 at 3:39 AM, Tristan Phillips tris.phill...@gmail.com wrote: Hooray I managed to take a flasher SD card, mount it on a Linux box and apply the patched kernel using tools/install_kernel.sh The flasher then successfully writes to the target BBB internal SD :) Robert, did you recommend working on a non flashing image to allow more customisation, in order to create a form of golden master? Installing packages and the like? Thank you all so much for the help :) Tris On Wednesday, 4 June 2014 19:20:43 UTC+1, Tristan Phillips wrote: Thank you :) On Wednesday, 4 June 2014 19:15:03 UTC+1, RobertCNelson wrote: On Wed, Jun 4, 2014 at 1:12 PM, Tristan Phillips tris.p...@gmail.com wrote: Nice one :) Yeap, and for a hint. Take the current non-flashing debian image - OK with Ubuntu too? With this one: (it's the exact same rsync based script as in debian) http://elinux.org/BeagleBoardUbuntu#BeagleBone.2FBeagleBone_Black install your kernel - by running tools/installkernel.sh on the pc with the SD card plugged in? yeap, or if you get stuck, look at: http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack- CopyKernelFiles for hints. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Using GPIO's as SPI
Sounds like fun. Good luck :) On Wed, Jun 4, 2014 at 2:17 PM, swapnes...@gmail.com 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+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] Reg BBB
hello world, Its great to find a place out of the many sites to let my queries get solved regarding the beaglebone black...Iam completely new to the world of BBB. Can any one brief a few things regarding the BBB?here are various things i knew and i need some details in depth. - The bbb has a 4gb 8 bit emmc onboard flash memory,,isn't it? the bbb has a micro sd card slot, how far this micro sd memory can be expanded? will it only support upto 4gb or even more?if so, how much? - how the data acquisition and data logging being done with beagle bone black? - how sampling is done and what is sampling rate? - is the data transfer takes place sequentially or simultaneowsly??if so why and how? - How long can the bbb work with an ordinaly 5v battery at max processing speed? - the 7analog input pins need voltage in the range upto 1.8v, how can i make sure that the data from sensors should be less than 1.8v? is there any down converter circuits available? - cant we do signal processing with bbb? i request anyone on the web to kindly show me some light in this regard..I am completely lost... please give any references. -- Best Regards, -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] I2C pull-ups while BBB is powered off
Hi everyone, I'm trying to interface a RTC with my BBB using the I2C bus. The reference manual states that none of the pins in the expansion connectors should be driven while the system is not powered on. I have isolated other inputs using tristate buffers and the SYS_RESETn, but the I2C lines, being bidirectional is a bit trickier. Is it necessary in this case to isolate the lines during power up? I'm connecting the pull-ups to the +3v3 pin on the expansion connector. If I should isolate the lines, what's the best method? I'm thinking of using a cmos switch to disconnect the resistors during power up, but maybe there are better ideas. Thnaks! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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] Rotate screen to portrait on QT (LCD 4D 7')
Hi, Could you point me where should I modify the compilation to build for X11? I am using this tutorial: http://www.cloud-rocket.com/2013/07/building-qt-for-beaglebone/ Is it a flag on ./configure? Best regards Em quarta-feira, 4 de junho de 2014 03h47min10s UTC-3, lisarden escreveu: it depends on how you build Qt sources. There are a number of options and you should explicitly specify if you want QWS or X11 support. You can't run applications built for QWS under X11 and vice versa 2014-06-04 7:02 GMT+04:00 Micka micka...@gmail.com javascript:: How did you got qws working? Normally qt on Debian is not compiled with qws... Am I wrong? Micka, On Jun 4, 2014 2:01 AM, Andersan Xiley anders...@gmail.com javascript: wrote: Hi, If I run withou qws, i got this error: root@beaglebone:~# ./App QWSSocket::connectToLocalFile could not connect:: No such file or directory QWSSocket::connectToLocalFile could not connect:: No such file or directory QWSSocket::connectToLocalFile could not connect:: No such file or directory QWSSocket::connectToLocalFile could not connect:: No such file or directory QWSSocket::connectToLocalFile could not connect:: No such file or directory QWSSocket::connectToLocalFile could not connect:: No such file or directory No Qt for Embedded Linux server appears to be running. If you want to run this program as a server, add the -qws command-line option. Thanks Em domingo, 1 de junho de 2014 11h49min01s UTC-3, lisarden escreveu: Run it without qws. Qws is a self-server mode. When you use x11 server then you don't need the qws option 01 Июн 2014 г. 4:23 пользователь Andersan Xiley anders...@gmail.com написал: Hi, I am able to rotate the screen using the following: opkg install xf86-video-fbdev xorg.conf is: Section Device Identifier Frame Buffer Driver fbdev OptionRotateCW EndSection But when I load my QT application, the screen do not rotate. I am loading the app using: pkill gdm ./App -qws Any idea? Regards -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@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...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- LinkedIn - http://www.linkedin.com/in/maximpodbereznyy Company - http://www.linkedin.com/company/mentorel Facebook - https://www.facebook.com/mentorel.company -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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] Reading an Analog input from a web page ?
Hello group; I am wondering if is possible to read an analog input on the BBB at the press of a button on a web page. I already have code that uses node.js and socket.io to turn on an LED in response to a button push. But I want to Read an input and display the result. Does anyone know how to do this ?? Thanks J http://www.packtpub.com/building-a-home-security-system-with-beaglebone/boo k http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't make pwm work on cape-universal
No need to modify cape-universal. Since I'm on the clock what I'll do is remove the pwm pins I need from cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm. I assume the published cape-universal .dts is in fact valid: https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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't make pwm work on cape-universal
On 6/5/2014 11:52 AM, maxmike wrote: No need to modify cape-universal. Since I'm on the clock what I'll do is remove the pwm pins I need from cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm. That will work, of course, but the whole reason I went through this exercise was to make it unnecessary for folks to fiddle with editing overlay files. I assume the published cape-universal .dts is in fact valid: https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universal-00A0.dts Yes, and if you're running one of RCN's recent Debian builds, this is already checked out for you in /opt/source/beaglebone-universal-io/. A git pull origin master will make sure you have the latest version. -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] I2C pull-ups while BBB is powered off
On 6/5/2014 10:47 AM, franciscoague...@gmail.com wrote: Hi everyone, I'm trying to interface a RTC with my BBB using the I2C bus. The reference manual states that none of the pins in the expansion connectors should be driven while the system is not powered on. I have isolated other inputs using tristate buffers and the SYS_RESETn, but the I2C lines, being bidirectional is a bit trickier. Is it necessary in this case to isolate the lines during power up? I'm connecting the pull-ups to the +3v3 pin on the expansion connector. If I should isolate the lines, what's the best method? I'm thinking of using a cmos switch to disconnect the resistors during power up, but maybe there are better ideas. A single FET per line will isolate the BeagleBone if power is off, and as a bonus will make the I2C inputs 5V tolerant. The basic circuit and theory of operation is described in section 18 of Version 2.1 of the I2C Specification (it's not in the newer 3.x versions of the spec). Basically, you tie the FET gate to the BBB I/O power rail, the source to the BBB I/O pin, and the drain to the high-voltage I2C signal (ie: pulled up to a non-zero value when the BBB is at 0V). -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] problem with connecting Beaglebone to the computer
My pc is running win7-32bit Ubuntu but both of them can't recognize. :-( -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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't make pwm work on cape-universal
On Thursday, June 5, 2014 10:12:01 AM UTC-7, Charles Steinkuehler wrote: On 6/5/2014 11:52 AM, maxmike wrote: No need to modify cape-universal. Since I'm on the clock what I'll do is remove the pwm pins I need from cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm. That will work, of course, but the whole reason I went through this exercise was to make it unnecessary for folks to fiddle with editing overlay files. Nevertheless, Charles - what you did brings a lot of rationality to the GPIO environment. And saves a whole lot of hassles in deciding what to assume about the rest of the pins. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not
From: CEinTX mpo...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Thursday, June 5, 2014 at 7:22 AM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not John, You definitely make some good points, however... I don't really feel I missed the mark completely. So when you say 'developer', do you mean hobbyist or product developer. If you mean hobbyist, I understand your comments completely. If not, that's a totally different situation entirely. If you are developing a product for sale, then I have little sympathy / empathy / whatever for not wanting to deal with the technology required to build a product. It's not cheap, easy, simple, _ fill in any of a long list of adjectives to describe the difficultly of designing a product much less building a business around it to market and sell it. One is not entirely constrained by the BBB design in doing your own - see what comes below (When I say 'you' in my comments - it's not pointed at you John but a general you from the community standpoint) I personally don't see these as problems as I've been doing this my whole professional career. So, yes I'm probably trivializing some of this as I don't see any of these items as potential stumbling blocks. By the BBB statements of use - this is not for commercial use. Although I know from speaking with Gerald, that many are using this for commercial apps. That's also one of the reasons that the supply is being gobbled up. So for those of you out there that are complaining about not being able to get BBBs, blame those that are not following the licensing and terms of use and eating up the supply for their commercial needs versus developing their own board. Here's a thought for you Gerald, require your distributors/resellers to have a reverse discount model. So as the volume goes up, so does the price - this should discourage volume buys without the organization's consent, which you are suppose to have if using this product commercially, and would make the distributors happy by increasing their margins. Or would require a custom 'factory' price to get a volume purchase at a discount to get around this. This is done the other way around - via product/design registrations all the time in the electronics distribution model. Just a thought. Gerald Co need to keep their costs as low as possible and this doesn¹t only refer to the cost of materials and labor, but also the cost of money. Therefor they need a consistent supply model with minimal supply interruptions because the last thing they need is to sit with large inventory when the demand dries up. Don¹t mess with pricing because there could be all kinds of unintended consequences. While the inventory shortfall is really irritating to most, it is because of the demand that is helping to keep the pricing down. Gerald has to manage a find balance between delayed delivery and maintaining demand volumes. Gerald Co are continuing to add resources to increase monthly volume and I think that is the best approach. So really it's suppose to be either for small non-commercial projects or using as a shortcut to figuring out what you need and don't to roll your own. It's not a one size fits all or trying to be everything to everybody - like a lot seem to think it is or should be. So really the capes and position of connectors, to me, are really a moot point as one is not suppose to be relying on this as a product platform. If it's not where you want or need for your product - roll your own. Embedded system design is not for the faint of heart. You need tools and a lot of patience to get it done - education, experience, and skill doesn't hurt either. If you don't have the tools or skills needed to leverage what Gerald and Co have done here, maybe as part of your business model, you should have some budget for tools and an engineer or hire a design house, um maybe like CircuitCo or another, to help fill the void. Just a thought. If you're just a hobbyist, then most of this discussion is moot, because you should just try to make what's available work or develop a much simpler cape to do what else you need. And if that doesn't work - you're back to roll your own - or find a different development platform that will support your needs. I even did a cape to vet out what I wanted to do before starting my design. So, use the resources available to you. Either using a SOM or not with this is probably not a project for a beginner. But this is also very far from the most complicated or demanding designs I've ever done. Even doing an I/O board is not trivial and that's the point I'm making. You still have a controlled impedance and probably controlled dielectric PCB to design and have fab'd. The I/O board will need to be a min of 4 layers to be able to control the impedances
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.
[beagleboard] Re: I2C pull-ups while BBB is powered off
Charles, Thanks for your response. I read the section you mentioned from the I2C standard and it seems that, for this to work properly, there has to be pull-up resistors on both sides of the FET, which doesn't solve my problem. Maybe I didn't understand something, but if I don't pull-up the I2C pins of the BBB, the lines will never go high, because the FET will be in its off state. I want to avoid pulling the I/O pins high before the BBB is fully powered on. On Thursday, June 5, 2014 12:47:53 PM UTC-3, Francisco Aguerre wrote: Hi everyone, I'm trying to interface a RTC with my BBB using the I2C bus. The reference manual states that none of the pins in the expansion connectors should be driven while the system is not powered on. I have isolated other inputs using tristate buffers and the SYS_RESETn, but the I2C lines, being bidirectional is a bit trickier. Is it necessary in this case to isolate the lines during power up? I'm connecting the pull-ups to the +3v3 pin on the expansion connector. If I should isolate the lines, what's the best method? I'm thinking of using a cmos switch to disconnect the resistors during power up, but maybe there are better ideas. Thnaks! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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: I2C pull-ups while BBB is powered off
You can use the internal pull-up resistors on the BBB if you don't want to put a pull-up resistor on the 'Bone side of the FET. In normal operation, the far-side (high-voltage) pull-up resistor will pull the BBB side high through the FET until the BBB side reaches the Vgs threashold voltage (around a volt for a typical logic-level FET). So the standard I2C pull-up resistor will pull the signal to around 2.3V, then the internal BBB pull-up only needs to pull the signal up the rest of the way. Since the node is now isolated by the FET from whatever is on the far side, there is minimal capacitance and the weak internal pull-up will work fine. Plus the signal is already above the input high level threshold voltage, so it really only needs to go all the way to 3.3V to provide additional noise immunity. On 6/5/2014 2:06 PM, Francisco Aguerre wrote: Charles, Thanks for your response. I read the section you mentioned from the I2C standard and it seems that, for this to work properly, there has to be pull-up resistors on both sides of the FET, which doesn't solve my problem. Maybe I didn't understand something, but if I don't pull-up the I2C pins of the BBB, the lines will never go high, because the FET will be in its off state. I want to avoid pulling the I/O pins high before the BBB is fully powered on. On Thursday, June 5, 2014 12:47:53 PM UTC-3, Francisco Aguerre wrote: Hi everyone, I'm trying to interface a RTC with my BBB using the I2C bus. The reference manual states that none of the pins in the expansion connectors should be driven while the system is not powered on. I have isolated other inputs using tristate buffers and the SYS_RESETn, but the I2C lines, being bidirectional is a bit trickier. Is it necessary in this case to isolate the lines during power up? I'm connecting the pull-ups to the +3v3 pin on the expansion connector. If I should isolate the lines, what's the best method? I'm thinking of using a cmos switch to disconnect the resistors during power up, but maybe there are better ideas. Thnaks! -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: I2C pull-ups while BBB is powered off
From: Francisco Aguerre franciscoague...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Thursday, June 5, 2014 at 12:06 PM To: beagleboard@googlegroups.com Subject: [beagleboard] Re: I2C pull-ups while BBB is powered off Charles, Thanks for your response. I read the section you mentioned from the I2C standard and it seems that, for this to work properly, there has to be pull-up resistors on both sides of the FET, which doesn't solve my problem. Maybe I didn't understand something, but if I don't pull-up the I2C pins of the BBB, the lines will never go high, because the FET will be in its off state. I want to avoid pulling the I/O pins high before the BBB is fully powered on. http://www.ti.com/product/TXS0102?keyMatch=txstisearch=Search-EN Regards, John On Thursday, June 5, 2014 12:47:53 PM UTC-3, Francisco Aguerre wrote: Hi everyone, I'm trying to interface a RTC with my BBB using the I2C bus. The reference manual states that none of the pins in the expansion connectors should be driven while the system is not powered on. I have isolated other inputs using tristate buffers and the SYS_RESETn, but the I2C lines, being bidirectional is a bit trickier. Is it necessary in this case to isolate the lines during power up? I'm connecting the pull-ups to the +3v3 pin on the expansion connector. If I should isolate the lines, what's the best method? I'm thinking of using a cmos switch to disconnect the resistors during power up, but maybe there are better ideas. Thnaks! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not
These pretty much already exist as a module check out gumstix which ave been around for quite some time. Eric On Thu, Jun 5, 2014 at 11:11 AM, John Syn john3...@gmail.com wrote: From: CEinTX mpo...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Thursday, June 5, 2014 at 7:22 AM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not John, You definitely make some good points, however... I don't really feel I missed the mark completely. So when you say 'developer', do you mean hobbyist or product developer. If you mean hobbyist, I understand your comments completely. If not, that's a totally different situation entirely. If you are developing a product for sale, then I have little sympathy / empathy / whatever for not wanting to deal with the technology required to build a product. It's not cheap, easy, simple, _ fill in any of a long list of adjectives to describe the difficultly of designing a product much less building a business around it to market and sell it. One is not entirely constrained by the BBB design in doing your own - see what comes below (When I say 'you' in my comments - it's not pointed at you John but a general you from the community standpoint) I personally don't see these as problems as I've been doing this my whole professional career. So, yes I'm probably trivializing some of this as I don't see any of these items as potential stumbling blocks. By the BBB statements of use - this is not for commercial use. Although I know from speaking with Gerald, that many are using this for commercial apps. That's also one of the reasons that the supply is being gobbled up. So for those of you out there that are complaining about not being able to get BBBs, blame those that are not following the licensing and terms of use and eating up the supply for their commercial needs versus developing their own board. Here's a thought for you Gerald, require your distributors/resellers to have a reverse discount model. So as the volume goes up, so does the price - this should discourage volume buys without the organization's consent, which you are suppose to have if using this product commercially, and would make the distributors happy by increasing their margins. Or would require a custom 'factory' price to get a volume purchase at a discount to get around this. This is done the other way around - via product/design registrations all the time in the electronics distribution model. Just a thought. Gerald Co need to keep their costs as low as possible and this doesn't only refer to the cost of materials and labor, but also the cost of money. Therefor they need a consistent supply model with minimal supply interruptions because the last thing they need is to sit with large inventory when the demand dries up. Don't mess with pricing because there could be all kinds of unintended consequences. While the inventory shortfall is really irritating to most, it is because of the demand that is helping to keep the pricing down. Gerald has to manage a find balance between delayed delivery and maintaining demand volumes. Gerald Co are continuing to add resources to increase monthly volume and I think that is the best approach. So really it's suppose to be either for small non-commercial projects or using as a shortcut to figuring out what you need and don't to roll your own. It's not a one size fits all or trying to be everything to everybody - like a lot seem to think it is or should be. So really the capes and position of connectors, to me, are really a moot point as one is not suppose to be relying on this as a product platform. If it's not where you want or need for your product - roll your own. Embedded system design is not for the faint of heart. You need tools and a lot of patience to get it done - education, experience, and skill doesn't hurt either. If you don't have the tools or skills needed to leverage what Gerald and Co have done here, maybe as part of your business model, you should have some budget for tools and an engineer or hire a design house, um maybe like CircuitCo or another, to help fill the void. Just a thought. If you're just a hobbyist, then most of this discussion is moot, because you should just try to make what's available work or develop a much simpler cape to do what else you need. And if that doesn't work - you're back to roll your own - or find a different development platform that will support your needs. I even did a cape to vet out what I wanted to do before starting my design. So, use the resources available to you. Either using a SOM or not with this is probably not a project for a beginner. But this is also very far from the most complicated or demanding designs I've ever done. Even doing an I/O board is not trivial and that's the point I'm making. You still have
Re: [beagleboard] Eclipse C and Remote Debugging
Yay, resolved, C/C++ remote debugging in eclipse now working! Thank you for all the help, in the end I changed the set-up of the virtualbox configuration, setting the network settings to: Bridged Adapter. I also installed: sudo apt-get install lib32ncurses5 Now it works perfrectly. Happy chappy! On Thursday, 5 June 2014 10:26:53 UTC+1, Jon wrote: Your virtualbox network is likely just using NAT, so to the BBB it will appear that the traffic is coming from the host computer. Agreeing with what Robert already said, I would start from the command line tools (gdb gdbserver) and work up. Regards, Jon On Thursday, 5 June 2014 07:35:03 UTC+1, Simon Platten wrote: Having thought about what is happening over night...I still don't understand why Remote debugging from host is 192.168.1.100 ??? I run Ubuntu 14.04 in Virtualbox on my Windows 7 x64 development system. The I/P addresses for the various components are as follows: Ubuntu, 10.1.174.100 Windows 7,192.168.1.100 Beaglebone Black, 192.168.1.161 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not
From: Eric Fort eric.f...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Thursday, June 5, 2014 at 12:56 PM To: beagleboard beagleboard@googlegroups.com Subject: Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not These pretty much already exist as a module check out gumstix which ave been around for quite some time. The best one I seen so far is this one from Maxim Podbereznyy in that it maintains compatibility to BBB. http://www.mentorel.com/product/usomiq-am335x/ Regards, John Eric On Thu, Jun 5, 2014 at 11:11 AM, John Syn john3...@gmail.com wrote: From: CEinTX mpo...@gmail.com Reply-To: beagleboard@googlegroups.com Date: Thursday, June 5, 2014 at 7:22 AM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not John, You definitely make some good points, however... I don't really feel I missed the mark completely. So when you say 'developer', do you mean hobbyist or product developer. If you mean hobbyist, I understand your comments completely. If not, that's a totally different situation entirely. If you are developing a product for sale, then I have little sympathy / empathy / whatever for not wanting to deal with the technology required to build a product. It's not cheap, easy, simple, _ fill in any of a long list of adjectives to describe the difficultly of designing a product much less building a business around it to market and sell it. One is not entirely constrained by the BBB design in doing your own - see what comes below (When I say 'you' in my comments - it's not pointed at you John but a general you from the community standpoint) I personally don't see these as problems as I've been doing this my whole professional career. So, yes I'm probably trivializing some of this as I don't see any of these items as potential stumbling blocks. By the BBB statements of use - this is not for commercial use. Although I know from speaking with Gerald, that many are using this for commercial apps. That's also one of the reasons that the supply is being gobbled up. So for those of you out there that are complaining about not being able to get BBBs, blame those that are not following the licensing and terms of use and eating up the supply for their commercial needs versus developing their own board. Here's a thought for you Gerald, require your distributors/resellers to have a reverse discount model. So as the volume goes up, so does the price - this should discourage volume buys without the organization's consent, which you are suppose to have if using this product commercially, and would make the distributors happy by increasing their margins. Or would require a custom 'factory' price to get a volume purchase at a discount to get around this. This is done the other way around - via product/design registrations all the time in the electronics distribution model. Just a thought. Gerald Co need to keep their costs as low as possible and this doesn¹t only refer to the cost of materials and labor, but also the cost of money. Therefor they need a consistent supply model with minimal supply interruptions because the last thing they need is to sit with large inventory when the demand dries up. Don¹t mess with pricing because there could be all kinds of unintended consequences. While the inventory shortfall is really irritating to most, it is because of the demand that is helping to keep the pricing down. Gerald has to manage a find balance between delayed delivery and maintaining demand volumes. Gerald Co are continuing to add resources to increase monthly volume and I think that is the best approach. So really it's suppose to be either for small non-commercial projects or using as a shortcut to figuring out what you need and don't to roll your own. It's not a one size fits all or trying to be everything to everybody - like a lot seem to think it is or should be. So really the capes and position of connectors, to me, are really a moot point as one is not suppose to be relying on this as a product platform. If it's not where you want or need for your product - roll your own. Embedded system design is not for the faint of heart. You need tools and a lot of patience to get it done - education, experience, and skill doesn't hurt either. If you don't have the tools or skills needed to leverage what Gerald and Co have done here, maybe as part of your business model, you should have some budget for tools and an engineer or hire a design house, um maybe like CircuitCo or another, to help fill the void. Just a thought. If you're just a hobbyist, then most of this discussion is moot, because you should just try to make what's available work or develop a much simpler cape to do what else you need. And if that doesn't work - you're back to roll
Re: [beagleboard] Can't make pwm work on cape-universal
On 6/5/2014 12:11 PM, Charles Steinkuehler wrote: On 6/5/2014 11:52 AM, maxmike wrote: No need to modify cape-universal. Since I'm on the clock what I'll do is remove the pwm pins I need from cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm. That will work, of course, but the whole reason I went through this exercise was to make it unnecessary for folks to fiddle with editing overlay files. OK, I got a chance to review this, and as I thought you just need to export the PWM channels so you can play with them via sysfs. Some details are available on the TI wiki: http://processors.wiki.ti.com/index.php/Linux_Core_PWM_User%27s_Guide Executive summary...as root: for PWM in 0 1 2 3 4 5 6 7 ; do echo $PWM /sys/class/pwm/export done ...and you'll have your period and duty files: find /sys/devices/ocp.*/ -name '*_ns' /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/period_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/period_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/period_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/duty_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/period_ns -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Beagleboard-xm avaliability
Hi, I'm looking for a Beagleboard-xm to buy in all distributors sugested by beagleboard.org (digikey, mouser, farnell etc) but there is no board avaliable to buy! The Beagleboard-xm has been discontinuated? Regards, -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Using GPIO's as SPI
Yes, I was talking about trying to do hard real-time data collection in a user-space program. If you look at the maximum interrupt latencies from other stuff running on the system, then you see just why PRUs are necessary to always meet your deadlines. Most of the time, a user-space program running mmap to access gpios will run up at Mhz speeds but every now and then one of your data samples might be 100 msec late because something else was running. That kind of irregular sampling makes an FFT worthless. (But there certainly are some slower speed control applications where that kind of latency is perfectly okay.) I have a program that runs the SPI0 port as a slave, and it can be clocked by the master SPI device at 12-16 MHz because my protocol never overflows the SPI FIFOs. I had to use mmap, so I could set SPI control registers in ways no Linux drivers support. On 6/5/2014 11:53 AM, Brandon I wrote: 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 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 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 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 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 mailto:beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Angstrom image is not booting to BBB
My BBB just flashed. I re-downloaded and extracted the image, remade the microSD image and flashed it. This was the 4th or 5th attempt, but it worked. I have no idea why this time worked and the others didn't. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from 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.
