The Project board is for sharing projects based on Silicon Labs' component with other community members. View Projects Guidelines ›

Hi everyone,


Welcome to a new episode of my Bluetooth in Action series. In this episode, I'll be looking at the different ways you can program, or use, the BGM111 module. As you'll see, you have three choices.


 In order to understand the different ways of using the module, we first need to look at how Bluetooth modules used to be connected. Bluetooth modules were integrated modules containing a small microcontroller, but you never knew exactly what it was, because you didn’t have access to it. When powered, it would automatically initiate a start-up sequence, read some parameters from flash, and open up a serial port; mostly UART or SPI. From there, your hardware application would “talk” to the module using serial, sending instructions and receiving responses. Once your application had configured the Bluetooth module as needed, the module would then enter a specific mode, where instead of communicating instructions, you would communicate raw data to be sent on the Bluetooth link, and you would receive data from that link.


To be honest, that actually worked pretty well. It was a problem to develop for, though. Most of these adapters used the old-style AT commands, and you had to write your own API. It wasn’t particularly difficult, it just required string manipulation knowledge. The problem often came with what is known as command and data mode. When in command mode, the adapter accepted instructions, and responded to those instructions. Like “Tell me know many adapters are visible”, “Here you go”. Data mode was simple; each byte received on the UART was broadcast to connected devices, and vice versa. One of the most frequent problems encountered was when switching between these two modes; if something went wrong, and you didn’t check, then the next time you issued an AT command, instead of being processed by the adapter, the string would be broadcast to all connected devices, who probably had no idea what you were talking about.


There was another problem to this – end of life management. Manufacturers often brought out new models as they added features, and if your product had a lifetime of ten years, you would almost certainly need to use, and support, several Bluetooth adapters. There would also be a pretty good chance that their AT commands wouldn’t be identical, that you would have to change a few things along the way. After a few years, your code would probably look something like “if device equals this, then do this, else if device equals this, do this, else if device equals yet another device, then do yet again something else, else printf “whoops! Haven’t finished the API yet”. And what about clients that want a specific firmware version for whatever reason, but who need new hardware? Don’t laugh, I’ve been there, it isn’t pleasant.


Luckily, that’s all over, now your application doesn’t need to configure anything, the module itself can embark enough intelligence to take care of all the fine details, and your application can receive analysed and treated data, concentrating on what it does best. In some cases, the Bluetooth module can replace entire applications. So, let’s have a look at how we can use the module.




Programming method number one – BGAPI. The BGAPI protocol was designed to act as a communication method between an application and an external adapter. And while this isn’t exactly programming the module, it is worth mentioning. When Bluetooth modules were external, BGAPI was a way to talk with the module. The API was clearly laid out, and could be used to create your own libraries. It had two major advantages. Firstly, you could use the programming language that you wanted. If for some reason you didn’t want to use C, you could use something else. Since the API was always the same, you wouldn’t be writing a library for a device, but for a family, which brings us to the second point; compatibility. If your current device was end of life, then you would have to change modules. If the module used the same API (and, of course, had the same functionality), then you could simply swap the module for another one, and not change a single line of code.


So, that might be interesting, but since the BGM111 module has both a microcontroller and Bluetooth integrated, why would anyone need the BGAPI? Well, for the second reason, compatibility. If your application already uses BGAPI, you can connect this device, and use the functionalities offered by this module. That doesn’t mean that compatibility is guaranteed; if your original application uses Bluetooth 2.1 with EDR, you won’t be able to use it with a single-mode Bluetooth smart device. If, on the other hand, your application is a Bluetooth beacon, and records the Bluetooth addresses of modules that are close by, then you probably don’t need to change anything.


There is another reason why you would want to use BGAPI. My desktop computer is where I record videos, where I do most of my development… Put simply, it’s where I work from the most. I love having three screens. I also have two laptops, one is a powerful i7, but it still isn’t as comfortable as the desktop. The other is a tiny ultrabook that I only use for writing, it has an 11-inch screen, non-upgradeable memory, but even if it is a joy to use, I can’t use it to create this series. The laptops do, however, have a huge advantage, they both have Bluetooth 4.0 modules. MY desktop also has integrated Bluetooth, but it only has Bluetooth 2.1, I can’t talk to these modules directly, so I have to have a laptop close by. It would be so much easier to have Bluetooth 4.0 directly on my desktop. I could just go out and buy an adapter, but where’s the fun in that? So sooner or later, I’ll be connecting a BGM111 module via BGAPI to my desktop, and using that to talk with the other modules. I think that’s going to be a lot of fun. And since I don’t want to do systems programming, I’ll use an existing Python library, and have something up and running in no time.




Programming method number two - BGLIB. Since the BGM111 is based on a microcontroller, you would expect to be able to program it using C, just like you can with the entire EFM32 range. This is where BGLib comes in, it is an ANSI C implementation that allows you to access all the Bluetooth functionality, while giving you complete control of the microcontroller. Historically, BGLib was designed for external processors and microcontrollers, since at the time, the module would have been external, so it used BGAPI. Today, BGLib still exists, but this time it exists inside the microcontroller, and as surprising as it sounds, it still uses BGAPI. Once again, compatibility is key, there is a system that works exceptionally well, so why not keep on using it?


BGLib has one major advantage. By using a library written in ANSI C, you can create an application in C that has access to every part of your microcontroller or microprocessor; from simple things like activating GPIOs, all the way to FPU commands, and even routines in assembly, while using an optimized library for Bluetooth functions. The best of both worlds.


The BGM111 is no exception to the BGLib philosophy. Instead of BGLib being integrated into an external processor, it can be used directly on the BGM111 itself. It still uses BGLib, so you get to control your Bluetooth radio using simple C commands, but you also have complete control over everything inside the microcontroller, and the Cortex-M4 with FPU has a lot to offer.




Programming method number three - BGScript. If you want to use the BGM111 as a standalone device, then you can’t use BGAPI, and if you aren’t a C developer, or if you are frightened by all the low-level development that goes with Cortex-M programming, BGScript might just be what you are looking for.

[4-2] Let’s face it, C programming can sometimes be a bit daunting. Simplicity Studio is aptly named, but even so, some people don’t want all the fuss that comes with C. You might have an excellent idea for a future IoT killer application, but if you don’t know C, you’ll spend more time debugging than developing, and by the time you get your project out, someone might have beat you to it. Or you might be a seasoned embedded C developer, but you just want to prototype an idea quickly, to see how it reacts. Scripting to the rescue.


BGScript is exactly as the name suggests, a scripting language. It takes away all the hassle of startup code, memory allocation, interrupt handlers, and so on, and lets you concentrate on functionality. It is event driven, that is to say that while the environment does nothing, the script does nothing. It requires specific actions to process data, and those actions can be devices connecting and disconnecting, receiving data wirelessly, or GPIO interrupts, to name but a few.


By using a simple language, you can have an application up within under an hour. The script has simple instructions that can be used to make complex applications. If you are familiar with scripting languages like Python, you’ll be comfortable using BGScript. If you aren’t familiar with scripting languages, don’t worry, it’s easy to pick up.


Check out the next video in this series here.

  • Bluetooth Low Energy
  • Projects
  • Wireless