Programming OpenEVSE with a Serial Cable instead of Hardware Programmer

Typically, OpenEVSE firmwares are flashed into the board using a hardware programmer, such as a USBasp. In the past, this was required, because the firmware had grown so large that there was no space left in the ATMega328P‘s flash to fit in a bootloader. However, the latest versions of the AVR tools that come with Arduino have shrunken down the binaries to the point that we now have space for a bootloader. Once the bootloader is installed, OpenEVSE can be programmed in exactly the same fashion as an Arduino Pro Mini, via a USB->TTL UART adapter, such as a FTDI cable, using the stk500 (arduino) protocol.

Before we can program the chip with a bootloader, we need to make a minor hardware mod. After a reset, the bootloader waits to see if a new firmware wants to be flashed before proceeding with booting the installed firmware. It is only during this very small time window that the ATMega328P‘s MCU is ready to accept a firmware. In order to trigger a reset via software, we need to connect the DTR pin of the FTDI cable to the RESET pin of the MCU via a .1uF capacitor.

Below is a photo of the mod, done on a Wattzilla C3 board, which is an OpenEVSE variant:

The DTR pin is on the far left of the 6-pin serial connector. The RESET pin can be accessed at either the left side of R10, as pictured above, or at Pin 5 of the ISP connector (red circle).

Once the hardware mod is in place, we must set the fuses to use a bootloader, and flash in the bootloader, using a hardware programmer. In this example, we will use OptiBoot, because it’s smaller and faster (115200 baud) than the standard Arduino bootloader.

avrdude -c USBasp -B0.5 -p m328p -Uflash:w:optiboot_atmega328.hex -Ulfuse:w:0xFF:m -Uhfuse:w:0xDE:m -Uefuse:w:0x05:m -Ulock:w:0x3F:m

After the bootloader is flashed in, we can thereafter flash in firmwares using just the FTDI cable:

avrdude -carduino -PCOM5 -b115200 -p m328p -Uflash:w:open_evse.hex

Substitute your FTDI cable’s virtual serial port for COM5 above.

For those who are not comfortable with command lines, it’s also possible to use the Arduino IDE to burn the bootloader, and flash in firmwares.

  1. Set your board to Arduino UNO by using the menu to navigate to Tools->Board->Arduino UNO
  2. Select your hardware programmer via Tools->Programmer
  3. Install the bootloader via Tools->Burn Bootloader
  4. Disconnect the hardware programmer, and use Tools->Port to select your FTDI cable’s virtual serial port.

Thereafter, you may flash in your sketches with the upload button. The above procedure will also work with any DIY or other Arduino clone which is not wired for a bootloader. Note that the bootloader takes up 512 bytes, so your maximum sketch size drops from 32768 to 32256 bytes.



Precision PWM Frequency for Arduino / ATmega 328P

I’m working on an application where I need fine adjustment of PWM frequency. The existing PWM code that I found, such as the Arduino PWM Frequency Library, only allows integral frequencies to be selected. On pins supported by 16-bit timers, the Arduino PWM Frequency Library allows fine adjustment of duty cycle, but not frequency. After searching for a while, I found an interesting article in Udo Klein’s Blinkenlight blog: Flexible Sweep. In the article, Klein has an Arduino sketch which sweeps the LEDs of a Blinkenlight board from 0-999.9999 Hz in increments of .0001 Hz.

I hacked his sketch into PrecisionPWM, which outputs PWM to any arbitrary digital pin in increments of .0001 Hz. What’s nice is that since it doesn’t use the ATmega’s internal PWM generator, you can use it on any arbitrary digital pin, whether or not it supports hardware PWM.

Download from github: PrecisionPWM

WS2812B LED (NeoPixel) Control: Part 2 – WiFi Control via Art-Net on ESP8266


For wireless control of WS2812B (NeoPixel) LEDs, I initially played with Bluetooth SPP (Serial Port Profile), due to the simplicity of setting up the host software… from the host’s software’s point of view, the connection just looks like a physical serial port. Unfortunately, the flakiness of my Windows 8.1 PCs’ Bluetooth SPP support caused me to abandon that solution.


ESP8266 modules provide a very low cost method of interfacing WS2812Bs to WiFi. Adafruit’s Huzzah module costs $9.95, but on eBay, NodeMCU clones, such as the LoLin NodeMCU board can be had for ~$3 shipped from China. This makes it even cheaper than the Arduino/Bluetooth combination!

What’s more, the LoLin board has a CH340G onboard, so it doesn’t require a FTDI cable to connect it to your host computer for programming. I ordered a few of the LoLin boards, but in the meantime, I started playing with the Adafruit Huzzah boards I had on hand.

With the addition of ESP8266 support via the Board Manager, Arduino becomes an easy to use platform for code development. Also, there are easily obtainable libraries for both WiFi configuration and control of the WS2812Bs.

One extra complexity of using an ESP8266 to control WS2812Bs is that the ESP8266 is a 3.3V device, while the WS2812B is a 5V device, (usually) necessitating level shifting. The WS2812B datasheet shows a threshold of >= 0.7VDD for logic HIGH, and <= 0.3VDD for logic LOW. The allowed VDD ranges from +3.5-5.3V. Interestingly, some WS2812Bs can actually work when powered by 3.3V, and driven by 3.3V logic, even though it’s out of spec, but many cannot. On the other hand, it’s totally within spec to be powered by 3.7V and driven by 3.3V logic. So, if you use a 3.7V LiPo battery to power the WS2812B strand, the WS2812B data line can be connected directly to the ESP8266 without any level shifting! If you choose to go this route, power the Huzzah from its VBat terminal, so that the 3.7V will be regulated down to 3.3V to power the ESP8266. More details are available in Adafruit’s NeoPixel Uber Guide.

Since I want to be able to drive long strands of LEDs, I elected to go the 5V power with level shifter route. Also, I have lots of 5V power supplies laying around. There are many different ways to do level shifting, either passive or active. The WS2812B has tight timing requirements, and runs at 800KHz, so care has to be taken in order to avoid signal distortion. One of the most reliable methods is to use a 74AHCT125 level shifter IC. I decided to first try a simple diode and pullup resistor circuit (credit: RPi GPIO Interface Circuits):

The circuit is currently working flawlessly for me, driving my 5m long strand of 150 LEDs.


In order to send data to our WS2812Bs over WiFi, we need some sort of IP protocol. Art-Net is a royalty-free protocol, which sends DMX data embedded in UDP packets. I decided to go with Art-Net because it is an industry standard that is supported by a variety of Pro software, and Jinx! and Glediator can talk to it.


I will not go into how to set up Arduino to compile sketches for the ESP8266, as that is discussed elsewhere. To compile for the Huzzah, select it as the compile target from the Tools pulldown menu:

Tools -> Board -> Adafruit HUZZAH ESP8266

I created a sketch, which is a mashup of a few different projects from github. The code is in my github repo: WS2812ArtNet. I stripped the Adafruit NeoPixel library down to the bare metal, and added a captive portal for configuring the WiFi connection. Also, it supports a hardware pin to erase the WiFi settings. Configuration is done via a few defines in WS2812ArtNet.ino. See the #defines for PIXEL_CNT, PIN_DATA, PIN_LED, and PIN_FACTORY_RESET. At a minimum, PIXEL_CNT must be set to the number of LEDs in your strand.

PIN_DATA is used to select the pin that’s used to drive the data to the LED strand.

PIN_LED is used to select the a pin which blinks an LED every time an Art-Net packet is received. This makes it easy to tell if the board is receiving data. In addition, the LED is initially off at boot-up, and turns solid red when the ESP8266 connects successfully to a WiFi AP. By default, PIN_LED = 0, which makes it control the onboard red LED on the Huzzah.

PIN_FACTORY_RESET wipes out any saved settings and clears the EEPROM when it’s grounded for 2 sec.

To load the WS2812ArtNet sketch into the ESP8266, first press the GPIO0 and Reset buttons simultaneously, and then let go of the Reset button. The red LED will then glow dimly, indicating that the bootloader is active. Once the sketch is loaded, when the ESP8266 initially boots up, it will create a WiFi AP with SSID WS2812ArtNet_hh-h. Use a computer, phone, etc to connect to the AP. Upon connection, it should automatically present a captive portal for configuration:

If the captive portal doesn’t automatically launch, open a web browser, and point it to Tap on Configure WiFi, and the ESP8266 will automatically scan for available APs:

Tap the desired AP’s SSID, and type in the passphrase. Additionally, you can also choose a starting Art-Net universe, and configure a static IP. After you tap save, the ESP8266 will reboot. If it connects successfully to your AP, the onboard red LED will light. Then, the LED strand will go into the startup test sequence of lighting up red, green, and blue, and then turning off. Once Art-Net data is received, the LED still start blinking with every packet it receives.  If you have trouble during setup, you can see debug messages by opening the ESP8266’s serial port in a terminal set to 115200,N,8,1.


When configuring Jinx!/Glediator, select GRB as the pixel data format.


Prev: WS2812B LED (NeoPixel) Control: Part 1 – Serial Control via 8-bit ATmega (Arduino)

WS2812B LED (NeoPixel) Control: Part 1 – Serial Control via 8-bit ATmega (Arduino)


I’ve been laying the groundwork for doing some projects using remote controlled RGB LEDs. My first attempt was Lampduino, which used discrete RGB LEDs, and an ITEAD Colorduino as a controller. In that project, I ran into several pitfalls:

  • though inexpensive, assembly of the LED matrix was very labor intensive
  • the LED’s were rather dim, due to the limited drive capability of the Colorduino
  • the frame rate was slow, due to limited baud rate and RAM
  • while it was scalable, I didn’t like the idea of having to use a separate Colorduino for every 64 LEDs

A few years have passed, and WS2812B LEDs have dropped enough in price enough to get into the range that I feel is affordable. They can be found on eBay and AliExpress very cheaply. Also, they can be controlled without any specialized hardware – all that is needed is one GPIO pin. There are libraries available for many of the popular microcontrollers. Some examples are Arduino, ESP8266, Teensy 3.x, and Raspberry Pi.


The other piece of the puzzle is control software. For Lampduino, I hacked uRaNGaTaNG’s mtXcontrol Processing sketch into rgbMtx, but I found Processing to be a very limiting platform, which was hard to debug. This time around, I found a couple of interesting free LED control programs, which are both quite powerful. The first one is Jinx! LED Matrix Control, which runs on Windows only, and the second is Glediator, which is a Java app. Both programs, while free, are not open source. However, they are both powerful enough to do some interesting things.


I decided to start my experiments with an Arduino Pro Mini clone, because they have a tiny footprint, are cheap (clones are <$2 shipped from China on eBay), and I happened to have some laying around. Also, the Arduino Pro Mini’s ATmega 328P MCU runs at 5V, so no level shifting is required when interfacing to WS2812Bs. Glediator’s creator, Solderlab, has barebones, fast serial client Arduino sketch which can be downloaded at: WS2812-Glediator-Interface. It can run on any 8-bit ATmega-based Arduino such as the Mega, UNO, Deumilanove, etc. The code that outputs the data to the LEDs is written in assembly language, and is thus, very fast & compact. Also, rather than using Arduino’s Serial library, it contains its own very compact serial code. At the expense of a little bit of speed, I decided to generalize it a bit, and add my own packet protocol. My code is on github at: WS2812Remote. The main changes that I made in my version of the code are:

  • Since I didn’t understand the Glediator example’s serial code, I reverted to using Arduino’s built-in Serial library. I’ve tested it with baud rates up to 1000000 and an FTDI cable on a Windows PC, and it works fine
  • I added support for my own packet protocol. Glediator’s serial protocol is extremely simple. Each frame starts with 0x01, followed by the pixel data stream. My simple packet protocol adds an XOR check byte, as well as a few simple commands such as color fill and blanking of the LEDs.

I also wrote a C++ program, called pkt_test, which demonstrates usage of my packet protocol.

Hookup of the WS2812B LED strand to the Arduino is quite simple. You can use any 8-bit Arduino. First, you must select a data pin to drive the strand. I arbitrarily decided to use pin PD2. For speed and compactness, instead of using Arduino functions to access the data pin, the code refers to the ATmega port and pin numbers, rather than Arduino’s rather arbitrary digital pin numbers. On the Arduino Pro Mini, digital pin 2 = PD2, as can be seen from the following pin mapping diagram:


So WS2812Remote.h is configured as follows:

#define DATA_PIN 2

Next, PIXEL_CNT needs to be set to the number of LEDs in your strand. I tested with an Adafruit NeoPixel ring containing 16 LEDs:

#define PIXEL_CNT   16

Connect your the data input pin of the first LED of your WS2812B strand to your selected data pin. Adafruit recommends a 300-500 ohm inline resistor to protect from voltage spikes. The NeoPixel ring I used already has a resistor onboard, so I didn’t need it. I connected the +5V and GND pins directly to the corresponding pins on the Arduino. To protect against current inrush when powering it up, Adafruit also recommends connecting a 100uf capacitor between the +5V and GND pins. However, it’s not necessary if you’re just going to power it from USB, which is what I did, since I was only powering 16 LEDs. For large strands, you will need an external power supply to supply sufficient current, as each LED can draw up to 60mA at full brightness. If using an external power supply, make sure to always apply power to the WS2812B strand before the data pin!


I used the same FTDI cable that I used for programming the Arduino as a virtual com port for sending data to it. When configuring Jinx! or Glediator, select Glediator protocol. For speed, the sketch just receives raw pixel data, and dumps it out to the LED strand, so the data format is in native GRB order.

When configuring Jinx! or Glediator, select Glediator as the device type (Jinx!) or output mode (Glediator). Make sure that the baud rate of the corresponding com port matches BAUD_RATE as defined in your sketch. I tested 115200 and 1000000 bps with my FTDI cable, and both worked fine with both programs. It failed at 1250000 bps.

If you want to play around with my packet protocol, the pkt_test code is self explanatory. I tested it with Visual Studio 2015 in Windows 8.1, and g++ in Debian linux 8.2.0. Prior to compilation, set COMM_PORT to correspond to your Arduino’s serial port. Also, confirm that BAUD_RATE in ../WS2812Remote.h matches the value that was used when loading the Arduino sketch. To compile and run pkt_test in linux, use:

g++ pkt_test.cpp serialib.cpp -o pkt_test
sudo ./pkt_test


My first inclination for wireless control was to use Bluetooth, due to its simplicity. The Bluetooth SPP (Serial Port Profile) makes it easy to construct a wireless virtual serial interface between a host computer and the Arduino. This allows you to use exactly the same host software configuration that you would for a direct serial connection to the host. I had an Elechouse EHB Serial Bluetooth Module in my parts bin (very similar to the ubiquitous HC-05), so I decided to try it out.

Before using the EHB module can be used, it must be configured with a series of simple AT commands. I hooked it up to my Windows PC with my FTDI cable, and used PuTTY as a serial terminal to configure it. Connecting the EHB module to the Arduino is quite straightforward:

Arduino -> EHB

5v -> VCC

Pairing the EHB to a host computer creates a virtual serial port for the host software to access. Unfortunately, I was using Windows 8.1 as my host computer, and its handling of Bluetooth SPP clients is rather flaky. Every time I powered down the LED controller, I had to unpair/pair the Bluetooth in order to get the virtual serial port to work properly. While it worked flawlessly when the virtual serial port was functional, ultimately, I abandoned Bluetooth due to the flakiness of Windows’ Bluetooth SPP support. Perhaps Linux can handle it better.

Next: WS2812B LED (NeoPixel) Control: Part 2 – WiFi Control via ARTnet on ESP8266

HowTo: Fix AVRDUDE 6.3/Arduino 1.6.10+ Compatibility Issues with USBasp Clones

I recently upgraded to Arduino 1.6.13, and found that I could no longer program my boards with my Chinese USBasp clone programmer. When the Arduino IDE tried to load the firmware with my USBasp, AVRDUDE couldn’t find my USBasp, and gave this error:

avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor=’’ product=’USBasp’

It turns out that the that AVRDUDE 6.3, which is bundled with Arduino 1.6.10+, has timing issues with USBasps. The fix is to replace your libUSB-win32 driver with libusbK v3.0.7.0. An easy way to install libusbK v3.0.7.0 is to use zadig. Download the zadig from

Plug your USBasp into your PC.

Launch zadig, and from the menubar, select Options->List All Devices

Next, from the top listbox, select USBasp.

From the Driver selector box, click the up or down arrow key until libusbK (v3.0.7.0) appears.

Finally, click the Replace Driver button.

The screen should look like this:


You do not have to reboot or disconnect/reconnect your USBasp. After Zadig finishes installing libusbK, AVRDUDE 6.3 will start working correctly with your USBasp.

NOTE: the version of AVRDUDE that Arduino 1.6.x uses is actually controlled by the Boards Manager (Tools->Board->Boards Manager). Even if you have a version of Arduino 1.6.x prior to 1.6.10, if your Arduino AVR Boards by Arduino is version 1.6.10+, it will use AVRDUDE 6.3.

Maple Mini – Serial Programming and Upgrading to Bootloader 2.0

My BAITE BTE14-07 Maple Mini clone came with LeafLabs’ original bootloader. I decided to upgrade to Bootloader 2.0 in order to free up some RAM, and take advantage of some of the new features.

UPDATE: Roger Clark, the STM32DUINO guru, posted a comment below, informing me that you can upload to Bootloader 2.0 by simply loading the updater sketch, without a USB->UART adapter, so you can try that first, and save my procedure below for if it somehow fails and bricks your Maple Mini.

The procedure looks pretty straightforward, but I ran into some snags. Perhaps the easiest way to change the bootloader in a Maple Mini is to use the STM32’s built-in serial bootloader to flash it in. The serial bootloader is in ROM, so it’s a fail-safe method to program the chip. The technique involves hooking up UART1 to a USB->UART adapter. I had a spare CP2101-based adapter that works with 3.3V hardware:


The hookup is straightforward:

TX -> rx1
RX -> tx1
3V3 -> Vcc

Here is what it looks looks like all hooked up:

Actually the RX1 & TX1 pins are 5V tolerant, so you can even use a 5V USB->UART adapter. Just make sure to hook up 5V -> vin instead of to Vcc, or you’ll be in for a very unpleasant surprise.

There are several programs available that can program the STM32 in serial bootloader mode. I tried both and stm32flash. Also, you will need the binary bootloader file, maple_mini_boot20.bin.

To put the board into serial bootloader mode, press and hold reset and but, release reset, and then release but. The board will look dead. This is normal. Then execute the command to flash in the bootloader. stm32flash is more straightforward, because it doesn’t require you to install Python. There are pre-compiled versions of stm32flash for various platforms in Arduino_STM32’s tools directory. My computer runs Windows 8.1, so I used the stm32flash.exe:

C:\git\Arduino_STM32\tools\win>stm32flash -w maple_mini_boot20.bin COM19 -b 230400 -g 0
stm32flash 0.4

Using Parser : Raw BINARY
Interface serial_w32: 230400 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (Medium-density)
– RAM : 20KiB (512b reserved by bootloader)
– Flash : 128KiB (sector size: 4×1024)
– Option RAM : 16b
– System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x08001b7c (100.00%) Done.

Note that you need to substitute your USB->UART converter’s serial port for COM19.

If you prefer Python, you can use instead. Make sure to use the version from the Arduino_STM32/tools directory. I tried to use the version from STM32duino-bootloader and the version from libmaple, and both of them wrote only the first 512 bytes of the bootloader, so the Maple Mini was no longer detected at all when plugged into my computer.

Here is how to execute

C:\git\Arduino_STM32\tools\win> -p COM19 -evw \hacking\STM32\maple_mini_boot20.bin
Reading data from \hacking\STM32\maple_mini_boot20.bin
Bootloader version 0x22
Chip id 0x410, STM32F1, performance, medium-density
Writing 7036 bytes to start address 0x8000000
Write 256 bytes at 0x8000000
Write 256 bytes at 0x8000100
Write 256 bytes at 0x8000200
Write 256 bytes at 0x8000300
Write 256 bytes at 0x8000400
Write 256 bytes at 0x8000500
Write 256 bytes at 0x8000600
Write 256 bytes at 0x8000700
Write 256 bytes at 0x8000800
Write 256 bytes at 0x8000900
Write 256 bytes at 0x8000A00
Write 256 bytes at 0x8000B00
Write 256 bytes at 0x8000C00
Write 256 bytes at 0x8000D00
Write 256 bytes at 0x8000E00
Write 256 bytes at 0x8000F00
Write 256 bytes at 0x8001000
Write 256 bytes at 0x8001100
Write 256 bytes at 0x8001200
Write 256 bytes at 0x8001300
Write 256 bytes at 0x8001400
Write 256 bytes at 0x8001500
Write 256 bytes at 0x8001600
Write 256 bytes at 0x8001700
Write 256 bytes at 0x8001800
Write 256 bytes at 0x8001900
Write 256 bytes at 0x8001A00
Write 256 bytes at 0x8001B00
Read 256 bytes at 0x8000000
Read 256 bytes at 0x8000100
Read 256 bytes at 0x8000200
Read 256 bytes at 0x8000300
Read 256 bytes at 0x8000400
Read 256 bytes at 0x8000500
Read 256 bytes at 0x8000600
Read 256 bytes at 0x8000700
Read 256 bytes at 0x8000800
Read 256 bytes at 0x8000900
Read 256 bytes at 0x8000A00
Read 256 bytes at 0x8000B00
Read 256 bytes at 0x8000C00
Read 256 bytes at 0x8000D00
Read 256 bytes at 0x8000E00
Read 256 bytes at 0x8000F00
Read 256 bytes at 0x8001000
Read 256 bytes at 0x8001100
Read 256 bytes at 0x8001200
Read 256 bytes at 0x8001300
Read 256 bytes at 0x8001400
Read 256 bytes at 0x8001500
Read 256 bytes at 0x8001600
Read 256 bytes at 0x8001700
Read 256 bytes at 0x8001800
Read 256 bytes at 0x8001900
Read 256 bytes at 0x8001A00
Read 256 bytes at 0x8001B00
Verification OK
Traceback (most recent call last):
File “C:\git\Arduino_STM32\tools\win\”, line 531, in
if conf[‘go’]:
KeyError: ‘go’

I don’t know what’s the cause of the error at the end, but as long as it writes 7036 bytes, you see Verification OK, the bootloader is installed correctly. Whe I ran the bad versions of, here is what the output looked like:

Bootloader version 22
Chip id `[‘0x4’, ‘0x10′]’
Write 256 bytes at 0x8000000
Write 256 bytes at 0x8000100
Read 256 bytes at 0x8000000
Read 256 bytes at 0x8000100
Verification OK

Even though it showed Verification OK, note how only 512 bytes were written to the Maple Mini.

If you have successfully flashed in the bootloader, the LED will flash continuously after you reset the board, indicating that the bootloader is running. In Arduino, you also must switch the setting to from Original to Bootloader 2.0:


If, for some reason, you want to revert to LeafLabs’ original bootloader, you can download it here: maple_mini_boot.bin.

The built-in STM32 serial bootloader is not only for installing bootloaders. You can also use it to flash in any other BIN file, including Arduino_STM32 sketeches.

First Look: BAITE Maple Mini Clone

Recently, I’ve been searching around for inexpensive higher powered alternatives to AVR-based Arduinos. There are several ARM MCU’s available that give a lot more bang for the buck in terms of RAM, speed, flash, and I/O. While I like PJRC’s Freescale-based Teensy 3.x boards a lot, they’re only available from a single source, and use a proprietary bootloader hosted on a separate MCU. FadeCandy is an OSHW board based on the same MCU as the Teensy 3.0, which is optimized for controlling LED’s. Unlike the Teensy 3.x, it uses an open source bootloader which is hosted on the Freescale MCU itself.

There are a lot of STM32 boards of various types available on eBay and AliExpress. LeafLabs’ Maple series of STM32 boards were pioneers in adapting Arduino for use with the STM32 platform. Unfortunately, the boards were quite expensive, and with the proliferation of cheap Chinese clones, they business was not sustainable, and they discontinued the line. Luckily, the OSS community has picked up the pieces, notably Roger Clark’s Arduino_STM32 project. The current state of the project is very impressive. Not only has Arduino compatibility been greatly improved, but they have created a new bootloader, and many other STM32 families are not supported beyond the Maple’s STM32F1.

I decided to dive in when I had a project that needed 10 PWM channels. The Maple Mini fit the bill. I bought a couple of BAITE BTE14-07 Maple Mini clones. They are quite cheap, under $4.50 including shipping from China. The board is packaged in an anti-static bag, and includes header pins:



While the pinouts, LED, and buttons of the BAITE BTE14-07 are identical to the original LeafLabs Maple Mini, the BAITE version is only 2-layer, instead of 4-layer. Also, instead of using two MCP1703 voltage regulators, one for the digital and one for the analog plane, the BAITE uses a single AMS1117. This means that LeafLabs version is probably more suitable for applications where ADC accuracy is required, but the BAITE version is better when more current is needed to drive attached peripherals.

I tried some sample sketches using Arduino 1.6.5 and Arduino_STM32, and the BAITE board worked perfectly. Some people on the STM32duino board consider it to be somewhat of a benchmark as far as Maple Mini clones go, so it’s probably a good bet for n00bs to the platform like me.

Arduino 1.0.5-r2 for AT90USB1286 and Printrboard

It’s been a few years since I hacked together the copy of Arduino-0022 that’s been floating around the web, which lets you compile and automatically upload Arduino code to an AT90USB1286. This made it a lot easier to develop Arduino code for the AT90USB1286, and in particular to easily modify the Marlin firmware for the Printrboard.

Yesterday, I figured it was high time to add AT90USB1286 support to Arduino 1.0.5-r2. The basic procedure for the modification was to first install Teensyduino, which adds the AT90USB1286 compilation support to Arduino, but only uploads to a Teensy++ 2.0, running PJRC’s proprietary halfkay bootloader. I modified the Teensyduino configuration to also support uploads to targets running the LUFA CDC Bootloader, or via USBtinyISP or USBasp ICSP programmers.

Note that I copy that I modified only runs on Microsoft Windows.
You can download it from github:
It’s easiest to download it as a zip file:

Once you unzip the archive and launch arduino.exe, you will notice some new entries in the Tools->Board menu:


The only difference between the Printrboard and AT90USB1286 entries is that the extraneous USB Type, CPU Speed, and Keyboard Layout submenus are grayed out from the Tools menu.

To load Marlin firmware onto a Printrboard, you will most likely want to use [BootloaderCDC]Printrboard.

Note that unlike my Arduino-0022 hack, the pinMode()/digitalRead()/digitalWrite() functions in version currently only support the pins that are exposed on the Teensy++ 2.0. This is because I haven’t yet had the time to figure out how to add in the remaining AT90USB1286. However, this limitation doesn’t affect Marlin firmware on the Printrboard, because Marlin uses its own fastio functions, rather than using Arduino digital pin numbers and pinMode()/digitalRead()/digitalWrite(). See pinmap.txt for the currently supported Arduino digital pin numbers.

Thanks again to PJRC for Teensyduino. Teensys are a great alternative to Arduino boards.

How to Update the Firmware on a USBasp V2.0

REVISED 2018-07-16

If you buy a cheap USBasp V2.0 ICSP programmer on eBay, chances are, avrdude will give you the following warning message:

avrdude: warning: cannot set sck period. please check for usbasp firmware update.

While it’s just a benign warning message which can be ignored with no ill effects, it’s still a constant irritant. Furthermore, it also prevents my speed up technique from working, because it relies on changing the sck period. To get rid of the warning, you must update the firmware to the latest version: usbasp.2011-05-28.tar.gz

If you have another ICSP programmer already, such as a USBtinyISP, programming in the new firmware is quite simple. If you have more than one USBasp, you can even use them to program each other. Here are the steps:

0. Verify that you have a USBasp V2.0, and that it has a 12MHz crystal and an ATMEGA8 or ATMEGA8A MCU onboard. DO NOT CONNECT IT TO THE USB PORT OF YOUR COMPUTER.

1. Short the JP2 (self-programming) jumper.

2. Connect the USBasp V2.0 to the USBtinyISP (or other ISP) using a 10-pin ribbon cable


3. Flash in the new firmware: avrdude -c usbtiny -p atmega8 -U flash:w:usbasp.atmega8.2011-05-28.hex

4. Reprogram the USBasp’s fuses: avrdude -c usbtiny -p atmega8 -u -U hfuse:w:0xc9:m -U lfuse:w:0xef:m

If you’re not using a USBtinyISP, substitute the proper parameter after -c (e.g. -c usbasp).

Note that the usbasp.2011-05-28.tar.gz archive doesn’t contain a compiled .hex file, so you have to re-compile it using WinAVR. Instead, you can just use my hex file, which I compiled directly from the sources:

If you don’t have another ICSP programmer, you can use an Arduino, following these instructions: Updating firmware on USBASP bought from eBay. However, you may also have to also set the fuses according to Step 3 above. My PC wouldn’t recognize the reprogrammed USBasp until I set the fuses.

Interfacing a TFT_320QVT LCD/Touchscreen/SD to a Teensy 3.0

I’m working on a project which needs a touchscreen LCD. After searching eBay for a while, I noticed that many vendors were selling basically the same 3.2″ 320×240 TFT with resistive touchscreen and SD card reader. Though there were slight variations in the silkscreens, they all had the same model number – TFT_320QVT. I bought mine from digitalzone88 for $12.29. TK0466-1-digitalzone88 TK0466-4-digitalzone88 The board uses a SSD1289 LCD driver IC, and runs on 3.3V. The 3.3V voltage is incompatible with the typical Arduino, which runs at 5V (some vendors have created shields to interface it to an Arduino Mega). However, I purchased the TFT_320QVT with the intention of interfacing it to a Teensy 3.0, which runs at 3.3V. I noticed that there were not enough through-hole I/O pins on Teensy 3.0 to simultaneously interface to the LCD, touchscreen, and SD card. This necessitated the usage of the Teensy 3.0’s additional I/O pins, accessible only via solder pads on its underside: teensy3b To facilitate access to the 14 solder pads, I attached some header pins to piece of stripboard, and soldered 40AWG wire-wrap wire to between the pads and headers: extenderThe Teensy 3.0 runs on PJRC’s specially modified version of Arduino – Teensyduino. The task was to find compatible Arduino libraries. First order of business was the LCD. I searched the web, and found that dawnmist had spent a considerable effort in modifying Henning Karlson’s UTFT to work with the Teensy 3.0. Unbeknownst to me at the time, dawnmist’s modified UTFT is actually bundled with Teensyduino!

Next, was to get the touch screen working. It turns out that the current version of Henning Karlson’s UTouch is compatible with the Teensy 3.0.

For the SD slot, I tried the version of the Arduino SD library that’s bundled with Teensyduino. Unfortunately, though the SD library works with the TFT_320QVT’s SD reader, it stops working if you instantiate a UTFT object in the sketch. I tried sdfatlib, and found that not only does it work w/ the Teensy 3.0, but it coexists fine with UTFT. The only catch I found is that it works only with SPI_HALF_SPEED. When I set it to SPI_FULL_SPEED, it stops working.

Here is the Teensy 3.0 running UTFT‘s demo sketch on the TFT_320QVT: utft

Below is the step-by-step procedure to getting the TFT_320QVT up and running with Teensy 3.0:

Step 1: Install the libraries

1. UTFT: Run the Teensyduino installer, and when the Libraries to Install dialog is displayed, check the box next to UTFT in the Choose Additional Libraries to Install combobox. (Note: Henning Karlson’s latest UTFT also works with Teensy 3.0, but my discussion below will show how to interface to the UTFT that’s bundled with Teensyduino 1.18).

2. UTouch: Download UTouch.rar. Use WinRar or 7-zip to extract the enclosed UTouch folder. From the Arduino IDE pull-down menu, use Sketch->Import Library->Add Library… to install the extracted UTouch folder. Alternatively, you can just copy Utouch/ to your arduinosketchbook/libraries directory.

3. sdfatlib: Download the latest version of sdfatlib. From the Arduino IDE pull-down menu, use Sketch->Import Library->Add Library… to install the downloaded file. You can alternatively just extract the SdFat/ folder into your arduinosketchbook/libraries directory.

Step 2: Wire it up

1. LCD: dawnmist‘s modified UTFT library that’s bundled with Teensyduino has a configuration file: arduinofolder\libraries\UTFT\hardware\arm\HW_Teensy3.h. Inside HW_Teensy3.h, there are 3 options for the LCD pin assignments: USE_B_D_PORTS, USE_C_D_PORTS, and USE_USER_PORTS. By default, the file has


enabled. USE_B_D_PORTS gives the best performance when your sketch needs to use SPI (which is needed for the SD card slot). USE_C_D_PORTS gives the fastest performance, but is incompatible with SPI. USE_USER_PORTS allows you to configure arbitrary pins (by changing the DB_0-DB_16 #defines), but results in the slowest performance. I elected to use the default USE_B_D_PORTS setting.

2. SD card reader: The SD card reader works via SPI, so it needs to use SD_DIN->DIN (MOSI – 11), SD_DO->DOUT (MISO – 12), SD_CLK->SCK (13), and one of the chip select pins, CS0-CS4 (10,9,20,21, or 15). I chose to use SD_CS->CS4 (15).

3. Touchscreen: The touchscreen uses 5 pins, T_DIN/T_DO,T_CS/T_CLK/T_IRQ, which can be assigned to any arbitrary free GPIO pins.

Below is a chart of my pin assignments:

Teensy_pin = TFT_320QVT_pin
0 = LCD_DB4
1 = LCD_DB5
2 = LCD_DB8
3 = LCD_LED_A (backlight)
5 = LCD_DB15
6 = LCD_DB12
7 = LCD_DB10
8 = LCD_DB11
11 = SD_DIN (MOSI)
12 = SD_DO (MISO)
13 = SD_CLK (SCK)
14 = LCD_DB9
15 = SD_CS
16 = LCD_DB0
17 = LCD_DB1
18 = LCD_DB3
19 = LCD_DB2
20 = LCD_DB13
21 = LCD_DB14
22 = LCD_WR
23 = LCD_RS
24 = T_CLK
25 = LCD_DB7
26 = T_CS
27 = T_DIN
28 = T_DO
29 = T_IRQ
32 = LCD_DB6

LCD_RD needs to be pulled up to 3.3v

I have created a sketch, UTFT_UTouch_SdFat_teensy3, that simultaneously demonstrates the LCD, touchscreen, and SD card by modifying the UTouch demo sketch. Below are the lines which are critical to configuring it to work with the above pin connections:
[code language=”c”]
#include <UTFT.h>
#include <UTouch.h>
#include <SdFat.h>

// bitmap file to load as background.
// must be 320×240 and in format output by ImageConverter565
char bkgRaw[] = "ade.raw";

uint8_t sdCS = 15; // SD_CS – chip select
SdFat sd;
SdFile inFile;

uint8_t lcdRS = 23;
uint8_t lcdWR = 22;
uint8_t lcdCS = 4;
uint8_t lcdReset = 9;
uint8_t lcdBacklight = 3; // must be a PWM pin for variable brightness
uint8_t lcdBacklightBrightness = 255; // 0-255
UTFT myGLCD(SSD1289, lcdRS, lcdWR, lcdCS, lcdReset);

// Initialize touchscreen
uint8_t t_Clk = 24;
uint8_t t_CS = 26;
uint8_t t_DIn = 27;
uint8_t t_DOut = 28;
uint8_t t_IRQ = 29;
UTouch myTouch(t_Clk, t_CS, t_DIn, t_DOut, t_IRQ);

The file displays a bitmap, ade.raw, as the background. Before running the sketch, copy ade.raw to a FAT-formatted SD card, and insert it into the TFT_320QVT’s SD card slot.

You can also substitute your own bitmap file. To create a .raw file, first create a 240×320 pixel jpg, png, or GIF file. Run it through either imageconverter565.exe (bundled with UTFT) or the online ImageConverter 565 make sure to select Convert to .raw file and Target Platform Arduino (AVR).

Here’s what UTFT_UTouch_SdFat_teensy3 looks like when it’s running:

Many thanks to dawnmist, and the others who figured out how to get UTFT working with the Teensy 3.0.


I obtained much of the information I needed from these pages:
dawnmist – screen working … finally
Teensy 3.0 – driving an SSD1289 with utft