Hard on the heels of the discussions around 2-line big fonts for the popular 2×16 character LCDs and set of 3-line numbers for the 4×20 character LCD, I decided to create a set of numbers that span the full 4-lines of a 4×20 display. The numbers are 20mm tall and, with the backlight, easy to read across a room. Ideal for clocks!
I downloaded and installed the recently launched Arduino IDE 1.6.0 and have been kicking its tires. So far, not bad. I especially like the addition of line numbers in the editor – a simple but very welcome addition. Anyway, I was playing with the latest SD Card library and came across a problem. It would appear that the “CardInfo” example sketch fails to calculate the capacity of SDHC cards over 4GB correctly, even though the stated capacity limit for Arduino support of SD cards is 32GB.
Now, you may not consider this to be an issue – bugs happen! However, I use this sketch to check all new SD cards so correcting the problem is a necessity! It’s also a useful lesson in checking variable type declarations.
As a follow-on from a recent post about creating large numbers on a 4×20 LCD, I have now completed a full big font character set that uses 2, rather than 3, lines of an LCD. This allows you to use these fonts on both the popular 2×16 and 4×20 displays.
This work is built upon an old “Instructable” article that was posted in 2010. Since then others have made many incremental improvements to the code and look of the big font characters (follow links and threads from the original article). However, I found that even the most recent designs still use SRAM to store the character sets and the custom glyphs used to construct them. As SRAM is a precious resource that should be used sparingly, my code has all of the character generation table driven and located in program space (see also my PROGMEM article on how to do this). This has freed up at least 700B of precious SRAM and the code overhead is minimal.
Back around Christmas time, my son Samuel and I designed and built an alarm clock with the unusual capability of waking him up with a pulsing bright light. To the RGB LED Strip Light Alarm Clock we added an IR receiver module and code to allow independent control of the LED strip using a readily available 24-key IR transmitter. In addition we also coded four special light effects.
Along with the 24-key IR remote that we used in the clock design, I have recently purchased a 44-key remote from eBay and have now mapped the transmitted IR code values for each key button. This makes it really easy to add IR control using a similar 24- or 44-key remote to any future project.
So, here’s a rhetorical question: What voltage/current curve is to reasonably expected from a rated power supply? (Note: I already ranted about a couple of 5V 2A supplies that failed to deliver, hence the “another” in the title.)
Your would think that I’d learn by now and shouldn’t be so pissed off when I test a power supply only to find it to deliver just a fraction of its rated performance. Case in point: I just took delivery of a rated 12V 1A switched-mode power supply (wall wart) that I bought on eBay. I plan to use it to drive a string of RGB LEDs so really wanted to get at least 0.7A at a supply of around least 10V – basically asking for about 7W, approx. 60% of its rated power delivery.
So, another rhetorical question: Is this an unreasonable expectation for a switched-mode power supply?
I suspect that for most users of Arduinos, the limited amount of data RAM (ATMega328 has 2KB) is a cause of concern, and with more complex sketches or for those using many libraries, a real problem. Now while it is often the case that there is plenty of program memory available (ATMega328 has 32KB) , the architecture of the ATM chip-set does not allow immediate access to this space. Yet there are many times when you need to store many constants and / or arrays of data or text (such as LCD character sets, MIDI program information, menus etc.) and it would be great to have these tucked away in program memory and not using any precious RAM.
While there are libraries of functions (Mikal Hart’s FLASH library, for one) to simplify the use of storing and reading data in the program memory, I like to understand what’s happening under the hood, so I hope you find this discussion helpful.
After I made the MIDI Drum I considered making new versions of the design to use different sensing technologies to trigger the percussion sounds. I tested ultrasonic modules as input sensors to the MIDI Drum software, but while they performed well I never bothered to complete a fully functioning prototype. Ahhh!
You see, I have always been fascinated by the laser-light organs (“Laser Harp”) that were made popular by Vangelis, Jean-Michel Jarre and other techno music artists “back in the day”. I particularly remember a video of Vangelis wearing white gloves in front of a fan of brilliantly coloured laser beams, ‘playing’ the organ by interrupting the beams with his hands. It was mesmerizing and sounded fantastic! [Just to show you that we are all fallible, here’s Jean-Michel Jarre playing his Laser Harp when it goes a little screwy. Tee hee!]
In the back of my mind I have always thought of creating something similar, using interrupted laser beams to activate different drum sounds. So, on the lookout for optical sensors I bought a couple of Sharp’s GP2Y0A21YK Infrared Proximity Distance Sensors, that operate over the range of 10-80cm. I found them on eBay for around $6US each. Neat!