The LM3x series of sensors are precision, easily-calibrated, integrated circuit temperature sensors. These are ideal as a beginner sensor, only to disappoint when code is copied from somewhere, run on the MCU and the temperature readings seem to be wildly varying and incorrect. Why is this happening and what can be done about it? Read on.
A question on the Arduino forum and the thread that followed prompted me to try and emulate a mechanical push- or thumb-wheel display update on an LCD module. The technique uses the LCD programmable characters and could be extended to other applications for simple LCD module animations.
Once I started using rotary encoders to provide a ‘modern’ user input experience, the elimination of panel mounted potentiometers for circuit settings and other adjustments was the next logical step. Panel mounted pots have a very different feel from the clicks of a rotary encoder, and potentiometers cannot easily be controlled by a microcontroller.
Digital Potentiometers perform the same functions as mechanical pots but can be automated. So how do they work?
One of the great things about Arduino systems is they enable us to try ideas and experiment with concepts. At a software level this is simple – write, compile and download. Hardware components, however, can be more time consuming as you either have to wire up a temporary breadboard or you have to build dedicated circuits.
There is a simple way to make the hardware more ‘plug and play’ by building small modules with a simple standard interface that can be combined to create bigger systems. The outcome is a library of standard modules that are easily connected to the Arduino to prototype ideas without fiddling with breadboard wires for the simple stuff.
I was exploring ways to make a future robot project more appealing and came across a number of articles about animated robotic eyes created to convey expression or mood. This looked like a bit of fun and quite achievable using the LED matrix modules that I have been playing with for a while. Here’s the result.
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”