Coding is Important but so is Hardware
BTW, Audible Rocks!
This Bluetooth serial link is nothing new. I had it working on the existing setup to send data from the ReactorForge control board to the Processing visualization program. The HC-06 Bluetooth module enabled me to see the live telemetry coming from the ReactorForge. That helps you to understand what is going on and tweak parameters such as the PID settings.
I’m excited to get the entire development process in one operating system. Before, I was bouncing between macOS, Windows in VMWare Fusion on the Mac, and a separate Windows machine. It’s a long story, but this was partly due to the Windows-only compiler I used at the time. Other shortcuts I made early in the process just to get things working enough to get the induction heater to Daniel’s shop also helped put me in that spot.
Getting the HC-06 Bluetooth to Serial module working on macOS wasn’t hard, but I did have one issue. The HC-06 seemed to just disconnect randomly after a minute or two of being connected. Then when I would try to reconnect to it, the port would be busy. I knew it wasn’t busy or open using lsof | grep HC-06 or whatever your’s is named, Reactor-Link in my case.
I fired up Windows in VMware Fusion and paired the HC-06 Bluetooth module. Then I opened a connection to it using a terminal program. I also began a screen session (terminal) on the Mac side with a USB to serial adapter. The USB serial adapter was connected to the HC-06 Bluetooth module to monitor it (and send data from it).
Anyway, this worked fine, and the HC-06 Bluetooth module never lost connection on the Windows side. I did notice that on the Windows side, the HC-06 Bluetooth module asked me for asked me for the pin number during the pairing process, but it did not ask on the Mac side. I removed the device from on the Mac side in the Bluetooth manager and re-Paired it. To my annoyance and relief, this fixed the disconnecting issue. Maybe I changed the pin in the past since the last time it had been connected to the Mac.
So this is the simple test setup. The photos say it all I think.
With that working, I’m going to work on the libraries now. I’m looking at whether or not to get the existing libraries working in the new environment or use new libraries. I’m leaning toward new libraries because there are quite a few compiler warnings and even some errors from the old ones. I’ll have to update function names and setup code, but I’d prefer to start with something cleaner and updated. I’m pushing it all to GitHub as I go!
The astute reader might notice that I am using the /dev/tty.* version of the device rather than the /dev/cu.* version. So, what’s the difference? TTY devices are for calling into UNIX systems, whereas CU (Call-Up) devices are for calling out from them (e.g., modems). We want to call-out, so /dev/cu.* is the correct device to use.
The technical difference is that /dev/tty.* devices will wait (or listen) for DCD (data-carrier-detect) e.g., someone calling in, before responding. /dev/cu.* devices do not assert DCD, so they will always connect (respond or succeed) immediately. Since neither the HC-06 Bluetooth module or the USB to serial adapter support DCD it’s not an issue. Still, following best practice, you should use the correct port.
So why did I use the wrong one in the photos? I switched to /dev/tty.* when I was having the connection issue and just forgot to switch back before documenting it.
If you follow the GitHub repository https://github.com/ThingEngineer/ReactorForge by clicking [Watch] you may have noticed work on the firmware. I’ve begun setting up the new development environment. Going forward, I don’t want to deal with switching to Windows to work in AVR Studio. I never liked that environment anyway. I had talked about possibly moving everything into the Arduino environment because of its popularity, however that has its own set of issues. For starters, support for the AT90PWM family of chips isn’t there, and I don’t want to spend the time to add it. Then there’s this:
Arduino is a great prototyping platform and IDE to get started on if you have never worked with microcontrollers. As a beginner, it can get you building projects faster than any other platform out there. But eventually, the features that make it convenient and easy to use can hold you back. It lacks many features which make writing code quicker, easier, and have become quite standard in modern text editors. There are also bits of code that get inserted into your code that can cause some very head-scratching issues.
The next logical step is to leave the Arduino IDE behind. We do that by working in a more fully-featured development environment. Atom + PlatformIO is my new favorite open source cross-platform IDE. It even comes with the Arduino framework among others. That lets you test drive it with a code structure you are familiar. When you are ready, you can remove the training wheels and go full native C++. There is so much more I could brag about with both of these tools. But I’ll let you discover the awesomeness yourself!
What’s next? I’m going to begin porting over the libraries used in the existing project. Then the main code, and start rewriting, optimizing, etc. The photo above is a test rig I used for setting up the new IDE. I will continue to use it throughout the porting process. Once the code is stable in its new environment, I’ll switch over to the ReactorForge!
I had also planned on using this setup to demo and explain the basics behind the AT90PMW software PLL setup. I’ll get to that but for now, it’s back to work in the new development environment!