#####11/6/2013— [Jon McKay](/blog/"http://tessel.io/status" target="_blank">status page for details). Personally, I’ve been spending a lot of time getting the Bluetooth module ready for release.
In a previous post, we talked about what goes into the hardware design and assembly of a module. But that’s only the beginning. After we put the module together, there’s a long process of testing the hardware works and writing the entire library.
The first step is to make sure that hardware works like it’s supposed to. The chances of it working 100% right with the first revision is infinitesimally small, so we make it easier on ourselves by breaking out any questionable connections with headers so that we have more flexibility when we start testing. Headers give us the option of easily changing connections (with jumpers or soldering on wires) or verifying the signals on those lines with a logic analyzer. We use and love Salae’s logic analyzer which will decode any signals we send over the wire so we can be sure our communications are working as expected. On our first Bluetooth module, we broke out a block of headers (see picture below) for all the communication signals so that we can easily test the receive, transmit and wakeup lines on the BlueGiga chip.
The BlueGiga Chip is what’s known as a System on a Chip (SoC), which means it has a microcontroller as well as a Bluetooth chip (the TI CC2540) and all the passive hardware like capacitors and resistors to make it all work reliably. The smaller group of headers at the bottom of the module exists so that we can program the BlueGiga chip with their proprietary toolchain. That’s right, we not only have to program the Tessel to communicate with the Bluetooth module, but we have to program the Bluetooth module itself to be able to respond. But don’t worry, if we need to update the firmware on the BlueGiga chip once we ship out the module, we can update it from the Tessel.
The next step is to make sure we can communicate with the module. Tessel initially supported only the SPI and I2C communication protocols, but the BlueGiga chip that we’re using communicates over UART. Each communication protocol has its pros and cons but these three are by the far the most common. To be able to interact with the BLE chip, we threw a SPI to UART bridge onto the module. I began making sure communication worked with the bridge over SPI, but soon after, we decided to add UART support to Tessel modules, rendering the bridge useless. Luckily, the fact that we add headers on all the communication channels meant that I could bypass the UART bridge by just adding some wires from Tessel’s UART to the header block, so we didn’t have to pay to manufacture more test module boards.
Now we’ll need to update the Tessel Node Package with the new UART function calls that we’ve made. The Tessel command line tools automatically inject the Tessel library as a dependency when we push code, so we don’t have to worry about updating any references.