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.
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?
Using the Parola library for double height displays is becoming increasingly popular with library users. Setting up the hardware and the library is not difficult, but it can cause problems if not done correctly. This article will explain the hardware and software setup considerations for trouble-free double height displays.
As the main function of the Parola library is to enable text animations, it is important to understand how these are set up and managed to completion from user code.
From a user perspective, Parola animation consist of 3 parts – setting up, running and resetting the animation. The process is not complex and is illustrated in the numerous library examples. This article breaks these down and explains how the Parola class methods apply in each phase.
The key function of the Parola library is to display text using different animations. These animations are built around a core supporting framework and largely follow the same patterns. This article explores how Parola animations code is constructed so that advanced users of the library have enough information to be able to write (and contribute!) their own new animations.