As I mentioned in a previous post, I bought a small variety of modules for interfacing to PICs. One of those is a Bluetooth Module. In all these years that I had known about Bluetooth, I had never actually checked out the story behind the name. Apparently it was named after some long ago Danish king named Harald Bluetooth. I thought maybe it had something to do with the fact that the antenna on a Bluetooth Module does sort of look like teeth and the circuit card is sometimes blue. Sure, make fun of me, but I bet you never would have guessed about the Danish king. Anyway, Bluetooth is a neat technology and there are lots of fun things you can do with your own Bluetooth card. So let’s take a look.
The picture shown here is typical of the Bluetooth modules available. When looking for one to buy, you can search on the terms “HC-05” and HC-06”. The differences between the two are in the firmware and usually in the number of pins on the board. The picture above is of an HC-06 module and comes with simplified firmware that only allows very basic configuration. It is also set as a “Slave” only Bluetooth device. In simple terms it means that it can only respond to commands from a “Master” device and cannot issue commands on its own. The HC-05 module has more configuration possibilities and can be set as either a “Master” or a “Slave” device. The HC-05 usually has six pins instead of just the four shown above for the HC-06. The State pin isn’t really important but the Key pin (sometimes goes by other names like “EN”) is required if you want to do any configuration. It should also be pointed out that the actual Bluetooth module in the picture above is the green circuit card. It is mounted on the blue circuit card which provides the pin outs and a 3.3VDC regulator. The Bluetooth modules are available in an unmounted form but I don’t recommend buying those.
Configuring the Bluetooth modules requires that you either buy or build an interface to an RS-232 serial port or to a USB port. I won’t cover how to build one in this Instructable but you should be able to find information on the web. Or just buy an interface. The configuration commands use AT commands sort of like what were used in the olden days with telephone modems. I’ve attached a user manual here that includes the AT commands for each module type. One thing to note is that the HC-06 requires UPPERCASE commands and the command string must complete within 1 second. That means that some of the longer strings for things like changing baud rates will need to be cut and pasted into your terminal program or you will need to set up text files to send. The UPPERCASE requirement is only if you are trying to send configuration commands. Regular communication mode can accept any 8-bits of data.
One of the nice things about the Bluetooth modules is that you can test them without needing a connection to a PIC or other microcontroller. The electrical requirements are shown above. You can then interface to the Bluetooth module with either your PC or with an app on your phone or tablet. If you use a Windows PC with a Bluetooth adapter, go into Devices and Printers and do a search for your Bluetooth module. The default pin number is 1234. After that, Windows should find driver software and assign two COM ports. Only one of the COM ports is for actual communicating with the Bluetooth so you may have to try both in your terminal program to find the right one. In your terminal program set the COM port to 9600 baud, 8 bits, no parity, 1 stop bit, and no flow control. In the configuration shown above, you should see every character you type echoed back to you. That’s because the Bluetooth TXD and RXD pins are shorted together. That means the Bluetooth receives the signal from the PC Bluetooth, sends it out the TXD (transmit data) terminal, receives it back on the RXD (receive data) terminal and broadcasts it back to your PC.
If you prefer to use a phone or tablet app, I can vouch that there are several available for Android. I’m not familiar with Apple products so you will have to check that on your own. The two I have used are “Bluetooth Terminal” by Juan Zambrano and “Bluetooth Serial Controller” by Next Prototypes. “Bluetooth Serial Controller” lets you configure a virtual keypad and set up your own command strings for each key. I’ll talk more about that in the next post when we actually use Bluetooth to control something. For testing purposes, “Bluetooth Terminal” is the one you want.
PIC Hardware Connections
Even though we don’t need a PIC to test the Bluetooth module, the diagram above and the supporting software are provided as a learning exercise and building block. As you can see, the Bluetooth transmit output (TXD) goes to the receive (RX) input of the PIC and the Bluetooth receive input (RXD) goes to the transmit (TX) output of the PIC. In effect the PIC is acting like the short circuit between the TXD and the RXD terminals we used in the previous step. Why would we do this, you may ask? It’s because it introduces us to a new area of the PIC – the asynchronous serial port. Most PICs, other than the 8-pin versions, have the serial port function and it’s a handy capability. Besides the Bluetooth module, I’ve used it for reading NMEA messages from a serial GPS receiver. USB may be king, but the old style serial communication is not dead yet.
The software link is listed below. While it is targeted for the 16F688, it is easily ported to other versions of the PIC. Just make sure that you choose one that has the asynchronous serial port capability. You will also need to change the line that identifies the PIC version (LIST=) and the INCLUDE file but those are intuitive changes. The __CONFIG line may also need tweaking just because one or two of the labels used are spelled differently in some of the INCLUDE files.
The software is really pretty simple because we just check for data input from the Bluetooth and then send it right back out to the Bluetooth. Init_Serial configures the port for 9600 baud (the Bluetooth default rate) and enables both the receiver and transmitter for asynchronous operation. Main_Loop just polls the receiver interrupt flag which gets set after receipt of a byte. If the flag is set then the data handler is called to read the byte and then check to see if the transmit buffer is available. If so, then it copies the received byte into the transmit buffer for output. In reality, the data is loaded into the transmit register and the PIC automatically loads it into the output shift register when it becomes available. The transmit interrupt flag will be set if the transmit register is empty, even if the transmit shift register is not empty. In this simple application we poll both the receive and the transmit interrupt flags instead of actually enabling them to interrupt the software. If we had a lot more stuff going on, like time intensive processing of the data, we would want to set up actual interrupt handlers. The Overflow routine is an error handler just in case we get more data bits received before we can read the register and clear the interrupt flag. That’s it for this post. Check out my other electronics projects.