Electrical – HC05 Bluetooth module: gpio pins usage

Self-test pin: Going by the description page of your breakout board, seems this pin would already be connected to a pull-down resistor, which thus disables the self-test feature. You don't need to change anything here.

Power-down pin: Must be driven to GND for the LPR550AL to operate. So put a solder-short or a wire between the Power-down pin and the Ground pin next to it. But alternatively, if for some reason, you want to use this pin to trigger the LPR550AL's Power-On versus Low-Power state on the fly, you can connect it to an Arduino pin (in your code, be sure to enable the internal pull-up, then write a LOW on it for LPR550AL Power-On operation).

Low-pass filters on outputs are for noise reduction. Your board, as designed, seems to already have them, so the board is ready to go. This is clearly described on the page that you listed in your question; please read such details on your original breakout board product page as well as the datasheet of LPR550AL before asking these questions!

VIN is your non-regulated input, and VDD is the regulated 3.3V that also powers the LPR550AL on the board.

Circuit: If, for whatever reason, you need a reference for setting up your own circuit (instead of using the breakout board), you can refer to this circuit diagram for the same board (source: bottom of [this Pololu webpage](http://www.pololu.com/catalog/product/1266 )). The circuit doesn't look too difficult, and the suggested capacitor and resistor values are fairly common ones.

Although the lines are routed as differential pairs, it's not necessarily a killer to your kind of application. The amount of crosstalk is actually still likely to be quite small, as diffpairs are often routed closer to the groundplane than to each other. It's not like they are a twisted wire with no shield, where the signals are effectively much better coupled to each other. And the traces are likely to be relatively short I imagine (if you are contemplating parallel transmission).

I would suggest you could happily set up a 25MHz parallel bus, with a series-terminated clock to signal the device at the far end to latch the data. Drive the data on one edge, latch it on the opposite edge, you'll have 20ns of time for crosstalk and reflections to settle out). You could drive the negative side of the clock driver to '0' and place it away from the databus to keep that signal as clean as possible. It doesn't sound that different from how we used to route asynchronous SRAM databusses (all the wires run very close together with an edge triggered write-enable line) and that used to work fine :)