Development Summer of (Bluegiga) Code

As anyone who has skimmed through my blog would know, I do a fair amount of work with Bluegiga’s products (the BLE112, BLE113, and BL121LR). Sometimes these are for personal projects, other times they’re involved in my startup consulting work. In any case, I’ve amassed (ahem… written) a collection of BGScript drivers, handy utility code, samples, and desktop/mobile apps to facilitate Bluegiga BLE development. I’ve put some of it on Github so far (here and here), but I still have a lot sitting around on various computers and in my head.

My plan over the next few months is to ensure that, not only is my source code available on Github, but that pre-packaged binaries are available for download, or my iOS and Android apps are on the app store to ease the transition for new Bluegiga developers who don’t know how to write apps.

I’m calling this, for lack of a better name, my “Summer of (Bluegiga) Code” - please note that Bluegiga has no involvement in this project, which is why I’m not calling it a “Bluegiga Summer of Code”.

Here are a couple of projects that I will be releasing this summer:

BLEGUI Log Parser

A very annoying aspect to BLE development is the mobile GATT caching layer. I know why Apple and Google do it, but damned if it doesn’t completely eff up my dev cycle.

I make a change to my GATT, and then spend the next 10-20 minutes trying to get that GATT change reflected on iOS or Android. Sometimes going so far as ruining my nice Nexus 7 by trying to use undocumented functionality (https://stackoverflow.com/questions/29179958/bluetoothgatt-showing-10-000-identical-characteristics-for-service).

Do I just turn Bluetooth on and off? Do I need to unpair? How many times should I cycle the power?

All I can say is that in a couple of years of BLE dev work, I haven’t found a deterministic way to make sure my GATT changes are reflected. Cycling the Bluetooth on/off -usually- works, but not always. And then, try sending updated firmware to a customer and telling them to cycle their Bluetooth to make it work… It’s insane.

Luckily (for my sanity), the Bluegiga BLEGUI app doesn’t do ANY caching (thank you BG, thank you so so much!). I can make a change and see it instantly reflected.

The downside of the BLEGUI app is that I can’t really use it for much else (other than OTA, naturally). Whenever I’m working with iBeacons and I want to scan advertisements, I’m stuck scrolling up and down that BLEGUI logger at the bottom of the app. Ridiculously enough, there is a fixed limit to the amount of resizing one can do to that console, so I can only see the past 3-4 advertisements. Given that I have about 10-20 active BLE devices around me at any time, that 2 inch logging screen is 95% useless.

To compensate for that, I whipped up a log filtering tool which runs alongside BLEGUI and I can choose to filter out everything except a specific MAC address or a handle (e.g. when enabling notifications on a specific GATT characteristic).

It’s still a little rough around the edges, and there are some small features I would like to add, however it’s streamlined certain aspects of my testing by about 50%.

[caption id=“attachment_880” align=“aligncenter” width=“1024”] Log Parser for Bluegiga BLEGUI - Ignore the window name in the image[/caption]

BGScript Remote Debugger (DEADBEEF)

If I had to pick the single most frustrating aspect of using BGScript, even moreso than the other limitations I’ve written about today and in the past, it would definitely be the lack of debugger.

Due to the nature of how BGScript is written and how it runs atop the TI CC2541, I cannot hook up a JLink to the board and breakpoint through my code to debug (like I do with -literally- every other MCU I use). This makes development tricky for anything but non-trivial projects.

Aside: An interesting recent experience. I inherited about 1300 lines of BGScript from a developer who had never used it before, and didn’t know some of its limitations. Inside this monstrosity of a project were things like a 5-tier, priority-inversion timer selection function to pick and run the 5 continuous timers, a 10ms period loop which ran 50-60 lines of code (thus, there was no possible way it was actually running every 10ms due to BGScript overhead), and a crazy bit-masking pattern to determine what was running and what wasn’t.

I was tasked to add features, however, the codebase was so unstable, that looking at the device funny would stop it from going to sleep, and other bizarre occurrences. Finally, I got fed up, so I re-wrote the entire codebase in 5 hours, removed all but 1 timer, and dropped about 25% of the code (after adding the additional features). The upside of this is that I developed some handy BGScript patterns which I’ve used time and time again, and they work out really nicely.

Aside aside, the point of the story is that in the original code, there was so much happening - and so many bugs, but it was really difficult to track them down, because I couldn’t breakpoint through the code.

A solution to this from the Bluegiga sample code is to use the UART to effectively ‘println’ and track your code that way, but this only works if the project exposed the UART lines in the first place (which the above project didn’t).

My solution to this problem was to expose a GATT characteristic that I could use as a remote debugging port - similar to a ‘println’ that works over BLE. Naturally, the GATT UUID is 0xdeadbeef (if you don’t get that, read this). Doing this works really well, however, you then run into the problem of how to actually read and track what is being exposed from that GATT.

In the image above, there is a ‘Debugger’ radio button. In this mode, the device tracks the 0xdeadbeef notifications and translates them to readable text. One feature I’m working on right now is to make that ability more generic, and let a user write custom translators and parsers directly in the app to manipulate the log data.

Additionally, I’ve written Android and iOS utility apps which handle the logger and translate the notifications into text. My Android development was stalled due to the StackOverflow post I wrote about earlier, but I will release my iOS app to the App Store later this summer.

Wrapping up

In addition to what I’ve written about, if anyone has any comments or requests, please don’t hesitate to ask!

Feature Photo credit: Paul’s Lab / Foter / CC BY-NC-SA