Thursday, November 27, 2014

Progress report (sort of)

So I have not updated my blog in a while. Grad school is keeping me pretty busy. Most of what I do with electronics now is related to the local hackspace I joined. I was able to use some tools there to shorten the bolts for the case of my RPN Scientific Calculator and I also have access to a laser cutter and 3D printer that I eventually want to use to make keys for it. One of the members there and I decided to start on a project together. We have not made enough progress yet to post about but we did finish a schematic of what we plan to do. For this we have both EPROMs and EEPROMs. The EPROMs have a small window and can be erased with UV light, though the lamp we have does not seem to be working. They would also need a higher voltage source to write them and I want to make a voltage multiplier when time allows. If I can get that working, it might also help me with another project that needs -27 volts for LCD contrast.

Another neat thing I have experimented with at the hackerspace is the Spark Core. One of our members was able to get a hold of several of these for us. These tiny little boards let you connect a microcontroller to Wi-Fi pretty painlessly. This would work really well for a project idea I have that I have not started on yet. One thing I don't like is the Arduino-like environment used to program them with but I think I could get used to it since I would probably use my own microcontroller for everything but Wi-Fi. Another idea would be to simply use the CC3000 chip the board uses without the Spark Core board, though that may be too complicated to be worth it. It seems that the newer Spark Photon uses a different chip which could be easier to use by itself, though Spark Photons are not scheduled to ship until March.

One thing I have been working on on my own is a sombrero with LEDs. It was supposed to be part of a Halloween costume, but I did not finish it in time. Each color (red, green, and blue) is soldered as a 4x4 matrix that has its own shift register. It might have been possible to solder all 48 LEDS (16 each of red, green, and blue) as a 6x8 matrix and use one less shift register, but this way lets me keep each LED on three times longer. NeoPixels would have worked well for this project but just one of them costs almost as much as all of the LEDs. The board for controlling everything is finished. Now all the LEDs just need to be sewed to the sombrero and the firmware written to control their flashing. In order to save time I only soldered buttons to the board for controlling the patterns of the LEDs, but I do have some nice potentiometers I bought that I now have time to use instead. Reading their value with an MSP430 worked great on the first try and I displayed it on my one wire debug display.

Tuesday, September 30, 2014

One wire debug display

Lately I haven't had much time to work on hobby projects but I did manage to do a few things. Sometimes for debugging I use an LED if the UART pins are not free to output to a serial terminal. This works alright for simple things but gets complicated when I start outputting different patterns of flashes. Instead I decided to wire a small screen to a microcontroller so that I can bitbang out debug information with just one pin.

At the beginning, I considered using a WM-1611-62C LCD from Russian telephones that I have had for the last two years. It runs on 1.5v, so I haven't been in a hurry to do anything with it. The documentation for it shows Vdd supplied by 5v through a 4.7k resistor with two standard diodes between Vdd and Vss. Running from the 3.6v of the launchpad, the voltage between Vdd and Vss was well under 1.5v and the display was very dim. Adding another diode brought the voltage up and resulted in the clear display you see on the right. Poking at the pins revealed what some of them do and I was able to bitbang some characters to the screen. This was possible even at 3.6v through diodes since the inputs are open drain. Unfortunately, other than 0-9, only a few other specialized characters are possible. Displaying anything in hexidecimal would not be possible, so I scratched the idea of using it.

The next idea I had was to use a cell phone screen. In Kyrgyzstan I found some 1202 cell phone screens for about $2 and I tried soldering 0.10mm wires to one of them. At 700°F the iron was way too hot and even at 550°F I managed to destroy the tiny ribbon cable of the LCD. The next LCD I tried was from a Nokia 3510i but I managed to lift the pads off of that LCD. It seems that the temperature displayed by the soldering iron might be wrong. Even at 350°F the iron melts solder very quickly.

Another idea I had was to use some small green 7 segment displays I have lying around. With one MSP430 I could multiplex all four of them. Even at the 6mA that a single pin can supply, these displays were very dim. Maybe it has something to do with running green LEDs at 3.6v. Next I tried a red 7 segment display from an answering machine that was very bright even at 1mA, so I soldered everything to perfboard like you see on the left. The MSP430 on there waits for data to come in on the purple line and flashes a number out digit by digit. It is probably not practical for displaying 32 bit numbers in decimal but seems to work well enough for 8 and 16 bit numbers in hex. The headers on the right are for relaying incoming data to a PC over UART, even if the UART pins on the main microcontroller are in use.

Saturday, August 23, 2014

6502 Virtual Trainer: Calculator Program

After I got my new Hakko FX-888, the first thing I did was solder the trainer to perfboard. It took some time to get used to the new iron but the board turned out well:

The FT232 cable connects to a few header pins soldered to a piece of perfboard connected perpendicularly to the main board by more pins that are bent at an angle. They make header pins at an angle but I used the last of mine on the board I made for programming the Z16F. There was also room to add some sockets and pins that can be used to program the MSP430, as well as power and status LEDs.

After using the board for about a week I had a strange error where the chip jumped to address 8080 on reset instead of 8000 which is stored at the reset vector. After some investigating, it seems there was a short between the Vcc pin of the IO expander and the pin controlling A7 of the 6502's address bus. On the back side of the board there was clearly no bridge which had me stumped but it worked fine after scraping away some of the flux between the joints. The problem reappeared after a week or two but was fixed again by cleaning the space between the joints. In frustration I ordered a W65C02 thinking the chip might have been damaged due to some acidental bus contention that had happened during testing. It seems that the pinout is a little different from the W65C816 I am using but it will still be useful because I plan to use it for an improved version of the trainer.

With the software I have made a little progress as well. The PC software skips sending any uninitialized memory and with a few other tweaks can program the whole 64kB memory in less than 3 seconds, down from 6 seconds. The microcontroller firmware is also a little better. Compiling with the -o3 flag in GCC brings average cycles per second up to about 16,000 from 12,000. However, setting the update rate to 100ms from 200ms to make typing more comfortable brings it back to around 14,000.

To learn 6502 assembly I decided to make a little test calculator program. It has turned out to be a really good way to get to know the chip, even though it has taken a lot longer than I expected. Below is a screenshot.

On the left is a text window for the 4-function RPN stack. It has 10 levels and each element is 8 bytes of packed BCD. This is convenient because the 6502 has a BCD mode. On the right is a window to enter formulas which can be graphed, like the first three, or repeated like the Celsius and Fahrenheit conversions. Formulas and graph colors can be selected with the dip switches. The toggle switch at the bottom selects between the two text windows and an LED above each window shows which one is selected. All of this could be done with a keyboard interface but I wanted to show off some of the peripherals that can be used. There is also a timer peripheral ticking every 500ms that the program reads to draw a flashing cursor in whichever of the two input text windows is active. The last peripheral is a multiplication ROM that works when single stepping the processor but not when running from SRAM yet.

There are still several improvements to be made to the trainer but I am done working on it for the moment. My plan is to port the code I have to an STM32 which will be much faster and also be able to store all 64kB of the 6502 address space in its internal RAM.

Thursday, July 3, 2014

Quiz Buzzer

About a month ago a friend of mine called and asked if I could make a buzzer system for a quiz game for students. Unfortunately, I only had two days until the competition and I did not get it working in time. Hopefully, I can fix it and send it to them to be used at the next competition in a few months.

The plan was that each of ten students would have a button connected to a buzzer by a few meters of wire and the first to press the button after a question was asked would cause a sound and light to go off. The connectors are RCA style and the buttons are from an automotive store.

These lead to an A42 enclosure I was able to sample from Serpac. The enclosure felt really sturdy but the plastic was surprisingly easy to cut and work with with just a knife. I will definitely use them again when I need an enclosure. The circuit itself was fairly simple with just an MSP430 microcontroller, buzzer, two 595 shift registers, and two 165 shift registers. I did not get around to adding the LEDs, although the firmware does use the shift registers to turn on the correct light when someone buzzes in.

To control things I made a separate detachable board with a 16x2 LCD. It will be easier to transport if the cable is detachable and it will also let me add a longer cable if the judges doing the scoring need to sit farther away from the enclosure. Other than the LCD, the board has a 555 to generate negative voltage for the LCD contrast and another 595 shift register to run the LCD. It also has buttons to change the time given to answer and to reset the counter.

For the cable I used Cat-5 again and this may be part of the reason it does not work correctly. For the connector I wanted to make something that would only plug in one way so that people other than me could use it without fear of plugging it in backwards and shorting something. Each side has a pin that can only be connected one way.

A project like this would take me a week at least but I tried to finish in two days because my friends needed it. The night before I stayed up soldering until 7am and when I finally switched it on, the LCD came on as expected and the buzzer sounded when I pressed one of the contestants buttons, but it made a high pitched screeching noise when it was finished buzzing. When I turned it off and tried again the LCD wouldn't display anything and only worked some of the time when I tried it again, so we weren't able to use it in the competition after all.

Why did it fail? In retrospect, I have had problems with this particular LCD in the past. When I was working on my calculator project I noticed that the LCD would often not work when being driven directly by a microcontroller but worked fine when being driven from a shift register like in this project. I'm not sure why it worked before and not now but the fact that it was flaky before might be a clue to my problem. Also, maybe my assumption that it will always work at voltages less than 5v is not correct or maybe supplying negative voltage to the display somehow has consequences. On the other hand, I observed the same faulty behavior with the contrast left unconnected. Another source of problems could be the Cat-5 Ethernet cable I am using for wiring. Each pair is twisted together and running a separate signal through each side of the pair instead of grounding one side might be leading to signal corruption. Finally, the loud screeching of the piezo buzzer is something I will have to figure out as well. Hopefully, when I understand more about this it will help me straighten things out with my clock project also.

Going from nothing to a nearly complete project in only two days was a lot of work, but in the end there was not enough time to troubleshoot problems. When I move into my new apartment next month I will have time to figure everything out and then I can send the working system back to Kyrgyzstan for my friends to use.

Monday, June 30, 2014

Clock Modification

The unfinished clock without the arms
For Christmas 2012 I got a battery powered alarm clock. It felt pretty sturdy but only plays a beep when the alarm goes off and it does not have a backlight. There was plenty of room inside the case so I decided to add a microcontroller to play the unofficial national anthem of Kyrgyzstan Кыргыз Жери (Kyrgyz Jeri) instead of just the beep. Although I have been working on it on and off for the past few months I have not gotten the bugs worked out.

The mechanism inside the clock runs from one AA battery and has a small buzzer that looks like a piezo. The positive side of the battery is connected directly to the buzzer by a wire. The other side of the buzzer is connected to a chip under an epoxy blob that switches the buzzer on and off. The 1.5v of the AA battery is not enough to run the MSP430 I am using so I wired in two AAA batteries. The clock case has just enough room for the extra batteries and a small piece of protoboard for the microcontroller. I opened the mechanism to solder in some wires so that the microcontroller can monitor the line switching the buzzer and drive the buzzer directly instead. One of the small gears inside quickly melted from the heat given off by the soldering iron a few inches away. Luckily, all of the local clocks use a similar mechanism and I replaced the whole thing for about $1. The wires from the mechanism are connected to a switch so that the buzzer can either be run by the microcontroller or by the original clock in case the extra batteries die. Another feature the clock is missing is a light, so I wired in an RGB LED I bought a few years ago. It has a light so that it can be used as a backlight but it also flashes colors in time with the music when the alarm goes off.

At first I tried soldering components directly to a DIP socket but this was surprisingly difficult, so I added everything to a small piece of left of protoboard. The AAA batteries are too big to fit in the clock case side by side so I couldn't use a battery holder. Instead I soldered wires directly to the batteries. This will make them hard to change but hopefully the MSP430 will use very little power waiting for the alarm to go off. Once I got everything soldered, the microcontroller would play the music it should but it would not stop playing even when it was disconnected from the line switching the signal. This is a problem I still have not figured out but I'm sure it has something to do with fluctuating signals in the circuit.

There were a number of other strange problems as well. The P1IES register used to enable edge selects for interrupts on the MSP430 sometimes gives the wrong value when you read from it. It would be useful to read it in an interrupt to know which phase of the cycle the interrupt was last configured to fire for. There was also a problem working with 32-bit values. It seems that doing math with constants and assigning the result to an unsigned long does not automatically promote the constants involved to 32-bit values as well. When I got the wrong value, I tried it out on a PC and got the expected value, which was a little perplexing. It seems that constants default to the bit size of the processor, which seems silly from a portability point of view. To have the constants treated as longs, the L prefix has to be added. Another strange thing that happened was that the buzzer always made a high-pitched whining even when not being driven. The batteries for the microcontroller also drained alarmingly fast. It turns out that both of those problems are related to the buzzer being electromechanical instead of a piezo. These buzzers do not charge and stop current from flowing like a piezo. It seems they only have about 40 ohms of resistance and this is why the batteries drained so quickly.

There are still a lot of bugs to be worked out but I hope to make progress soon and finish this little project quickly.

Monday, June 23, 2014

6502 Virtual Trainer: Update

Lately I have been working on several different projects and I have made a lot of progress on the 6502 Virtual Trainer. The first step was connecting the PC interface to an MSP430 over UART. This was easy because I have done it in other projects. Microchip let me sample some MCP23S17 IO expanders and I was really excited to be able to try them out to read and write the pins of the 6502. Unfortunately, they were a little finicky to get going because the datasheet incorrectly lists the reset pin as an output instead of an input.  They do save a lot of space, though, because five shift registers would be needed to replace them. After that was solved, I was able to single-step the processor as I intended but only at about 90 cycles per second. For comparison's sake, with the processor doing nothing else, that is a little too slow to type comfortably. At the beginning I knew this would be slow but that is much slower than I expected. The bottleneck seems to be the USB<->serial layer since the program sends lots of small packets of data instead of small numbers of large packets. To speed this up, I send 10 bytes of op codes every packet. Then the MSP430 can use the data sent if it needs to read a byte that is near. It will have to request more data if a jump takes place or data is read from another location in memory but in general this improvement led to a speed up of about 150 cycles per second. This was still not as fast as I had hoped for so I decided to keep a copy of all of the memory on an SPI SRAM chip. For this I used a 23LC1024, also from Microchip, which holds 128k. Using an SPI SRAM might seem to make less sense than just hooking up a typical parallel SRAM but by letting the microcontroller control the memory I can hold extra information about the data such as which bytes have not been initialized and which should be ROM. This will let me break when reads and writes that would be illegal are performed. Even during testing this turned out to be useful as it is easy for a beginner to assembly to write something like LDX $FF instead of LDX #$FF. As a compromise the MSP430 runs the 6502 as fast as possible then pauses and updates the PC every 200ms or when 64 bytes of memory have been modified, whichever comes first. Another way to speed things up was to increase the COM port speed from the 230,400 bps max of the MSComm control I'm using with Visual Basic 6 to 1,000,000 bps. At 1,200,000 bps the MSP430 could not keep up running the 6502 and reading data. With these changes I can run the 6502 at about 12,000 cycles per second. This is still pretty slow but fast enough to play with for learning purposes. To test things I made a few programs including one that draws a faded red pattern like below:

Tuesday, May 13, 2014

RPN Scientific Calculator: Case

After a few months of work, the case for my calculator is finally finished. Back in January I made a post with a picture of the clad I soldered together for the case. My plan at the time was to stuff all of the internals of the calculator into the case over the course of a few days but it ended up taking much longer.

The first hurdle was figuring out how to attach the front and back plates to the case. In the end I settled on epoxy. The first one I tried was still oily after 24 hours and did not hold very well but a much cheaper one held extremely well and I used it to glue four bolts to either side of the case body. Oddly enough the epoxy turned the clad green pretty quickly. From there I made holes with a box cutter in the front and back pieces for the bolts. Cutting out the hole for the keypad and LCD in the front piece of clad with a box cutter and wire cutters was a real chore and I don't plan on working with clad ever again without something like a dremel. For spacers between the clad and components I used rubber erasers.

These are cheap and easy to work with. My only fear is that they may dry out and crack someday. At first I tried gluing one of the plastic battery holders to an eraser with epoxy but surprisingly the bond was very weak. Super glue worked very well, though, and I glued in more erasers to hold the LCD, PCB, and keypad in place. All of that added a noticeable amount of weight to everything. The front and back pieces also have erasers glued to them to help hold everything together.

There was not enough room to comfortably route the wires from the LCD and keypad to the PCB so I desoldered them and used Cat5 cable instead. The wires inside are much smaller and easier to work with. It is also possible to leave the individual wires inside the Cat5 cable to make routing neater and I did this for some of the keypad wires. After assembling everything it worked fairly well except the keypad buttons were hooked up upside down. This was easy to fix in software and I loaded the new version using the programming pins soldered to the PCB without having to take the PCB out of the case. There was another bug that caused the calculator to freeze after pressing escape. For some reason the program was going into sleep mode when I pressed escape. I must have added this during debugging but it does not make sense at this point.

The next step will be to add some sort of labels for the keys and then paint it if I decide to.