Hacking the TP-Link TL-WR703N – Part 1: Brick it and then hack its serial port

I’m working on an embedded project that needs to be able to run node.js over WiFi. There aren’t too many cheap boards that can run linux. The $25 Raspberry Pi and the discontinued Pogoplug V2, which can be had for about $15 immediately came to mind. However, each of these boards had their shortcomings.  The Pogoplug is discontinued, so it may not be available in the future, and also, the PCB is rather big.  Neither of them has  built-in storage, and while both of them can take cheap <$10 USB WiFi adapters, the usable range is rather short.  Adding a power supply and a better USB WiFi adapter can easily drive the cost up by another $25. I recently discovered that the Arduino Yun, which has built-in WiFi, embeds an AR9331 processor.  The Arduino Yun is much too expensive, so I wondered if AR9331‘s could be bought separately. It turns out the answer is no, but then I discovered the vary hackable TP-Link TL-WR703N. A lot of hardware hackers are loading OpenWrt into this cute little WiFi router, and taking advantage of the many precompiled packages that are available. While node.js isn’t currently officially supported, I found that Giorgio Cefaro had gotten node.js running on an Arduino Yun. The Yun runs linio, which is based on OpenWrt, and since it uses the AR9331, I’m hoping that I can use his precompiled packages on my TL-WR703N.

I put “TL-WR703N” in to Amazon.com, and found it for $19.99 – what a steal, I thought. When it arrived, I found out that I’d ordered a TL-WR702N by mistake (grr.. Amazon for returning the wrong model in my search), which uses the same processor, but has much too little flash memory to load OpenWrt, and doesn’t have a USB port. Oh well, it works very well as a low-power WiFi client. I took it out to my garage, which is very far away from my AP, and was amazed that it worked as well as my Linksys WRT54G, which has dual external antennas! Furthermore, the TL-WR702N is has very flexible firmware, which allows it to act as a portable AP, repeater, etc. A great little device to carry around on trips. But I digress …

I ended up buying a TL-WR703N on eBay for $23. It came with Chinese firmware, but I was able to load OpenWrt following the instructions on the wiki page.  Much to my chagrin, after rebooting into OpenWrt, I was not able to ping or connect to it. The unit is now bricked. The only way to bring it back from the dead is to load new firmware via a serial connection.  [UPDATE: I found a way to unbrick it without any hardware hacking, if it is able to go into OpenWrt failsafe mode. See Method #1] Luckily, the TL-WR703N has a built-in UART for this purpose, but the PCB only has tiny pads for connecting to it. There are lots of instructions on other sites describing how to do this, but I’ll document my experiences here. Here’s what the case looks like with the top lid removed:

opencase

It’s held on by 3 clips. I first tried to use a guitar pick, and several plastic tools to open it up without marring the surface, but the case was just too tight. Finally, I wedged a small screwdriver in the location pictured below:

pryhere

Once the first clip popped loose, I was able to just carefully pry the lid up and off from that edge, popping the other two clips open in the process. To hook up the UART, 3 pins are needed: Tx, Rx, and GND. Most writeups say to solder onto the round gold pads labeled TP IN  (Rx) and TP OUT (Tx). However, from Squonk’s reverse engineering of the PCB, I noticed that C57 connects between TP_IN and GND, and C55 connects between TP_OUT and GND:

uart

It turns out that C57 and C55 are unpopulated on the board. I decided that it would be easier to solder to the pre-tinned pads instead of trying to scrape the solder mask off of the round pads:

serial

It turns out that I was wrong. I managed to solder my 40AWG wire-wrap wire onto one of C55‘s pads, but the rest of them were too tricky due to their small size. So I scraped off the solder mask on TP IN, and soldered there, and I found a relatively large capacitor, C37 to use for my GND connection:

soldered

TIP: Modern machine-assembled PCB’s are typically coated with a solder mask, which is an insulator. Before attempting to solder to one of the copper pads, scrape off the solder mask where you want the solder to stick with an x-acto knife, exposing the bright copper below.  Try not to scrape off the solder mask in adjacent areas, to reduce the chance of creating solder bridges (shorts).

Next, I applied a liberal amount of hot melt glue to secure the connections:

glued

To connect the UART to a PC, the easiest way is to use a USB to 3.3V UART adapter. Unfortunately, the only one I have is 5V, which would fry the AR9331. I ordered this CP2102-based one which I found on eBay:

CP2102_0Connecting the USB UART adapter to the TL-WR703N is easy:

TP_OUT -> RXD
TP_IN -> TXD
GND -> GND

To access the serial console from your PC, you must first install the appropriate drivers for your USB UART adapter. Then, use a serial terminal client program (I like to use PuTTY), and connect to the virtual serial port with parameters: 115200,N,8,1.

To be continued after I receive my USB -> TTL adapter …

Next: Hacking the TP-Link TL-WR703N – Part 2: Bring it back from the dead

LeafCAN v2 Firmware in Alpha Test

I have been working on v2 of the LeafCAN firmware, which adds a whole slew of new screens, selectable via a rotary encoder.  The rotary encoder is connected to the AD0/1/2 pins on the expansion header of the LeafCAN V2 hardware.  The code is currently in alpha testing, and is available in the development branch of the LeafCAN github repository.  Be aware that the development branch is for my bleeding edge code, and at any time, the code there may be broken, as I continually checkpoint my code.  I will move it to the master branch when it’s ready to be released.

While I was developing the LeafCAN v2 firmware, I received a pleasant surprise in the mail from Barbouri (GregC) of the MyNissanLeaf forum.  He designed a PCB with 16×2 OLED display + RGB Led Rotary Encoder support,

v2o

and sent me a completely assembled and tested rig.  I immediately added support for this new hardware variant into my working LeafCAN v2 firmware code.  The RGB knob is cool:

encoderled

but I am still pondering how best to use it. Currently, I have it blue when the car is idle, red when it’s consuming power, and green during regen.
Below is an overview of LeafCAN v2Alpha3. The various screens are selected by rotating the encoder knob. Some of the screens have different modes, selected via a press of the encoder knob. The first screen is the familiar info screen from LeafCAN v1.3:

mainscreen

The top line from left to right is: kWh remaining/gids/fixed fuel bars, and the bottom line is: pack voltage/SOC%/instantaneous kW. The next screen is an idea lifted from Turbo3’s WattsLeft, the DTE (distance to event) screen:

dtel

The top line shows various miles/kWh values, 2.0/3.0/4.0/5.0/6.0, and bottom line shows the distance in miles to the event, in this case, Low Battery.  Pressing the encoder button switches it to miles until Very Low Battery:

dtev

and pressing the button a third time shows miles until Turtle:

dtet

Thanks to a breakthrough in active can sampling, spearheaded by GregH and TickTock, I was able to implement the following new screens. The first one has on the top line, High Precision State of Charge (SOC)%.  The bottom line shows State of Charge (Ah), and possibly a Battery Health %.

soccap

The next screen shows the 4 battery pack temperature sensors:

batttemp

The units are selectable between Celcius and Fahrenheit with a press of the button. Finally, the last screen shows the minimum and maximum cell-pair voltages in mV, as well as their difference:

cellvolt

When an OLED is installed, the display now blanks after 5 sec of inactivity on the CAN bus. Pressing and holding the knob for a second wakes the display up for 5 sec.  When an LCD is installed, the press/hold turns on the backlight for 5 sec, instead.

I will be working towards finishing LeafCAN v2.0 in the coming weeks, and will announce its release here.

Barbouri and I are also collaborating on a dual-CAN bus version of the LeafCAN hardware, which will be able to monitor the Car-CAN as well as the EV-CAN on the Nissan Leaf. This will open up access to various information which is accessible only via the Car-CAN, such as friction brake actuation, steering angle, etc.

I would also like to point out that GregH has yet another cool Leaf CAN bus dash display in the works (only $80) that is worth checking out. Also, TickTock and garygid are working on the very fancy dual-touchscreen open-source CANary Project. Turbo3 has also figured out how to extract data from the Leaf Car-CAN using a cheap ELM-327 clone dongle and an Android phone. There is currently a flurry of CAN bus hacking on the Leaf.

UCTronics 3.2″ TFT LCD Arduino Shield with Touchscreen

Updated 2014-03-14

I’ve been looking for a way to add a touchscreen UI to my projects.  To this end, I purchased a UCTronics 3.2″ TFT LCD Arduino Shield.  Most of the cheap TFT touchscreens that I found need about 38 pins, and therefore, need to interface with an Arduino Mega.  What makes this UCTronics shield unique is that it uses an onboard latch to convert the onboard SSD1289 TFT driver data bus from 16-bits to 8-bits.  This allows it to connect to an Arduino Duemilanove or UNO.  The board I received is a RevB board, and it looks somewhat different from the board pictured in the UCTronics product description.  The resistive touch panel on top of the TFT very similar to the touch panel used in the Nintendo DS.  Below is the board running UTFT’s demo (UTFT_Demo_320x240):

front

When I purchased this display, I had to use a specially modified version of UTFT downloaded from UCTronics: 3inch2_RevB.zip. This is because at the time, UTFT only supported the SSD1289 in 16-bit mode. However, as of 2014/14/03, the shield now works with the official UTFT distribution. The key is to supply the correct parameters to the UTFT constructor:

[code lang=”c”]

UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);

[/code]

SSD1289_8 specifies that we’re using an SSD1289 controller in 8-bit mode. The rest of the parameters are the pin assignments.

When compiling for an Arduino Duemilanove or UNO, the IDE will complain that the sketch is too big, unless you comment out all of the #define DISABLE_xxx except for #define DISABLE_SSD1289 in UTFT’s memorysaver.h.

While UCTronics’ version of UTFT comes preconfigured, it is based on an older version of UTFT, which is slower. On my Duemilanove, the UTFT_Demo_320x240 sketch takes 57.7 sec to execute with UCTronics’ UTFT, and 48.6 sec with the official UTFT library.  This is mainly because the latest UTFT has a new function called _fast_fill_8(), which speeds up certain fills. However, the sketches built with the newer UTFT library are bigger. With UCTronics’ UTFT, UTFT_Demo_320x240 compiles to 27248 bytes, and 30092 bytes with official UTFT.

Here is a bottom view of the shield:

shield

At right is the integrated micro SD card reader, which is handy for storing bitmap data to load into the screen.

UCTronics supplies ArduCAM_Touch to support the touchscreen. However, I decided to just use UTouch, instead. Below is the UTouch_ButtonTest example sketch:

btndemo

To use UTouch, you must configure the following lines in the sketch:

[code lang=”c”]
UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);
UTouch myTouch(13,10,11,12,9);
[/code]

I was able to operate the buttons by pressing firmly with my fingers. Note that the touchscreen is resistive, not capacitive, so it works by pressure. A stylus gives you considerably more control. The touchscreen is very similar to the one found in a Nintendo DS.

At first, I was disappointed by the bitmap display.  This is the output of the UTFT_Read_BMP demo sketch supplied by UCTronics:

bmp

There is severe quantization of the colors. This is the way due to the way that UCTronics implemented the UTFT::dispBitmap() function in their modified UTFT library. I wrote my own function, dispRaw(), to instead display .raw files generated by UTFT’s ImageConverter 565:

[code language=”c”]
// display a raw bitmap that was processed with ImageConverter565

#include <UTFT.h>
#include <SD.h>
#include <Wire.h>

#define SD_CS 8

//UTFT(byte model, int RS, int WR,int CS,int RD)
UTFT myGLCD(SSD1289_8,A1,A2,A0,A3);

void dispRaw(UTFT *utft,File inFile)
{
char VH,VL;
int i,j = 0;
cbi(utft->P_CS, utft->B_CS);
for(i = 0; i < 320; i++)
for(j = 0; j < 240; j++) {
VL = inFile.read();
VH = inFile.read();
utft->LCD_Write_DATA(VL,VH);
}
sbi(utft->P_CS, utft->B_CS);
utft->clrXY();
}

void setup()
{
myGLCD.InitLCD();
if (SD.begin(SD_CS))
{
char VH,VL;
File inFile;
inFile = SD.open("ade.raw",FILE_READ);
if (! inFile)
{
while (1); //if file does not exsit, stop here.
}
dispRaw(&myGLCD,inFile);
inFile.close();
}
}

void loop(){}
[/code]

The output looks a lot better:

ade

The display is actually much higher quality than the photo above.  The photo contains screening and moire patterns that you don’t see with the naked eye.  To create a RAW file, first create a 240×320 pixel jpg,png, or GIF file.  Run it through either imageconverter565.exe or the online ImageConverter 565 make sure to select Convert to .raw file and Target Platform Arduino (AVR). Copy it to a FAT-formatted uSD card, and insert it into the uSD slot.

It takes about 6 seconds to load a fullscreen RAW file. I’m think the bottleneck is the reading of the data from the SD card. Clearing the screen takes almost 1 second. The speed is acceptable when running UTFT_Demo_240x320.  This is board is no speed demon, but the speed seems adequate for implementing a graphic touchscreen control panel. If you need a fast display, look elsewhere.

Resources:

User Guide
UCTronics Customized UTFT library

UTFT
UTouch

EKitsZone UNO Rev.3 First Look

I recently decided to buy an Arduino UNO R3, to test compatibility with my sketches, which I have been testing w/ a Deumilanove.  The UNO R3 contains an ATmega16U2  instead of an FTDI chip to do the serial to USB conversion, as well as 3 extra pins on the digital side of the board: SCL/SDA/AREF.  One thing I don’t like about the Arduino UNO is that while it uses a 16MHz crystal for the 16U2, the main 328P MCU runs on a resonator, which is not as accurate.  I found the EKitsZone UNO Rev.3 on eBay for $14.99, and decided to give it a try.

unor3The notable differences in the EKitsZone Rev.3 versus the Arduino UNO R3 are:

  1. the ATmega328P uses a 16MHz crystal oscillator instead of a resonator, so its timing is just as accurate as a Deumilanove
  2. the reset button is mounted at a right angle, so it’s easily accessible even when a shield is attached on top
  3. it uses a mini-USB connector instead of a full-sized one
  4. the JP2 pins aren’t filled with solder, so it’s easier to solder in headers, should you want to connect something the PB4..PB7 pins on the 16U2
  5. the programming header for the 16U2 isn’t installed, but it’s easy to solder one in

I see 1-4 as advantages.  Plus, the board is a cool looking red color.

Build Ganzfeld-style Photic Goggles (AVS Lightframes)

Building upon my passive Ganzfeld goggles, I decided to build a set of Ganzfeld-style lightframes for photic brain stimulation.  I was inspired by the goggles which come with the very expensive Laxman mind machine:

laxman

Typical lightframes which come with audio-visual stimulation (AVS) mind machines use point source LEDs, such as this pair which came with my MindPlace Sirius mind machine:

siriusgoggles

I covered the basics of how to construct such goggles in a previous article: Build an Audio Player Based Mind Machine Part 1: Photic Goggles

Even the RGB “ganzframes” which come with the MindPlace Procyon mind machine are rather feeble, consisting of point source SMT LEDs, covered by a simple roughened square of translucent plastic… the effect is only mildly diffuse, and still looks like a cluster of point sources.  Inspired by Michael Rule’s hallucinogenic goggles project, I modified his goggles design to my tastes, and built a monochrome replacement for my Sirius lightframes.

Parts for this project:

parts

BOM

  • wiring harness from cheap headphones (a pair of earbuds from your local 99 cent store are a good donor)
  • 2 LEDs – I chose white LEDs
  • a ping-pong ball – I already sliced it in half in the photo.  Using the seam as a guide, cut it in half with a very sharp x-acto knife
  • passive ganzfeld goggles prepared as described in my previous article:  Relax Your Mind: Build Your Own Ganzfeld Goggles

If you your LEDs are of the clear point-source variety, it’s a good idea to scuff them up a bit with to make them more diffuse. You don’t have to do the whole LED.  Rubbing the tip with sandpaper will suffice:

ledscuff

Trim the LED leads, and solder them to the headphone wires:

soldering

The polarity of the wiring depends on the requirements of your particular mind machine.  My Sirius mind machine uses common-anode wiring (also known as CP or common-power), so the anodes connect to ground, and the cathodes go to the right and left channel signal leads.  If your mind machine requires common-cathode wiring (aka CG/common-ground), then you should connect the cathodes to ground, and the anodes to the left and right signals.

After soldering the LEDs, drill a small hole in the side of each ping-pong ball half (I actually just twirled the tip of my x-acto knife, rather than using a drill bit), and then tack them to the balls with hot melt glue.  The blob of glue that holds the tip of the LED to the ball actually helps to diffuse the light a bit more.  Notice that the LED’s are pointed toward the ball instead of away from it, so that you instead of shining the LED beam into your eyes, it bounces off the ball.

ledplacement

Next, carefully glue the ping-pong ball halves to the front of the goggles.  Tack one side of the ball, wait for it to harden, and work your way around it a section at a time, while bending it to conform to the shape of the goggles.  Be careful of overheating when applying hot glue to the ping-pong balls.  My glue gun was a bit hot, and the heat warped them a bit. Notice the flattened parts of the balls below:

melted

Here are the completed goggles:

completed

They work fabulously … much better than conventional point-source lightframes, and an added bonus is that they can be used with eyes open.

monogoggles

Plus, they look really cool & trippy: goggleshead

Here is a preview of my hallucination machine. It’s a standalone Arduino-based mind machine, which is my remix Michael Rule’s Hallucinogenic goggles.  The goggles are of identical design, but use RGB LEDs rather than a single color.  I will document the build in a future article.

hallucinationmachine

Related Post: Relax Your Mind: Build Your Own Ganzfeld Goggles

Build a Bluetooth Low Energy (BLE) Controlled RGB LED

I have been wanting to play with my RedBearLab BLE Shield for some time, but have been too busy. This weekend, I finally was able to allocate some time to experiment with it. I decided to do something relatively easy as my first project, so as to familiarize myself with the Bluetooth API’s on both the Arduino and the host side. Wirelessly controlling an RGB LED seemed like something fun to do.  RedBearLab has some example programs for Mac OSX and iOS in their BLE SDK.  I decided to start with OSX, since the compiler and SDK are a free download from Apple.

One nice thing about BLE is that you can write iOS apps that talk to it without going through Apple’s expensive MFA program.  Apple is being asinine, as usual, and decided not to support the RFCOMM profile, which allows older versions of Bluetooth to emulate serial ports, and talk to arbitrary devices.  However, they still force you to pay them $99 per year (yes, per year, not a one-time fee) for the *privilege* of being able to run your own iOS apps on an actual device.  Annoying and evil…

While recent Apple computers have Bluetooth 4.0 support built-in, I have an older Mac Book Pro from 2008.  I bought a cheap CSR BT 4.0 dongle on eBay for <$10.

My Mac is running OSX Mountain Lion, but I was not able to get it working at first, even though I followed the hack described at: https://discussions.apple.com/thread/2265096?start=0&tstart=0. (Note: I deleted the bcdDevice key, rather than updating it as described in the article).  Then I noticed that Apple wanted to install an OSX update.  Once I updated to OSX 10.7.5, the dongle started working properly.  What’s strange is, with the update, I found that there is actually a kext which is configured to directly support my dongle (USB VID = 0x0a12, PID = 0x0001) straight out of the box, but for some strange reason, OSX was detecting it as a Broadcom device, rather than Cambridge Silicon Radio.  While the dongle is working now with the hack, it is a bit flaky on my Mac, and sometimes can’t talk to the BLE Shield, unless I unplug/plug it in or retry several times.  On the other hand, it works flawlessly on my Windows 8 machine.  If anyone knows of a cheap and reliable BT 4.0 dongle for OSX, please leave a comment below.  FYI, when you plug in the BT 4.0 dongle, OSX automatically disables the built-in Bluetooth controller.

Schematic:

I used a common-cathode RGB LED.  Here is the schematic:

 

 

The brightness of each color channel is controlled via PWM, using a value from 0-255.  The BLE Shield uses pins D8 and D9 for communication.  My Arduino Duemilanove has 6 PWM pins: D11, D10, D9, D6, D5, and D3.  Therefore, I decided to use D6=red, D5=green, and D3=blue. I wired it up on a mini protoboard.  To diffuse the light, I drilled a small hole into a Ping-Pong ball, and attached it to the LED.  Here is my test rig:

 

 

I have uploaded all of the code for this project to github: https://github.com/lincomatic/BleRgbLed

Arduino Sketch:

The Arduino code for this project is in BleRgbLed.ino.  Before you can compile the sketch, you must install the BLE Arduino library.  Simply unzip libBLEShield_v1.0.zip into <arduinosketchbook>/libraries.  You will have two subfolders, BLE/ and BluetoothLowEnergy/.

To maintain communication integrity between the host and the Arduino, I decided to implement a simple 5-byte packet format:

<sync byte><red><green><blue><checksum>

where

 <sync byte> = 0xA5

and

<checksum> = <red> XOR <green> XOR <blue>

This way, if the signal drops out or some packets get corrupted, the Arduino can reject bad data, and easily regain sync.

OSX Cocoa App:

The Mac OSX app is very straightforward, using 3 sliders, one for each color, to control the LED:

As a template, I used RedBearLab’s SimpleControl_Mac example, which is included in their BLE SDK.  To compile the app, your Mac must be running OSX 10.7.2+, and you must use XCode 4.2+. To compile an OSX or iOS app that talks to the BLE shield, you must add two frameworks to your project:  1) BLE_Framework from RedBearLab’s SDK and 2) IOBluetooth.framework from Apple’s SDK.

It would be very straightforward to port the app to iOS, using the SimpleControl_IOS sample as a template, but I haven’t done it yet, because my Apple Developer license expired, and I don’t want to spend another $99 for a new one.  It is supposedly possible to run it on your Mac via the iOS Simulator without a developer license, but I wasn’t able to get the simulator to connect to the BLE shield through my BT4.0 dongle.  iPhone 4S/5 and late model iPads have BLE built-in.  I believe you need to be running iOS 5.1+ to use BLE API’s.

Here is what it looks like in a darkened room.  It’s bright enough to make a nice night light. It looks a bit like an Ambient Orb, and with a bit of extra coding, could actually behave like one. With some transistors to drive more current, you could drive RGB LED strips, and make multicolored under-counter kitchen lighting.

I think it would be cool to use the LED as a notifier for SMS messages, voice mail, etc for an iPhone, but I am not yet sure whether or not the proper API’s are available.

I am more comfortable programming Microsoft Windows apps… if anyone has any good examples for getting started with BLE communication API’s under Windows, please leave a comment below.

One of my goals is to build wirelessly controlled RGB LED goggles for photic brain stimulation – once I get this working, I will post a blog entry.

Code Download: https://github.com/lincomatic/BleRgbLed

Previous Post: RedBearLab BLE Shield – First Look

LiquidTWI2 v1.1.0 Released

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

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:

  1. download LiquidTWI2 from github.
  2. copy the LiquidTWI2 folder to <arduinosketchbook>/libraries/LiquidTWI2

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

Teensy 3.0 – First Look

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:

  • 32 bit ARM Cortex-M4 48 MHz CPU (M4 = DSP extensions)
  • 128K Flash Memory, 16K RAM, 2K EEPROM
  • 14* High Resolution Analog Inputs (13 bits usable, 16 bit hardware)
  • 34* Digital I/O Pins (10 shared with analog)
  • 10 PWM outputs
  • 8 Timers for intervals/delays, separate from PWM
  • USB with dedicated DMA memory transfers
  • 3 UARTs (serial ports)
  • SPI, I2C, I2S, IR modulator
  • I2S (for high quality audio interface)
  • Real Time Clock (with user-added 32.768 crystal and battery)
  • 4 general purpose DMA channels (separate from USB)
  • Touch Sensor Inputs

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.

AT90CAN Support for Arduino 1.0+

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