Building an RN52 Bluetooth MetaData Display with Arduino

If you want to get started with creating your own 16x2 HD44780 LCD display for interfacing with a Microchip RN52 or a Doayee BAL, use the buttons to find out more about our Arduino library, or the Bluetooth Audio Link project itsself.

To see the specific example sketch referenced by this post, click here.

You can picture the scene... an unexpectedly lengthy evening in the pub for the Doayee team leads to a morning on the sofa. Tom is hungry (what's new), Jacob doesn't really fancy investigating the problems on his latest design and Thom is putting off going to the supermarket. One thing we can agree on though is that this morning needs a soundtrack. One of us reaches over to the BAL that sits atop the stereo amp to turn it on.  Someone says "wouldn't it be nice if we had a little display for the song information" and that's how a "quick 30 minute task" took up 7 days of our spare time, developing a display system that had good features, was robust to all the very weird stuff the RN52 firmware does sometimes, and setting up a Doayee git repo along the way!

The screen was nearly an AXE133Y but that plan was quickly cut short when we couldn't find it. Instead we opted for the standard 16x2 HD44780 LCD, because what electronics hobbyist doesn't have one of those lying around without a purpose. After a 5 minute struggle of remembering how to wire such a thing up, we had a message displaying on the screen.

So, next question, what do we want this screen to actually show us? Our existing Arduino library gave us a fair amount of options. So we settled on the top line displaying the track title continuously whilst the bottom line cycles through four modes: artist, album, track count of total, and connected device. A few quick edits to the library made requesting this data fairly straightforward. A function was written in order to compare the MAC address of the connected device with a database of friendly names that could be displayed on the screen.

The procedure for requesting information from the RN52 leaves a lot to be desired. In many cases its' outputs don't match what Microchip have written that it should in their own guide. Sometimes, especially when requesting connection data, which includes the MAC address of the connected device, the output screws up for no particular reason, especially around a track change. If you then go ahead and try and use what it actually gave you for the screen display, it tends to break things as you pass unexpected (and frankly unreasonable) characters around the place. Some tinkering with the library had to be done to test that the string that it was about to return at least resembled a MAC address before going forward.

There are still some changes we'd like to make here. Currently our library functions for grabbing track and album data etc. involve grabbing all the metadata and parsing it for the relevant part. While this is fine in isolation, there is just no point in making calls like this consecutively, so we're working to get getMetaData to populate a structure from a single request instead. This hopefully reduces the chance of any crashes.... or maybe we're asking too much of the RN52 there.

At this point we had the screen displaying all the data we wanted when we wanted it to but with one caveat, only the first 16 characters of it - the make_str function in our LCD example sketch operates on all strings we want to print right before we do so in order to ensure that if the data is less than 16 characters, the rest is filled up with blank space so old characters from a previous track aren't left on the screen. Similarly if the string passed in is longer than 16 characters, it will truncate it at the correct point so it does not overflow onto the other line.

So how do we display more data on the screen. There's a remarkable amount of thought that has to go into scrolling text across a display like this. How do we control the scroll speed and mode changes independently. How do we ensure we don't start scrolling immediately and miss the first few characters? How do we wrap the string so that it begins to come back onto the screen after a few spaces, rather than the whole length of the screen which would just be annoying. This is where the getStringToDisplay function in our example comes in handy: each scroll_t object passed into it contains the raw string and an index representing which character in it should currently be at the leftmost side of the display. Then it works its magic truncating up to that point, adding a few spaces, and sticking the truncated stuff at the other end. Check it out...!

This article has only covered a handful of the consideration that had to go into making this have its basic functionality, and merely scratched the surface of making the thing work with the RN52 API without the chip freaking out and stopping the music stream. Now, we're releasing it to the world in the hope someone else can find some more bugs and hopefully fix them! Read more about the library by clicking here. Or check out our GitHub!