Re: [beagleboard] Serial header on Beaglebone Black
Here is an example: https://forums.adafruit.com/viewtopic.php?f=49t=54034p=273057hilit=gps+ultimate+c#p273057 search the Adafruit beaglebone forum for Ultimate GPS On Thu, Oct 9, 2014 at 10:21 AM, meino.cra...@gmx.de wrote: Hi, My beaglebone blacks system (kernel and software) is on sdcard. I dont use the internal flash. I want to connect an Utlimate GPS chip by Adafruit (http://www.adafruit.com/product/746) to the Beaglebone black. This chip uses an UART type of connection. Is it posible to connect the chip to the serial header, which already exist on the beaglebone black PCB, if I switch off the serial console in uEnv.txt or may this harm the GPS chip, because any garbage which comes out of the header while booting the board kills/harms it? Any precautions I have to take? Or is this the wrong way to go? Thank you very much for any help in advance! Best regards, mcc -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Host - Pru synchronization
Some PRU code samples: https://github.com/jstampfl?tab=repositories On Fri, Oct 3, 2014 at 12:14 PM, Ray Madigan raymond.madi...@gmail.com wrote: Thanks for the reference document. I have been out of town all week and am just getting back at this. I don't want to be told the answer, thats just no fun. I am trying to figure out how this works so if someone can tell me why I'm not thinking about this correctly that would be useful. I have tried many permutations of the following and can't seem to find something to start with. #define ARM_PRU0_INTERRUPT 21 #define CONST_PRUSSINTC C0 #define SICR_OFFSET 0x24 // Load the interrupt number into register 17 LDIR17, ARM_PRU0_INTERRUPT // Write 4 bytes from R17 into pruss intc offset by the sicr SBCO R17, CONST_PRUSSINTC, SICR_OFFSET, 4 Are there tutorials somewhere for this assmebly language, I haven't used assembler since the 8080 :) On Monday, September 29, 2014 3:44:59 PM UTC-7, Charles Steinkuehler wrote: Section 6.2.2.5 Interrupt Status Clearing: https://github.com/beagleboard/am335x_pru_package/blob/master/ am335xPruReferenceGuide.pdf On 9/26/2014 6:47 PM, Ray Madigan wrote: Thank you very much. I appreciate you taking time to help me figure this out. Now I just have to figure out how to do what you just said. On Friday, September 26, 2014 2:15:28 PM UTC-7, Charles Steinkuehler wrote: You can't clear bits in the status register, you have to clear whatever is generating the status bit directly. That's either an input pin or (in your case) the interrupt from the local INTC. So try clearing the actual interrupt bit, and the PRU code should then wait as expected for the next handshake. I suspect the PRU is currently running to completion because you're never clearing the interrupt that kicks things off, so waitForHost() doesn't actually do anything after the first wait and simply falls through from then on. -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- Charles Steinkuehler cha...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] SUART PRU
The PRU has an UART: https://github.com/jstampfl/Pruuart On Mon, Sep 22, 2014 at 5:02 PM, Micka mickamus...@gmail.com wrote: Hi, I need more UART for my project, and the best way I heard is by using the PRU. There is a link about that : http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide#Building_SUART_Firmware But it say that the driver is built for linux 3.2 . So is it compatible for Linux 3.8 ? If it is compatible with Linux 3.8, how do you install this driver ? Do I have to compile it ? Or just copy past the driver and put it somewhere ? = git://gitorious.org/pru/am335x-pru-uart-fw.git I just found out about the existence of PRU, sounds like very interesting ! Micka, -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Why is it using BBB in commercial products not encouraged?
Special Computing sells a version of the BBB with unrestricted use. https://specialcomp.com/beaglebone/ On Wed, Sep 17, 2014 at 7:44 PM, Philip Polstra ppols...@gmail.com wrote: I have some bb-xm and original beaglebone boards I have been running since I bought them years ago that only get shut down when I move them. No issues with reliability. You can base commercial products on this board and people do so. On Sep 17, 2014 7:29 AM, sufi al hussaini sufialhussa...@gmail.com wrote: I have boards running nearly continuously for years. Do you mean BBB boards? If I were to clone and get my own hardware, would the prebuilt linux images(for BBB) and other capes work out-of-the-box on my hardware? Forgive me if this is a stupid question. I'm only a newbie. Thanks. On Wednesday, September 17, 2014 3:21:58 PM UTC+4, Philip Polstra wrote: I have boards running nearly continuously for years. I think the thought is that if you had to make loads of devices based on this you should just clone the open source design. On Sep 17, 2014 5:32 AM, sufi al hussaini sufialh...@gmail.com wrote: Hi everyone, Just wanted to ask about this. I have read this at more than one place, but I couldn't understand the reason behind it. Why shouldn't I use BBB in commercial products? Or why isn't it encouraged? Does it have something to do with over all system stability and other technical issues? Or is it simply because BBB production is lagging behind demand? Regards, Zaxter. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] BBB A6 B running slow, C ok
What information would you like? What is the latest version of the bootloader for these boards? On Thu, Sep 11, 2014 at 11:27 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Sep 11, 2014 at 10:23 AM, jstam...@gmail.com wrote: From dmesg: A6 - Debian bone 60 - vdd-mpu 1100 mV, Bogomips 545 B - Debian bone 60 - vdd-mpu 1100 mV, Bogomips 545 C - Debian bone 60 - vdd-mpu 1325 mV, Bogomips 993 Also: A6 - Angstrom 3.8.13 - vdd-mpu 1100 mV, Bogomips 545 B - Angstrom 3.8.13 - vdd-mpu 1100 mV, Bogomips 545 C - Debian bone47 - vdd-mpu 1325 mV, Bogomips 993 Do this mean that the A6 B boards are running at 500 or 600 MHz? With the little information you have shown. My guess, your Revision C is running a newer bootloader that enabled 1Ghz at bootup.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] BBB A6 B running slow, C ok
Ok, will do that tomorrow and report On Thu, Sep 11, 2014 at 11:37 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Sep 11, 2014 at 10:34 AM, John Stampfl jstam...@gmail.com wrote: What information would you like? What is the latest version of the bootloader for these boards? Well, since the C works.. Run the debian flasher on the A6/B http://beagleboard.org/latest-images Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Are the 'modes' in the BBB documentation just history or what?
Here is a nice spreadsheet http://www.embedded-things.com/bbb/beaglebone-black-pin-mux-spreadsheet/ On Mon, Sep 8, 2014 at 6:15 AM, John Syn john3...@gmail.com wrote: On 9/7/14, 2:07 AM, c...@isbd.net c...@isbd.net wrote: John Syn john3...@gmail.com wrote: I'd love to find a document or tutorial that describes how this all hangs together but there doesn't seem to be anything other than the (huge) processor documentation which is vey much reference material and (as I referred to above) various blogs etc. showing how to do one particular thing but without any attempt to explain it. The pinmux section uses the register offset and in the attached spreadsheet, that offset is related to the P8/P9 connector pins. The right column defines how the pins are setup in the V3.15-bone5 device tree. Thanks, but attachments don't work when using news group access to gmane (or at least I don't think they do, I couldn't see anything). Could you possibly point me at a URL for the spreadsheet or mail it to me directly (E-Mail in header works). To explain how the spreadsheet works: If you look at the AM335x TRM, start with the CONTROL_MODULE Registers in Section 9.3.1. The first I/O pin is conf_gpmc_ad0 which is at offset 800h, but the pinmux in the device tree defines this as address 0h so you always have to subtract 800h from the offset from this table. On the right column, you will see a reference to 9.3.1.50 which defines the mode, pull up, pull down, etc. Now you have to use either the schematic or the BBB SRM to map the processor pin (conf_gpmc_ad0) to a board connector pin (P8_25). Regards John -- Chris Green · -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Are the 'modes' in the BBB documentation just history or what?
I hadn't googled for pinmux for a while: http://roshan.info/blog/2014/03/03/beaglebone-black-pinmux-and-dts-helper/ On Mon, Sep 8, 2014 at 8:21 AM, John Stampfl jstam...@gmail.com wrote: Here is a nice spreadsheet http://www.embedded-things.com/bbb/beaglebone-black-pin-mux-spreadsheet/ On Mon, Sep 8, 2014 at 6:15 AM, John Syn john3...@gmail.com wrote: On 9/7/14, 2:07 AM, c...@isbd.net c...@isbd.net wrote: John Syn john3...@gmail.com wrote: I'd love to find a document or tutorial that describes how this all hangs together but there doesn't seem to be anything other than the (huge) processor documentation which is vey much reference material and (as I referred to above) various blogs etc. showing how to do one particular thing but without any attempt to explain it. The pinmux section uses the register offset and in the attached spreadsheet, that offset is related to the P8/P9 connector pins. The right column defines how the pins are setup in the V3.15-bone5 device tree. Thanks, but attachments don't work when using news group access to gmane (or at least I don't think they do, I couldn't see anything). Could you possibly point me at a URL for the spreadsheet or mail it to me directly (E-Mail in header works). To explain how the spreadsheet works: If you look at the AM335x TRM, start with the CONTROL_MODULE Registers in Section 9.3.1. The first I/O pin is conf_gpmc_ad0 which is at offset 800h, but the pinmux in the device tree defines this as address 0h so you always have to subtract 800h from the offset from this table. On the right column, you will see a reference to 9.3.1.50 which defines the mode, pull up, pull down, etc. Now you have to use either the schematic or the BBB SRM to map the processor pin (conf_gpmc_ad0) to a board connector pin (P8_25). Regards John -- Chris Green · -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Are the 'modes' in the BBB documentation just history or what?
and of course: https://github.com/cdsteinkuehler/beaglebone-universal-io On Mon, Sep 8, 2014 at 8:27 AM, John Stampfl jstam...@gmail.com wrote: I hadn't googled for pinmux for a while: http://roshan.info/blog/2014/03/03/beaglebone-black-pinmux-and-dts-helper/ On Mon, Sep 8, 2014 at 8:21 AM, John Stampfl jstam...@gmail.com wrote: Here is a nice spreadsheet http://www.embedded-things.com/bbb/beaglebone-black-pin-mux-spreadsheet/ On Mon, Sep 8, 2014 at 6:15 AM, John Syn john3...@gmail.com wrote: On 9/7/14, 2:07 AM, c...@isbd.net c...@isbd.net wrote: John Syn john3...@gmail.com wrote: I'd love to find a document or tutorial that describes how this all hangs together but there doesn't seem to be anything other than the (huge) processor documentation which is vey much reference material and (as I referred to above) various blogs etc. showing how to do one particular thing but without any attempt to explain it. The pinmux section uses the register offset and in the attached spreadsheet, that offset is related to the P8/P9 connector pins. The right column defines how the pins are setup in the V3.15-bone5 device tree. Thanks, but attachments don't work when using news group access to gmane (or at least I don't think they do, I couldn't see anything). Could you possibly point me at a URL for the spreadsheet or mail it to me directly (E-Mail in header works). To explain how the spreadsheet works: If you look at the AM335x TRM, start with the CONTROL_MODULE Registers in Section 9.3.1. The first I/O pin is conf_gpmc_ad0 which is at offset 800h, but the pinmux in the device tree defines this as address 0h so you always have to subtract 800h from the offset from this table. On the right column, you will see a reference to 9.3.1.50 which defines the mode, pull up, pull down, etc. Now you have to use either the schematic or the BBB SRM to map the processor pin (conf_gpmc_ad0) to a board connector pin (P8_25). Regards John -- Chris Green · -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- John Stampfl -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Reading GPIO input from mem in PRU (BBB)
You can look at some of the examples (the C program based on App-loader) at https://github.com/jstampfl The example PRU_memAccessPRUDataRam should exit with the halt, it is sending the interrupt mov r31.t30 that sends the interrupt to the linux program. You can program the loops and exits anyway you want. In fact you can start the p prpgram and exit the c program leaving the p running. On Tue, Jul 29, 2014 at 2:37 PM, Jacob Ole Juul Kolding dac...@gmail.com wrote: I modified the PRU_memAccessPRUDataRam.p with the interrupt code and without the HALT command and now the code (and C program) exits successfully. But how do I send an interrupt the other way? Say I want the PRU to run a loop until the C code reads a key input? Or should I just do that using shared mem? Thanks /Jacob 2014-07-29 0:44 GMT+02:00 John Stampfl jstam...@gmail.com: Looks like to me you just halted the PRU. the comment: // r2 contains of all GPIO1, so now you can inspect the value of bit 12 as desired , I think is a hint you need to do something (write some code) to look at the value of r2. your say I found the following code and although it compiles the example app never exits while waiting for HALT This sounds like you are referring to the program that loads and starts the Pru. Why don't you show all the code involved. If you follow the examples in the am335x_pru_package, you will see the App-loader C program. The App-loader initializes a linux interrupt and the PRU INTC (interrupt controler) so the PRU can send an interrrupt to the linux program. Are you doing something like this? if so, you are not sending the interrupt back to linix. You can look at some PRU programs in the examples of the am335x_pru_package. For example, There is the PRU_memAccessPRUDataRam which shows the linux program reading from the PRU data memory. Just put r2 from the example above into the PRU data memory and read in linux. On Tue, Jul 29, 2014 at 1:00 AM, Jacob Ole Juul Kolding dac...@gmail.com wrote: Hi I found the following code and although it compiles the example app never exits while waiting for HALT. And after that all other example apps no longer work. #define GPIO0 0x44e07000 #define GPIO1 0x4804c000 #define GPIO2 0x481ac000 #define GPIO_OE 0x134 #define GPIO_DATAIN 0x138 MOV r3, GPIO1 | GPIO_OE LBBO r2, r3, 0, 4 SET r2, 12 // set bit 12 SBBO r2, r3, 0, 4 MOV r3, GPIO1 | GPIO_DATAIN LBBO r2, r3, 0, 4 // Store register contents into r2 // r2 contains of all GPIO1, so now you can inspect the value of bit 12 as desired HALT can anyone tell what’s wrong or another way of doing this? /Jacob -- In acting as if life has meaning, we will find, thank God, that it does - John Cottingham -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- In acting as if life has meaning, we will find, thank God, that it does - John Cottingham -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: CYCLE counter to time pulse w/ HC-SR04
OK On Mon, Jul 28, 2014 at 3:09 PM, Troy Dack t...@dack.com.au wrote: Nevermind, I worked it out. gcc -c -o pt.o pt.c gcc -lpthread -lprussdrv -o pt pt.o On Sunday, 13 July 2014 12:55:52 UTC+10, jsta...@gmail.com wrote: Here is an example of using the PRUSS cycle counter to time a pulse. Files at: github.org/jstampfl/Prutimer here is the PRUSS code: / pt.p // To get the echo pulse on pin P8 15. // assemble: pasm -v3 -b pt.p (could be pasm_2 if you follow directions .setcallreg r29.w0 // Going to use r31 for interrupt .origin 0 .entrypoint T811 #define CTRL 0x22000 //Start of control registers. T811: mov r8,CTRL //set r8 for the lbbo ldi r12, 0 // Local memory address for pru0 data memory ldi r2, 0 // zero to zero the cycle counter TB1: qbbs TB1,r31,15 // wait here for echo line to go low // WAIT FOR THE ECHO PULSE TB2: qbbc TB2,r31,15 // wait here for echo line to go high - start of pulse // START THE CYCLE COUNTER lbbo r9,r8,0,4 // Get the control register set r9,3 // Set the cycle counter enable sbbo r9,r8,0,4 // Put back to the register to start // WAIT FOR THE PULSE TO END TB3: qbbs TB3,r31,15 // wait here until echo line goes low. // STOP THE CYCLE COUNTER lbbo r9,r8,0,4 // get control register clr r9,3 // clear counter to disable sbbo r9,r8,0,4 // put back ldi r10,1 // not neccessary, was going to use as signal // GET THE CYCLE COUNT AND PUT IN PRU0 LOCAL DATA MEMORY lbbo r11,r8,12,4 // get the CYCLE count sbbo r10,r12,0,8 // put r10 r11 (the unused signal cycle count) in // pru0 data memory sbbo r2,r8,12,4 // Zero the cycle count // SEND INTERRUPT SIGNAL TO LINUX SIDE mov r31.b0,35 //Send interrupt to Linux side lbbo r11,r12,8,4 // Check for end flag from Linux side qbne TB1,r11,2 // go back for more TB4: halt -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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 to find PRUSS SDK for BBB?
http://elinux.org/Ti_AM33XX_PRUSSv2 On Mon, Jul 28, 2014 at 7:40 PM, Jacob Ole Juul Kolding dac...@gmail.com wrote: Hi Can anyone tell me where to find the newest sdk for building and running code on the PRU's? Thanks /Jacob -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Where to find PRUSS SDK for BBB?
https://github.com/beagleboard/am335x_pru_package On Mon, Jul 28, 2014 at 9:32 PM, Alexander Hiam hiamalexan...@gmail.com wrote: It's on TI's site: http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm On Monday, July 28, 2014 7:40:44 AM UTC-4, Dacobi wrote: Hi Can anyone tell me where to find the newest sdk for building and running code on the PRU's? Thanks /Jacob -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Reading GPIO input from mem in PRU (BBB)
Looks like to me you just halted the PRU. the comment: // r2 contains of all GPIO1, so now you can inspect the value of bit 12 as desired , I think is a hint you need to do something (write some code) to look at the value of r2. your say I found the following code and although it compiles the example app never exits while waiting for HALT This sounds like you are referring to the program that loads and starts the Pru. Why don't you show all the code involved. If you follow the examples in the am335x_pru_package, you will see the App-loader C program. The App-loader initializes a linux interrupt and the PRU INTC (interrupt controler) so the PRU can send an interrrupt to the linux program. Are you doing something like this? if so, you are not sending the interrupt back to linix. You can look at some PRU programs in the examples of the am335x_pru_package. For example, There is the PRU_memAccessPRUDataRam https://github.com/beagleboard/am335x_pru_package/tree/master/pru_sw/example_apps/PRU_memAccessPRUDataRam which shows the linux program reading from the PRU data memory. Just put r2 from the example above into the PRU data memory and read in linux. On Tue, Jul 29, 2014 at 1:00 AM, Jacob Ole Juul Kolding dac...@gmail.com wrote: Hi I found the following code and although it compiles the example app never exits while waiting for HALT. And after that all other example apps no longer work. #define GPIO0 0x44e07000 #define GPIO1 0x4804c000 #define GPIO2 0x481ac000 #define GPIO_OE 0x134 #define GPIO_DATAIN 0x138 MOV r3, GPIO1 | GPIO_OE LBBO r2, r3, 0, 4 SET r2, 12 // set bit 12 SBBO r2, r3, 0, 4 MOV r3, GPIO1 | GPIO_DATAIN LBBO r2, r3, 0, 4 // Store register contents into r2 // r2 contains of all GPIO1, so now you can inspect the value of bit 12 as desired HALT can anyone tell what’s wrong or another way of doing this? /Jacob -- In acting as if life has meaning, we will find, thank God, that it does - John Cottingham -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Rev C BBB: problems getting i2c to work
I have an I2C example running of Rev A5. Posted on the ADAFRUIT Beaglebone forum. You can search for HMC5883L compass, C programming On Sun, Jul 27, 2014 at 7:58 PM, lintweaker gtmkra...@gmail.com wrote: I have a BBB rev C from elemen14. Everything is working fine, including getting sound from a external DAC board connected through I2S. One thing I cannot get to work is I2C. I have tried every possible I2C port, at most I only get I2C controller timeouts. I have tried without any pullup resistors, 10k, 4k7 and 5k6 resistors. The I2C devices (DAC chip @0x48 and serial EEPROM @ 0x50) never show up with i2cdetect. The same devices just work without a hitch on my raspberry pi (no pullup needed). Any thoughts how to fix this? I am running the stock BBB debian, kernel now up to 3.8.13-bone62. 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] inaccuracy issue of clock_nanosleep() with Debian
Try the cycle counter in the pru. look in the pru section of the forum On Thu, Jul 17, 2014 at 10:35 PM, sun19920...@gmail.com wrote: I use BeagleboneBlack with Debian, kernel v3.15, and I want to implement an accurate timer on my BBB. I use clock_nanosleep() to wait for 1 second. However, it always turns to be 1 second and 100~120 microsecond delay. (I measured clock_nanosleep() between clock_gettime() and with oscilloscope.) I also run linuxPTP (a software that adjusts system clock, CLOCK_REALTIME, to synchronize linux system with PTP.) to synchronize my BBB. I have no idea how to improve it, should I change linux to real-time linux? (Xenomai or RobertCNelson's patch for linux) or is there another way (such as software, codes, etc) to get more accuracy timer? (under 1us delay.) 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] inaccuracy issue of clock_nanosleep() with Debian
You also might find accessing the timers from PRU is more accurate On Fri, Jul 18, 2014 at 12:10 AM, sun19920...@gmail.com wrote: Hello, John, Excuse me, may I ask that PRU can be used beyond linux system clock? Because I need to synchronize my BBB with ourter PTP(precision time protocol) message , if PRU using its clock, then the BBB will become asynchronized device.. Thanks. John Stampfl於 2014年7月17日星期四UTC+8下午11時02分32秒寫道： Try the cycle counter in the pru. look in the pru section of the forum On Thu, Jul 17, 2014 at 10:35 PM, sun19...@gmail.com wrote: I use BeagleboneBlack with Debian, kernel v3.15, and I want to implement an accurate timer on my BBB. I use clock_nanosleep() to wait for 1 second. However, it always turns to be 1 second and 100~120 microsecond delay. (I measured clock_nanosleep() between clock_gettime() and with oscilloscope.) I also run linuxPTP (a software that adjusts system clock, CLOCK_REALTIME, to synchronize linux system with PTP.) to synchronize my BBB. I have no idea how to improve it, should I change linux to real-time linux? (Xenomai or RobertCNelson's patch for linux) or is there another way (such as software, codes, etc) to get more accuracy timer? (under 1us delay.) Thanks! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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. -- John Stampfl -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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.
