Re: [beagleboard] Re: What happens on read/write conflict on the PRU scrartchpad?
Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off). Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad. In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere. Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : Hello Carlos, Thanks for sharing. Personally I'm always interested in what others are doing, and like to see progress reports. Not that anyone has to report anything to me personally, but I still like reading about what others are doing. I expect some day in the future I will be investing some time getting to know the PRU's as well. But as a hobby, I have the luxury of doing so, when I get around to it ;) Anyway, I've always found the PRUs interesting . . .maybe that will be my next pet project ? On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes carl...@gmail.com wrote: Hello everyone. This is just an update. I tried the direct connection mode but it is more suitable for syncing the two PRUs. Anyway, my previous approach will work. As Lenny said: In case that one PRU reads from the scratchpad and in the same cycle the other PRU writes to it, I am pretty sure that there will be no conflicts. It is the standard behaviour when you program sequential logic with a hardware description language. However, the read operation will yield the old data from the scratchpad, that is the ones from before the write operation. That's exactly what happens. no extra delays or any type of conflict. Thank you Lenny, and everyone else. Carlos Novaes PS: If it is of interest to someone here comes my test experiment: I had PRU0 and PRU1 with cycle register enabled and counting clock cycles. Over each iteration on a total of twenty, the cycle register was read and stored into one register from r0 to r19. This on both PRUs On PRU0 I also read r23 from scratch pad and the store its lower word (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle counting is 6 for each iteration. On PRU1 I store the lower word of r23 into the upper word of one of r0 to r19 (according to the iteration) and also increment r23 and store it on the scratchpad. Total cycle counting is 7 for each iteration. Then, on both PRUs, write r0 to r19 into the shared ram and signal the ARM. On the ARM side, wait for signals from PRU0 and PRU1, read the shared ram (data from both PRUs), calculate the cycle offset of each iteration and print the results. There are no stall on any PRU, all iteractions takes exactly 6 cycles on PRU0 and 7 cycles on PRU1. At each 7 iteractions, PRU0 will repeat the previous value of r23. Here comes the output from console: : PRU0:: PRU1: Value : Cycle : Cycle Offset ::Value : Cycle : Cycle Offset : 1 : 58960: -- ::1 : 16: -- : 2 : 58966: 6::2 : 23: 7: 3 : 58972: 6::3 : 30: 7: 4 : 58978: 6::4 : 37: 7: 5 : 58984: 6::5 : 44: 7: 6 : 58990: 6::6 : 51: 7: 7 : 58996: 6::7 : 58: 7: 7 : 59002: 6::8 : 65: 7: 8 : 59008: 6::9 : 72: 7: 9 : 59014: 6:: 10 : 79: 7: 10 : 59020: 6:: 11
Re: [beagleboard] Re: What happens on read/write conflict on the PRU scrartchpad?
*The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad.* *In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere.* I do not know git very well either. It's something I've been putting off for a while( learning about ), but eventually I think all software developers need to learn, and use git. It's been keeping me from sharing my current code for the project I'm working on, but it's currently a mess anyway heh ! I have not even updated my blog in a couple years . . . which has been on my mind too. Lots of energy to invest in such thing though - When you would rather be doing something else like learning some new software / hardware aspect, etc. I would not mind seeing your work sometime, but could not say when I would get the time to look. If a blog post or similar I probably read a couple a day so would not be a problem - But reading through, and understanding someones code . . . is another story. Especially since my ASM is very rusty, and my ARM ASM knowledge is non existent. On Thu, Aug 6, 2015 at 2:10 PM, Carlos Novaes carlos...@gmail.com wrote: Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off). Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad. In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere. Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : Hello Carlos, Thanks for sharing. Personally I'm always interested in what others are doing, and like to see progress reports. Not that anyone has to report anything to me personally, but I still like reading about what others are doing. I expect some day in the future I will be investing some time getting to know the PRU's as well. But as a hobby, I have the luxury of doing so, when I get around to it ;) Anyway, I've always found the PRUs interesting . . .maybe that will be my next pet project ? On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes carl...@gmail.com wrote: Hello everyone. This is just an update. I tried the direct connection mode but it is more suitable for syncing the two PRUs. Anyway, my previous approach will work. As Lenny said: In case that one PRU reads from the scratchpad and in the same cycle the other PRU writes to it, I am pretty sure that there will be no conflicts. It is the standard behaviour when you program sequential logic with a hardware description language. However, the read operation will yield the old data from the scratchpad, that is the ones from before the write operation. That's exactly what happens. no extra delays or any type of conflict. Thank you Lenny, and everyone else. Carlos Novaes PS: If it is of interest to someone here comes my test experiment: I had PRU0 and PRU1 with cycle register enabled and counting clock cycles. Over each iteration on a total of twenty, the cycle register was read and stored into one register from r0 to r19. This on both PRUs On PRU0 I also read r23 from scratch pad and the store its lower word (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle counting is 6 for each iteration. On PRU1 I store the lower word of r23 into the upper word of one of r0 to r19 (according to the iteration) and also increment r23 and store it on the scratchpad. Total cycle counting is 7 for each iteration. Then, on both PRUs, write r0 to r19 into the shared ram and signal the ARM. On the ARM side, wait for signals from PRU0 and PRU1, read the shared ram (data from both PRUs), calculate the cycle offset of each iteration and print the results. There are no stall on any PRU, all iteractions takes exactly 6 cycles on PRU0 and 7 cycles on PRU1. At each 7 iteractions, PRU0 will repeat the previous value of r23. Here comes the output from console: : PRU0
Re: [beagleboard] Re: What happens on read/write conflict on the PRU scrartchpad?
Can you help me, I've installed UHD but Uhd_find_devices and Uhd_probe nothing :( Please help On Fri, Aug 7, 2015 at 4:18 AM, William Hermans yyrk...@gmail.com wrote: *The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad.* *In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere.* I do not know git very well either. It's something I've been putting off for a while( learning about ), but eventually I think all software developers need to learn, and use git. It's been keeping me from sharing my current code for the project I'm working on, but it's currently a mess anyway heh ! I have not even updated my blog in a couple years . . . which has been on my mind too. Lots of energy to invest in such thing though - When you would rather be doing something else like learning some new software / hardware aspect, etc. I would not mind seeing your work sometime, but could not say when I would get the time to look. If a blog post or similar I probably read a couple a day so would not be a problem - But reading through, and understanding someones code . . . is another story. Especially since my ASM is very rusty, and my ARM ASM knowledge is non existent. On Thu, Aug 6, 2015 at 2:10 PM, Carlos Novaes carlos...@gmail.com wrote: Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off). Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad. In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere. Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : Hello Carlos, Thanks for sharing. Personally I'm always interested in what others are doing, and like to see progress reports. Not that anyone has to report anything to me personally, but I still like reading about what others are doing. I expect some day in the future I will be investing some time getting to know the PRU's as well. But as a hobby, I have the luxury of doing so, when I get around to it ;) Anyway, I've always found the PRUs interesting . . .maybe that will be my next pet project ? On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes carl...@gmail.com wrote: Hello everyone. This is just an update. I tried the direct connection mode but it is more suitable for syncing the two PRUs. Anyway, my previous approach will work. As Lenny said: In case that one PRU reads from the scratchpad and in the same cycle the other PRU writes to it, I am pretty sure that there will be no conflicts. It is the standard behaviour when you program sequential logic with a hardware description language. However, the read operation will yield the old data from the scratchpad, that is the ones from before the write operation. That's exactly what happens. no extra delays or any type of conflict. Thank you Lenny, and everyone else. Carlos Novaes PS: If it is of interest to someone here comes my test experiment: I had PRU0 and PRU1 with cycle register enabled and counting clock cycles. Over each iteration on a total of twenty, the cycle register was read and stored into one register from r0 to r19. This on both PRUs On PRU0 I also read r23 from scratch pad and the store its lower word (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle counting is 6 for each iteration. On PRU1 I store the lower word of r23 into the upper word of one of r0 to r19 (according to the iteration) and also increment r23 and store it on the scratchpad. Total cycle counting is 7 for each iteration. Then, on both PRUs, write r0 to r19 into the shared ram and signal the ARM. On the ARM side, wait for signals from PRU0 and PRU1, read the shared ram (data from both PRUs), calculate the cycle offset of each iteration and print the results. There are no stall on any PRU, all iteractions takes exactly 6 cycles on PRU0 and 7 cycles on PRU1. At each 7 iteractions, PRU0 will repeat the previous value of r23. Here comes the
Re: [beagleboard] Re: What happens on read/write conflict on the PRU scrartchpad?
Can you help me, I've installed UHD on beaglebone but Uhd_find_devices and Uhd_probe nothing :( Please help On Fri, Aug 7, 2015 at 4:41 AM, April Hutagaol april.hutag...@gmail.com wrote: Can you help me, I've installed UHD but Uhd_find_devices and Uhd_probe nothing :( Please help On Fri, Aug 7, 2015 at 4:18 AM, William Hermans yyrk...@gmail.com wrote: *The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad.* *In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere.* I do not know git very well either. It's something I've been putting off for a while( learning about ), but eventually I think all software developers need to learn, and use git. It's been keeping me from sharing my current code for the project I'm working on, but it's currently a mess anyway heh ! I have not even updated my blog in a couple years . . . which has been on my mind too. Lots of energy to invest in such thing though - When you would rather be doing something else like learning some new software / hardware aspect, etc. I would not mind seeing your work sometime, but could not say when I would get the time to look. If a blog post or similar I probably read a couple a day so would not be a problem - But reading through, and understanding someones code . . . is another story. Especially since my ASM is very rusty, and my ARM ASM knowledge is non existent. On Thu, Aug 6, 2015 at 2:10 PM, Carlos Novaes carlos...@gmail.com wrote: Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off). Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad. In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere. Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : Hello Carlos, Thanks for sharing. Personally I'm always interested in what others are doing, and like to see progress reports. Not that anyone has to report anything to me personally, but I still like reading about what others are doing. I expect some day in the future I will be investing some time getting to know the PRU's as well. But as a hobby, I have the luxury of doing so, when I get around to it ;) Anyway, I've always found the PRUs interesting . . .maybe that will be my next pet project ? On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes carl...@gmail.com wrote: Hello everyone. This is just an update. I tried the direct connection mode but it is more suitable for syncing the two PRUs. Anyway, my previous approach will work. As Lenny said: In case that one PRU reads from the scratchpad and in the same cycle the other PRU writes to it, I am pretty sure that there will be no conflicts. It is the standard behaviour when you program sequential logic with a hardware description language. However, the read operation will yield the old data from the scratchpad, that is the ones from before the write operation. That's exactly what happens. no extra delays or any type of conflict. Thank you Lenny, and everyone else. Carlos Novaes PS: If it is of interest to someone here comes my test experiment: I had PRU0 and PRU1 with cycle register enabled and counting clock cycles. Over each iteration on a total of twenty, the cycle register was read and stored into one register from r0 to r19. This on both PRUs On PRU0 I also read r23 from scratch pad and the store its lower word (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle counting is 6 for each iteration. On PRU1 I store the lower word of r23 into the upper word of one of r0 to r19 (according to the iteration) and also increment r23 and store it on the scratchpad. Total cycle counting is 7 for each iteration. Then, on both PRUs, write r0 to r19 into the shared ram and signal the ARM. On the ARM side, wait for signals from PRU0 and PRU1, read the shared ram (data from both PRUs), calculate the cycle offset of each iteration and print
[beagleboard] Dead Beaglebone black with usb but works with 5 V power cable
Hello I am a beginner. I had connected beaglebone black to my laptop over usb. After about 30 minutes, leds were powered off. now it is not powering up over usb. If i attach 5v power cable to it, it powers up but can't sign in using putty over ethernet. Every time it gives connection error and using this case, no drive for beaglebone black shows up in windows as it used to show with usb. I dont know what happened. can u please 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] CAD-Model for BBB?
Ah great...but it seems to generate a STEP model out of the Orcad file I need to buy there full version!? Does anybody have this software and can provide the STEP model here? 2015-08-06 15:47 GMT+02:00 Gerald Coley ger...@beagleboard.org: Check the support Wiki. http://www.elinux.org/Beagleboard:BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28C.29 Gerald On Thu, Aug 6, 2015 at 12:46 AM, Karl Karpfen karlkarpfe...@gmail.com wrote: Hi, is there a CAD-model available of the BBB and perhaps of one (standard) cape? 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. -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- 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/0XDpjH6rIdQ/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] Updated firmware files.
Anyway, yeah, not working. On Thu, Aug 6, 2015 at 5:07 PM, William Hermans yyrk...@gmail.com wrote: So . . . william@xanbustester:~$ lsmod Module Size Used by can_raw 0 can_dev11496 0 can26598 1 can_raw usb_f_ecm 9066 1 g_ether 4633 0 usb_f_rndis20474 2 g_ether u_ether10985 3 usb_f_ecm,usb_f_rndis,g_ether libcomposite 43358 3 usb_f_ecm,usb_f_rndis,g_ether tda998x11577 0 tilcdc 24624 0 omap_aes 12439 0 omap_sham 20563 0 omap_rng4264 0 drm_kms_helper103830 3 tda998x,tilcdc rng_core7113 1 omap_rng uio_pdrv_genirq 3321 0 uio 8146 1 uio_pdrv_genirq leds_gpio 3186 0 william@xanbustester:~$ uname -r 4.2.0-rc4-bone2 Searching the web . . . On Thu, Aug 6, 2015 at 4:56 PM, William Hermans yyrk...@gmail.com wrote: Was reading through the older testers wanted posts . . . sudo apt-get install bb-customizations sudo apt-get install device-tree-compiler git clone https://github.com/RobertCNelson/bb.org-overlays cd ./bb.org-overlays/ sudo ./install.sh sudo shutdown now -r /* board hung, had to walk to it and yank power*/ cat /sys/devices/platform/bone_capemgr/slots 0: P- -1 cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial 1: PF -1 2: PF -1 3: PF -1 sudo modprobe can sudo modprobe can-dev sudo modprobe can-raw sudo ip link set can0 type can bitrate 25 triple-sampling on Cannot find device can0 sudo ip link set can1 type can bitrate 25 triple-sampling on Cannot find device can1 Odd . . . maybe the CAN port is not currently plugged in. But shouldn't the port at least acknowledge it's there ? To be continued . . . On Thu, Aug 6, 2015 at 4:14 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 6:12 PM, William Hermans yyrk...@gmail.com wrote: Hey Robert if you have the time . . . If I need to install dtbo files ( specifically for the Logic Supply serial /CAN cape ) Which files / deb am I looking for ? I haven't packaged them yet... https://github.com/beagleboard/bb.org-overlays Long story short, I've update my older nfsroot rootfs via adding your repo, apt-get install linux-image-4.2.xxx, editing uEnv.txt, and running depmod. Also since I'm using a single uEnv.txt setup instead of a two stage . . . I can emulate cmdline with no ill effects ? Correct! Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Updated firmware files.
Was reading through the older testers wanted posts . . . sudo apt-get install bb-customizations sudo apt-get install device-tree-compiler git clone https://github.com/RobertCNelson/bb.org-overlays cd ./bb.org-overlays/ sudo ./install.sh sudo shutdown now -r /* board hung, had to walk to it and yank power*/ cat /sys/devices/platform/bone_capemgr/slots 0: P- -1 cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial 1: PF -1 2: PF -1 3: PF -1 sudo modprobe can sudo modprobe can-dev sudo modprobe can-raw sudo ip link set can0 type can bitrate 25 triple-sampling on Cannot find device can0 sudo ip link set can1 type can bitrate 25 triple-sampling on Cannot find device can1 Odd . . . maybe the CAN port is not currently plugged in. But shouldn't the port at least acknowledge it's there ? To be continued . . . On Thu, Aug 6, 2015 at 4:14 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 6:12 PM, William Hermans yyrk...@gmail.com wrote: Hey Robert if you have the time . . . If I need to install dtbo files ( specifically for the Logic Supply serial /CAN cape ) Which files / deb am I looking for ? I haven't packaged them yet... https://github.com/beagleboard/bb.org-overlays Long story short, I've update my older nfsroot rootfs via adding your repo, apt-get install linux-image-4.2.xxx, editing uEnv.txt, and running depmod. Also since I'm using a single uEnv.txt setup instead of a two stage . . . I can emulate cmdline with no ill effects ? Correct! Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Updated firmware files.
On Thu, Aug 6, 2015 at 7:38 PM, William Hermans yyrk...@gmail.com wrote: Anyway, yeah, not working. is it showing up under: sudo ifconfig -a ?? i've been mostly testing on the v4.1.x-ti branch, so something might have broke on mainline.. Do the other 2 serial ports show up? dmesg | grep serial Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: What happens on read/write conflict on the PRU scrartchpad?
Ah ok software radio, gnuradio etc. But yes like Carlos said start a new topic of your own. On Thu, Aug 6, 2015 at 6:31 PM, William Hermans yyrk...@gmail.com wrote: Ultra High Definition Television ? Pretty sure the BBB can not do 4k video . . . On Thu, Aug 6, 2015 at 5:30 PM, Carlos Novaes carlos...@gmail.com wrote: I don´t know UHD. If there are any usb device connected, lsusb and dmesg will show it. You better start a new and specific topic anyway. Le jeudi 6 août 2015 18:41:32 UTC-3, April Hutagaol a écrit : Can you help me, I've installed UHD but Uhd_find_devices and Uhd_probe nothing :( Please help On Fri, Aug 7, 2015 at 4:18 AM, William Hermans yyr...@gmail.com wrote: *The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad.* *In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere.* I do not know git very well either. It's something I've been putting off for a while( learning about ), but eventually I think all software developers need to learn, and use git. It's been keeping me from sharing my current code for the project I'm working on, but it's currently a mess anyway heh ! I have not even updated my blog in a couple years . . . which has been on my mind too. Lots of energy to invest in such thing though - When you would rather be doing something else like learning some new software / hardware aspect, etc. I would not mind seeing your work sometime, but could not say when I would get the time to look. If a blog post or similar I probably read a couple a day so would not be a problem - But reading through, and understanding someones code . . . is another story. Especially since my ASM is very rusty, and my ARM ASM knowledge is non existent. On Thu, Aug 6, 2015 at 2:10 PM, Carlos Novaes carl...@gmail.com wrote: Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off). Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad. In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere. Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : Hello Carlos, Thanks for sharing. Personally I'm always interested in what others are doing, and like to see progress reports. Not that anyone has to report anything to me personally, but I still like reading about what others are doing. I expect some day in the future I will be investing some time getting to know the PRU's as well. But as a hobby, I have the luxury of doing so, when I get around to it ;) Anyway, I've always found the PRUs interesting . . .maybe that will be my next pet project ? On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes carl...@gmail.com wrote: Hello everyone. This is just an update. I tried the direct connection mode but it is more suitable for syncing the two PRUs. Anyway, my previous approach will work. As Lenny said: In case that one PRU reads from the scratchpad and in the same cycle the other PRU writes to it, I am pretty sure that there will be no conflicts. It is the standard behaviour when you program sequential logic with a hardware description language. However, the read operation will yield the old data from the scratchpad, that is the ones from before the write operation. That's exactly what happens. no extra delays or any type of conflict. Thank you Lenny, and everyone else. Carlos Novaes PS: If it is of interest to someone here comes my test experiment: I had PRU0 and PRU1 with cycle register enabled and counting clock cycles. Over each iteration on a total of twenty, the cycle register was read and stored into one register from r0 to r19. This on both PRUs On PRU0 I also read r23 from scratch pad and the store its lower word (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle counting is 6 for each iteration. On PRU1 I store the lower word of r23 into the upper word of one of r0 to r19 (according to the
Re: [beagleboard] Re: What happens on read/write conflict on the PRU scrartchpad?
I don´t know UHD. If there are any usb device connected, lsusb and dmesg will show it. You better start a new and specific topic anyway. Le jeudi 6 août 2015 18:41:32 UTC-3, April Hutagaol a écrit : Can you help me, I've installed UHD but Uhd_find_devices and Uhd_probe nothing :( Please help On Fri, Aug 7, 2015 at 4:18 AM, William Hermans yyr...@gmail.com javascript: wrote: *The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad.* *In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere.* I do not know git very well either. It's something I've been putting off for a while( learning about ), but eventually I think all software developers need to learn, and use git. It's been keeping me from sharing my current code for the project I'm working on, but it's currently a mess anyway heh ! I have not even updated my blog in a couple years . . . which has been on my mind too. Lots of energy to invest in such thing though - When you would rather be doing something else like learning some new software / hardware aspect, etc. I would not mind seeing your work sometime, but could not say when I would get the time to look. If a blog post or similar I probably read a couple a day so would not be a problem - But reading through, and understanding someones code . . . is another story. Especially since my ASM is very rusty, and my ARM ASM knowledge is non existent. On Thu, Aug 6, 2015 at 2:10 PM, Carlos Novaes carl...@gmail.com javascript: wrote: Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off). Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad. In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere. Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : Hello Carlos, Thanks for sharing. Personally I'm always interested in what others are doing, and like to see progress reports. Not that anyone has to report anything to me personally, but I still like reading about what others are doing. I expect some day in the future I will be investing some time getting to know the PRU's as well. But as a hobby, I have the luxury of doing so, when I get around to it ;) Anyway, I've always found the PRUs interesting . . .maybe that will be my next pet project ? On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes carl...@gmail.com wrote: Hello everyone. This is just an update. I tried the direct connection mode but it is more suitable for syncing the two PRUs. Anyway, my previous approach will work. As Lenny said: In case that one PRU reads from the scratchpad and in the same cycle the other PRU writes to it, I am pretty sure that there will be no conflicts. It is the standard behaviour when you program sequential logic with a hardware description language. However, the read operation will yield the old data from the scratchpad, that is the ones from before the write operation. That's exactly what happens. no extra delays or any type of conflict. Thank you Lenny, and everyone else. Carlos Novaes PS: If it is of interest to someone here comes my test experiment: I had PRU0 and PRU1 with cycle register enabled and counting clock cycles. Over each iteration on a total of twenty, the cycle register was read and stored into one register from r0 to r19. This on both PRUs On PRU0 I also read r23 from scratch pad and the store its lower word (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle counting is 6 for each iteration. On PRU1 I store the lower word of r23 into the upper word of one of r0 to r19 (according to the iteration) and also increment r23 and store it on the scratchpad. Total cycle counting is 7 for each iteration. Then, on both PRUs, write r0 to r19 into the shared ram and signal the ARM. On the ARM side, wait for signals from PRU0 and PRU1, read
Re: [beagleboard] Updated firmware files.
Second thought, I may just pull in a 4.1.x image and go with that. If you have one that does not reboot that often . . . dahm board already auto booted . . . Unless you want me to check this one out just for informational purposes. On Thu, Aug 6, 2015 at 6:04 PM, William Hermans yyrk...@gmail.com wrote: By older I mean something in the range of 4.1.x lol I have found they're much faster than the older image I was currently working with. *bone47 On Thu, Aug 6, 2015 at 6:03 PM, William Hermans yyrk...@gmail.com wrote: *is it showing up under:* * sudo ifconfig -a ??* No. *i've been mostly testing on the v4.1.x-ti branch, so something might* * have broke on mainline..* * Do the other 2 serial ports show up?* * dmesg | grep serial* william@xanbustester:~$ dmesg |grep serial [2.803479] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 154, base_baud = 300) is a 8250 Robert, Give me a bit to make sure this is not my fault. First - william@xanbustester:~$ dtc -v Version: DTC 1.4.0 So this is the wrong version. Had to hack together /opt/scripts from an older wheezy 7.8 image, but I've got it in place now. About to start over from installing dtc. Also, I installed canutils *before* putting this image on the board in question. I kind of doubt that is the problem, but not discounting that possibility. So yeah give me a little bit to poke around, and if it's not going to work . . .feel free to recommend me an older more suitable image. It'll be a slight hassle to go into uEnv.txt to make changes, and run depmod, but honestly thats all pretty easy . . . It will be harder to slim down the image again and uh . . . other stuff. On Thu, Aug 6, 2015 at 5:40 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 7:38 PM, William Hermans yyrk...@gmail.com wrote: Anyway, yeah, not working. is it showing up under: sudo ifconfig -a ?? i've been mostly testing on the v4.1.x-ti branch, so something might have broke on mainline.. Do the other 2 serial ports show up? dmesg | grep serial Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] OpenGL and BBB - simple HelloTriangle example
The files are located at: http://www.dcbcyber.com/tmp/src.tar.gz or http://www.dcbcyber.com/tmp/src.zip Originally this did more than what you are asking for. I had Bullet physics doing ray casting and collision detection and OpenAL playing sounds. I also had two rooms connected by a corridor. Unfortunately I seem to have lost my media files that I created. Without drawing the meshes it should still load up and draw a cross hair in the middle of the screen. I also included a line you can uncomment that should turn the cross hair into a triangle. I commented out the code for physics, sound, world loading, and input and movement. Feel free to play with that stuff if you feel like it. The code is messy. I never got around to cleaning up or finishing. If it doesn't work let me know. I will help as much as I can. I no longer have a Beagleboard. I don't have a BBB but I might get one. I do have a Pandaboard which is similar. David. On Thu, 8/6/15, John London john.tip...@blackkitetechnology.com wrote: Subject: Re: [beagleboard] OpenGL and BBB - simple HelloTriangle example To: BeagleBoard beagleboard@googlegroups.com Cc: n2...@yahoo.com Date: Thursday, August 6, 2015, 11:09 AM David, thank you very much indeed, that would be extremely helpful! On Thursday, August 6, 2015 at 3:05:27 PM UTC+1, davidcb wrote: At home I have a very simple program I wrote for the Beagleboard that does what you are trying to do. I think it should compile for the BBB fairly easily. When I get home later this evening I can find it and send it to you. On Thursday, August 6, 2015 8:18 AM, John London john@ blackkitetechnology.com wrote: I'm trying to get a simple example (Hello Triangle) working with BBB running Debian. I do NOT want to run the example under X11 - I want to run it from the command line. I do not want to use GLUT; I think this means it uses the framebuffer. Is this possible and does anyone have an example of how to do this please? I have been trying to use the example below, taken directly from the Examples directory of the PowerVR SDK. When I run the compiled program, I get an error: libEGL warning: DRI2: xcb_connect failed libEGL warning: DRI2: xcb_connect failed Failed to initialise the EGLDisplay Is the code trying to make a connection to X11 perhaps? I am using the Makefile and code below. # # File Makefile # Title Makes the demo # Author PowerVR # # Copyright Copyright (C) by Imagination Technologies Limited. # .PHONY: clean SDKDIR = $(shell cd ../../../../../.. pwd) VPATH = ../.. CROSS_COMPILE ?= arm-linux-gnueabihf- ifdef TOOLCHAIN PLAT_CC = $(TOOLCHAIN)/bin/$(CROSS_ COMPILE)gcc PLAT_CPP = $(TOOLCHAIN)/bin/$(CROSS_ COMPILE)g++ PLAT_AR = $(TOOLCHAIN)/bin/$(CROSS_ COMPILE)ar else PLAT_CC = $(CROSS_COMPILE)gcc PLAT_CPP = $(CROSS_COMPILE)g++ PLAT_AR = $(CROSS_COMPILE)ar endif ifeq $(X11BUILD) 1 ifndef X11ROOT $(error When building an X11 BUILD you must set X11ROOT to point at the location where your X11 headers and libs can be found.) endif ifeq $(EWSBUILD) 1 $(error Cannot have both X11BUILD and EWSBUILD enabled at the same time) endif WS_LIBS = -L$(X11ROOT)/lib -lX11 -lXau -ldl WS_RPATH = $(X11ROOT)/lib WS_INC = $(X11ROOT)/include WS = X11 else ifeq $(EWSBUILD) 1 PLAT_CFLAGS += -DEWS WS_LIBS = -lews WS_INC = WS=EWS else ifeq $(DRMBUILD) 1 ifndef DRMROOT $(error When building a DRM BUILD you must set DRMROOT to point at the location where your DRM headers and libs can be found.) endif WS_LIBS = -L$(DRMROOT)/lib -ldrm -lgbm -ludev -ldl -Wl,--rpath-link,$(DRMROOT)/li b WS_INC = $(DRMROOT)/include $(DRMROOT)/include/libdrm $(DRMROOT)/include/gbm WS=DRM else WS_LIBS = WS_INC = WS = NullWS endif endif endif LIBDIR ?= $(SDKDIR)/Builds/Linux/armv7hf /Lib LIBDIR_FLAGS = -L$(LIBDIR) -Wl,--rpath-link,$(LIBDIR):$(W S_RPATH) ifdef Debug DEBUG_RELEASE = Debug PLAT_CFLAGS += -g else DEBUG_RELEASE = Release PLAT_CFLAGS += -O2 endif PLAT_CFLAGS += -Wall -march=armv7 -mfloat-abi=hard PLAT_INC = $(SDKDIR)/Builds/Include $(WS_INC) PLAT_OBJPATH = $(DEBUG_RELEASE)$(WS) PLAT_LINK = $(LIBDIR_FLAGS) -lEGL -lGLESv2 $(WS_LIBS) -L$(TOOLCHAIN)/lib -march=armv7 -mfloat-abi=hard ifeq $(WS) X11 SRCNAME = OGLES2HelloAPI_LinuxX11 else ifeq $(WS) EWS SRCNAME = OGLES2HelloAPI_EWS else ifeq $(WS) DRM SRCNAME = OGLES2HelloAPI_LinuxDRM else SRCNAME = OGLES2HelloAPI_NullWS endif endif endif OUTNAME = OGLES2HelloAPI OBJECTS = $(PLAT_OBJPATH)/$(SRCNAME).o COMMON_INCLUDES = $(addprefix - ... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [beagleboard] Updated firmware files.
*is it showing up under:* * sudo ifconfig -a ??* No. *i've been mostly testing on the v4.1.x-ti branch, so something might* * have broke on mainline..* * Do the other 2 serial ports show up?* * dmesg | grep serial* william@xanbustester:~$ dmesg |grep serial [2.803479] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 154, base_baud = 300) is a 8250 Robert, Give me a bit to make sure this is not my fault. First - william@xanbustester:~$ dtc -v Version: DTC 1.4.0 So this is the wrong version. Had to hack together /opt/scripts from an older wheezy 7.8 image, but I've got it in place now. About to start over from installing dtc. Also, I installed canutils *before* putting this image on the board in question. I kind of doubt that is the problem, but not discounting that possibility. So yeah give me a little bit to poke around, and if it's not going to work . . .feel free to recommend me an older more suitable image. It'll be a slight hassle to go into uEnv.txt to make changes, and run depmod, but honestly thats all pretty easy . . . It will be harder to slim down the image again and uh . . . other stuff. On Thu, Aug 6, 2015 at 5:40 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 7:38 PM, William Hermans yyrk...@gmail.com wrote: Anyway, yeah, not working. is it showing up under: sudo ifconfig -a ?? i've been mostly testing on the v4.1.x-ti branch, so something might have broke on mainline.. Do the other 2 serial ports show up? dmesg | grep serial Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Updated firmware files.
By older I mean something in the range of 4.1.x lol I have found they're much faster than the older image I was currently working with. *bone47 On Thu, Aug 6, 2015 at 6:03 PM, William Hermans yyrk...@gmail.com wrote: *is it showing up under:* * sudo ifconfig -a ??* No. *i've been mostly testing on the v4.1.x-ti branch, so something might* * have broke on mainline..* * Do the other 2 serial ports show up?* * dmesg | grep serial* william@xanbustester:~$ dmesg |grep serial [2.803479] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 154, base_baud = 300) is a 8250 Robert, Give me a bit to make sure this is not my fault. First - william@xanbustester:~$ dtc -v Version: DTC 1.4.0 So this is the wrong version. Had to hack together /opt/scripts from an older wheezy 7.8 image, but I've got it in place now. About to start over from installing dtc. Also, I installed canutils *before* putting this image on the board in question. I kind of doubt that is the problem, but not discounting that possibility. So yeah give me a little bit to poke around, and if it's not going to work . . .feel free to recommend me an older more suitable image. It'll be a slight hassle to go into uEnv.txt to make changes, and run depmod, but honestly thats all pretty easy . . . It will be harder to slim down the image again and uh . . . other stuff. On Thu, Aug 6, 2015 at 5:40 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 7:38 PM, William Hermans yyrk...@gmail.com wrote: Anyway, yeah, not working. is it showing up under: sudo ifconfig -a ?? i've been mostly testing on the v4.1.x-ti branch, so something might have broke on mainline.. Do the other 2 serial ports show up? dmesg | grep serial Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Updated firmware files.
On Thu, Aug 6, 2015 at 6:12 PM, William Hermans yyrk...@gmail.com wrote: Hey Robert if you have the time . . . If I need to install dtbo files ( specifically for the Logic Supply serial /CAN cape ) Which files / deb am I looking for ? I haven't packaged them yet... https://github.com/beagleboard/bb.org-overlays Long story short, I've update my older nfsroot rootfs via adding your repo, apt-get install linux-image-4.2.xxx, editing uEnv.txt, and running depmod. Also since I'm using a single uEnv.txt setup instead of a two stage . . . I can emulate cmdline with no ill effects ? Correct! Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Updated firmware files.
So . . . william@xanbustester:~$ lsmod Module Size Used by can_raw 0 can_dev11496 0 can26598 1 can_raw usb_f_ecm 9066 1 g_ether 4633 0 usb_f_rndis20474 2 g_ether u_ether10985 3 usb_f_ecm,usb_f_rndis,g_ether libcomposite 43358 3 usb_f_ecm,usb_f_rndis,g_ether tda998x11577 0 tilcdc 24624 0 omap_aes 12439 0 omap_sham 20563 0 omap_rng4264 0 drm_kms_helper103830 3 tda998x,tilcdc rng_core7113 1 omap_rng uio_pdrv_genirq 3321 0 uio 8146 1 uio_pdrv_genirq leds_gpio 3186 0 william@xanbustester:~$ uname -r 4.2.0-rc4-bone2 Searching the web . . . On Thu, Aug 6, 2015 at 4:56 PM, William Hermans yyrk...@gmail.com wrote: Was reading through the older testers wanted posts . . . sudo apt-get install bb-customizations sudo apt-get install device-tree-compiler git clone https://github.com/RobertCNelson/bb.org-overlays cd ./bb.org-overlays/ sudo ./install.sh sudo shutdown now -r /* board hung, had to walk to it and yank power*/ cat /sys/devices/platform/bone_capemgr/slots 0: P- -1 cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial 1: PF -1 2: PF -1 3: PF -1 sudo modprobe can sudo modprobe can-dev sudo modprobe can-raw sudo ip link set can0 type can bitrate 25 triple-sampling on Cannot find device can0 sudo ip link set can1 type can bitrate 25 triple-sampling on Cannot find device can1 Odd . . . maybe the CAN port is not currently plugged in. But shouldn't the port at least acknowledge it's there ? To be continued . . . On Thu, Aug 6, 2015 at 4:14 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 6:12 PM, William Hermans yyrk...@gmail.com wrote: Hey Robert if you have the time . . . If I need to install dtbo files ( specifically for the Logic Supply serial /CAN cape ) Which files / deb am I looking for ? I haven't packaged them yet... https://github.com/beagleboard/bb.org-overlays Long story short, I've update my older nfsroot rootfs via adding your repo, apt-get install linux-image-4.2.xxx, editing uEnv.txt, and running depmod. Also since I'm using a single uEnv.txt setup instead of a two stage . . . I can emulate cmdline with no ill effects ? Correct! Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Updated firmware files.
Hey Robert if you have the time . . . If I need to install dtbo files ( specifically for the Logic Supply serial /CAN cape ) Which files / deb am I looking for ? Long story short, I've update my older nfsroot rootfs via adding your repo, apt-get install linux-image-4.2.xxx, editing uEnv.txt, and running depmod. Also since I'm using a single uEnv.txt setup instead of a two stage . . . I can emulate cmdline with no ill effects ? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: What happens on read/write conflict on the PRU scrartchpad?
Ultra High Definition Television ? Pretty sure the BBB can not do 4k video . . . On Thu, Aug 6, 2015 at 5:30 PM, Carlos Novaes carlos...@gmail.com wrote: I don´t know UHD. If there are any usb device connected, lsusb and dmesg will show it. You better start a new and specific topic anyway. Le jeudi 6 août 2015 18:41:32 UTC-3, April Hutagaol a écrit : Can you help me, I've installed UHD but Uhd_find_devices and Uhd_probe nothing :( Please help On Fri, Aug 7, 2015 at 4:18 AM, William Hermans yyr...@gmail.com wrote: *The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad.* *In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere.* I do not know git very well either. It's something I've been putting off for a while( learning about ), but eventually I think all software developers need to learn, and use git. It's been keeping me from sharing my current code for the project I'm working on, but it's currently a mess anyway heh ! I have not even updated my blog in a couple years . . . which has been on my mind too. Lots of energy to invest in such thing though - When you would rather be doing something else like learning some new software / hardware aspect, etc. I would not mind seeing your work sometime, but could not say when I would get the time to look. If a blog post or similar I probably read a couple a day so would not be a problem - But reading through, and understanding someones code . . . is another story. Especially since my ASM is very rusty, and my ARM ASM knowledge is non existent. On Thu, Aug 6, 2015 at 2:10 PM, Carlos Novaes carl...@gmail.com wrote: Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off). Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : The Prus are pretty powerfull for driving the io pins and their deterministic nature are very useful. But it was a little hard for me to learn each topic. Gpio access, interrupts, memory mapping and the scratchpad. In the process of learning, I have written a small library, I called it libpru. It is composed of pru assembly include file and c++ counterpart for the arm processor. Maybe it can be useful to other people, I do not know git very well but maybe I will uploaded it somewhere. Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : Hello Carlos, Thanks for sharing. Personally I'm always interested in what others are doing, and like to see progress reports. Not that anyone has to report anything to me personally, but I still like reading about what others are doing. I expect some day in the future I will be investing some time getting to know the PRU's as well. But as a hobby, I have the luxury of doing so, when I get around to it ;) Anyway, I've always found the PRUs interesting . . .maybe that will be my next pet project ? On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes carl...@gmail.com wrote: Hello everyone. This is just an update. I tried the direct connection mode but it is more suitable for syncing the two PRUs. Anyway, my previous approach will work. As Lenny said: In case that one PRU reads from the scratchpad and in the same cycle the other PRU writes to it, I am pretty sure that there will be no conflicts. It is the standard behaviour when you program sequential logic with a hardware description language. However, the read operation will yield the old data from the scratchpad, that is the ones from before the write operation. That's exactly what happens. no extra delays or any type of conflict. Thank you Lenny, and everyone else. Carlos Novaes PS: If it is of interest to someone here comes my test experiment: I had PRU0 and PRU1 with cycle register enabled and counting clock cycles. Over each iteration on a total of twenty, the cycle register was read and stored into one register from r0 to r19. This on both PRUs On PRU0 I also read r23 from scratch pad and the store its lower word (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle counting is 6 for each iteration. On PRU1 I store the lower word of r23 into the upper word of one of r0 to r19 (according to the iteration) and also increment r23 and store it on the scratchpad. Total cycle counting is 7 for each iteration. Then, on both PRUs, write r0 to r19 into the shared ram and
Re: [beagleboard] Updated firmware files.
hah ! What an idiot I am! william@xanbustester:~$ dtc -v Version: DTC 1.4.1-g8b4fb3be william@xanbustester:~$ cat /sys/devices/platform/bone_capemgr/slots 0: P---L- 1 cape-CBB-Serial,r01,Logic Supply,cape-CBB-Serial 1: PF -1 2: PF -1 3: PF -1 william@xanbustester:~$ sudo modprobe can [sudo] password for william: william@xanbustester:~$ sudo modprobe can-dev william@xanbustester:~$ sudo modprobe can-raw william@xanbustester:~$ sudo ip link set can0 type can bitrate 25 triple-sampling on william@xanbustester:~$ sudo ifconfig can0 can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:182 All because of wrong dtc version. And the silent fail when loading, but not showing L for *cat /sys/devices/platform/bone_capemgr/slots* under the device kind of gave me a clue . . . By the way Robert, don't ask me why I felt compelled to pull in opt/scripts . . . heh only needed overlay.sh and install.sh and had those already from previous steps . . . On Thu, Aug 6, 2015 at 6:18 PM, William Hermans yyrk...@gmail.com wrote: Second thought, I may just pull in a 4.1.x image and go with that. If you have one that does not reboot that often . . . dahm board already auto booted . . . Unless you want me to check this one out just for informational purposes. On Thu, Aug 6, 2015 at 6:04 PM, William Hermans yyrk...@gmail.com wrote: By older I mean something in the range of 4.1.x lol I have found they're much faster than the older image I was currently working with. *bone47 On Thu, Aug 6, 2015 at 6:03 PM, William Hermans yyrk...@gmail.com wrote: *is it showing up under:* * sudo ifconfig -a ??* No. *i've been mostly testing on the v4.1.x-ti branch, so something might* * have broke on mainline..* * Do the other 2 serial ports show up?* * dmesg | grep serial* william@xanbustester:~$ dmesg |grep serial [2.803479] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 154, base_baud = 300) is a 8250 Robert, Give me a bit to make sure this is not my fault. First - william@xanbustester:~$ dtc -v Version: DTC 1.4.0 So this is the wrong version. Had to hack together /opt/scripts from an older wheezy 7.8 image, but I've got it in place now. About to start over from installing dtc. Also, I installed canutils *before* putting this image on the board in question. I kind of doubt that is the problem, but not discounting that possibility. So yeah give me a little bit to poke around, and if it's not going to work . . .feel free to recommend me an older more suitable image. It'll be a slight hassle to go into uEnv.txt to make changes, and run depmod, but honestly thats all pretty easy . . . It will be harder to slim down the image again and uh . . . other stuff. On Thu, Aug 6, 2015 at 5:40 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 7:38 PM, William Hermans yyrk...@gmail.com wrote: Anyway, yeah, not working. is it showing up under: sudo ifconfig -a ?? i've been mostly testing on the v4.1.x-ti branch, so something might have broke on mainline.. Do the other 2 serial ports show up? dmesg | grep serial Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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 a BBB from batteries
Hi! I received my 32 channels servo cape https://github.com/fma38/BeagleBone/tree/master/servos PCB (from SeeedStudio), and started to make some tests with my little hexapod https://www.logre.eu/wiki/Hexapod. Now comes the problem of powering up the BBB. My first idea was to use 2 Ni-Mh batteries: a big one for the servos, and a smaller one for the BBB. I then found this very interesting topic: BBB - Rechargeable on-board battery system http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-system. So, I plan to do this: connect a tiny LiPo battery to the PMIC, and connect the big battery (6V Ni-Mh) to both servos supply and to the BBB (through a 5V regulator, which I can put on the cape). My next Hexapod will use TowerPro MG996R servos, which are much biger than the 9g of the prototype. When moving, the voltage of the battery can fall, and may not be enough to power the BBB. So, the tiny LiPo will take over, and continue to power the BBB. But this may happen very often, while the hexapod walk; so the BBB may quickly switches from on battery to the other. Is it a problem? Thanks for any suggestion. Frédéric -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: NOPx instructions
No idea? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: SSH via USB only possible when no additional network adapters are running (Kernel4.1.3 RT,Debian8.1)
Solved! The host PC seems to be the problem. On two other notebook it works... Greetings Am Donnerstag, 6. August 2015 11:31:19 UTC+2 schrieb Ben F.: Hi, I can only SSH to my BBB (Kernel 4.1.3 RT, Debian 8.1) via USB when I have unplugged all additional network adapters (e.g. Ethernet, Wifi stick...). When I have plugged in a Wifi stick, I can not connect (even ping) the BeagleBone Black via USB. Is there somewhere a config or another file which for example prioritizes these interfaces? Thanks in advance Benjamin -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Unnable to read MSP430 with BeagelBone.
import serial port_name = '/dev/ttyACM0' ps = serial.Serial(port_name , 9600, timeout=1) rint(Connected!) while not self.done: ps_data = ps.readline() print(ps_data) Basically that is it. I'am preaty sure it work because I use it in my computer (MAC) and works fine -of course with different port name' which I also read using another script. So in my computer I get numerical values and in the BB i just get Blanks. On Thursday, August 6, 2015 at 9:20:34 AM UTC-5, Miguel Aveiro wrote: Hi Hugo, I don't think its a driver problem. Does python show you any exceptions? Can you send us a relevant piece of your script? Miguel Aveiro On 06-08-2015 01:57, Hugo Cardoza wrote: I have a script in python build thats reads the data from the msp430 using the usb serial. But when I ran this script in BeageleBone I justo get a blank enter. I must be missing something. I already tried the rules in here http://energia.nu/guide/guide_linux/ Please some advice. I think the problem has to do with the drives or smt like that. My second guess is the power but i have the BB connect to a 5v 2.5A http://imco.org.mx/ Instituto Mexicano para la Competitividad A.C. Musset No.32, Polanco, CP11560. México D.F. Twitter: @IMCOmx http://twitter.com/imcomx | Facebook: /IMCOmx http://facebook.com/imcomx | YouTube: /IMCOmexico http://youtube.com/imcomexico -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- http://imco.org.mx/ Instituto Mexicano para la Competitividad A.C. Musset No.32, Polanco, CP11560. México D.F. Twitter: @IMCOmx http://twitter.com/imcomx | Facebook: /IMCOmx http://facebook.com/imcomx | YouTube: /IMCOmexico http://youtube.com/imcomexico -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] PRU HDMI
On 8/6/2015 1:49 AM, ozgungu...@gmail.com wrote: I need to get data (10MHz) with PRU from camera and send it with hdmi. But it seems these channels conflict in beaglebone black. Is there an alternative hardware or software to solve this problem? HDMI overlaps with most of the available pins for PRU1, but the PRU0 pins are mostly available on the P8/P9 pin headers without having to disable key BBB functionality (HDMI/EMMC). -- 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] Adding PRU eCAP to beaglebone-universal-io
On 8/5/2015 9:54 PM, Nicholas Piegdon wrote: You are my hero! Renaming the dtbo was all it took and my PRU eCAP test worked on the first try. Now that I know it works, this feels like the kind of thing I should submit as a pull request. Assuming that's alright with you, I'm guessing my next steps are to clean this up a bit, drop my custom-named version, also add and test the same mapping on P8_15, then duplicate all of that in the universaln and universala versions, too. Is there anything else I'm missing? I'm glad it's working! The compiled-in overlay files has bitten me more than once as well. :) The changes you list sound good, I look forward to the PR. Holler if you get stuck or have any questions. -- 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] Unnable to read MSP430 with BeagelBone.
Hi Hugo, I don't think its a driver problem. Does python show you any exceptions? Can you send us a relevant piece of your script? Miguel Aveiro On 06-08-2015 01:57, Hugo Cardoza wrote: I have a script in python build thats reads the data from the msp430 using the usb serial. But when I ran this script in BeageleBone I justo get a blank enter. I must be missing something. I already tried the rules in here http://energia.nu/guide/guide_linux/ Please some advice. I think the problem has to do with the drives or smt like that. My second guess is the power but i have the BB connect to a 5v 2.5A http://imco.org.mx/ Instituto Mexicano para la Competitividad A.C. Musset No.32, Polanco, CP11560. México D.F. Twitter: @IMCOmx http://twitter.com/imcomx | Facebook: /IMCOmx http://facebook.com/imcomx | YouTube: /IMCOmexico http://youtube.com/imcomexico -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] GPIO activation during startup
Hi, I need to set a GPIO output high as early as possible during the startup and keep it active until the system shuts down. What I did so far: - Use GPIO 0.7 for testing - Set GPIO0.7 high in python script automatically after startup - GPIO becomes high approx. 24s after power-on - Modify device tree to set GPIO0.7 high - GPIO becomes high approx. 9s after startup - Set GPIO0.7 high in u-boot scipt (/boot/boot.scr) - GPIO becomes high after approx. 3.5s, but becomes low again after approx. 6s My problem now is that the GPIO becomes low for approx. 3s after it was set by u-boot and before the device tree. I guess I need to understand the kernel boot process a little bit better. Any suggestion, where to start or any hint where to look at? Regards Axel -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] CAD-Model for BBB?
Check the support Wiki. http://www.elinux.org/Beagleboard:BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28C.29 Gerald On Thu, Aug 6, 2015 at 12:46 AM, Karl Karpfen karlkarpfe...@gmail.com wrote: Hi, is there a CAD-model available of the BBB and perhaps of one (standard) cape? 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. -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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 use UART3 on beagleboard-xm which runs Android?
Hi, I want to use the DB9 connector on the Board for communicating with a serial port. how can I do that? Accoarding to the schematics, the Pin is GPIO166 and 165, I set the mode to UART using echo 2 uart3_rx_irrx echo 2 uart3_tx_irtx and then I tried to use microcom to check if it works: busybox microcom -s9600 /dev/ttyO2 asafasafasafasafasafasafasafasafasaasaf ^X root@android:/sys/kernel/debug/omap_mux # busybox microcom -s9600 /dev/ttyO3 busybox microcom -s9600 /dev/ttyO3 asaasafasfasfasfasfaasasfaasasf ^X I didn't receive any char on the other side, If there is any sample script which shows how to do that on the BeagleBoard-xm, I would love to see it! thank you very much! Asaf -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Where is software manual for the beagleboard?
Hi, I would like to do some bare metal programming on the beagle board. Is there a published software/hardware manual for the board that list all the hardware interfaces addresses, timers, clocktick, interrupts, etc.? Also does the board give you access to the processor clock to do real time processing -- I am not talking about wall clock. And if it does, then what is the resolution? Thanks for you help! LAG -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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 HDMI
I need to get data (10MHz) with PRU from camera and send it with hdmi. But it seems these channels conflict in beaglebone black. Is there an alternative hardware or software to solve this problem? 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] Hardware Programming Manual?
Hi, Does the beagle board have a hardware programming manual to do bare metal programming? I am looking the software hardware addresses for all the interfaces, clocks, interrupts, etc., on the board. Is that possible? -LAG -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Where is software manual for the beagleboard?
http://www.ti.com/product/AM3358/technicaldocuments Gerald On Wed, Aug 5, 2015 at 8:28 PM, LAG luis_a_go...@msn.com wrote: Hi, I would like to do some bare metal programming on the beagle board. Is there a published software/hardware manual for the board that list all the hardware interfaces addresses, timers, clocktick, interrupts, etc.? Also does the board give you access to the processor clock to do real time processing -- I am not talking about wall clock. And if it does, then what is the resolution? Thanks for you help! LAG -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Hardware Programming Manual?
Yes. It is called the AM3358 Technical Reference Manual for the processor. http://www.ti.com/product/AM3358/technicaldocuments The design information on the board itself is found on the link I sent earlier, the Wiki. and is called the System Reference Manual. Gerald On Wed, Aug 5, 2015 at 8:46 PM, LAG luis_a_go...@msn.com wrote: Hi, Does the beagle board have a hardware programming manual to do bare metal programming? I am looking the software hardware addresses for all the interfaces, clocks, interrupts, etc., on the board. Is that possible? -LAG -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] SSH via USB only possible when no additional network adapters are running (Kernel4.1.3 RT,Debian8.1)
Hi, I can only SSH to my BBB (Kernel 4.1.3 RT, Debian 8.1) via USB when I have unplugged all additional network adapters (e.g. Ethernet, Wifi stick...). When I have plugged in a Wifi stick, I can not connect (even ping) the BeagleBone Black via USB. Is there somewhere a config or another file which for example prioritizes these interfaces? Thanks in advance Benjamin -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Flashing a customized kernel (4.1.3-bone-rt-r15) to the BBB
Thanks, works! Regards, Benjamin Am Mittwoch, 29. Juli 2015 19:28:19 UTC+2 schrieb RobertCNelson: On Wed, Jul 29, 2015 at 11:16 AM, Ben F. benc...@gmail.com javascript: wrote: Hi, We have a project with many BBBs, therefore I need that modified kernel mentioned above running on all BBBs. Every BBB should be easyily flashable with one SSD with that modified kernel. What I did/tried so far: 1.) build_kernel.sh of the 4.1.3-bone-rt-r15 kernel. Some extras added (e.g. debugfs) -- No errors 2.) Installed / copied the EMMC Flasher to my SSD wget https://rcn-ee.com/rootfs/2015-07-08/flasher/BBB-eMMC-flasher-debian-8.1-console-armhf-2015-07-08-2gb.img.xz -- The BeagleBone Black accepts the image and starts to flash (just for testing) 3.) install_kernel.sh Function works, it copies the content of the new kernel (e.g. 4.1.3-bone-rt-r15-modules.tar.gz etc.) to the SSD. But the BBB does not flash with this modified SSD. Only the 4 User LEDs blink up at all for a few seconds, then they are dark. After a few seconds they blink up again. Seems that the BBB hangs at a point. Use the ./build_deb.sh script and just install the linux-image*.deb Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
On Thu, Aug 6, 2015 at 9:28 AM, Axel Barkow a...@barkow.name wrote: Hi, I need to set a GPIO output high as early as possible during the startup and keep it active until the system shuts down. What I did so far: - Use GPIO 0.7 for testing - Set GPIO0.7 high in python script automatically after startup - GPIO becomes high approx. 24s after power-on - Modify device tree to set GPIO0.7 high - GPIO becomes high approx. 9s after startup - Set GPIO0.7 high in u-boot scipt (/boot/boot.scr) - GPIO becomes high after approx. 3.5s, but becomes low again after approx. 6s My problem now is that the GPIO becomes low for approx. 3s after it was set by u-boot and before the device tree. I guess I need to understand the kernel boot process a little bit better. Any suggestion, where to start or any hint where to look at? use the 'gpio-hog' option so the kernel doesn't re-set the gpio upon startup... See the example to keep the eMMC in reset: https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-boneblack-overlay.dts#L28-L36 Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
Add a pullup or just use a GPIO that defaults to high. Nothing is faster than that. Gerald On Thu, Aug 6, 2015 at 9:28 AM, Axel Barkow a...@barkow.name wrote: Hi, I need to set a GPIO output high as early as possible during the startup and keep it active until the system shuts down. What I did so far: - Use GPIO 0.7 for testing - Set GPIO0.7 high in python script automatically after startup - GPIO becomes high approx. 24s after power-on - Modify device tree to set GPIO0.7 high - GPIO becomes high approx. 9s after startup - Set GPIO0.7 high in u-boot scipt (/boot/boot.scr) - GPIO becomes high after approx. 3.5s, but becomes low again after approx. 6s My problem now is that the GPIO becomes low for approx. 3s after it was set by u-boot and before the device tree. I guess I need to understand the kernel boot process a little bit better. Any suggestion, where to start or any hint where to look at? Regards Axel -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
Hi Robert, thanks, that improved the situation, but the GPIO is still going low for approx. 500ms. Any further suggestion? Regards Axel Am Donnerstag, 6. August 2015 16:32:38 UTC+2 schrieb RobertCNelson: On Thu, Aug 6, 2015 at 9:28 AM, Axel Barkow ax...@barkow.name javascript: wrote: Hi, I need to set a GPIO output high as early as possible during the startup and keep it active until the system shuts down. What I did so far: - Use GPIO 0.7 for testing - Set GPIO0.7 high in python script automatically after startup - GPIO becomes high approx. 24s after power-on - Modify device tree to set GPIO0.7 high - GPIO becomes high approx. 9s after startup - Set GPIO0.7 high in u-boot scipt (/boot/boot.scr) - GPIO becomes high after approx. 3.5s, but becomes low again after approx. 6s My problem now is that the GPIO becomes low for approx. 3s after it was set by u-boot and before the device tree. I guess I need to understand the kernel boot process a little bit better. Any suggestion, where to start or any hint where to look at? use the 'gpio-hog' option so the kernel doesn't re-set the gpio upon startup... See the example to keep the eMMC in reset: https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-boneblack-overlay.dts#L28-L36 Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] OpenGL and BBB - simple HelloTriangle example
David, thank you very much indeed, that would be extremely helpful! On Thursday, August 6, 2015 at 3:05:27 PM UTC+1, davidcb wrote: At home I have a very simple program I wrote for the Beagleboard that does what you are trying to do. I think it should compile for the BBB fairly easily. When I get home later this evening I can find it and send it to you. On Thursday, August 6, 2015 8:18 AM, John London john@blackkitetechnology.com javascript: wrote: I'm trying to get a simple example (Hello Triangle) working with BBB running Debian. I do NOT want to run the example under X11 - I want to run it from the command line. I do not want to use GLUT; I think this means it uses the framebuffer. Is this possible and does anyone have an example of how to do this please? I have been trying to use the example below, taken directly from the Examples directory of the PowerVR SDK. When I run the compiled program, I get an error: libEGL warning: DRI2: xcb_connect failed libEGL warning: DRI2: xcb_connect failed Failed to initialise the EGLDisplay Is the code trying to make a connection to X11 perhaps? I am using the Makefile and code below. # # File Makefile # Title Makes the demo # Author PowerVR # # Copyright Copyright (C) by Imagination Technologies Limited. # .PHONY: clean SDKDIR = $(shell cd ../../../../../.. pwd) VPATH = ../.. CROSS_COMPILE ?= arm-linux-gnueabihf- ifdef TOOLCHAIN PLAT_CC = $(TOOLCHAIN)/bin/$(CROSS_COMPILE)gcc PLAT_CPP = $(TOOLCHAIN)/bin/$(CROSS_COMPILE)g++ PLAT_AR = $(TOOLCHAIN)/bin/$(CROSS_COMPILE)ar else PLAT_CC = $(CROSS_COMPILE)gcc PLAT_CPP = $(CROSS_COMPILE)g++ PLAT_AR = $(CROSS_COMPILE)ar endif ifeq $(X11BUILD) 1 ifndef X11ROOT $(error When building an X11 BUILD you must set X11ROOT to point at the location where your X11 headers and libs can be found.) endif ifeq $(EWSBUILD) 1 $(error Cannot have both X11BUILD and EWSBUILD enabled at the same time) endif WS_LIBS = -L$(X11ROOT)/lib -lX11 -lXau -ldl WS_RPATH = $(X11ROOT)/lib WS_INC = $(X11ROOT)/include WS = X11 else ifeq $(EWSBUILD) 1 PLAT_CFLAGS += -DEWS WS_LIBS = -lews WS_INC = WS=EWS else ifeq $(DRMBUILD) 1 ifndef DRMROOT $(error When building a DRM BUILD you must set DRMROOT to point at the location where your DRM headers and libs can be found.) endif WS_LIBS = -L$(DRMROOT)/lib -ldrm -lgbm -ludev -ldl -Wl,--rpath-link,$( DRMROOT)/lib WS_INC = $(DRMROOT)/include $(DRMROOT)/include/libdrm $(DRMROOT)/include/ gbm WS=DRM else WS_LIBS = WS_INC = WS = NullWS endif endif endif LIBDIR ?= $(SDKDIR)/Builds/Linux/armv7hf/Lib LIBDIR_FLAGS = -L$(LIBDIR) -Wl,--rpath-link,$(LIBDIR):$(WS_RPATH) ifdef Debug DEBUG_RELEASE = Debug PLAT_CFLAGS += -g else DEBUG_RELEASE = Release PLAT_CFLAGS += -O2 endif PLAT_CFLAGS += -Wall -march=armv7 -mfloat-abi=hard PLAT_INC = $(SDKDIR)/Builds/Include $(WS_INC) PLAT_OBJPATH = $(DEBUG_RELEASE)$(WS) PLAT_LINK = $(LIBDIR_FLAGS) -lEGL -lGLESv2 $(WS_LIBS) -L$(TOOLCHAIN)/lib - march=armv7 -mfloat-abi=hard ifeq $(WS) X11 SRCNAME = OGLES2HelloAPI_LinuxX11 else ifeq $(WS) EWS SRCNAME = OGLES2HelloAPI_EWS else ifeq $(WS) DRM SRCNAME = OGLES2HelloAPI_LinuxDRM else SRCNAME = OGLES2HelloAPI_NullWS endif endif endif OUTNAME = OGLES2HelloAPI OBJECTS = $(PLAT_OBJPATH)/$(SRCNAME).o COMMON_INCLUDES = $(addprefix - ... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
Hi Gerald, thanks, I need to check, if this is a possible solution. I want to use the output to keep the BBB powered, when the external start signal goes low and power the whole system down depending on some software decisions. Therefore the output is connected to a shutdown pin of a voltage regulator, whcih provides the 5V. I'm afraid adding a pullup here will keep the system active forever... Regards Axel Am Donnerstag, 6. August 2015 16:32:44 UTC+2 schrieb Gerald: Add a pullup or just use a GPIO that defaults to high. Nothing is faster than that. Gerald On Thu, Aug 6, 2015 at 9:28 AM, Axel Barkow ax...@barkow.name javascript: wrote: Hi, I need to set a GPIO output high as early as possible during the startup and keep it active until the system shuts down. What I did so far: - Use GPIO 0.7 for testing - Set GPIO0.7 high in python script automatically after startup - GPIO becomes high approx. 24s after power-on - Modify device tree to set GPIO0.7 high - GPIO becomes high approx. 9s after startup - Set GPIO0.7 high in u-boot scipt (/boot/boot.scr) - GPIO becomes high after approx. 3.5s, but becomes low again after approx. 6s My problem now is that the GPIO becomes low for approx. 3s after it was set by u-boot and before the device tree. I guess I need to understand the kernel boot process a little bit better. Any suggestion, where to start or any hint where to look at? Regards Axel -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org javascript: http://beagleboard.org/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
On Thu, Aug 6, 2015 at 10:01 AM, Axel Barkow a...@barkow.name wrote: Here a picture to show, what I measured. KL 15 is the external start signal, BBB 3.3V is the 3.3V line of the BBB and POWER HOLD is GPIO0.7. At T1 the power is switched on and at T2 I think that the GPIO is set by the device tree configuration. Regards Axel https://lh3.googleusercontent.com/-ej2Mnld8X4s/VcN2R3Od_PI/ACM/u-IKwgOgI6w/s1600/screenshot.png That is odd.. the point of gpio-hog was to leave the specified gpio output in a specific state, even during gpio initialization. What kernel is this btw? Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
Pullup is large. Your SW can always override it and take it low when you are ready. Gerald On Thu, Aug 6, 2015 at 10:05 AM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:01 AM, Axel Barkow a...@barkow.name wrote: Here a picture to show, what I measured. KL 15 is the external start signal, BBB 3.3V is the 3.3V line of the BBB and POWER HOLD is GPIO0.7. At T1 the power is switched on and at T2 I think that the GPIO is set by the device tree configuration. Regards Axel https://lh3.googleusercontent.com/-ej2Mnld8X4s/VcN2R3Od_PI/ACM/u-IKwgOgI6w/s1600/screenshot.png That is odd.. the point of gpio-hog was to leave the specified gpio output in a specific state, even during gpio initialization. What kernel is this btw? Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
debian@beaglebone:~$ uname -a Linux beaglebone 4.1.3-ti-r7 #1 SMP PREEMPT Thu Jul 30 20:00:23 UTC 2015 armv7l GNU/Linux Am Donnerstag, 6. August 2015 17:05:48 UTC+2 schrieb RobertCNelson: On Thu, Aug 6, 2015 at 10:01 AM, Axel Barkow ax...@barkow.name javascript: wrote: Here a picture to show, what I measured. KL 15 is the external start signal, BBB 3.3V is the 3.3V line of the BBB and POWER HOLD is GPIO0.7. At T1 the power is switched on and at T2 I think that the GPIO is set by the device tree configuration. Regards Axel https://lh3.googleusercontent.com/-ej2Mnld8X4s/VcN2R3Od_PI/ACM/u-IKwgOgI6w/s1600/screenshot.png That is odd.. the point of gpio-hog was to leave the specified gpio output in a specific state, even during gpio initialization. What kernel is this btw? Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] GPIO activation during startup
Now I synchronized my measurements with the serial console output. Loaded script from /boot/boot.scr gpio: pin 56 (gpio 56) value is 1 Running bootscript from mmc1:1 ... ## Executing script at 8200 Output becomes high here gpio: pin 7 (gpio 7) value is 1 Checking for: /boot/uEnv.txt ... gpio: pin 55 (gpio 55) value is 1 1604 bytes read in 30 ms (51.8 KiB/s) Loaded environment from /boot/uEnv.txt Checking if uname_r is set in /boot/uEnv.txt... gpio: pin 56 (gpio 56) value is 1 Running uname_boot ... loading /boot/vmlinuz-4.1.3-ti-r7 ... 8211648 bytes read in 481 ms (16.3 MiB/s) loading /boot/dtbs/4.1.3-ti-r7/am335x-boneblack.dtb ... 57645 bytes read in 64 ms (878.9 KiB/s) loading /boot/initrd.img-4.1.3-ti-r7 ... 4570423 bytes read in 1222 ms (3.6 MiB/s) debug: [console=tty0 console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-CAN1 root=/dev/mmcblk0p1 rootfstype=ext4 rootwait fixrtc coherent_pool=1M] ... debug: [bootz 0x8200 0x8808:45bd37 0x8800] ... Kernel image @ 0x8200 [ 0x00 - 0x7d4cc0 ] ## Flattened Device Tree blob at 8800 Booting using the fdt blob at 0x8800 Using Device Tree in place at 8800, end 8801112c Output becomes low 0.645s after the last serial message and 2.571s before the next Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.1.3-ti-r7 (root@b2-omap5-uevm-2gb) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT Thu Jul 30 20:00:23 UTC 2015 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI AM335x BeagleBone Black [0.00] cma: Reserved 24 MiB at 0x9e00 [0.00] Memory policy: Data cache writeback Am Donnerstag, 6. August 2015 17:07:36 UTC+2 schrieb Axel Barkow: debian@beaglebone:~$ uname -a Linux beaglebone 4.1.3-ti-r7 #1 SMP PREEMPT Thu Jul 30 20:00:23 UTC 2015 armv7l GNU/Linux Am Donnerstag, 6. August 2015 17:05:48 UTC+2 schrieb RobertCNelson: On Thu, Aug 6, 2015 at 10:01 AM, Axel Barkow ax...@barkow.name wrote: Here a picture to show, what I measured. KL 15 is the external start signal, BBB 3.3V is the 3.3V line of the BBB and POWER HOLD is GPIO0.7. At T1 the power is switched on and at T2 I think that the GPIO is set by the device tree configuration. Regards Axel https://lh3.googleusercontent.com/-ej2Mnld8X4s/VcN2R3Od_PI/ACM/u-IKwgOgI6w/s1600/screenshot.png That is odd.. the point of gpio-hog was to leave the specified gpio output in a specific state, even during gpio initialization. What kernel is this btw? Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Where is software manual for the beagleboard?
Very basic need but answer is very simple. You look at board users guide obtain TI part number example am55xx and Google part number to find ti support page. TI calling software program guide TRM it has all details. Repeat process for rest of careers Sent from Yahoo Mail on Android From:LAG luis_a_go...@msn.com Date:Thu, Aug 6, 2015 at 9:59 AM Subject:[beagleboard] Where is software manual for the beagleboard? Hi, I would like to do some bare metal programming on the beagle board. Is there a published software/hardware manual for the board that list all the hardware interfaces addresses, timers, clocktick, interrupts, etc.? Also does the board give you access to the processor clock to do real time processing -- I am not talking about wall clock. And if it does, then what is the resolution? Thanks for you help! LAG -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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.
