Category: Arduino

ESP8266, Serial Adapters, and Resets

As detailed in the previous post, I’ve been having some trouble getting the Arduino development environment to automatically reset my ESP8266 board using the DTR and CTS lines of the serial adapter. Part of my problem may still have been the cheap serial adapter, but today I found a new part.

The ESP8266 is extremely sensitive to noise on the CH_PD line, and I was using a 9″ long jumper to connect CH_PD to RTS. I confirmed with my O-scope that RTS was pulsing as it should, but the first pulse threw the ESP8266 into some weird state where it spewed noise on a bunch of pins (GPIO0 seemed to be the worst), and uploading would, naturally, fail.

Switching to 3″ jumpers cleared up the problem and let my Arduino IDE reset the ESP8266 as it should.

I’ve changed the schematic in the Github repo for the project to reflect the new reset wiring, but I still have to add a 5V input connection for charging the battery. Once that’s done, I can design a new PCB.


Bah humbug

The V2 toybrain boards have the diagnostic LED on analog input 6, which isn’t able to also act as an IO pin. Other than that, though, they work. This entry is mostly a note to me to fix that if I make another rev of the board.

Flashing bootloaders on an ATMega328 with the internal clock enabled

The V2 Toybrain boards are getting pressed into service for an art project that I’m working on, so I’m trying to get a set of them up and running. I use Linux, so the tools for talking to AVR microcontrollers are the Arduino IDE, and avrdude, which the Arduino IDE uses.

I started today by telling the Arduino IDE that my boards are a Lilypad Arduino with an ATMega328 on them. This isn’t true, but the electrical design of the board is such that this is close enough. I also informed the IDE that I had a USBTiny ICSP programmer. That bit is true. I had high hopes (because I’m lazy, and configuring the IDE is not the problem I’m trying to solve) that this would let me just hit the “burn bootloader” option in the IDE. Such is not the case. I got the error message:

avrdude: Warning: cannot open USB device: Permission denied
Error while burning bootloader.
avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

I’m a normal user, and the permissions on the USB device are not such that mere users can talk to it. I figured I’d double-check by using avrdude as root (so the permissions would be ok). Then I ran into my next problem:

sudo avrdude -p m328p -c usbtiny
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9514
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
         Double check chip, or use -F to override this check.

The version of avrdude I have is 5.11.1, and doesn’t ship with a hardware definition for the ATMega328, just the ATMega328P. The P is for Picopower, and isn’t related to anything I’m doing (it mostly relates to the technology used to make the chip, and some power handling options like brownout detection). To get around this, I opened /etc/avrdude.conf and copied the ATMega328P hardware definition. Then I changed the descriptions and a few of the fuse bytes to match the parts I do have, and saved the file. Now avrdude doesn’t flip out about my chips.

Unfortunately, programming them through the Arduino IDE is still a bad plan, as the configuration for the LilyPad Arduino isn’t close enough to the hardware I’m using. Specifically, the Lilypad/328 configuration sets the lfuse bits to use an external oscillator, and I’m using the internal oscillator. Once the bad fuse settings are burned in, the chip doesn’t communicate unless it has a 8Mhz crystal attached to it. The error message from avrdude is:

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

I added a crystal (temporarily) to the bricked boards so I could reset the fuses, and they worked fine after that. One of them had the chip on 90 degrees from the proper orientation too, and gave the same error as the chips with the bad fuses, so that error can be anything from the wiring being bad to the chip being configured wrong.

To use avrdude as non-root, I put

ATTR{idVendor}=="1781", ATTR{idProduct}=="0c9f", GROUP="dialout", MODE="0666"

in /etc/udev/rules.d/99-usb-tiny-asp.rules and restarted udev. That lets users in the dialout group have appropriate access to the USB port for the programmer.

The commands to burn the fuse and flash the bootloader are:

avrdude -c usbtiny -p m328 -U lfuse:w:0xE2:m -U flash:w:/home/ams/arduino-1.6.0/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex

My current fuses are lfuse:0xe2, hfuse:0xda, efuse:0x05.

Now we’ll see if I can send a program to them…

USB parallel ports under Python on Ubuntu

I have this PCB designed to control four flame effects. Instead of running it on the Arduino, I’m doing an FFT on a laptop and trying to control the solenoid drivers through a USB parallel port adapter on the laptop.

Ubuntu recognizes the USB parallel port adapter, and gives me a port in /dev/usb/lp0. I don’t have permissions to access it, because its user and group are root and lp, and I’m neither of those. The specific error is:

>>> p = parallel.Parallel('/dev/usb/lp0')
Traceback (most recent call last):
  File "", line 1, in
  File "/usr/lib/python2.7/dist-packages/parallel/", line 187, in __init__
    self._fd =, os.O_RDWR)
OSError: [Errno 13] Permission denied: '/dev/usb/lp0'

sudo chmod o+rw /dev/usb/lp0 doesn’t get me any closer, because whatever python-parallel does under the hood is not a legit operation on that dev entry.

>>> p = parallel.Parallel("/dev/usb/lp0")
Traceback (most recent call last):
  File "", line 1, in
  File "/usr/lib/python2.7/dist-packages/parallel/", line 189, in __init__
  File "/usr/lib/python2.7/dist-packages/parallel/", line 241, in PPEXCL
   fcntl.ioctl(self._fd, PPEXCL)
IOError: [Errno 25] Inappropriate ioctl for device

The /dev/usb/lp0 device entry appears to be created by the usblp module. I have a suspicion that what’s going on here is that the device entry created by usblp isn’t claimable the way one created by ppdev would be.

Using rmmod to get rid of usblp doesn’t work, it just gets restarted when I re-insert the USB connector for the adapter. Blacklisting it in /etc/modprobe.d/blacklist.conf just means that the /dev entry doesn’t get created, not that ppdev takes over.

Most reports online also indicate that USB parallel ports don’t really act like parallel ports, but only work for connecting parallel printers. Since I’ve already wasted enough time on this, it’s time to go with plan B. I’m going to fully populate the board, so that it has an Arduino on it, and then interface to that using serial commands and possibly Processing or OpenFrameworks.

A New Contender!

As I mentioned back in this entry, I don’t think the further development of the ToyBrain controller is useful. The main use case is amply solved by the Pololu Baby Orangutan. However, there is a project that I want something similar for, where the Baby Orangutan won’t work.

The idea behind the project is to make cheap swarm robots out of small robot toys, using something like the ToyBrain or Baby Oranguntan, but with wireless. The Moteino has wireless, but no motor drivers. The Baby Orangutan has motor drivers, but no wireless. The solution, then, appears to be to make a motor driver shield for the Moteino or a wireless shield for the Baby Orangutan. Of the two, I’m more inclined to do the motor shield for the Moteino, but I haven’t done any really analysis.

Microcontroller fun

The Arduino has a huge hobbyist-level codebase and lots of libraries for talking to various devices.

The 8051 is a venerable old processor that still gets used in lots of stuff because it’s cheap, and has a low gate count.

It’s probably possible to port a lot of the Arduino stuff (everything that doesn’t use specific on-chip features) to the 8051, thus allowing people to use the software environment they are comfortable with on a new chip. The same is likely true of PICs, and other chips.

The general case, then, is to create a translation system that automates, as much as possible, the process of porting the Arduino libraries and environment from one chip to another. This is, at a high level, possible because anything a computer with a turing-complete instruction set can do, any other computer with a turing-complete instruction set can also do. The hang-up would be on limitations of real hardware (there’s a lot of cool stuff in there, but no infinite data/instruction tape).

Potential ToyBrain Substitutes

The point of the ToyBrain project isn’t really to create the ToyBrain hardware. It’s to allow me to have a module that I can drop into children’s toys to add programability. Building the actual ToyBrain modules kind of got off into the weeds a bit, so I’ve taken a look around to see what the prices are like for modules that do more or less what I want. Here’s a comparison.

The Pololu Baby Orangutan. ($20) The Baby Orangutan has a 20MHz ATmega328P microcontroller (32k ROM/2k RAM) and a dual H-Bridge motor driver that can supply around 1A continuious power per channel.

The Cal-Eng MicroDuino ($25) Uses a 16MHz ATmega328P and a dual H-bridge that can supply 800mA per channel.

The Cal-Eng NanoDuino ($35) Essentially the same hardware as the MicroDuino, but about the same size as a penny.

The TinyCircuits TinyDuno + TinyShield Motor ($20 + $20) ATMega328. The motor shield can drive four motors, but has an upper limit of 500mA without heat-sinking, so it would need either a heat sink or for the driver channels to be paralleled. It also needs an $18 programming shield, but that’s a one-time expense. Measures about an inch square, and can be cut down to be round.

Microduino Studio Microduino ($?) Not available yet. Proposed hardware is in line with the others, but the motor driver, programming board, and CPU are all seperate, so the system cost will likely be around $40-60 per system. The proposed motor driver is the A3906, which is a dual 1A H-bridge.

Femtoduino ($12 + $5) ATMega328P microcontroller, 400mA per channel motor driver board. Cheap and very small (dime-sized), but the motor driver is weak.

Digispark + Motor Shield ($9 + $10) ATTiny85 (8K ROM/512 RAM) with 6 IO lines, 4 of which would be used to drive the 1.2A motor drivers. Smaller than a quarter, and very cheap. This probably does not have sufficent IO for my purposes, and is barely cost-competitive with the Baby Orangutan.

Looking at the available competition, if I want something better than just buying hardware, I have to essentially make the Pololu Baby Orangutan, only smaller, and with a higher output current. If there’s a 2A dual H-bridge motor driver IC available, this might be possible, but it won’t be by continuing the development path that I’m on (with a socketed, replacable motor driver). The STMicroelectronics L620x series bridges look good, but cost $7, so my $20 budget for parts would be half-blown on one IC.

For my projects that would have used the ToyBrains, I’m going to use the Baby Orangutan controllers instead. I may eventually see if I can get a small board together that uses the through-hole motor driver chips, but it’s not going to be a big priority.

ToyBrain Version 2 Firmware Troubles

I’ve started trying to load a bootloader onto the V2 hardware for the ToyBrains, as part of attempting to make a luminous fez for my girlfriend. I ran into a few problems.

The first problem I had was that the IC I’m using is the ATMega328, not the ATMega328P. So far, the only difference I can find between the two is their voltage range, but they have different ID strings. To get around this, I duplicated the chip definition for the 328P in avrdude.conf, and replaced the ID with the proper ID for a 328 (no P). This seemed to work for getting the Arduino IDE to burn the bootloader to my chip.

Unfortunately, I had made the Arduino boards.txt file description of my board by copying the Arduino Nano section. This includes a fuse setting for an external clock crystal. The toybrain boards don’t have a clock crystal, and use the internal RC oscillator of the Atmega328 instead. This meant that when the board was reflashed, it had no clock, and so not only could it not be programmed from the IDE, it also couldn’t be reflashed with a new bootloader using the USBTinyISP. The big symptom of this is that avrdude immediately fails to init, and if I used the -F (force, which you should never do) flag, it reported a part ID of 0x000000.

To fix that problem, I wired two small caps and a crystal to add an external oscillator to the board, tacked it to the appropriate pins, and reset the flags.

At this point, I think I have the bootloader installed, and the fuses at least mostly correct. The Lilypad Arduino with the ATMega328P uses these fuses: Low: 0xE2 High: 0xD8 Extended: 0x05, which mean that the clock is internal, and not divided by 8, so it runs at 8MHz. The bootloader settings set the size of the bootloader, which is the same as the one I am using (ATmegaBOOT_168_atmega328_pro_8MHz.hex), and the boot interrupt vector.

However, I still get a problem when I attempt to upload a program to the device. If I set the upload speed to 57600, avrdude beefs about the chip ID. If I set it to 19200, avrdude says the programmer is not responding.

My current guesses at the cause of the problem are these:

  • My clock settings are slightly off, so the chip is running at the wrong speed for the bootloader. As a result, the serial data rate is bad, and the data that avrdude gets back is nonsense. This can be fixed by applying the above fuse settings via the USBTinyICSP.
  • I have the reset vector or bootloader size setting wrong, and so the chip doesn’t start the bootloader correctly when it is reset. Again, this is a matter of fixing the fuses.
  • Something else that I haven’t considered yet, e.g. there is something wrong with my hardware.

I’m going to work on it more tonight and see if I can get it going.

Toybrain further improvements

I populated one of the Toybrain V2 boards and gave it a bit of a shakedown. I still have to test the motor driver, but I’ve at least fixed the backwards ICSP header and the reversed TX/RX lines. I did add a LED for debugging, but then hooked it up to a ADC line, so lighting it up means losing an analog pin.

For those as don’t know, you can get the analog pins on an Arduino/ATMega168/ATMega328/whatever to act as a digital GPIO by treating it like one, using the aliases “A0” through “A5”. Full instructions are here.

The V2 boards also have a reset button, which is very useful.

I’m already working on V3, which is going to be smaller. The V2 has headers for power, ground, and data for each pin, which I think is a bit much. I want that room back to build a voltage regulator and some filtering onto the board. The microcontroller can run at 1.8 to 5.5 volts, so the filtering is a bit more important than the regulation. However, some toys surely run at 6 volts or more, and would ruin the microcontroller, which is a SMD device.

So V3 will include filter capacitors, probably SMD, on the power rails, and a 3.3V regulator (The Micrel MIC5209-3.3 in SOT233 package looks good) or the option to short around it. The regulator only supplies the power for the microcontroller, so it won’t need to be very high power.

Nuiteblaster fail

I aligned the mirrors and powered up the draft hardware for the Nuiteblaster, and it didn’t work. This kind of fails to surprise me, as I changed a lot of stuff in the design. I think my speakers are good, but that using MOSFETs was an error. I used MOSFETs because they have a very low resistance when turned on, so they don’t waste energy as heat.

However, the MOSFETs in the design are switching 12V, and are getting a base drive of 5V. This means the voltage from the gate to the grounded source (Vgs) is at most 5V, because that’s what the Arduino can source, voltage-wise. The voltage from the drain to the source (Vds) is 12V. Since Vgs is > Vth (the point at which the MOSFET turns on), but nowhere near 12V, the MOSFETs are probably not getting driven into saturation, even when the outputs are fully on. This is compounded by the fact that since the code runs the PWM of the Arduino very fast, it is unlikely that that gate capacitance gets fully charged, and so the MOSFETs probably see a much lower average voltage at the gate, and so are probably operating in ohmic mode most of the time.

Whatever the cause, the speaker motion was quite small, and the MOSFETs got so hot that when I licked my finger and touched one of them, it sizzled.

I’m contemplating two possible fixes for this. The first is to replace the MOSFETs with the TIP120 power darlingtons that the schematic calls for. The second is to build my own power darlington transistor out of a 2n2222 switching the gate of the MOSFET to the full 12V of the beefy power supply that I’m driving the whole thing with. This would almost certainly drive the MOSFET into saturation, and hopefully get me the gain that my current rig lacks.

The speakers might also not be the best speakers for the job, but they are the ones I have. If I can’t get the system to work by changing the electronics, I’ll try new speakers next.