Lincomatic's Blog |
For the Adafruit RGB LCD Shield (MCP23017), I changed the GPIO writing from 16-bit to 8-bits. This increased the library size by 14 bytes, but it’s well worth it, because writing a 47-character string has sped up from 99ms to 76ms on my Arduino Duemilanove – that’s about a 25% increase! This is vs Adafruit’s RGB LCD library, which is 1.4K bigger, and takes 322ms.
Download: LiquidTWI2
Related Post: LiquidTWI2 – A Lean, High Performance I2C LCD Library for Arduino
I have released LiquidTWI2, a lean, high speed I2C LCD Library for Arduino. This library is an extension of the great work done by FalconFour on his LiquidTWI library. Notable additions to LiquidTWI:
LiquidTWI2 also supports the Adafruit I2c Backpack (MCP23008-based) in I2C mode. The library is a drop-in replacement for both the Adafruit LiquidCrystal Library (for the I2C backpack) and the Adafruit RGB LCD Shield Library. By replacing either of Adafruit’s libraries with LiquidTWI2, memory use will decrease, and writing to the LCD will become blazingly fast.
Installation:
Usage:
I2C Backpack or compatible MCP23008-based module
#include <Wire.h>
#include <LiquidTWI2.h>
LiquidTWI2 lcd(0); // 0 = i2c address
void setup() {
lcd.setMCPType(LTI_TYPE_MCP23008); // must be called before begin()
lcd.begin(16,2);
lcd.setBacklight(HIGH); // only supports HIGH or LOW
}
void loop() {
lcd.print(“Hello World!”);
delay(500);
lcd.clear();
delay(500);
}
RGB LCD Shield or compatible MCP23017-based module
#include <Wire.h>
#include <LiquidTWI2.h>
LiquidTWI2 lcd(0);void setup() {
lcd.setMCPType(LTI_TYPE_MCP23017); // must be called before begin()
lcd.begin(16,2);
lcd.setBacklight(WHITE); // see LiquidTWI2.h for color options
}
void loop() {
lcd.print(“Hello World!”);
delay(500);
lcd.clear();
delay(500);
uint8_t btns = readButtons();
}
Note that you must call setMCPType() with the correct module type prior to the first call to begin(). The module type can be switched at any time during runtime by merely calling setMCPType() and begin() again. This allows you to create a single firmware which can run with either module, and store the module type in EEPROM.
When working in a memory-constrained environment, you can save memory by disabling the unneeded support. Edit LiquidTWI2.h and comment out the #define for either MCP23008 or MCP23017.
For further speed gains, you can tweak the speed of the I2C bus. See the included i2c_perftest example sketch.
Download: https://github.com/lincomatic/LiquidTWI2/downloads
Related Post: LiquidTWI2 v1.1.0 Released
I recently backed Paul Stoffregen’s Teensy 3.0 on Kickstarter. Paul is a contributor to the Arduino project, and is the creator of the Teensy line of AVR-based Arduino compatible boards. Of all of the projects on Kickstarter that I have backed, the Teensy 3.0 was the by far the fastest to ship after the close of funding.
Teensy 3.0 is not currently listed on the PRJC website, as Paul is working on first fulfilling all of his Kickstarter pledges. However, if you are lucky, you might be able to score one via this hidden URL: http://www.pjrc.com/store/teensy3.html.
Unlike the its 8-bit brethren, Teensy 3.0 is based on a 32-bit ARM Cortex-M4 MCU, specifically, Freescale’s “Kinetis” K-series PK20DX128VLH5 (first batch, subsequent batches will be the functionally equivalent MK20DX128VLH5).
Here are Teensy 3.0′ technical specs:
All pins have interrupt capability.
* 14 Digital-only and 10 Analog/Digital pins are accessible around the exterior of Teensy 3.0, and available when used on a breadboard. 10 more Digital-only pins, and 4 more Analog-only pins are accessible at interior and bottom-side pads.
Note that that unlike Arduino, the I/O pins operate at 3.3V. This makes level-shifting a requirement if you want to interface to your existing 5V Arduino peripherals. On the other hand, 3.3V makes it ideal as a real-time I/O expander for the Raspberry Pi.
Like its other Teensy brethren, USB device support is built in. Software support for USB host mode is slated to be available in 2013.
My Teensy 3.0 arrived in a padded envelope via USPS. It came packaged with a handy pinout reference card, which shows the pinouts and their usages on both the top and bottom of the board.
I knew the reason that it was named Teensy, but didn’t hit me exactly how teensy it was until I unpackaged it:
As of this writing, the the software is in its 5th beta, and is distributed as a pre-configured Arduino 1.0.1 distribution. The download links are listed in Kickstarter Update #18: Fifth Software Update. After launching the Arduino IDE, select Tools->Board->Teensy 3.0. Once Teensy 3.0 isselected, an interesting menu becomes available at Tools->CPU Speed. The default setting is overclocked at 96MHz, which PRJC claims will run stably. You can also select 48 or 24 MHz.
The board is pre-loaded with the standard Arduino LED blink sketch. All I have tested so far is to verify that I am able to compile and upload the Blink sketch. Note that in Files->Examples->Teensy, there are a many of standard Teensy example sketches, but I’m not sure how many of them are currently working with the Teensy 3.0. The File->Examples->Teensy->Tutorial1->Blink sketch has the LED pin set to 11. In order to blink the onboard LED on the Teensy 3.0, you must change the pin number back to the standard Arduino pin 13. Like previous Teensy boards, the IDE launches Teensy loader to do the actual transfer to the board, rather than using avrdude.
Normally, it is not necessary to press the button on the board in order to initiate firmware upload, but it is there as a backup. Firmware upload is very fast, since the Teensy 3.0 has a native USB interface, rather than going through an FTDI Serial->USB converter.
I am looking forward to building projects with the Teensy 3.0, once I figure out a use for its extra horsepower.
I have adapted the Arduino AT90CANxx support to work with Arduino 1.0+. Also, I have moved the code to github, so that it will be easier to update. Note that the Arduino 1.0+ support is currently only alpha quality. I have compiled a few sketches, but I also have found some which currently can’t compile.
You can always download the latest version at https://github.com/lincomatic/AT90CAN
It is easiest to download the whole repository as a zip file: https://github.com/lincomatic/AT90CAN/zipball/master
Follow the instructions in the README file. For more information, see the post linked below.
Related Post: AVR CAN Bus Project – Step 1: Programming AT90CAN128 with Arduino
SeeedStudio was kind enough to send me a BLE Shield. Designed by RedBearLab and sold by SeeedStudio, the BLE Shield is a convenient way to experiment with Bluetooth Low Energy on an Arduino. Bluetooth Low Energy is a feature of the Bluetooth 4.0 specification, which is aimed primarily at low-power, low-latency wireless applications.
Here is a top view of the BLE Shield:
The tiny square SMT chip in the upper left is the Nordic Semiconductor nRF8001, a single-chip BLE connectivity IC.
The pass through headers support the extra pins on the new Arduino Leonardo. Currently, switch K1 should be left in the OFF position, as the OFF position is not supported. The bottom of the board is not particularly interesting:
Note that it connects to the ICSP header, and that the pins are not extended through the top of the board, so if you want to stack it with a shield that also needs the ICSP pins, you will have to put the BLE shield on top.
Currently, BLE support on host devices is patchy at best. On the Android platform, the Samsung Galaxy S3 contains a BT 4.0 hardware, but it’s currently not possible to program BLE, because the drivers are not yet available.
On Apple’s iOS platform, only the iPhone 4S/5, new iPad, and iPod 5th generation support BLE. What’s nice is that there’s full support in the iOS SDK. Unlike regular Bluetooth, for which very few profiles are available to the programmer in iOS (not even RFCOMM), you can easily design design your own custom BLE hardware and app. What’s more, with BLE, you can avoid the expensive MFi hardware program, and simply submit your app for approval.
I am not sure what kind of SDK support is available in Windows, but I have ordered a cheap BT 4.0 dongle to try on my PC.
To program the Arduino, you must first download and install the BLE Shield Library. To install the library, unzip the BLE and BluetoothLowEnergy folders into your <sketchbook>/libraries folder. There is a sample BLEFirmata sketch in the BluetoothLowEnergy/examples folder. It is compatible only with Arduino v1.0+. The BLEFirmata sketch allows you to read/write the Arduino’s I/O pins from a remote device. The current implementation of the library uses pins 8 and 9 for handshaking, so they are not available to your application. Furthermore, communication with the board is via SPI (MISO/MOSI/SCK) pins.
If you have a compatible iOS device, after loading BLEFirmata into your Arduino, you can go to the App Store, and download RedBearLab’s free BLE Arduino app. I installed BLE Arduino on my iPad under iOS6. When you launch the app and tap the Connect button, it automatically finds and connects to your BLE Shield. Unlike regular Bluetooth, you don’t have to go to Settings->General->Bluetooth and pair the devices (I wonder what happens if you have multiple BLE devices in the area, and how security is handled). Once the app finds your BLE Shield, it prompts you for the type of Arduino it’s attached to:
My Arduino Deumilanove is not listed as one of the options, but it works fine when you select Uno. You can read or write any of the I/O’s in realtime. If you select an analog pin, the app also gives you the option of treating it as analog or digital on input:
Here is the app displaying the value of pin A0 when configured for analog input, and the A0 pin is connected to the 3.3V pin:
Note that my USB cable is attached to the Arduino only to power it.
You can download the BLE iOS SDK and sample code from RedBearLab. Their website also has lots of other documentation, as well as a forum for getting help.
I am looking forward to implementing some projects with the BLE Shield in the near future.
I recently made the mistake of installing TwelveKeys by NCH Software on my computer. Afterwards, I noticed strange new items the context menus that pop up when you right click a file in Window Explorer. For instance, when I right clicked on a ZIP file, there was a new item, Extract with Express Zip. Since TwelveKeys is a program for music transcription, it didn’t occur to me that this strange context menu item came from installing TwelveKeys. Only after I googled Express Zip did I find out that it was installed by Twelvekeys. It turns out that a number of other people were irritated by NCH Software adding extraneous context menu items to their systems.
I immediately uninstalled TwelveKeys, and much to my dismay, found out that the uninstaller leaves the context menu items behind. Even worse, the context menu items all refer to software which gets uninstalled, so they point to a nonexistent file. I used regedit to search for “NCH Software,” and found well over 100 junk context menu items in left in my registry!
Here is one of the 20+ entries it installed for VLC alone:
The items all attempt to launch TwelveKeys.exe with argument -extfind to automatically download more software into your system.
It took me over an hour to manually search for and delete the garbage with regedit. This is a particularly insidious form of spam, and should not be tolerated. I will never again install any programs by NCH Software on any of my computers.
Chris H built and sent me a revised board for LeafCAN. The V2 board puts all of the components on the back of the board, instead of facing the LCD. By also eliminating all of the header pins (except for the ones used to connect the LCD), the assembly becomes considerably thinner than V1:
Below are my V2 and V1 meters side-by-side. The V2 meter is on the left:
The new circuit allows software control of the backlight, so I changed the firmware to turn off the backlight 5 seconds after CAN bus activity stops, and turn it back on when the activity resumes.
I also added a new feature, which I call “fixed fuel bars.” Recently, I noticed that the 12-segment fuel bar display in the Leaf’s dash is misleading and inconsistent. Even as your battery degrades, it always displays 12 bars at 100% charge, regardless of how much energy your battery can store. Over the course of 10K miles and 1 year of driving, my range has been dropping. Lately, I’ve been caught off guard, almost running down to turtle on 2 occasions, on a 66 mile drive that used to be easy. My SOC at 100% has dropped from 270 to 255 (I never got 281, even when the car was new). Another thing is, the car often only has the range with 3 bars remaining that I used to get with 2 bars remaining. So, I decided to make a new fuel display, which directly links the SOC and “fuel.” On my fuel scale, 13 = 281 gids, and the transition from 0 -> 1 is at 24 gids, which corresponds to Very Low Battery. The number is displayed with 1 decimal point. I put the zero point at Very Low Battery, because when the charge gets this low, we really need more precision, and should be using raw SOC values. Unlike the fuel bar display in the dash, the first bar contains as much energy as the rest.
I find it more convenient to use this new fuel gauge than SOC %, because I can easily do the calculations in my head while driving. When driving, I’ll count the number of miles for it to drop by 1, and then multiply it by the remaining count. For example, saw the car goes 8.3 miles when the “fuel” drops from 11.1->10.1.” Then I estimate that I can comfortably drive 80 miles given the current driving conditions.
Worst case for me is about 5 miles per fuel point, so when I want a conservative estimate of range, and I know I’m not going to be climbing any long, steep hills, I can just multiply the fuel number * 5 to estimate range.
In the photo below, you can see I’ve rounded the corners on the new case, and the slimmer design looks nicer. Also, I’ve switched to a 4-conductor white telephone cable, which is slimmer, and thin enough to squeeze in the gap between the left dash & the body. I’m able to use only 4 conductors, because this build is hardcoded to use only the EV bus, so the only wires I need are power/ground/CANH/CANL.
The top line displays: remaining pack KWh/SOC in gids/remaining fuel
The bottom line displays: pack voltage/instantaneous amps/instantaneous power draw KW (pack voltage * amps / 1000).
As usual, the latest code is available on github, and you are welcome to modify the display code to suit your own tastes.
My house has a crazy amount of sprinklers. In the front yard alone, there are 14 channels, which have been controlled by two very old Irri-Trol DewBee 7-channel units. I’m sure that they were fancy high-end stuff when they were purchased, but they look like they’re over 20 years old. Not only were they a pain in the ass to program, but for the past year, they’ve been flaky, watering on the wrong days. Another irritant is that they use a 9v battery backup which doesn’t last very long, so every time we have a long power outage, I’ve had to spend 1/2 hour reprogramming them. It was high time for a replacement, but I couldn’t find anything that met my all of requirements at the hardware store:
In addition, I thought it would be cool to be able to control it from the Internet, so I could change the settings if necessary, when away from the house. I recently started playing with my Raspberry Pi, and was looking for a project to do with it, as a way to learn the ropes. An Internet-connected sprinkler with a web browser interface immediately came to mind. The RPi seemed perfect for the task, with its built in Internet connectivity, SD card, and tons of RAM. One thing I’ve found with Arduino is that it’s easy to run low on memory when implementing web interfaces on it. No such problem with the RPi. The RPi doesn’t have enough GPIO pins to handle my 14 channels + an LCD display, but I figured that I could cook something up with I2C. The control aspect seemed relatively easy to handle, but then I started thinking about how much work the web interface would entail.
Before starting on my own DIY sprinkler, I decided to search for existing open source sprinklers and happened upon Ray’s Hobby’s OpenSprinkler. As soon as I saw it, I knew that I shouldn’t bother reinventing the wheel. OpenSprinkler is an Arduino-compatible system with:
Since I needed 14 channels, I ordered a DIY OpenSprinkler 1.4u kit ($89.99) and an extension board ($25.99). Pre-assembled SMT boards are also available at higher cost. Shipping was very fast, and I received a box a few days after I placed the order. The kit came nicely packaged, with bubble wrap protecting all of the delicate parts:
The components were also bagged in separate groups, which made finding the parts easier:
Ray’s Hobby has great documentation on their website. The step-by-step assembly instructions are very clearly written, with lots of photos, and easy enough for even a noob to follow. It took me about 3.5 hours to assemble both the main board and extension board, and one hour of that was spent undoing a careless error on my part. I inadvertently soldered 4 of the triacs on the main controller board backwards, and had to clip the leads and solder them onto the top of the PCB in order to reverse the connections. You can see in the photo below that the rightmost 4 triacs are all askew due to my messy rework:
The kit doesn’t come with a 24V transformer, so I salvaged one from one of my DewBees. The firmware is completely open source Arduino code, and is hosted on github. The controller has a built-in USBtinyISP, so you don’t need an FTDI cable or programmer to load the firmware. It comes preloaded with the latest release, so I didn’t test uploading new firmware yet.
Ray takes the cautious approach, walking the user through inserting only the switching regulator and testing the power supply voltages before inserting the remaining IC’s. After verifying the 5V and 3.3V supply voltages, I inserted the rest of the IC’s and to my delight, the unit powered up flawlessly on the first try:
The unit has a test mode that is entered by pressing and holding the top button while powering up. In test mode, it cycles through the channels, turning each one on for 5 seconds. I tested the triacs with a voltmeter, and was happy to find that I hadn’t fried any of them or messed up any PCB traces while doing my rework.
I mounted the units on top of my existing controllers by simply sticking them on with double-sided foam tape:
This way, I can revert to the old controllers when I sell my house. I’m not sure if the new owners will be savvy enough to figure how to connect it up to the Internet, figure out the IP number mapping to the unit, and then pull it up on a web browser.
For Internet connectivity, I’m using an old Linksys WRT54G in running DD-WRT in wireless repeater bridge mode. An added benefit is that I can now use my house’s WiFi from my driveway, where the signal was previously too weak. I have my router set up to assign a fixed IP to the OpenSprinkler. If you forget the IP number, pressing the 2nd button displays the current IP number and TCP port.
The web interface is a bit quirky, but it’s easy to use once you figure it out, and has a terrific graphical preview screen. The preview screen is actually one of the features that really sold me on OpenSprinkler, because it makes it very easy to check your programming for errors:
Ray cleverly gets around the limited memory of the ATMega328 MCU, and avoids having to have an onboard SD card by hosting a bunch of javascripts on his own webserver. This means that in order for the web interface to function, the unit must have Internet connectivity. You can host the scripts on your own LAN if you wish, but then you need to have a webserver running at all times.
I’ve only OpenSprinkler running for a couple of days, but so far, it’s running flawlessly. I am very impressed with the quality of Ray’s Hobby’s products and detailed documentation, and would definitely recommend them to my friends. Ray is actively working on improvements to the firmware, and since it’s open source, I’m able to hack it any way that I please.
I just backed the Teensy 3.0 on Kickstarter. It’s designed by Paul Stoffregen, the same wizard behind the Arduino-compatible Teensy boards. It sports a 32-bit ARM Cortex-M4 chip, and is programmable via Arduino and C. This looks like it’s going to be a great platform for building embedded projects that need more power than the typical Arduino. The board is tiny compared to Raspberry Pi.
Technical Specs:
At $22, it’s a bargain. The campaign ends on Sept 16, so get them while they’re hot!
My house isn’t wired for Ethernet, so I needed to get my Raspberry Pi networked via WiFi. USB WiFi dongles are cheap, and can easily be found for less than $10. I just happened to have an Airlink101 AWLL6075 laying around. By coincidence, it uses the RTL8191SU chipset, and the official Raspbian distribution is preloaded with the appropriate driver (module r8712u).
USB WiFi dongles use quite a bit of current, and some web references said that they could only be used with the RPi via a powered USB hub. However, some people reported success without the hub. I couldn’t find a working powered USB hub in my house, so I tried connecting my dongle directly to my RPi.
While googling around for instructions on how to configure Raspbian for my WPA2-PSK network, I found several different sets of instructions for configuration, and none of them worked. After wasting a whole afternoon with no luck, I found out that early RPi boards had 140mA polyfuses to limit current draw on the USB ports. In addition to limiting the current too severely, the polyfuses lower the voltage below spec. Therefore, later boards have 0 ohm resistors instead of the polyfuses. Here is an official blog post which shows that the later boards don’t have the fuses: http://www.raspberrypi.org/archives/1929
The fuses in question are F1 and F2. The polyfuses are green, and have 14 written on them. The 0 ohm resistors are black. If your RPi has the resistors, then you don’t need to modify it. My board had the polyfuses, so I shunted them by soldering in jumper wires:
Bingo! The WiFi fired right up and connected to my AP on the first boot after the fix.
The easiest way to configure the SSID and password for your network is to edit the file /etc/network/interfaces:
$ sudo nano /etc/network/interfaces
Add the following lines to the file:
auto wlan0
iface wlan0 inet dhcp
wpa-ssid “YOURSSID”
wpa-psk “YOURPASSWORD”
Substitute your network’s SSID and password in the quotes above. If present, remove the 70-persistent-net.rules file:
$,sudo rm /etc/udev/rules.d/70-persistent-net.rules
Upon rebooting, your WiFi should connect up automatically. If you want to start it without rebooting, type
$ sudo ifup wlan0
Here are some useful commands related to your WiFi configuration:
$ iwlist wlan0 scan
scans for and displays available WiFi networks.
$ iwconfig
shows WiFi connection info, such as ESSID, bit rate, and frequency.
$ ifconfig
displays network information, such as IP number, MAC address, and packet errors.