I tend to assume that batteries I happen upon will not be charged. Also that lead-acid batteries I happen upon will be low on water, even so-called sealed lead-acid batteries.

I wanted to start charging the batteries from my “new” scooter while working on other aspects of the project and the scooter didn’t come with a charger — I’ll deal with that later. Not knowing much about the wiring circuit yet, I didn’t want to connect an external charger to the batteries while they were still in-circuit and chance damaging the speed controller, so I needed to disconnect and remove them.

Wiggle wiggle wiggle <grunt> wiggle pull <grunt> WIGGLE WIGGLE BEND <grunt>

Wha?

Who does this??? When they said solder the quick-disconnect terminals, they meant the wire side.

Fine. My uncle’s iron and a pair of pliers solved that problem.

Two batteries, extricated and not yet cleaned.

In spite of being “sealed,” you can pry off the cover (preferably after cleaning, which I did first with Goo-Gone and then with dish soap and water)

and get to the cell caps, each with a little absorbent pad in case the cell venting carries too much moisture.

I could see no water in any cell of either battery. I borrowed a jug of distilled water from my folks (I don’t know why Mom always has some, but she does) and started filling them up … after taking measurements.

I filled each cell, waited for air bubbles to trickle to the top, refilled, waited, refilled, waited … I’m guessing between the initial fill and while charging, I ended up putting at least 10 ml of water into each cell.

Then put battery 1 on my variable power supply with the voltage set to 13.8 V and the current limited initially to 0.1 A, raising the current limit to 0.3 A as it was clear that nothing horrible was happening. I checked on it every half-hour to hour, frequently refilling at least one cell in which I could no longer see any water.

After about four hours, it was up to 13.5 V. The water level in the cells had risen to overflow the opening and fill each reservoir. If I watched long enough, I could see the water in a couple of cells <pop>, indicating they were just starting to gas and it was time for me to stop this method of charging for the day. (More on that on a subsequent day, hopefully tomorrow.)

While battery 1 was charging, I was also checking water levels in battery 2 and refilling low cells, just sitting on the counter.

Recalling that it had an initial 10 V charge to battery 1′s 11.7 V, noting that they had been connected in series, and knowing that the worst cell in a battery generally has a cascading failure, I expected a different charging experience from battery 2, and I was quite right.

I connected it to the power supply and it immediately showed 13.8 V at a 0.1-A current draw. Now, about an hour later, it’s at 13.5 V and 0.3 A and most of the cells have overflowed. It’s nearly done charging but I haven’t put nearly as much energy into it as I was able to put into battery 1 — that is to say, it’s not “taking” as much of a charge.

Tomorrow, schedule willing, a load test and an attempt at desulfation.

All of the wires are cut, the deck is missing, the rear wheel was unattached, naturally the drive belt was missing, and no charger.

$10. I bought it. Sounds like a fun project, eh?

The battery and speed-control bucket could use some repair but seems at least functional. I started working on the batteries but as soon as my brother was available redirected my attention to reattaching the rear wheel.

The rear wheel is belt-driven and needs to be positioned to align with the motor pulley but the spacers were absent and it slid freely from side to side.

A trip to the hardware store resulted in a roll pin with ID slightly larger than the 1/4″ axle diameter and length slightly greater than the two spacers needed, for $1.89. Then my brother’s giant chop saw made short work of creating two pieces from one.

Touched up a bit on the bench grinder, ends rounded over with a file, and interiors cleaned out with a round file, spacers fit perfectly and the rear wheel bolts on securely. We “kicked” our way up and down the driveway and are eager to get the scooter powered up.

Next: Battery investigation.

The original is in this post from 2011.

I have no CC notices posted for the whole site (though I’d be happy to); but of course the Berne Convention provides for automatic copyright upon creation and publication of a work, so this is a blatant copyright violation.

Regardless, why is an eBay seller with only 110 feedbacks (vs one who does business on a scale of 110,000) too lazy to take their own picture of what they claim to have for sale?

6502 Microprocessor, Apple ][, and Asteroids

A couple of weeks ago, I went to an annual holiday lunch with former coworkers and got to visit with an old friend. He was reminiscing about 6502 assembly programming on the Apple ][ and wondered whether I'd know where he could get one. I told him that I could probably loan him one or two; but (with a mischievous glint in my eye) that I have a couple of upright Asteroids arcade games and they run on 6502s and I’ve always wanted to reprogram one and write my own game.

Bump, set, spike. Yeah, he’s interested.

It’s not a completely impractical idea. I have a large schematic set that includes the addressing of the memory-mapped I/O and some rudimentary information on the operation of the vector generator board. There’s even a project to comment the disassembled ROM, which would give further hints about how to interface to the hardware.

If one were to undertake such a project, one would really like to use a USB-attached EPROM emulator so one could dump new code into the machine frequently and rapidly for testing and development. But at a bare minimum, one would need a stack of EPROMs and a programmer and ideally a ZIF-socket daughterboard to fit into the original EPROM socket and make it easy to swap EPROMs. As I have no Windows machines and do my electronics development on a synchronized fleet of Mac and Linux machines, a commercial EPROM programmer that I can use is going to be a little bit hard to come by.

Yes, I could run Windows under virtualization on my Mac; I think I may even be able to get a legal copy through my campus’s license agreement. But I’m not interested in going that direction unless I have to.

Isn’t it about time the world had a cross-platform EPROM programmer?

Yes, it is what it looks like.

I’m the second owner.

It hasn’t been powered on in 36 years.

I’ll post more pictures as I share the story and test it carefully to make sure it’s safe to power on.

Install CrossPack Development Environment

First, install CrossPack, which provides “the GNU compiler suite, a C library for the AVR, the AVRDUDE uploader and several other useful tools.” Make sure you completely close your Terminal program (if you had it running) and restart it after the installation, to pick up the location it adds to your command search path.

Test the Programmer and Connectivity

Once installed, connect your programmer (I have a couple of USBtinyISPs, so that’s what I used) to your computer and target board and test that the programmer is working and sees your ATtiny:

$ avrdude -c usbtiny -p attiny25
avrdude: AVR device initialized and ready to accept instructions

avrdude done. Thank you.


If you get any other response, check the troubleshooting notes at the bottom of Jeff Keyzer’s AVR toolchain installation page.

Create Blink Code

The CrossPack web page includes a blinky demo project, but it’s written for a different microcontroller and requires minor adaptation to work on the ATtiny25. Follow along both here and there for greatest insight.

In your Terminal window,

$ avr-project blink
Using template: /usr/local/CrossPack-AVR-20120217/etc/templates/TemplateProject
$ cd blink/firmware
$ ls
Makefile main.c


The Crosspack example is written for an ATmega8, which has more I/O ports than the ATtiny. The ATtiny has a single I/O port, and it’s port B (mystery of the universe why not A). So adapting the example code, use your favorite text editor to insert into main.c to create the following (picking whichever pin you’d like to use for your LED):

#include <avr/io.h>
#include <util/delay.h>

#define LEDPIN (3)

int main(void) {
    DDRB = 1 << LEDPIN;  //  make only the LED pin an output
    while (1) {
        char i;
        for (i = 0; i < 10; ++i) {
            _delay_ms(50);
        }
        PORTB ^= 1 << LEDPIN;
    }
    return 0;   /* never reached */
}

Calculate Fuse Values and Edit the Makefile

Use the Engbedded AVR fuse calculator to calculate the command-line values to set all the ATtiny behavior flags. Use AVR part name: ATtiny25, uncheck (for this example) Divide clock by 8 internally, and scroll down to Current settings. You should see something like

-U lfuse:w:0xe2:m -U hfuse:w:0xdf:m
-U efuse:w:0xff:m


Back in Terminal, edit Makefile . Update the following lines:

DEVICE = attiny25
PROGRAMMER = -c usbtiny
FUSES = -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m


(using whatever programmer you have and any additional flags it needs) and save and exit the Makefile .

Compile and Load the Program

Run

$ make
avr-gcc -Wall -Os -DF_CPU=8000000 -mmcu=attiny25 -c main.c -o main.o
avr-gcc -Wall -Os -DF_CPU=8000000 -mmcu=attiny25 -o main.elf main.o
rm -f main.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avr-size --format=avr --mcu=attiny25 main.elf
AVR Memory Usage
----------------
Device: attiny25

Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)


to build the program. If you get errors instead, double-check main.c around the line the compiler indicates.

Run

$ make flash
avrdude -c usbtiny -p attiny25 -U flash:w:main.hex:i

avrdude done. Thank you.


to program the IC. Run

$ make fuse
avrdude -c usbtiny -p attiny25 -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m

avrdude done. Thank you.


to burn the fuse bits.

Behold Blinky Goodness

The board I’m developing doesn’t have an LED on it, so I clipped my logic analyzer to ground and I/O pin B3 (IC pin 2) to test for blinking.

1 Hz blinking on my I/O pin. Fundamental programming accomplished.

I aligned each chip’s pins by hand, clamped it to the board with a gator clamp (with heatshrinked jaws), soldered the far row of pins, rotated the board, and soldered the now-far row of pins.

Three rows I was able to do by blob-and-drag (heat the pins at the uphill end of the row, make a big solder blob, and drag it down the row at a pace slow enough to heat the pins but fast enough to keep the surface of the blob from oxidizing too badly, trusting surface tension to bring the blob with you and leave only a lovely solder fillet below each pin). Three rows I ended up doing slop-and-wick (get solder all over the place, then use “Size: Good” solder braid to remove solder bridges from between the pins, leaving a lovely solder fillet below each pin and evidence scorched flux everywhere).

I’d take recommendations on a good flux remover — preferably detailed recommendations indicating whether you have to scrub or just spray, how cleanly it washes off, etc. You can see that the rubbing alcohol I used leaves a bit of residue.

It looked like a trivial change, but after making it, the display’s screen remained blank.

But … but … but … the slave-select line is supposed to be held low during each byte of transmission. I know the ATmega’s SPI hardware doesn’t manage it for you, but surely the Arduino’s SPI.transfer() function does, right???

Working Arduino SPI Transfer

No. You have to manage it manually.

void LcdWrite(byte dc, byte data) {
digitalWrite(PIN_SS, LOW);
digitalWrite(PIN_DC, dc);
SPI.transfer(data);
digitalWrite(PIN_SS, HIGH);
}

SPI support is a perfect candidate to be a real object-oriented class rather than a functional library in OO clothing. Instantiate objects that know which slave-select pin is theirs, which may have different bit orders and clock rates and clock modes, and provide a transfer() method that sets all the registers, twiddles SS for you, and transfers your byte.

Sigh.

Faster Arduino SPI Transfer

BTW, notice on the second capture that manually bouncing SS using two digitalWrite()s takes longer than transferring eight bits of data using the hardware SPI. Start to understand why I want to transfer data using hardware instead of bit-banging?

Manipulating the SS bit in the port register directly is much faster … at the cost of being much less clear what’s going on to non-native speakers of C.

void LcdWrite(byte dc, byte data) {
PORTB &= ~ (1 << 2);
digitalWrite(PIN_DC, dc);
SPI.transfer(data);
PORTB |= (1 << 2);
}

ATmega I/O Pin Hardware Toggling for Fastest Arduino SPI Transfer (That Isn't Any Faster)

The C-based bit manipulation code above is already fast enough that the timing constraint has moved back to the programmer-selected SPI clocking speed and the ultimate solution -- using the ATmega's hardware-based pin toggle feature -- doesn't save any noticeable time, but the code sure looks cool but it's the right thing to do and it's a risky game to play to assume you always know correctly the logic level of the pin when you enter the function.

void LcdWrite(byte dc, byte data) {
PINB = _BV(PINB2);
digitalWrite(PIN_DC, dc);
SPI.transfer(data);
PINB = _BV(PINB2);
}

(BTW, I had a dream recently -- which I did not know was not real -- in which the latest Arduino release added digitalWrite(pin, TOGGLE) to do the above. Imagine my disappointment tonight to learn it was only a dream. And no, I'm not the first to suggest that feature, by a long shot. Just, maybe, the first to think it had actually happened.)

I haven’t made an Arduino-compatible before, and the only two things I found daunting were the crystal, which I understand has to be exactly matched to its supporting capacitors or the circuit won’t resonate, so it was important to find the same one used in the Arduino; and the resettable polyfuse on the USB power lines, which doesn’t (in the Arduino circuit) specify whether 500 mA is the hold current or the trip current.

I found an Arduino playground post by Tom Igoe giving Digi-Key part numbers for a bare-bones breadboard Arduino-compatible and chased the out-of-stock crystal to the equivalent Digi-Key catalog number 887-1019-ND. I searched far and wide for information on the polyfuse and gave up, settling on 500 mA hold current, since that’s permitted (after negotiation) by the USB spec and surely we wouldn’t want to trip at the maximum permitted current.

With that data in hand, I still had a healthy dose of uncertainty about my likelihood of building a working Arduino-compatible. I prefer to develop and test modularly, so I wanted to assemble a working proof-of-concept Arduino-compatible before diving into the LED calculator project. And as it happens, I had a perfect project waiting in the wings — an Arduino-compatible board with ground and power headers surrounding the normal I/O headers (like servo connectors), to make it easy to connect external sensors without going all-out and buying a sensor shield (which actually has the I/O pin at the end of each connector rather than in the middle, whatever). I want to build my own version of my friend Trevor’s household temperature-monitoring system, and such an Arduino-compatible would be a great platform for terminating the three-wire temperature sensors.

To speed the process, I started with the EAGLE schematic of the Freeduino through-hole design, ripping up the board and laying it out mostly from scratch to make room for my extra header rows. I had the board produced by BatchPCB, I received it last week, and I have now assembled it into a working Arduino-compatible.

But not — this is going to sound soooo familiar — without some snags along the way.

Testing the FTDI USB-Serial

The one component not available in a through-hole package was the FTDI USB-serial chip; and I planned on hand-soldering it; and that’s way easier to do without other components looming over it and getting in the way of the iron; so I attached it first. And that led me to test it first as well, since I test as I go.

This is about the minimal set of components to test the entire operation of the FTDI chip. Power jumper and lots of bypass capacitors, polyfuse, power LED and current-limiting resistor, transmit and receive LEDs and resistors, and … yeah, the Arduino’s digital pin 13 LED is completely unnecessary.

And it worked! I powered it up first connected only to a powered external USB hub so that if anything was horribly wrong, there was no way it could smoke my computer. The power LED came on and the transmit and receive LEDs came on and stayed on. With only the slightest twinge of hesitation, I plugged it into my laptop. The transmit and receive LEDs went out, ZTerm recognized a new serial port, and I could type into the receive LED to my heart’s content.

ATmega and ISP Header

The next step was to install the microcontroller and try to in-system program it. The minimum additions were the ATmega and socket, the crystal and its capacitors, the reset button and pull-up resistor, and the ISP programming header.

I connected my USBtinyISP, fired up the Arduino IDE, and tried to burn the bootloader — and it didn’t work. The USBtinyISP thought it had no chip connected.

It was late Wednesday evening and I had to put the board away with the problem unsolved. I didn’t yet know whether the problem was with the microcontroller not even running, with the programming port, or somewhere else in the design.

Troubleshooting In-System Programming

Thursday night I had a rehearsal so didn’t get to devote much time to the problem, but I did move the ATmega from a working Arduino into this board and it worked, running the Blink sketch. I put the ATmega from this board into the working Arduino board and in-system programmed it, and it worked, both there and when I put it back into this board. That was a relief — it meant the fundamental design was okay and I had a problem with the programming port.

Which is so dead simple, how can it have a problem??? It’s just traces!

But one of the traces is both the ISP clock line (SCK) and the Arduino-compatible’s digital pin 13, which has an LED on it, which loads down the ISP clock line … I lifted one leg of the current-limiting resistor, but that didn’t fix it.

I spent Friday evening with friends making (and consuming!) pizza and ice cream, so it was Saturday before I got back to this. By then I had examined the schematic and board layout over and over again, comparing them to multiple other references for the ISP pinout, not finding any problems; and I knew I had to get more serious. It was time to learn to use my Saleae logic analyzer.

I love the product. I find the manual not well organized and I got no response to my polite email months ago detailing many, many ways they could make it more clear for me — such as listing what voltage range is considered logic high. I love the look of the user interface. I find manipulating the view and the data clumsy. I hate learning to use new products and systems when I’m in the middle of something hard I wish I didn’t have to do, and I learned anyway.

I connected the logic analyzer to every pin of the ISP port — including the 5V power pin, mainly for completeness but partly out of paranoia — of the working, real Arduino and set the analyzer to trigger on a negative-going edge of the RESET line (or assertion of /RESET, if you wanna be that way). I captured the beginning of an ISP cycle, then moved the analyzer to the homemade Arduino-compatible and repeated the capture. You may safely ignore the transitions on SCK before the trigger event (time 0.0) — the boards are running the Blink code until they get reset to start the programming (attempt), and that’s the LED pin.

I saw enough differences between these captures that I wasn’t sure where to begin, so I decided to go to the source: Atmel’s application note AVR910P In-System Programming. I verified the ISP port pinout yet again. I read about the functions of each pin. And on page 4, I found this gem:

When Reset is applied to the target AVR microcontroller, the MISO pin is set up to be an input with no pull up. Only after the “Programming Enable” command has been correctly transmitted to the target will the target AVR microcontroller set its MISO pin to become an output. During this first time, the In-System programmer will apply its pull up to keep the MISO line stable until it is driven by the target microcontroller.

Hang on. MISO is set to be an input and the ISP will apply a pull-up? Then why, on my board, is it low the entire time? It must be shorted to ground.

I grabbed the meter. MISO was shorted to ground.

AWESOME! I just have to find the solder splash … which is unlikely on a commercially-produced board with solder mask … and there’s no solder splash.

Okay, I just have to find the design error connecting MISO to ground. Yeahno, EAGLE absolutely has MISO and GND as separate signals. And BatchPCB sent me a spare copy of the board, which I checked with a meter, and which did not have MISO shorted to ground.

Okay, I just have to find the manufacturing error shorting MISO to ground. Many, many minutes with a magnifying glass and I found nothing.

The whole time I’m thinking about how glad I am it’s a two-layer board so I don’t have to be paranoid about a short on an interior layer where I can’t see it.

Yesterday ended and I went to bed knowing I had a signal shorted to ground and being completely unable to find it.

Today I knew I had to get yet more serious. Out came the Capacitor Wizard.

Scoff all you want. It has saved me countless hours testing capacitors in-circuit, but its utility doesn’t end there. It is an exquisitely sensitive ohmmeter and can easily detect the difference in resistance between 1″ and 2″ of copper trace.

I put one probe on the ground plane and tested every point along the MISO path with the other probe. The short to ground was quite clearly nearest the header at the top of the board.

Back to the magnifying glass, and knowing where to look, I found this. (As always, click to see full resolution.) It looked like a booger in the varnish, but it extended across the isolation between the ground plane and MISO, and it was in the segment of the MISO trace where the Capacitor Wizard said it should be.

I took the board to Ron’s to use his big magnifying glass to get the pic, and he was convinced the booger wasn’t in the copper layer and didn’t want to scratch up my pretty new board finding out, especially after knocking down the surface of the booger with a plastic scratching stick and not getting down to copper. He even desoldered the microcontroller socket to get a closer look at its pads and the vias under the socket … finding nothing, of course.

So when he stepped out of the shop for a bit, I cut the MISO trace near the microcontroller to isolate which end of the trace had the short to ground — and it was the upper end. Armed with that information, Ron couldn’t help but capitulate. I allowed him the honor of scraping away the “hair” for me, which quickly revealed itself as copper, and he quickly revealed a few words he knew. And the short was gone.

Ron did a gorgeous, almost invisible job of jumpering over the trace I had cut. MISO was still not shorted. I brought the board home and resoldered the socket and MISO was still not shorted. I tested the ISP. It now works fine with the digital pin 13 LED out of circuit and it doesn’t like the load with the LED in circuit.

No problem. For my prototype board, I socketed the ancient, power-sucking LED so I can remove it if ever I want to in-system program the board again. Inside my LED calculator, I probably won’t put a “Blink” LED. If I want to make a board that does have an LED on digital pin 13, I’ll buy a modern, high-efficiency LED that I can run with a much higher series resistance, just like the real Arduino does, and not load down the SCK pin so much.

Sweet, Sweet Success at Last

A little more soldering to install the headers and the rest of the components, and that’s the rest of the story.

Well, almost.

To quote SparkFun forum user FlorinC, talking about an entirely different board,

The capacitors look taller than the headers. This will be a problem when a shield is plugged in.

<scratches head> Yup. Ya got me there. Good thing I built this one specifically to avoid using a shield.

But well noted. I’ll use leetle capacitors should I decide to make an Arduino-compatible into which I intend to plug a shield.