Trade speed for inputs?

[jedahan]

Is it possible to double the amount of inputs in exchange for halving the sample rate?

I skimmed some of the firmware files and its way over my head, but it seems like the reference guide alludes to the fact that with both PRUs active, you should be able to access 34 pins using direct connection mode, or 32 pins using 16 bit parallel capture mode (+ 1 pin for an external clock). I really am not sure if I am reading or understanding things correctly though.

I am trying to sniff a famicom (6502 game console). Its got 8 lines for data, 16 for address. 5V logic. Is there a remote possibility of me being able to modify beaglelogic enough to support sniffing reliably if the clock of the famicom is around 8Mhz? I would love to manufacture or buy a cape to try this out...

[abhishek-kakkar]

To be able to reliably capture 8 MHz signals, I'd use a sample rate of at least 3*8 = 24 MHz.

Currently the firmware of BeagleLogic works this way: one PRU samples the input pins, the other PRU writes it to buffer. I wrote this blog post recently which might help you understand the firmware working in a bit more detail: http://theembeddedkitchen.net/beaglelogic-building-a-logic-analyzer-with-the-prus-part-1/449

16 inputs can be used if you disable the eMMC and the serial debug header that contains the 2 most significant bit inputs of PRU1 with a little modification [there are buffers on the serial debug pins].

About both PRUs sampling independently and writing to RAM, there could be a problem if there are bus collisions. I am not sure how successful it can be, but the best way to find out would be to try it.

To add more pins, the pinmux entries in the device tree also needs to be modified to route the extra pins to the PRU inputs.

Since the clock here is 8 MHz, I wonder if building something like a serializer could be useful here to, say, double the clock speed to 16 MHz while dropping the number of pins sniffed to 12 [ the converse of what you proposed], which can then fit within the number of inputs to be sampled?

[jedahan]

Ahh that article is really informative. OK I will try throwing a few PISO shift registers in between and see how that works. Any estimate for the next batch of capes or should I just send the current design to a one-off fab?

[jedahan]

While accessing the DDR RAM there is a very low but finite probability of bus conflicts while data is being written, and having such an instruction within the real-time sampling loop has the potential to compromise the sampling operation. So we would like to separate both of them.

Is this documented somewhere / where could I get more information in understanding how the bus conflicts will happen and if there's a way to avoid them.

Also, will the bus conflicts be possible even when writing to RAM 0,1, and 2, because they go through the interconnect bus anyway? Or is there some reason those could be safer than writing to DDR RAM?

[abhishek-kakkar]

While accessing the DDR RAM there is a very low but finite probability of bus conflicts while data is being written, and having such an instruction within the real-time sampling loop has the potential to compromise the sampling operation. So we would like to separate both of them.

Is this documented somewhere / where could I get more information in understanding how the bus conflicts will happen and if there's a way to avoid them.

Documentation on this is very scarce, the only source being the AM335x reference manual. There is very little information publicly available on how the interconnects within the SoC work, so that line is just being paranoid about it, I haven't found a test case yet when this happens.

PRU RAM 0,1,2 are internal to the subsystem, conflict could only happen if there is a write collision between the two PRUs otherwise it should be fine.

[abhishek-kakkar]

BeagleLogic standalone was a PoC designed in 2017 that supported the full 16-bit PRU sampling part, but hasn't moved past the prototype phase yet. Input gearboxing (less inputs, more sampling rate; or more inputs for less sample rate) in theory can be done using a FPGA with BeagleLogic being appropriately aware of how the inputs should appear.

Marking the issue closed because it's been a long time, please feel free to reopen a new one in case clarifications are still needed.