RN4678 Baud Rate Sensitivity FYI
This is an FYI for others experiencing issues with the RN4678 Bluetooth device. I hope this helps with some of the odd issues I've read concerning the RN4678.
First of all, I saved a lot of work by buying the RN-4678-PICTAIL. Using the PICTAIL, in only an hour or so, I knew what had to be done to talk to the chip and configure it for my needs. I needed to set the baud rate to 912600 instead of the default 115200, and I needed to set the Name so it showed up in the PC's Device List with a friendly name. So I highly recommend you spring for the PICTAIL.
We are using the RN4678 as a Bluetooth "wire" so to speak, i.e. SPP in Classic mode I think it's called. The point is, we're not Bluetooth experts, so we don't want to be doing a complicated Bluetooth Stack in software; that's a lot of code-space on a PIC. The PC connects, the PIC sees it, and starts talking, via the RN4678, to the PC. The RN4678 handles all the Bluetooth stuff for us.
We use Uart3 of a dsPIC33EP512GM710 running at 70 MHz (yes, it's a 70MHz PIC). We hook up the PIC's RTS/CTS to the RN4678's CTS/RTS, and the PIC's TxData/RxData to the RN4678's RxData/TxData. It may be obvious to most, but I point out the crossed PIC/RN4678 signal-names; RTS-to-CTS, and TxData-to-RxData. Uart-driven devices are not always consistent in their naming-conventions. It all depends on if you're looking at the pins from the PIC point-of-view, or the device's point-of-view.
On the PIC, we set the Uart to 115200 baud, configure the RN4678 for 912600 Baud, switch the Uart to 912600 baud, then we execute a do-forever loop that simply sends the '&&&' command to Enter Command Mode, followed by the '---' command to Exit Command Mode, and verifying the responses to both commands as we go. I use Uart1 as a Debug-Out Uart to a terminal window on my PC so I can watch the loop progress. I found that the loop would fail one of the commands every few (5 or 6) loop iterations. If everything is working correctly, it should NEVER fail, but I was getting MANY failures. This is not good!
So here's the analysis: I configure the PIC to use the internal oscillator so I can program it for almost ANY clock frequency. Everything else on our PIC-system uses 912600 Baud with a 70MHz PIC clock. But - at a 70MHz clock, the PIC cannot generate exactly
921600 or 115200 baud rates at the Uarts. The Uart's BRG is not hi-res enough to beat the PIC-clock to a precise baud rate. The actual bauds with our 70MHz clock are 921052 (Err of -548) and 115131 (Err of -69). In all our past projects (several with both a 33F and 33E PIC), that amount of baud error was acceptable and everything operated fine... but NOT the RN4678.
The closest PIC clock (without going over 70 MHz) that produced exact baud rates of 912600 and 115200 is 58982400. This PIC clock produced 0 baud Error at both baud rates... and the RN4678 is happy as a clam. We experienced no more dropped loop-iterations. So, apparently, the RN4678 is VERY sensitive to a mismatched baud, at least at the higher rates.
Just remember - when configuring your UART, the desired baud is not necessarily the baud you actually get, and the device you're talking to (via the UART) may not tolerate the difference, even a minuscule difference.
A couple years ago, I had to write a tool that beats PIC-clock frequencies against Uart baud rates to reveal exactly what's going on. It outputs the precise maximized PIC clock such that we get our desired baud rates, desired baud versus actual baud, the amount of baud error, and the magic-register settings to achieve the PIC clock and Uart baud rates. This single little trick (tweaking the PIC-clock) has saved our butts in UART-land, and CAN-land (another baud-sensitive protocol), several times.
I'm just sayin'.
post edited by jjones11 - 2018/09/20 21:11:23