One of the great features of the Arduino community is the availability of thousands of pre-written libraries that add hardware and other functionality to your projects without needing to write your own code. There are usually quite a few to pick from and your code will often depend on libraries, so the quality of the library you use can be critical to how your code performs. How do you write good libraries or how would you evaluate the quality of the latest library you downloaded?
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.
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.
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.