BeagleLogic[1] does some interesting tricks[2] to get a solid 100MHz sampling rate. The *PRU Cookbook* presents an overview of it. Check it out.
--Mark [1] https://beaglelogic.readthedocs.io/en/latest/ [2] https://theembeddedkitchen.net/beaglelogic-building-a-logic-analyzer-with-the-prus-part-1/449 [3] https://markayoder.github.io/PRUCookbook/01case/case.html#_beaglelogic_a_14_channel_logic_analyzer On Monday, October 19, 2020 at 5:25:45 AM UTC-4 Andrew P. Lentvorski wrote: > Hmm, that's an interesting idea, Dimitar, to encode the increment in the > immediate. That's probably ... useful. > > That mechanism would give me a 64-sample burst per register which could > possibly get me to 1920 samples *if* the SBBO doesn't stall out anywhere. > > I thought about the BeagleLogic, but it relies on the fact that every > other cycle is NOP, so it can effectively run something simultaneously at > half-speed in the interleaved time. > > Looks like it's time for some experiments. I'll report back if I see > anything interesting. > On Sunday, October 18, 2020 at 12:11:33 PM UTC-7 [email protected] wrote: > >> Hi, >> >> Do you require continuous 200MHz sampling? That would be difficult I >> think. >> >> If you require bursts of 200MHz sampling, how long should those bursts >> be? Even if you find autoincrement opcode, you would still need to add one >> jump instruction to "loop". >> >> You can try hardcoding the "increment" into the constant offset field. >> And load several registers with starting address of each 256-byte chunk of >> your destination buffer. Example: >> >> init: >> ldi r0, __buf_start >> ldi r1, __buf_start+256 >> ldi r2, __buf_start+256*2 >> ... >> burst_store: >> sbbo &r31, r0, 0, 4 >> sbbo &r31, r0, 4, 4 >> sbbo &r31, r0, 8, 4 >> sbbo &r31, r0, 12, 4 >> sbbo &r31, r0, 16, 4 >> .... >> sbbo &r31, r0, 252, 4 >> sbbo &r31, r1, 0, 4 >> sbbo &r31, r0, 4, 4 >> ... >> >> I am not sure what are the buffering limits of PRU's posted writes. I >> doubt if so many consecutive sbbo instructions would not stall. >> >> You should also examine BeagleLogic firmware's operation mode for 100MHz. >> Perhaps you can modify it to take 200MHz bursts instead of continuous >> 100MHz sampling. Difference with above single-PRU example is that you would >> use PRU register banks for buffering, which would decouple sampling from >> SBBO bus operations. >> >> Regards, >> Dimitar >> >> On Sunday, October 18, 2020 at 10:16:44 AM UTC+3 Andrew P. Lentvorski >> wrote: >> >>> Hi, folks, >>> >>> I'm trying to dump R31 over and over into either RAM0 or Shared DRAM >>> (Data RAM). >>> >>> So, basically it looks like I have to do: >>> >>> Store R31 to address in register >>> Increment address in register >>> (Lather rinse repeat) >>> >>> As that stands, that's a 100MHz sample of R31. Is there anyway to do >>> the autoincrement on the store? That would double my sampling rate to >>> 200MHz which would be the maximum possible. >>> >>> Alternatively, is there a different way to sample and store R31 >>> repeatedly to RAM0 or Shared DRAM? I can't seem to see one, but there are >>> so many permutation of Store Burst, mapping, the broadside transfer bus, >>> and peripherals that I can quite easily be missing something that someone >>> more experienced knows about. >>> >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c9c6d7a7-8da7-488d-9051-888a1901e41an%40googlegroups.com.
