[beagleboard] Re: Saving Data In a Text File
Craig, I think your answer is not precise. This is not a Linux question but a Windows/Putty question. Possible answers could be: 1) use copy/paste from the putty window to the file you like 2) use putty log option. :-) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: How to exchange data between host C prog and PRU C prog?
You may use prussdrv_map_prumem(...) to map PRU memory to host (C-client) utility. If no pin state change, first of all you should show us your pin mux settings of the respective pins. HTH -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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 with own cape stops working
Hi Uli, on your design, some your signals go to the BBB boot mode pins. For example, 2_D0_RX signal goes to the SYS_BOOT_8 of the BBB which must be Low at power up. Please check every other your signal likewise, if they do not prevent the BBB from booting. Normally people just disable all the drivers on the cape until the BBB is up and running. This is what was initially suggested. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Beaglebone Black Rev. C: Protecting GPIO pins during boot until SYS_RESETn signal is HI
On Wednesday, August 13, 2014 7:52:05 PM UTC+6, Paul wrote: What kind of solutions are others out there using to protect GPIO pins during boot? I have a sensor connected that is loop powered so it will be applying voltage at all times to the BBB. My thought is to use some sort of FET bus to protect the board. Ideas or thoughts? Thanks. As soon as you did not post anything particular about your concern - not a schematic, nor description, the only advice is: do not use any pins multiplexed with other functions and use opto-isolators for any other. In many many cases direct connection works of course. No need in any FETs. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: ADC reading by PRU
I'm trying to use the code for this task, but when I run the sample application, I'm getting a segmentation fault. Segmentation faults in 90% occasions come from null-pointer dereferencing. Please add few debug prints to your code and tell us where the crash happens. (by the way, do you have/see any printout on the console, before the segmentation fault?) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: problem with GPIO 117
Please show us the pinmux settings for your GPIO3_21 pin as well. On Friday, August 8, 2014 1:11:19 AM UTC+6, bou...@gmail.com wrote: Do you have any idea on what could be the problem? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Write to EEPROM on BBB?
On Thursday, August 7, 2014 5:15:57 PM UTC+6, Karl Karpfen wrote: OK, so that's my current code, based on StarterWare example, writeEEPROM() is called e.g. with addr=4 and length=4 plus some reasonable data: void writeEEPROM(unsigned int addr,unsigned int length,const unsigned char *data) ... Well, here is a BeagleBoard forum. I wish you meet somebody using Starterware here, but more luck should be if asking on e2e.ti.com forums. My suggestion was to look at the i2c diagram (using oscilloscope). This surely helped you understand the case. If you cannot, sorry.. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Write to EEPROM on BBB?
So...anything else that could be missing? Hi, seems nothing is missed. In this case I'd proceed with an oscilloscope: 1) ensure the WP (U7.5) is really Low level. 2) look at the i2c diagram and ensure there is an acnowledge to (page) write operation 3) ensure there is long acnowledge delay on the second page write (otherwise the EEPROM is write protected or some other device responds with the i2c ACK!) You say you use bare metal soft support. Are you sure your i2c diagarm is correct (correct stop condition)? If not, bytes could be read successfully but page write may not begin.. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: GPIO input not working
P8.15,/* GPIO1_15 */ Hi, While on the schematic GPIO1_15 is inside the bracket labeled Caution: Used On Board, actually it (P8.15) is not connected anywhere but to the processor pad. That is actually NOT used on board. I verified this many times: no troubles with GPIO1_15. I do not think that setting pinmux to 0x07 is a good idea. If you want to read the GPIO you need the respective receiver enabled. The 0x27 pinmux data is much better. What else.. If you often want to see what the actual pinmux settings are, or what is the GPIO state, this might be handy: http://www.academ.org/~sv/epc/pinmux.pdf -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: beaglebone black read i2c.
Which connection? Why 0x70 arduino? On Monday, July 14, 2014 4:33:36 AM UTC+6, ruben campos wrote: Hello good day community. I'm logged in beaglebone black and hope you can help me. would like to read the address 0x70 arduino and processing the data in beagblebone black. I hope you can help me. regards Ruben. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: How does one find the TCP address of a BBB ?
I hooked up an ethernet cable between my BBB my network hub, and tried to access the web page at *192.168.7.2 *as directed. To communicate with the BBB at 172.168.7.2 no Ethernet cable is needed. USB connection only. (ans as far as I remember, not any Windows LAN configuration - everything goes PNP at USB driver installation) Another case should be if you connected 2 or more BBBs.. :) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: BeagleBone Black hang
From your logs I see that BBB does not hang, it crashes at u-boot.img reading, and starts over. Something about power or overheating possible. Try external power supply. Look for hot chips on the BBB (or try fan to cool it) List everything connected to the BBB here, for us to know your environment. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Beaglebone black is not detected at all by my computer
What do you mean by computer was unable? Device recognition is performed by an operating system. Windows? Device manager shows no USB devices? connect console cable and show us the log. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: set up PADCONF for am33xx from userspace
Control module registers are write protected. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: BBB PRU input test
On Monday, June 23, 2014 6:04:48 PM UTC+6, Charles Steinkuehler wrote: The problem here is that you are reading from R31 using the SET command, which the PRU reference guide explicitly states does not work. The reference guide indicates the source will be NULL, which one might *assume* means all zeros, but in reality could mean just about anything (including something like the source input pins on the ALU are floating). -- Charles Steinkuehler cha...@steinkuehler.net javascript: Hmm.. Could you please give us an example which produce bad result? I widely use the set reg, r31, bit# to compose a single bit mask and have never seen any problems. Ask TI is not that good suggestion because they always reply PRU is not supported and advise asking questions here. 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.
Re: [beagleboard] Re: BBB PRU input test
We still have no answer on initial question: why set r3, r31.t16 results in r3=0x08 ? I'd like the pru asm compiler just reject this code as it seems of little sense. However it does not and produce the instruction coded as 0x1F10FFE3, Which if deassembled actually is a SET R3, R31, 0x10 Then the result of its execution should probably be 0x1. Then, why that claimed 0x08 ?? Is it really so? (deassembly was performed using http://pastebin.com/2y7uRRwA) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Device Tree Overlay pinmux modification doe not modify the physical pin or the file interface values
Hi Michael When I do 'cat value' in the gpio48 directory, I get 1. I should get a 0 since the pulldown is enabled. To my experience the 'cat value' not always reflects actual level on the wire. and Should modifications in the DTO reflect in the file interfaces and on the physical pin itself, DTO modifications not always change the pinmux settings or pin state. (For example uEnv.txt settings might override them) I concluded useless to study roots of every case, as well as got tired from checking pinmux settings and wire levels every time I connect new device to the system, and wrote small linux utility showing the punmux settings, GPIO configurations, and wire levels(if GPIO receiver enabled). Maybe it will be helpful in your case, to understand what is where: www.academ.org/~sv/epc/pinmux.pdf Serge -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Syntax in the tech ref manual question
C24 is this PRU RAM offset C25 is that PRU RAM offset Running code on PRU0 you address PRU1 RAM using C25. Same code if run on PRU1 will access the PRU0 RAM. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: r30 and r31 output/input only?
Just wanted to check, r30 is output and r31 is input only on the PRU? In short, yes they are. If you are about the In/Out use of the registers. There is much more. For example, R31 could be used as a zero source, for single-bit mask composition. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Relative branching on the PRU
Or is there something I am missing about scope on macros? I think, you are. The scope of the labels declared inside the macro declaration is the macro itself. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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 XCHG instruction problem
Hello group, I cannot understand of how the XCHG PRU instruction works (or cannot make it working as expected). I expect that XCHG 10, r1, 4 should exchange the contents of r1 with the scratch pad bank0.r1, 4 bytes: put r1 contents there, and get S-pad data, simultaneously. However I see the XCHG behaviour exactly the same as the XIN instruction, that is scratchpad is being read OK, but nothing is written to the scratchpad. The code: mov r1, 0x01 XOUT 10, r1, 4 // init the S-pad to value of 0x01 mov r1, 0x02 XCHG 10, r1, 4 // Make S-pad=0x02, r1 = 0x01 SBCO r1, C24, 0x00, 4 // r1 - RAM0..3, and I see the RAM0 = 0x01 - OK mov r1, 0x03 XCHG 10, r1, 4 // Make S-pad=0x03, r1 = 0x02 SBCO r1, C24, 0x04, 4 // r1 - RAM4..7, but I see the RAM4 = 0x01 - BAD! Should be 0x02 Could somebody please confirm that XCHG instruction works, or does not work, or how to make it exchanging the data reg-scratchpad? (no register shifting used: PRUCFG.SPP=0) Thanks! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How to find DDR physical address for passing data to/from pruss?
Most examples provided in the github are correct enough for me to use them. If you niticed any particular bug, please address it exactly. To access PRU registers, and PRU memory you should use the driver. The driver calls (like prussdrv_map_prumem) return pointers you can use to directly read/write PRU hardware. Ther resulting code might look like (writing to the local PRU RAM, from the client): static char *pruMem; ... pruMem[THIS_PRU_NUMBER] = 0; Another case is if you want to pass the DDR buffer address so that it will write there. The simplest case (IMHO) is to use the frame buffer /dev/fb0. Open it, find DDR mapping parameters, and pass to the PRU. On Sunday, May 11, 2014 11:57:31 PM UTC+6, ags wrote: What is the correct way to correctly use memory in userspace to access registers and memory used by device drivers (specifically the PRU in this case)? Is the example provided correct, both the app_loader helper code and/or the example applications? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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.
