If you are like me, you need energy to work. And sometimes, at the end of a long workday, it is just too long since you had lunch. In my office, I am not alone in this, so we made a vending machine with some chocolate, nuts and other snacks to help us get through the day.
The machine runs off an EFM32 STK and uses RFID to authenticate users and keep track of balances. It has a simple LCD-and-buttons user interface and a telnet interface over WiFi for adding users, products etc.
I have put up the source code and a description of the system on bitbucket if anyone is interested in making something similar:
In this episode of my Bluetooth in Action series, we’ll be finishing our first application. We might be coming back to this later when we learn a few techniques, but before we release version 1.0, there are a few things that need to be done.
The more we add to our code, the more we need to be careful that the code is readable. In the last episode, we wrote a few lines of code that are now difficult to read, because we can't remember exactly what we meant. Let's change that.
To make the application more useful, and to give it a more professional touch, we need to use a second timer. You can have a large amount of timers, you just need to provide a numerical timer channel. We'll add a timer, but the problem is, each timer uses the same event code, meaning that we need to have detection code inside the event. If event one, if event two... This isn't readable, and if we come back to this in a month or two, we won't remember what they mean. We can use the const directive to translate numbers into something more meaningful, for example, power_handle and alarm_handle.
Also, our code is beginning to get dense. If the same event code is to handle two different timers, then it would be best to separate them, by creating procedures. A procedure, like a function in C, or a def in python, allows you to create callable portions of code. There is a pitfall, however, the procedure itself must be written before being called, otherwise the compiler won't know what to do, and will abort with an error message. So, everything to do with the power LED timer will go into one procedure, and everything to do with the alarm timer will go into a second procedure. Inside the timer event, we can call these functions, depending on the channel, making things much easier to read, and more importantly, easier to come back to. Remember, when returning to a project, you won't remember everything that you did, and it is good practice to write code as if you were writing it for someone else.
Well, that's it for the luggage application, at least for now. You now have the software needed to get up and running, all you need to do is to fit it inside your hardware, and add an alarm. Let me know how it went for you, and I'll see you soon for some more projects. Bye bye!
The original contest proposal was to design small bluetooth low energy digital tokens, useful for prototyping board or card games.
The idea that tokens are useful as health counters, information tokens, or even just a cute updatable fridge magnet. I ended up doing an in-depth exploration of the image-sending component of these tokens. The below is a build log of how I got my computer to push simple bitmap images to my blue gecko digital "token".
After receiving my devkit, I set to work trying to modify the existing examples. Having no prior experience with SiLab’s 32-bit parts, I was somewhat surprised at how much effort was required to get the toolchain set up. Just following the start guide isn’t quite enough, I also needed to work through QSG120.
One huge thing that I somehow missed was that the EFR32BG only works with the IAR toolchain. That was quite disheartening; working with EFM8 parts feels like a much more polished experience as silabs licenses the required keil compiler for you. Unfortunately, the bluetooth stack & demo does not fit in IAR’s free “kickstart” edition, so I had to register for a 30-day trial. Originally, I had planned to develop a custom small digital token board, but since I couldn’t really justify buying a $3k+ compiler, I decided to just get the proof-of-concept working.
Getting to Hello World
Ok, now that setup's done, I had one last hurdle to clear before I could sink my teeth into the project. I wish that the “getting started” page linked to the necessary documents for getting your own simple application up and running. It’s great for getting things installed, but there’s no good “hello world” tutorial included. The best guide is probably just working through the official FAE training (also mirrored a bit in AN975). Working through that got me to a simple bluetooth example that echos to serial any writes over bluetooth.
Once I got something up and running, I read the full developer guide (UG136) to see how things in the stack fit together.
Picking the Protocol:
Similar to USB, in Bluetooth there are different “profiles” that devices can advertise and implement depending on their function. For instance, there is a heart rate profile, a battery status profile, and an human interface device profile. However, there’s no simple serial communication profile, which would have made streaming image data easier. To the internets!
The community seems to have standardized on an unofficial nordic UART service specification:
<!-- UART Service --> <service uuid="6e400001-b5a3-f393-e0a9-e50e24dcca9e" advertise="true"> <description>UART Service</description> <characteristic uuid="6e400002-b5a3-f393-e0a9-e50e24dcca9e" id="tx_data"> <properties write="true" /> <value type="hex" length="20" /> </characteristic> <characteristic uuid="6e400003-b5a3-f393-e0a9-e50e24dcca9e" id="rx_data"> <properties read="true" notify="true" /> <value type="hex" length="20" /> </characteristic> </service>
One nice thing about this unofficial standard is that vendors such as Adafruit have designed libraries and apps that specifically look for this service and allow me to easily communicate with my device.
With newfound knowledge in hand, my plan was to package up the images on the computer and send them over-the-air to the devkit through this UART service.
Sending an entire image bit-by-bit would take an unreasonable 100+ packets. In the interest of speed (and laziness), I chose to use a very simple Run-length encoding scheme. For each sent byte, the first bit encodes the color (0 for white, 1 for black), and then the next 7 bytes encodes the number of consecutive pixels of that color (0 - 127). A zero byte indicates the end of the sequence.
Typically, a characteristic value is allowed to be 20 bytes, but I was only able to write 18 byte bursts for some reason, so I decided to just run with it instead of trying to debug what was going on. The first byte in the sequence indicates the command (0x1 to clear the screen, 0x2 to draw a line), and the following bytes are the encoded image data.
We have one big non portable LC meter in the labor.
I would like to do something new, portable.
This is a low cost inductance and capacitance meter device. The main board is a SLSTK3400A with the EFM32 Happy Gecko Microcontroller and the measure module is a LC-meter 1.0 expansion board . The device can measure The Cx value between 0.1pF to 33mF(0.1 - 33,000,000,000pF), or Lx value between 100nH and 1H.(0.1-1,000,000uH)
The Expansion board contains the hardware part for the Smith-trigger oscillator, mode switch, button and banana connectors.
The full document is here: