This post outlines Stage 1 of a scalable, clock-driven 8-bit parallel data transport platform designed to establish high-throughput, multi-device processing pipelines using PRU subsystem nodes.
Instead of building a rigid, board-specific deployment, this architecture abstracts the data source entirely. Because data ingestion is strictly driven by an external hardware clock line (CLK), the transport layer handles raw data streams identically, whether interfacing a test transmitter node, an OV5640 camera, or an upstream processing unit.
The primary objective of this stage is to validate the underlying synchronous 8-bit parallel bus mechanics, firmware loop limits, and driver ring-buffer synchronization under a continuous, real-time workload.
Hardware Implementation:
The physical test bench routes the parallel bus pins across the expansion headers of two independent BeagleBoard hardware nodes:
- Transmitter Node: BeagleBone Black (BBB) exporting pre-selected, pre-encoded reference payload blocks over designated P8/P9 expansion headers.
- Receiver Node: PocketBeagle 2 (PB2) sampling the bus over matching P1/P2 expansion headers.
- Attenuation Matrix: A pin-correct breadboard circuit coupling the nodes via a series of 110-Ohm protection resistors. [1]
Signal timing evaluation using a ZOYI ZT703 handheld oscilloscope shows expected edge attenuation at 30 MHz. Rather than square waves, the clock line presents consistent high-frequency spikes. The receiver core relies on these sharp rising edges for precise state tracking.
Workload Partitioning and Firmware Design:
To guarantee a reliable 35ns per byte capture window without data corruption or loss of clock synchronization, the system split separates critical timing logic from OS memory management:
- Bare-Metal PRU Firmware: Written entirely in optimized C using the TI PRU optimizing compiler structures. The execution loop handles strict, cycle-accurate polling of the external clock line to sample input registers (R31 tracking) instantly on the rising edge. Loop unrolling and minimal variable overhead prevent compiler anomalies, achieving strict deterministic timing boundaries.
- Linux Kernel Driver: A native kernel module executing on the host core to manage a shared-memory ring buffer. The driver utilizes atomic context tracking structures (CTX) to synchronize memory read windows with the active PRU write pointers. This kernel-space abstraction completely bypasses user-space filesystem latencies and scheduling overhead, eliminating context-switch delays and cache misses.
Payload Integrity and Verification:
System performance is mathematically verified through a complete cryptographic loop. A unique SHA-256 checksum is calculated across the baseline payload on the BeagleBone Black. The PocketBeagle 2 captures the 29 MHz hardware stream silently to protect timing margins, flushes the raw binary bytes to local storage, and parses unaligned asynchronous frame boundaries using a host-side Python script to drop partial leading or trailing data fragments. Generating an identical SHA-256 hash on the recovered data proves a 100% bit-perfect transmission with zero dropped clock pulses.
Platform Roadmap Trajectory:
This layout operates as a functional stepping stone for modular processing chains:
- Stage 2: Direct 8-Bit Camera Ingestion (Integrating an OV5640 camera module directly into the clock-driven PB2 PRU receiver interface).
- Stage 3: Piped Multi-Node Processing Chains (Expanding the firmware and kernel driver framework across multi-core industrial SoCs like the AM62x, AM65x, or AM67x platforms to pipe, process, and transmit data sequentially via NEON and PRU coprocessors). [1, 2]
A detailed overview video documenting the physical wiring layouts, driver execution logs, and side-by-side verification baselines has been uploaded to YouTube.
Video Link: https://www.youtube.com/watch?v=xOOTbS9ZcHo&t=7s
The project repository is currently in a private deployment phase. However, access to the low-level C codebase, custom kernel driver modules, and schematic layouts can be shared with community members, developers, or engineering teams upon request for technical review.
Feedback on optimizing the PRU C loop structure further or handling higher frequency bus attenuation on the expansion headers is highly welcome.
