Sunday, January 18, 2015

Space Sombrero

For Halloween I decided to put some LEDs controlled by an MSP430 on a sombrero. Unfortunately, I did not finish in time to take it to the Halloween party at our hackerspace but I did finish working on it the last week.

The LEDs are soldered in three 4x4 matrixes, one matrix for each color. My plan was to combine red, green, and blue into one point diffused with ping pong balls. In the end I skipped the diffusers. The LEDs are bright enough on their own. They are taken from a string of Christmas tree lights so the total of 48 LEDs cost about a dollar. Something like NeoPixels (WS2812) would have been better for this project but would have been much more expensive.


Each color is run by its own 74HC595 shift register, so only one LED per color can be on at a time. This reduces apparent brightness when several LEDs are driven by PWM but is still brighter than using only one matrix for all the LEDs. With a 1k resistor they are very bright, which I noticed when experimenting with them before. Everything is controlled by a small PCB. Each matrix is connected to a Cat5 ethernet cable which has four twisted pairs, exactly enough to multiplex 16 LEDs. The two knobs control speed and color of the patterns and a button switches between patterns. Altogether the hardware is really simple, though there were some headaches soldering the board. The legs of the potentiometers are very weak so I soldered header pins to the back of them for stability. They are really sturdy now but Vcc was shorting through the body of the potentiometers. Once I fixed that, there still showed only about 4k resistance between ground and Vcc. A tiny fleck of solder on the metal body of the power switch was also causing a short. After fixing that there was still a 33k resistance between ground and Vcc. Desocketing and unsoldering narrowed it down to the L4931 voltage regulator. Several other L4931s I measured had the same resistance. After putting everything back together, it worked fine.

The potentiometers and knobs for them came from my local electronics store. They are logarithmic, although linear would work much better for communicating speed to the microcontroller. Converting the curve mathematically seemed pretty tricky, so I used a look up table of a few measured values instead. After soldering the potentiometers onto the board, I realized that the seven values I measured were not enough, so I plotted them on a graph and extrapolated more points. The values I came up with work pretty well, though when changing colors the distances between points don't feel exactly even. The next time I use potentiometers like this I will try to do a lot more exact measuring before soldering them so the points will be more even.

Here is a short video of a few patterns I programmed in. You can see how the speed and color knobs work. There is a lot of room left in the flash for more patterns but this is enough to consider the project finished.

video

Tuesday, January 6, 2015

Brainfuck Microcontroller

For a year or two I have been thinking about making a brainfuck computer out of 7400 series logic. Homebrew computers made out of logic chips are fairly common so my idea was to implement it as a microcontroller, with an input and output port instead of a screen or keyboard. This way I could drive LEDs, displays, shift registers, or anything else a microcontroller can. Before I made any progress on my idea, I stumbled on a neat project that is similar, The BrainFuck Machine. It uses a UART chip for input and output. Running an HD44780 or LED matrix with my project using brainfuck code should be an extra challenge.

Not long ago another member at the hackerspace I go to was talking about 7400 series logic projects and spontaneously asked me if I had ever thought about making a brainfuck computer. We had come up with the same idea independently and decided to work together. He already had quite a lot of chips including RAM and UV-erasable EPROMs to work with. His UV lamp didn't work any more so I got a replacement bulb for just a few dollars from Bulb Town. That didn't work either so I had a look inside the lamp. The ballast appeared to be sealed with some kind of gasket to the body and there doesn't seem to be any way to get inside it without breaking that. A few other chips were plain old EEPROMs that work at 5v. With some shift registers and a transistor for level shifting, it was pretty easy to program and read them with an MSP430 on a breadboard. When I finish transferring that to perfboard, I will make a post on it.

My partner and I drew up a schematic that looked reasonable and he started on a wire-wrapped board for everything. Personally, I prefer to solder boards but it will be a good chance to see how wire-wrapping works. He also knows how to make printed circuit boards with the materials at the hackerspace. Over the winter break I haven't been at home with any hardware, so I started working on a simulated version of the project with the program Atanua. It is a 7400 chip simulator that was recently released for free. A year or so ago I was really interested in using it but gave up after all of the annoying pop-ups asking to pay. In principle I would not mind paying $5-10 for something like that if it had more features that in other programs are standard:
Click to enlarge
  • Cut, copy, and paste
  • Selection tool
  • Properties window for objects
  • Rotate for objects
  • Connection points for wires
  • Buttons with no letters
  • More 7400 chips
  • SRAM chips
  • Detailed screenshots
Despite the above annoyances, the simulation turned out alright in the end. To make things a little easier, I only implemented an 8 bit address space. The only RAM chip that can be simulated is a 74LS89, so the data stack is only 4 bits wide and 16 elements deep. At first I connected all the control signals for the chips to buttons so they could be manually operated. After I got that working, I started using EEPROM data to control the signals. The first version pushed the address of every [ onto a stack and jumped back to that at the corresponding ] if the current data wasn't 0. This only used a few chips and worked well but test code failed. It took me a while to realize that a loop like this that always executes at least once is equivalent to a do...while loop, not the plain while loop it is supposed to work like. The next version used a jump instruction that stores the jump address as the byte after the instruction. Getting the signal sequence right so that the jump address is not treated as an op code but is loaded into a buffer then transferred to the address buffer on the right cycle according to the data stack value was pretty tricky. Sometimes backwards jumps loaded half a cycle early, so I inserted a NOP after every forward jump. This wastes space and cycles but is acceptable for this small conceptual test. The jump sequencer could also take less cycles and some of the glue logic could be reduced, which I plan to do when we start on the full version.

In addition to the eight standard commands, it also supports # which many implementations use as a debug command to halt execution. The clock is run through a counter and XORed to produce two alternating clock signals. New EEPROM data appears on even cycles and is latched in as control signals on odd cycles so that the EEPROM output has time to settle before being latched. This probably doesn't matter in the simulation but seems like a necessary step on real hardware. Otherwise, I'm not sure how data appears on the bus and is latched in the same cycle. The control signals themselves use all 8 of the bits for convenience's sake, although they could be condensed. The data readout uses 74LS47 BCD converter chips connected to every three bits which gives an octal display.

To test the setup I wrote this short program which clears the first 6 bytes of the stack then sets the first four to 1, 2, 4, and 8 using multiplication. Then it outputs each byte in turn to the output buffer for a Larson scanner effect. The program comes to 249 bytes when run through the very simple assembler program I wrote, which is just shy of the 256 bytes available with an 8 bit address space.

[-]>
[-]>
[-]>
[-]>
[-]>
[-]
<<<<<
+
[
   [
      >++
      >+
      <<-
   ]
   >>
   [<<+>>-]
   <
]
<
[
   .<.<.<
   .>.>.>
]

Zero first six bytes





Return pointer to 0

Start counter at 1


Add two for every one of counter

Make a copy of counter
Subtract one from counter
Loop until counter==0
Point to copy of counter
Copy counter back to its place
New counter is next address
Loop until counter overflows to 0
Set pointer to last value

Output 8, 4, 2

Output 1, 2, 4
Loop forever

Sunday, December 28, 2014

Microcontroller Showdown, Revisited

Back in March I finished the microcontroller comparison of a few chips I was considering using. The 8051 based chips all fared poorly in BCD calculations, which is the main thing they would be used for in another calculator project. Some other 8051 fans pointed out that tests like mine test the compiler more than the chip and the SDCC compiler does a lot less optimizing than GCC. So, I decided to recode the BCD Add routine from the test in assembly. At the beginning I didn't consider this because I thought I would only ever write C for the 8051, but after writing assembly for the 6502, I was excited to try it for the 8051 too.

For this test I used the MCU 8051 IDE simulator. It is really impressive! Being able to see all the RAM and registers helped a lot. It is similar in some ways to what I hoped to accomplish with my 6502 Virtual Trainer. When I translated the original BCD Add function from C, I left out the parts used for subtraction, since they weren't used in the test. Also, some of the values that don't change inside loops are calculated once before the loop and stored for use later. This makes sense because a good C compiler would do this for you. All values are stored in the internal DATA, although this would be far too small for real calculations. The simulator can also work with SDCC, so I was able to simulate the function in C after commenting out the parts for subtraction.

The assembly took a simulated 440us to execute. The C version took between 1365 and 1732us depending on memory model and whether the BCD data was stored in DATA or XDATA. Curiously, storing it in XDATA was always faster. The medium memory model was faster than the large memory model. It seems then that hand-coding the routine in assembly is 3-4 times faster. To be fair, the routines for other architectures might also show a speed up if they were rewritten. Compared to the original numbers of the test, a 3x speedup would make the DS89C450 faster than the MSP430 for this routine. The difference might actually be a little bigger since this test used an upgraded version of SDCC that might optimize better. With that in mind, an 8051-based calculator with external bus (coded in assembly) would outperform an MSP430 with SPI SRAM. That is a bit of a surprise after the results of the first test.

The LPC1114 could also be sped up a little. In the original test the chip was configured to run at 50MHz. Because the flash runs at a maximum 20MHz, 3 wait states are required when executing from flash. However, 3 wait states is a little wasteful since 2.5 would be enough. Running the chip at 40MHz would only require 2 wait states, and would let the flash run at full speed. I'm not sure this would give a whole 16% speedup but I imagine it would offer a little bit of a boost.

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.

WM-1611-62C
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.