• The Making of a Module: The Dive from Hardware to JS

    Wednesday, November 6, 2013

    11/6/2013— Jon McKay

    The Technical Machine team is hard at work designing, assembling, programming and testing all the components of Tessel and its modules (see our 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.

    Next, I started working with the UART library and writing the bluetooth driver in C. I started working in C as opposed to JavaScript because BlueGiga provides a C library called BGLib that makes it easy to prove out the BlueGiga functionality quickly. I had to write and test the UART library in C anyway. We make heavy use of logic analyzers at this point to make sure the waveforms that are being sent between Tessel and the module look exactly how they should.

    Once the UART library was finished and proved out with the BGLib library, it was time to move on to JavaScript land. In order to do that, we tell our Lua runtime what UART JavaScript functions correspond to which UART C functions. It’s the layer of glue between the two worlds.


    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.

    This takes us up to about where I am now. I still need to port the BGLib library to JavaScript (or some variation of it) and write some abstractions on top of it to make Bluetooth transmissions as simple as possible. From there, it will just be revising the hardware schematic with any problems I found and squashing any bugs in the UART code. Easier said than done.



    #tessel #technical machine #bluetooth #ble #jon mckay #js on hardware #javascript #hardware hacking #open source #oshw

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013