Re: [beagleboard] Re: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

sdrv_get_phys_addr to get the physical address it > > seems to store to one contiguous memory and is limited to 8mb. > > > > I believe it is allocated contiguous from uio_pruss as well. > > > > > > On Friday, February 5, 2016 at 7:33:59 PM UTC-5, Bill Gray wrote: > &

[beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

Hi, I've got PRU0 of my BBB pulling in 12 Bytes of data from a ADC with a sampling frequency of 31250hz. I want to stash all of this data in an array that lives in DDR memory. I would like to make the array 0x4000 bytes (16kB) large. This would give me 1365 12 byte records and about 43ms of

[beagleboard] PRU direct to McSPI?

Hi all. I'm trying to cram a lot of realtime work onto a single BBB, and things are getting tight. I've *fully* consumed PRU1 and I've got a lot of realtime work left to do. One of the things that I need to do is to get a bunch of ADC readings. Specifically I need to get 5 12-bit readings o

Re: [beagleboard] Re: PRU DISABLE and RESET.

program around both of these possible eventualities... which is going to be a decent piece of work that I was hoping to avoid. Oh well... Thanks for your insight/suggestion. Bill On Tue, Jan 12, 2016 at 12:16 AM, Karl Karpfen wrote: > Am Samstag, 9. Januar 2016 02:05:01 UTC+1 schrieb Bill G

[beagleboard] PRU DISABLE and RESET.

Hi, I've been working on some code and I have come across a tricky behavior in the PRU. Basically I don't seem to be able to gain complete control of the state in which the PRU starts up!!?? My code runs in a continuous loop and wiggles various pins via r30. When I start the code up, or re-s

Re: [beagleboard] Re: PRU Clocks phase shifting with respect to each other??

essage 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/zhCplP-SEok/unsubscribe. > To unsubscribe from this group and all its topics, send an email to >

Re: [beagleboard] Re: PRU Clocks phase shifting with respect to each other??

r, and you'll have single > clock cycle accuracy. The PRU will always have at least a few > instructions of uncertainty since it takes more than one instruction > to sample the value and capture the current "time". > > On 12/23/2015 4:02 PM, Bill Gray wrote: > &

[beagleboard] Re: PRU Clocks phase shifting with respect to each other??

You are trying to generate and measure on the same clock edges. Very tiny > time shifts can move you a whole clock cycle. > --- Graham > > == > > > On Wednesday, December 23, 2015 at 1:27:22 PM UTC-6, Bill Gray wrote: >> >> Hi, >> >> I am trying to debug

[beagleboard] PRU Clocks phase shifting with respect to each other??

Hi, I am trying to debug a weird behavior. I have code running on PRU 1 that creates a specific waveform on 8 pru output pins (pru1_0 - pru1_7). I am trying to confirm the accuracy of my PRU 1 code by running code on PRU 0 that watches the pins on PRU 1 (physically linked) and measures their

Re: [beagleboard] Setting GPIO Values "from cold" startup???

Dec 15, 2015 at 2:52 PM, Bill Gray > wrote: > >> Gerald, >> >> Thanks so much. >> >> How interesting! I suppose I can just cold boot the BBB and see which >> pins are where to figure out where things start, but I would love to read >> up more o

Re: [beagleboard] Setting GPIO Values "from cold" startup???

lls you the default for all the pins on power up. Some are > high and some are low. Until the SW changes that, they stay and the preset > levels. > > http://www.ti.com/product/am3358 > > > Gerald > > On Tue, Dec 15, 2015 at 12:04 PM, Bill Gray > wrote: > >> Hi

[beagleboard] Setting GPIO Values "from cold" startup???

Hi, I'm developing a system that uses PRU 1 to send a PWM to a switched mode power converter. When I first turn the system on, I want the PWM signal to be low. If the pin is high, I will pretty much surely blow my mosfets as current surges through my circuit. For some reason, when I first tu

[beagleboard] Using pruDebug to modify register values?

I've been hacking away on the PRU and finding prudebug to be a fabulously useful tool for stepping through code. Has anyone had any luck using the WR or WRD commands to modify data in the PRU registers? I haven't been able to figure out how the offsets are working. They don't appear to be re

Re: [beagleboard] Re: Does BBB have a running counter that I can access?

up in /sys/devices/ocp.3/ but how do I make use of them? Answers to any of these questions would be super helpful! Thank you, Bill On Tue, Feb 3, 2015 at 7:35 AM, TJF wrote: > When this is your aim > > Am Montag, 2. Februar 2015 21:40:19 UTC+1 schrieb Bill Gray: >> >> ..

Re: [beagleboard] Does BBB have a running counter that I can access?

ctually a 1Ghz clock, but rather a 25Mhz clock. This is all fine for my purposes, but I'm really not sure how it is that DMTIMER2 got turned on, or how to turn on the other DMTIMERs. Thanks, Bill On Mon, Feb 2, 2015 at 12:40 PM, Bill Gray wrote: > Hello, > > I'm writing a

[beagleboard] Does BBB have a running counter that I can access?

Hello, I'm writing a program for the PRU to determine the RPM of motor and do a number of other things as well. Instead of having the PRU run a loop of pre-determined length to meter time, I would prefer to be able to access some hardware counter that is ticking away to see how many ticks have

Re: [beagleboard] Re: What happens if PRU & host try and write same memory address at same time?

> > > On Friday, January 16, 2015 at 1:58:33 PM UTC-5, Bill Gray wrote: > >> >> The idea is that the host program is constantly setting an address in >> shared memory to 0 in a loop. The PRU is also constantly incrementing that >> same address. If the host loop stops,

[beagleboard] What happens if PRU & host try and write same memory address at same time?

Hi, I've been writing a program to have the PRU on my BBB manage a switched-mode power converter. I want to make sure that if something goes wrong in the host program the power converter is shutdown gracefully, so I have implemented a simple "watch dog timer" scheme. The idea is that the host

Re: [beagleboard] Re: PRU - Low Latency I/O

Great! Thanks so much for the help. Bill On Sun, Nov 2, 2014 at 4:15 AM, TJF wrote: > > > Am Sonntag, 2. November 2014 01:40:22 UTC+1 schrieb Bill Gray: >> >> Am I correct in assuming that the low latency pins are specific to one or >> the other PRU? For ex

Re: [beagleboard] Re: PRU - Low Latency I/O

wrote: > Hello Bill! > > I'm dealing with PRU stuff since month, creating the libpruio > <http://beagleboard.org/project/libpruio/> library. > > Am Freitag, 31. Oktober 2014 18:00:03 UTC+1 schrieb Bill Gray: >> >> I'm wondering if there is some special way

[beagleboard] PRU - Low Latency I/O

Hello All! I've recently begun digging into the PRU for a realtime project that I am working on. I have found tons of helpful information out there, and I am now up and running with PRU programming! Yay! One of the great resources I've found was this video of Jason Kridner talking about BBB

[beagleboard] Re: What is smallest period for PWM?

Thanks Karl. Right on. So a 50Mhz frequency with a 10ns pulse should be possible! Great! Have you been able to observe such a waveform on your BBB? The issue that I am having is that I can't get the pin on the Beaglebone Black to move nearly that fast! Right now, a 10,000ns pulse hardly e

[beagleboard] What is smallest period for PWM?

So, I've been playing around with PWM, and I would like to have one PWM channel drive a buck circuit and another channel drive a boost circuit. The magnetics that I am looking to use would like to be driven in the 100-150khz range. Mosfets to drive this are not a dime a dozen, but perhaps $10/

Re: [beagleboard] Re: How to get PWM working with latest Debian image?

Mark, Thanks so much! That tutorial did the trick. I was not submitting am33xx_pwm to the cape manager. I'm still not sure what it is, but no matter... it works now! Thanks again. Bill -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are

[beagleboard] Re: How to get PWM working with latest Debian image?

Update #1 Using this tutorial... http://www.linux.com/learn/tutorials/776799-servo-control-from-the-beaglebone-black/ I have found the device tree overlays in /lib/firmware, and I think that I have successfully loaded bone_pwm_P9_14 and bone_pwm_P9_16. I think that this is successful because

[beagleboard] How to get PWM working with latest Debian image?

So, I'm trying to get PWM up and running on my BBB. I've spent a good deal of time trying to track down instructions on the web, and found a whole bunch of stuff... but none of it seems to be applicable to my particular system... nor do they appear to agree with each other? I am running the l