Bluetooth Module - R&D, Testing, and the Code that Makes Use of It.

A lot of trial and error with this board, and it wasn't necessarily the board's fault. When you have more than one component that has to be tweaked to work in a system, it's hard to balance and find a working solution. Add to that a third party, and you have chaos that leads to an endless stream of expletives and uncontrollably thrown f-bombs!

I had a fourth party even. Maybe even a fifth if you count Putty and Window's quirkiness. Hey! Let's just add enough butterfly-effect devices and software to a new system and hope for the perfect storm of conditions to make it work! No wonder my new projects take infinity to become born!

Anyway, all rants aside, I achieved success after spending almost a whole day working on it. And now that I have you wondering what the hell I am talking about, let me clue you in.


GOAL: Achieve serial communications through bluetooth with the Teensy 3.0. 
THE STAGE: Dell n7100 quad core laptop, Teensy 3.0, Kootek® BT2S Bluetooth to Serial Slave RS232 TTL UART Module Board for Arduino, Cable Matters 2 Pack, Gold Plated Hi-Speed USB 2.0 Type A to Micro-B Cable 6 Feet, PuTTY terminal program. 
END RESULT: Serial communications via interrupt service routines on the Teensy.

It actually took MORE than a day to get this right, but that was because I did a few stupid things in C that I normally do not do. Rusty I guess. 

First of all, I found that the 15' micro USB cables are great for my embedded work, but not very good for powering devices. After all, if you factor in impedance over length, and voltage drop, it's a miracle these cables offer enough juice to power a leaf! Yeah, right. A leaf needs no power, so there ya go.

Right out of the packaging and into the breadboard, wired to 5vdc and common ground, and its RX and TX terminals jumpered to a Teensy, the device powered up and greeted me with a fast flashing on-board LED. This is a confusing feature of the board. One would think that once it is paired with a host, the light would go solid, or change color, or SOMETHING! Instead, it just continues to flash which doesn't help you at all. It continues, at least until you open a channel to it, then it goes solid. I'm not sure I like this feature because such a bright burning LED when a com port is established isn't very friendly to portable battery sources. That's for another day.

The COM ports it uses is also confusing. Windows 7 shows two ports assigned. One for incoming and one for outgoing. It turns out that one COM is adequate for both. Windows gives you the option of changing this COM port designation but I left it the way it is. COM 6. Anyway, when I went to pair with it, it showed right up as a hardware looking graphic named HC-06. The device has a pin of 1234 as it's code so I used that, and I was paired!

WOOHOO! Now what? The problem I had the most trouble with is that the Teensy has 3 serial ports, but 4 usable. One was connected to the blue tooth module, and the other was the one emulated over the USB connection. The USB connected link proved to be the most troublesome for sure. But without a third-party USB to SERIAL device connected, I had to use this connection to talk to the Teensy directly from my laptop. 

The problem here is, the Teensy is also programmed via the same USB connection. Have an established serial connection through a COM interface, you run into issues with programming. In order to test changes in my code on the Teensy, I had to close my PuTTY session with it to take advantage of the AUTO programming mode of the Teensy uploader. This involved numerous closing and opening of sessions, answering confirmation pop-ups, and an arduous cycle of stop, close PuTTY sessions, change code, compile, upload, reopen PuTTY sessions, and test. There is no noticeable way around this so I just did it, uttering foul language along the way. 

After all this trouble though, I succeeded in typing in one session and seeing it in another. Both ways through both sessions. One session connected through the USB cable, and the other through the blue tooth wireless module. I was on my way!

Now for an off-road experience down a service road that branches from the main highway. You ready?

I have NEVER been happy with looped handled serial communications handling routines. Serial is a hardware experience and should be serviced via hardware interrupts! I had no clue how to do this with Arduino software so I was deep into a read-and-understand experience with the hardware and software. This is where our off-road vehicle hits numerous brick walls, fallen trees, and a few hikers along the way. No, metaphorically. No actual hikers were harmed during this R&D encounter.

As it turns out, and I have a wealth of thank you's for the lead software designer and creator of the Teensy for posting a long reply to a fellow on his forums. He explains how the Teensy 3.0 uses an ARM processor, not an AVR Amtel processor. One of the massive differences between the platforms is the handling of interrupts. Apparently, the chaps at Freescale eat their Wheaties before designing a processor, and actually listen to the embedded community. They took great care in designing a beautiful, elegant, and absolutely GENIUS hardware approach to handling interrupts in software. I could go on and on, offering countless lines of text detailing this ISR strategy, but it isn't suitable for this blog entry. I'll go further into it as I master it. 

Code coming soon when I figure out how to post it in blogger! =(

So now, my serial communications are handled via hardware timer interrupts, and I have four of them running now. One for communications, one for status LED, one for LED FX, and one for LED interface with the code. These interrupts sing together like boys in a choir and they sound great!

So now I need a command processor. That's where the software becomes a bit more complex, but there is processing headroom to allow for feedback, and a serial handshake experience that my eyes, and hardware, can live with. 

That brings me to NOW. I am ready to receive commands via blue tooth on the Teensy, process that command, and send back feedback as to success or failure. Once this command structure is solidified, the laptop role is replaced by the legacy Droid, running custom software, telling the effects system what to do and when. 

And that's for another blog. Stay tuned!

More when I design and code it.