Summer Hackathon

Over the past year, I have not had as much time as I would have liked to devote to my electronics projects because I have been so busy with school. Hopefully I will be able to catch up this summer. My goal is to finish some projects I have already started on and start on some others I have been planning for a long time.

Here is a list of what I will be working on. Even though I probably won't have time to finish them all, these are my goals for the summer.

EEPROM Computer	Progress:	40%
As part of another project, I got interested in using an EEPROM lookup table to do four bit additions and ended up with this test setup. A 32KB EEPROM can hold 64 tables, which is enough to implement all the op codes for a full CPU. Hopefully this will greatly reduce the amount of logic involved. All that should be needed are some counters, buffers, and a multiplexer. So far I have finished most of a simulation in Atanua and started on a symbolic assembler. After I finish the assembler and have the simulation running, I will move everything to perfboard and program the op codes and source code into real EEPROMs.

8-bit Homebrew Computer	Progress:	0%
This project is something I have been thinking about for a long time. I won't say exactly how I plan to do it yet but looking on the internet I haven't found anything similar. It won't be possible to simulate this project in Atanua, so I plan to build it directly on a breadboard. The same assembler from the EEPROM Computer should be able to be changed to work for this also. I'm not sure yet whether it will be worth it to make a PC simulator for this project.

Brainfuck Micrcontroller	Progress:	50%
After I finished the simulation for this project, I did not do much more work on it. The simulated version is four bits and will have to be expanded to eight in the final hardware. The software for the project is very simple, as all it does is convert Brainfuck commands into simple op codes.

Juggalo Robot	Progress:	70%
My brother and I started work on converting a remote control car into a robot. It will have a baby doll on top with moving arms and a rotating head. He decided to paint the doll's face and make the robot juggalo themed. He got motor drivers working with an Arduino for servos in the arms and a stepper for the head. My work so far has been to reroute motor control signals on the car from the motors to a microcontroller. That way another microcontroller in the remote control can send motor control signals over the radio, which the microcontroller in the car will intercept and interpret. Then it can activate the motors, servos, or stepper according to the signal sent by the remote. The hardware is mostly finished. All that's left is the software, which should be pretty simple.

ESP8266	Progress:	0%
Last year we had a fun night doing projects with some SparkCores at our hackerspace and I decided to get a hold of an ESP8266. At $4 it was much cheaper than a SparkCore, even if it is not as easy to program. Unfortunately, I have not had time to even hook it up and try anything with it. One of my plans is to install it in a calculator for an idea I have been thinking about for a long time. One of the challenges will be getting it to connect correctly to WiFi at my university or local cafes. Another idea is to use it to program MSP430s or EEPROMs from my Chromebook, since it can't program them directly over USB.

Wireless Breadboard	Progress:	0%
This is a project I put a lot of thought into before I found out that it has already been done. My plan is to use IO expanders to control every row of a breadboard with a microcontroller. For rows that should be connected wirelessly, the microcontroller will read and relay signals to the appropriate row. This will be comparatively slow because the microcontroller will be bitbanging both the input and output of the IO expanders. Another project I saw used an FPGA, which would be much faster, but using IO expanders will hopefully be an acceptable solution, even if it is much slower. All the connections between rows will be set on the PC, which is hopefully more convenient than plugging in wires. The main advantage will be monitoring the rows and displaying data in an easy to read way on the PC. This should really speed up debugging. Also, output signals can be controlled from the PC, so programming EEPROMs or other chips should be easy.

ATF1508 CPLD	Progress:	5%
For my next 6502 project I want to use a CPLD for the address decoding. The ATF1508 is one of the few ones left in production that runs at 5 volts. It can be programmed over JTAG, so I started soldering a programmer that will use an MPS430. The chip comes in PLCC. so soldering the adapter will be a little inconvenient. My plan is to add LEDs and dip switches so I can test my designs after programming.

BASIC Interpreter	Progress:	30%
A couple of projects I would like to do eventually will need to run a BASIC interpreter. One of them is the wireless breadboard mentioned above. It would be better for new functionality, like device programming, to be done with some kind of script. That way, new scripts can be transfered to the chip at run time, instead of having to reflash the chip every time.

LCD Programming	Progress:	0%
Some of the upcoming projects will need an output of some kind. A four inch LCD should work well for the ones that a 20x4 character LCD isn't enough for. Hopefully I can get one kind of LCD going that will work for several of the projects. Another option is a 5.5 inch LCD I got a few years ago. It is much larger but requires -27 volts for contrast. This is not easy to generate, but if I can get it going, I will hopefully be able to buy several more pretty cheaply. It would work well with homebrew projects if I can get it working without a microcontroller. The STM32F429 board I have been working with also has an LCD that I would like to get going.

Improved 6502 Trainer	Progress:	20%
The 6502 Virtual Trainer was nearly finished when I stopped working on it months ago. It works really well, except that the max speed is just under 0.02 MHz. Now that I have my STM32 board running, I hope to port the code for the project from the MSP430. It ran the BCD multiply routine from the microcontroller comparison about 15 times faster, although that's probably not a good indicator of how much faster it would be for this project. There are a few changes to how UART works that might speed things up also. Another speedup will come from driving the GPIOs directly, instead of through IO expanders. Hopefully all of this together will give me the 50x speedup I need to hit 1MHz. At first I intend to make a board that will plug into the STM32 board directly and possibly use a UART cable for communication. When I figure out how to design PCBs I will make a standalone board with an STM32F429 and an FT232.

Improved RPN Calculator	Progress:	40%
For one of my friends I would like to remake my original RPN Scientific Calculator. This time I will use an LPC1114, which will allow me to copy numbers to the chip's memory before calculating. This should greatly increase calculation time because the external memory won't have to be accessed during any calculations. This will also make the firmware smaller. It should easily fit into the 32 KB the chip has, so two microcontrollers won't be necessary. Also, I would like to use a 23LC1024 SPI SRAM this time instead of parallel RAM. Altogether, the circuit should be very small.

EEPROM Programmer

For a couple of projects I want to work on in the next few months I will need to use EEPROMs. Another member at our hackerspace I have been working with on the BrainFuck microcontroller gave me a few EEPROMs and UV-erasable EPROMs. Like I posted before, I was able to program some of the EEPROMs with an MSP430 on a breadboard and now I have it soldered onto protoboard.

The UART is handled by an FT232R chip that I deadbugged. It gave me a lot of problems when I first soldered 24 gauge Ethernet wire to the pins. At first I tried to tin the pins and this led to several shorts. Because the chip was superglued to the board, there was no way to get at them to fix it. Pure acetone paint remover did not take the superglue off and neither did soaking the board in fingernail polish remover for several hours. The glue got gummy but would not come off, so I left the chip where it was and soldered female headers next to it. Then I soldered another FT232R onto a small piece of protoboard with male headers so I could plug it in to replace the other chip. You can see it on the left side of the picture with the red wirewrap wire. The old chip is partly visible just underneath. The first time I tried I accidentally shorted some of the pins together when I was soldering them, so I bent them vertically to make it easier to get at them. When I bent one down to make more room, it broke off. Unfortunately this was the Vcc pin which I couldn't do without so I had to start over with a third chip. Once I got everything soldered, it worked fine.

The local electronics store did not have any USB B connectors so I had to use a dual USB A connector. The MSP430 is running off the 3.3v provided by the FT232R, so I was afraid of programming it at 3.6v with a LaunchPad since 0.3v above Vcc is the absolute maximum rating in the datasheet. That's why I have the two programming lines running through diodes on the little protoboard above the MSP430. The third "bandaid" piece of protoboard holds two transistors for level shifting. Controlling the EEPROM WE and OE lines with the MSP430 worked fine but it turns out that TTL chips can source voltage from their inputs which would damage the MSP430. The EEPROMs I have now are not TTL but I might run across one at the hackerspace and I wanted to be safe. The ZIF socket on there also came from a hackerspace member who had found some and didn't mind sharing.

The shift registers that control the data and address lines are running at 5v. The data line going to the microcontroller from the 74HC165 shift register is switched by a PN2222A. This limits SPI speed to about 400k/s. When I find a faster transistor, I should be able to read and write much quicker. The software interface is just over a plain serial terminal. In retrospect, it would have been easier to design a custom program on the PC side but it's convenient that it can work with any operating system without special software. To transfer I use XMODEM which caused some headaches at the beginning. It turns out that TeraTerm transfers the first packet twice without being asked, which caused an overflow of my UART buffer and was hard to track down since that's not expected behavior for XMODEM. It burns about 100 bytes per second but with a faster transistor I hope to write fast enough to do page writes, which will speed things up a lot.

AT89LP6440 Flashing

For the Microcontroller Comparison I have been trying to get the AT89LP6440 to work. When I sampled the chip I thought it could be programmed over serial with an FTDI cable like the DS89C450, but it turns out that it needs a parallel port. There are adapters and programmers that will simulate a parallel port over USB but I don't want to buy one for a chip that I might not use much in the future.

As a workaround I used the FTDI cable to bitbang the SPI interface. This was tricky because I had to write a whole new loading program instead of relying on the program Atmel supplies. Thankfully, they provide very good documentation of the ISP specification. Bits are sampled on MISO on the falling edge of the clock and MOSI is sampled on the rising edge. My first version of the program worked well but could only upload about 100 bytes of firmware per second. Part of this is due to reading MISO every clock cycle, which is not always necessary. By splitting reading and writing into different functions and sending pin states in groups instead of individually, flashing is much faster. There is a bug, though, that randomly gives a wrong byte when I try to read from the chip to verify the firmware. The wrong byte is always at a different address and sometimes the verification completes, so I know the AT89LP6440 has been programmed properly. I wasted about a week trying to tweak the program and saw that the D2XX drivers supplied by FTDI are unreliable and pretty buggy (at least when used under Windows 7 for bitbanging). This particular problem could be with the chip but several of the other D2XX functions I tried didn't work very well either. The same problem happens with both synchronous and asynchronous modes. There is an open source library called libFTDI but I didn't get very far with it because installing the driver for it would mean losing the virtual COM port you get with the FTDI driver. The next step would be to program the chip using another microcontroller connected to the PC over UART but I don't want to waste any more time on this chip since I am unlikely to use it for anything after the microcontroller comparison.

You can download the program here: AT89Loader. Flashing seems to work with no problems but verification occasionally fails.