3 ms·

I love the PIOs, it's such a great idea. I've only used one to emulate a 4021 shift register being clocked at 100 kHz, which is light work compared to what they

by TillE 5y ago

I love the PIOs, it's such a great idea. I've only used one to emulate a 4021 shift register being clocked at 100 kHz, which is light work compared to what they're capable of, but still something an Arduino struggles to keep up with.

nomel 5y ago
I used them (PRU in Beaglebone) to implement e-fuse burning with JTAG (the chips stops working if you take a little too long) and MDIO (the interface for controlling a network PHY). My interesting battle story around this is that I first implemented the MDIO as bit banging in the kernel. This used quite a bit of CPU, which I wanted to use for other things. I switched it over to the PRU and CPU usage dropped to 1%. Great! But the data rate was much slower, with huge latency spikes. It turned out that the CPU usage was so low that the CPU governor thought the system was idle, so was throttling the CPU to just a few hundred MHz. I had to change the governor to keep the CPU clock to 100%, then everything was about 10x faster.
- Teknoman117 5y ago
  The PRUs in the beaglebone are way more flexible to be honest. Most of my effort with the Pico PIOs is squeezing everything to fit inside the 32 instruction limit.
  - synack 5y ago
    If you're short on PIO memory, the OUT EXEC instruction will execute an instruction directly from the FIFO. Feed the FIFO with a DMA channel and it'll keep up with the system clock. From the RP2040 datasheet section 3.4.5.2: > OUT EXEC allows instructions to be included inline in the FIFO datastream. The OUT itself executes on one cycle, and the instruction from the OSR is executed on the next cycle. There are no restrictions on the types of instructions which can be executed by this mechanism. Delay cycles on the initial OUT are ignored, but the executee may insert delay cycles as normal.
- dexterhaslem 5y ago
  is this open source? im using an am355x and would be interested in looking if so
  - nomel 5y ago
    No, sorry. I also don't have documentation that I can give. When I left the company, the Beaglebone community was pretty well into a C compiler, which is probably complete by now. There was also some coprocessor library being developed, to provide a nice interface to the host. It was all asm and kernel modules back then. I'm sure things are much easier now.
- fps-hero 5y ago
  It is very humbling to know I’m not the only person to have had to implement bit banged MDIO recently. If your PHY’s data sheet says clause 45 register access only and you don’t have GPIO access as the bus master, run away. Unfortunately I was tasked with emulating a clause 45 PHY on a clause 22 bus. Without creative use of the microcontroller peripherals, it is next to impossible to achieve implemented a 2.5Mhz slave. I had to use an edge interrupt to jump in to a while loop state machine, whose state was determined by a timer counter driven by the MDIO bus, with all GPIO acessd via hard coded bit banded GPIO. Fun times, but this is definitely an FPGA job.

by TillE 5y ago

nomel 5y ago

I used them (PRU in Beaglebone) to implement e-fuse burning with JTAG (the chips stops working if you take a little too long) and MDIO (the interface for controlling a network PHY). My interesting battle story around this is that I first implemented the MDIO as bit banging in the kernel. This used quite a bit of CPU, which I wanted to use for other things. I switched it over to the PRU and CPU usage dropped to 1%. Great! But the data rate was much slower, with huge latency spikes. It turned out that the CPU usage was so low that the CPU governor thought the system was idle, so was throttling the CPU to just a few hundred MHz. I had to change the governor to keep the CPU clock to 100%, then everything was about 10x faster.

Teknoman117 5y ago
The PRUs in the beaglebone are way more flexible to be honest. Most of my effort with the Pico PIOs is squeezing everything to fit inside the 32 instruction limit.
- synack 5y ago
  If you're short on PIO memory, the OUT EXEC instruction will execute an instruction directly from the FIFO. Feed the FIFO with a DMA channel and it'll keep up with the system clock. From the RP2040 datasheet section 3.4.5.2: > OUT EXEC allows instructions to be included inline in the FIFO datastream. The OUT itself executes on one cycle, and the instruction from the OSR is executed on the next cycle. There are no restrictions on the types of instructions which can be executed by this mechanism. Delay cycles on the initial OUT are ignored, but the executee may insert delay cycles as normal.
dexterhaslem 5y ago
is this open source? im using an am355x and would be interested in looking if so
- nomel 5y ago
  No, sorry. I also don't have documentation that I can give. When I left the company, the Beaglebone community was pretty well into a C compiler, which is probably complete by now. There was also some coprocessor library being developed, to provide a nice interface to the host. It was all asm and kernel modules back then. I'm sure things are much easier now.
fps-hero 5y ago
It is very humbling to know I’m not the only person to have had to implement bit banged MDIO recently. If your PHY’s data sheet says clause 45 register access only and you don’t have GPIO access as the bus master, run away. Unfortunately I was tasked with emulating a clause 45 PHY on a clause 22 bus. Without creative use of the microcontroller peripherals, it is next to impossible to achieve implemented a 2.5Mhz slave. I had to use an edge interrupt to jump in to a while loop state machine, whose state was determined by a timer counter driven by the MDIO bus, with all GPIO acessd via hard coded bit banded GPIO. Fun times, but this is definitely an FPGA job.