In Part 1 I described the hardware components and the functionality of the LED clock. This this part, I’ll explore the software required to implement the functionality and seamlessly manage the different user interfaces.
I wanted a create a simple project to test a few ideas and still be useful in its own right. Walking through my local IKEA store, I saw a really inexpensive analog clock (Rusch) and decided that it would provide the right vehicle for what I had in mind.
In the last few projects I completed, I needed to find a way to process user commands arising from multiple input sources. A simple example would be a clock with tact switches and a Bluetooth interface providing identical functionality from either user input source.
For these applications I developed a simple modular and scalable approach that can be applied in other projects.
The amount of RAM an application uses is printed out by the IDE at compile time. For applications that don’t allocate memory, this is a really good guide to how much spare RAM is available at run time.
However, if an application, like any using the Parola libraries, uses memory from the heap, you need to make sure that there is sufficient memory left for run-time memory allocation.
Vertical LED dot displays are not a common requirement, but they can be created using the standard library with a few tweaks to the software.
As I get questions about vertical displays from time to time, I will cover the basic process of how this is done in this short article. Continue reading “Parola A to Z – Vertical Displays”
In the first part of this blog I described building a test apparatus that allows me to experiment with tuning a PID loop controlling a levitating pin pong ball in a tube.
This second installment is about trying different hands-on methods of tuning the loop, understanding how they are derived, and how well they perform compared to each other.
PID (Proportional, Integral, Derivative) control is a classic control algorithm that I have used for a few projects, ending with ‘good enough’ control, without really spending time learning how to properly tune the PID constants.
Time for me to fill in the gap in my knowledge, so in this two part blog I want to capture my learning. Hopefully it is useful for someone else. In this first part I will document the learning and testing rig and software. The next part will be about tuning the control loop.
In a previous post, I looked at creating reliable communications using Classic Bluetooth. While that approach works well, and is a reliable way to connect devices, there may be circumstances when a Bluetooth Low Energy (BLE) connection is preferable.
As it turns out, Bluetooth and BLE are about as similar as apples and oranges. The change in transmission protocol technology is more than a trivial change in the code and its structure.
In this article I explore the difference between BT and BLE and how the previous BT AI2 app needs to be adapted.
MIT App Inventor (AI2) is a web-based online graphical mobile application development environment for Android devices, where you can create an application by simply dragging and connecting a series of function blocks.
When researching the task, I found a lot of disparate information about how to write the Bluetooth management code for AI2. This information (some good, some wrong, and a lot repetitive) was synthesized it into a set of functions, described here, that provide a reliable communications interface to my project.
Despite the advent of source level debuggers for Arduino code, one of the most accessible ways to debug Arduino projects is still the Serial.print() statement. It is how most beginners will start when trying to debug their code.
But what do you do with all the print() statements sprinkled through the code once your application is working?