Druzyek

I've have several projects with a 5 pin header for the 6 pin FT232 cable since none of the projects use the 6th pin. One time I plugged the header into pins 2-6 of the FT232 cable instead of 1-5 and my launchpad died :S Also, took a while to get my first MCP23S17 I/O expander to work since the datasheet incorrectly lists the RESET pin as an output, not an input.

I've have several projects with a 5 pin header for the 6 pin FT232 cable since none of the projects use the 6th pin. One time I plugged the header into pins 2-6 of the FT232 cable instead of 1-5 and my launchpad died :S Also, took a while to get my first MCP23S17 I/O expander to work since the datasheet incorrectly lists the RESET pin as an output, not an input.

Porting my RPN Calculator code from MSP430 to LPC1114. Added keystroke programming and a Vfd screen.
 

@@abecedarian
 
I already did. I'm just porting it to this processor because it is faster and has enough internal RAM to buffer variables.
 
http://forum.43oh.com/topic/5003-rpn-scientific-calculator/
 

Porting my RPN Calculator code from MSP430 to LPC1114. Added keystroke programming and a Vfd screen.
 

Porting my RPN Calculator code from MSP430 to LPC1114. Added keystroke programming and a Vfd screen.
 

Porting my RPN Calculator code from MSP430 to LPC1114. Added keystroke programming and a Vfd screen.
 

Here is a project I started working on for our hackerspace's Halloween party but didn't finish in time. It is three 4x4 LED matrixes, one each for red, green, and blue. Each is driven by a shift register. The LEDs are from a string of Christmas tree lights. The control board has potentiometers for speed and color control.
 

 
Here is a video of some of the patterns:
http://youtu.be/yC3cBqeHkpk

Here is a project I started working on for our hackerspace's Halloween party but didn't finish in time. It is three 4x4 LED matrixes, one each for red, green, and blue. Each is driven by a shift register. The LEDs are from a string of Christmas tree lights. The control board has potentiometers for speed and color control.
 

 
Here is a video of some of the patterns:
http://youtu.be/yC3cBqeHkpk

@@username 229 puffs of magic smoke?

Use them as IO expanders for your MSP430 projects.

I think most people misunderstand the philosophy behind the propeller. They left out all of the timers and interrupts on purpose and you have 8 cores so you can do the same as you could with 1 core and loads of peripherals. The difference is you now have room for 7 custom peripherals and 1 main core.
 
I'm not sure why you would want 8 cores running simultaneously anyway. Efficiently using even 2 cores for 1 task is a non-trivial problem. Other microcontrollers handle multiple tasks with 1 core. Why not give each task its own core and eliminate other problems like interrupt latency while you're at it?

I've been curious about 6502s lately (I was too young when the craze hit) and I have been working on this:

The MSP430 communicates with a program over UART, driving the 6502 data lines and using IO expanders to drive the address lines. I started out with RAM and ROM stored on the PC and fetching data every cycle over UART but this maxes out at about 90hz. Now everything is stored on a 128k SPI SRAM and the MSP430 syncs that memory with the memory on the PC every 200ms. I can get about 12,000hz this way (0.012MHz) Keeping all the data on the PC lets me view memory, set breakpoints, single-step, etc. It also keeps track of what memory is uninitialized, read-only, and executable so that it can break on improper memory access.

All the peripherals like buttons, switches, screens, LEDs, etc are virtual and can be mapped to any memory location.

It's way too slow to be a functional computer but it works well enough for learning about 6502 hardware and assembly.

I've been curious about 6502s lately (I was too young when the craze hit) and I have been working on this:

The MSP430 communicates with a program over UART, driving the 6502 data lines and using IO expanders to drive the address lines. I started out with RAM and ROM stored on the PC and fetching data every cycle over UART but this maxes out at about 90hz. Now everything is stored on a 128k SPI SRAM and the MSP430 syncs that memory with the memory on the PC every 200ms. I can get about 12,000hz this way (0.012MHz) Keeping all the data on the PC lets me view memory, set breakpoints, single-step, etc. It also keeps track of what memory is uninitialized, read-only, and executable so that it can break on improper memory access.

All the peripherals like buttons, switches, screens, LEDs, etc are virtual and can be mapped to any memory location.

It's way too slow to be a functional computer but it works well enough for learning about 6502 hardware and assembly.

I've been curious about 6502s lately (I was too young when the craze hit) and I have been working on this:

The MSP430 communicates with a program over UART, driving the 6502 data lines and using IO expanders to drive the address lines. I started out with RAM and ROM stored on the PC and fetching data every cycle over UART but this maxes out at about 90hz. Now everything is stored on a 128k SPI SRAM and the MSP430 syncs that memory with the memory on the PC every 200ms. I can get about 12,000hz this way (0.012MHz) Keeping all the data on the PC lets me view memory, set breakpoints, single-step, etc. It also keeps track of what memory is uninitialized, read-only, and executable so that it can break on improper memory access.

All the peripherals like buttons, switches, screens, LEDs, etc are virtual and can be mapped to any memory location.

It's way too slow to be a functional computer but it works well enough for learning about 6502 hardware and assembly.

I've been curious about 6502s lately (I was too young when the craze hit) and I have been working on this:

The MSP430 communicates with a program over UART, driving the 6502 data lines and using IO expanders to drive the address lines. I started out with RAM and ROM stored on the PC and fetching data every cycle over UART but this maxes out at about 90hz. Now everything is stored on a 128k SPI SRAM and the MSP430 syncs that memory with the memory on the PC every 200ms. I can get about 12,000hz this way (0.012MHz) Keeping all the data on the PC lets me view memory, set breakpoints, single-step, etc. It also keeps track of what memory is uninitialized, read-only, and executable so that it can break on improper memory access.

All the peripherals like buttons, switches, screens, LEDs, etc are virtual and can be mapped to any memory location.

It's way too slow to be a functional computer but it works well enough for learning about 6502 hardware and assembly.

I've been curious about 6502s lately (I was too young when the craze hit) and I have been working on this:

The MSP430 communicates with a program over UART, driving the 6502 data lines and using IO expanders to drive the address lines. I started out with RAM and ROM stored on the PC and fetching data every cycle over UART but this maxes out at about 90hz. Now everything is stored on a 128k SPI SRAM and the MSP430 syncs that memory with the memory on the PC every 200ms. I can get about 12,000hz this way (0.012MHz) Keeping all the data on the PC lets me view memory, set breakpoints, single-step, etc. It also keeps track of what memory is uninitialized, read-only, and executable so that it can break on improper memory access.

All the peripherals like buttons, switches, screens, LEDs, etc are virtual and can be mapped to any memory location.

It's way too slow to be a functional computer but it works well enough for learning about 6502 hardware and assembly.

I've been curious about 6502s lately (I was too young when the craze hit) and I have been working on this:

The MSP430 communicates with a program over UART, driving the 6502 data lines and using IO expanders to drive the address lines. I started out with RAM and ROM stored on the PC and fetching data every cycle over UART but this maxes out at about 90hz. Now everything is stored on a 128k SPI SRAM and the MSP430 syncs that memory with the memory on the PC every 200ms. I can get about 12,000hz this way (0.012MHz) Keeping all the data on the PC lets me view memory, set breakpoints, single-step, etc. It also keeps track of what memory is uninitialized, read-only, and executable so that it can break on improper memory access.

All the peripherals like buttons, switches, screens, LEDs, etc are virtual and can be mapped to any memory location.

It's way too slow to be a functional computer but it works well enough for learning about 6502 hardware and assembly.

Wow! This is really cool! Doesn't touching the metal on the back every short anything?

Bump.
 
Finally moved the emulator to a single PCB design (after one failed PCB design). Now my kids can take them and use them in school.
 
Source code can be found at https://github.com/simpleavr/tms0800.
 
Source code based on Ken Shirriff and other's work, please see http://righto.com/ti and http://righto.com/sinclair
 

 
A few photos...
 

 
PCB design available upon request.
 
 

This is my new universal graphics library (original one is here.)
 
Supported boards (this is out of the "box" support, but the library will work with any board after small changes.)
 
TI's MSP430FR5969 LaunchPad (ugl16msp only for now)
TI's MSP430F5529 LaunchPad
TI's MSP430G2 LaunchPad with G2553 chip
RobG's MSP430G2955 Dev Board
RobG's MSP430F5172 Dev Board
RobG's MSP430F5510 Dev Board
 
Supported displays
 
1.8" ST7735 based JD-T1800 - ugl8
2.2" HX8340 based displays - ugl8
2.2" ILI9225 based displays (touch panel) - ugl8
2.2" ILI9341 based displays 320x240 pixels - ugl16
 
Tiva versions are right here
 

 

 
 
ugl8msp.zip (name change 4/18/14)
ugl16msp.zip (updated 4/19/14)

@@chicken, your boards look nice. I saw your pictures of them on the other post. Cool!
 
No pictures yet but I usually get samples sent to another address and everything from the last 6 months was sent to me last month. I got an XMOS board, an STM32 board, and one of the 128x32 displays from Noritake. I also sampled a beefy STM32F407 chip while I was at it.
 
The "What are you working on" thread is a good idea. I have been playing with some single-cycle 8051s but they are even slower than value line MSP430s, so nothing much to report.

dAISy USB is alive!
 
Before reflow - can you spot the DOH! moment I had shortly after reflow?

 
And flashing LED after programming via F5529 LaunchPad

 
Pretty jazzed that it worked at first try!
Next up, migrating the dAISy project to the MSP430F5508. Already have it working on the MSP430F5529.

Overview
This is a scientific calculator I built that uses RPN notation. Features:
BCD number format with 1-255 places Internal accuracy configurable from 6 to 32 decimal places Two separate 200 level stacks Optional scientific notation Functions: (a)sin, (a)cos, (a)tan, y^x, x root y, e^x, ln, 10^x, log, mod 20x4 character LCD 42 buttons The source code is available on https://github.com/druzyek/RPN_Calculator.
 

 
Software
The interface shows 4 levels of the stack, similar to some HP calculators. While I was writing the code for BCD calculations, I used a console program to test the routines. You can download it from GitHub if you want to test out the functionality: rpnmain_pc.c It will compile for Windows if #WINDOWS is defined or for Linux with the ncurses library if #LINUX is defined.
On Windows: gcc -o rpncalc.exe rpnmain_pc.c On Linux: gcc -lncurses -o rpncalc rpnmain_pc.c Numbers are stored in unpacked BCD format on an external SRAM chip. I wanted to access this memory using variables but there is no convenient way to do this since every variable requires a function to access it. A simple functions like:
X+=Y*Z-Q; would become something like this (assuming we are passing pointers):
RAM_Write(X,RAM_Read(X)+(RAM_Read(Y)*RAM_Read(Z)-RAM_Read(Q)); To simplify things, I wrote a preprocessor program that looks for any variables that need to be stored in external RAM and converts access to them to function calls. External variables are all stored as pointers, so the PC version will work exactly the same with or without the preprocessor. To mark variables as external, #pragma directives are used. These are usually ignored by the compiler if they are not recognized, so they are a convenient way to communicate with the preprocessor. Here is an example:
//Before processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;msg[i];i++) putchar(msg[i]); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char text1[30]; unsigned char text2[30]; #pragma MM_END text1[0]='A'; text1[1]=0; puts(text1); } //After processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;RAM_Read(msg+i);i++) putchar(RAM_Read(msg+i)); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char *text1=(unsigned char*)200; unsigned char *text2=(unsigned char*)230; #pragma MM_END RAM_Write(text1+0,'A'); RAM_Write(text1+1,0); puts(text1); } The trig and log functions are computed using CORDIC routines. This is a very efficient way to compute these functions for processors that cannot multiply or divide quickly. Instead, a lookup table is used with adds and shifts, which are much faster. I was able to speed the shifting up even more by using another lookup table that let me right shift 4 digits at a time. One way to measure the accuracy of calculations is with the calculator forensic found here: http://www.rskey.org/~mwsebastian/miscprj/forensics.htm. After setting accuracy to 24 places arcsin(arccos(arctan(tan(cos(sin(9)))))) evaluates to this:

 
The settings page allows the accuracy to be set from 6 to 32 decimal places. With the default of 12, trig functions calculate in about a second. With 32 decimal places calculations take 3-4 seconds. After setting the accuracy, the program finds the largest element in the CORDIC table that is still significant, so that no time is wasted on elements that have no effect on the answer. The settings page also shows the current battery charge.

 
When I began this project I wasn't sure how much I could fit into 16kB of firmware space. In the end it grew bigger than this and I had to use two MSP430s to hold everything. Part of this is due to all of the functions used to access external memory. The interface code also added a lot more to the size than I expected but I was able to add checks for most of the functions and add some meaningful error messages.

 
Hardware
My design uses two MSP430G2553s connected over UART. One of them (the master) reads the keyboard matrix, updates the LCD, and manages the interface. The other is connected to the data lines of 128k of parallel SRAM and does all of the calculating. The address lines of the SRAM are driven by two 74HC595 shift registers controlled by the second MSP430. The 17th address pin is controlled by the first MSP430 and allows the program to switch between two separate stacks. Here is the schematic: 

 
The keypad is formed from 42 tactile buttons arranged in a 6x7 matrix and read with a 74HC165 shift register by the master MSP430. The LCD and keyboard share the same pins since they are never used at the same time. Here is the layout of the keys.

 
The LCD is an HD44780 compatible 20x4 character LCD. It is rated for 5v but the logic works fine at 3.6v. The contrast needs to be close to 5v for anything to show up on the screen, so I used a 555 timer and some diodes to supply around -1.2v to the contrast pin. The result is very solid and clear.
 
The calculator runs on four AA batteries regulated by an LM1117 configured to supply around 3.5 volts. To run at 16MHz the MSP430s need at least 3.3 volts. The wiggle room between the two voltages will let me see when the batteries are starting to wear down. By the time the voltage gets down to 3.3v, the batteries will be down to 1.15v or so, which can be considered dead.
 
The PCB is made from perfboard. The top of the board contains female headers so that the keyboard and LCD can be unplugged. Part of the board had to be cut away so that it will fit in the case with the batteries. Although it is quite small, I ended up using over three meters of wire.

 
The case is soldered out of copper clad. I used a lot of solder on it and it feels very sturdy. I will give it a coat of paint tomorrow before assembling everything.

Overview
This is a scientific calculator I built that uses RPN notation. Features:
BCD number format with 1-255 places Internal accuracy configurable from 6 to 32 decimal places Two separate 200 level stacks Optional scientific notation Functions: (a)sin, (a)cos, (a)tan, y^x, x root y, e^x, ln, 10^x, log, mod 20x4 character LCD 42 buttons The source code is available on https://github.com/druzyek/RPN_Calculator.
 

 
Software
The interface shows 4 levels of the stack, similar to some HP calculators. While I was writing the code for BCD calculations, I used a console program to test the routines. You can download it from GitHub if you want to test out the functionality: rpnmain_pc.c It will compile for Windows if #WINDOWS is defined or for Linux with the ncurses library if #LINUX is defined.
On Windows: gcc -o rpncalc.exe rpnmain_pc.c On Linux: gcc -lncurses -o rpncalc rpnmain_pc.c Numbers are stored in unpacked BCD format on an external SRAM chip. I wanted to access this memory using variables but there is no convenient way to do this since every variable requires a function to access it. A simple functions like:
X+=Y*Z-Q; would become something like this (assuming we are passing pointers):
RAM_Write(X,RAM_Read(X)+(RAM_Read(Y)*RAM_Read(Z)-RAM_Read(Q)); To simplify things, I wrote a preprocessor program that looks for any variables that need to be stored in external RAM and converts access to them to function calls. External variables are all stored as pointers, so the PC version will work exactly the same with or without the preprocessor. To mark variables as external, #pragma directives are used. These are usually ignored by the compiler if they are not recognized, so they are a convenient way to communicate with the preprocessor. Here is an example:
//Before processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;msg[i];i++) putchar(msg[i]); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char text1[30]; unsigned char text2[30]; #pragma MM_END text1[0]='A'; text1[1]=0; puts(text1); } //After processing void puts(unsigned char *msg) { #pragma MM_VAR msg for (int i=0;RAM_Read(msg+i);i++) putchar(RAM_Read(msg+i)); } int main() { #pragma MM_OFFSET 200 #pragma MM_DECLARE unsigned char *text1=(unsigned char*)200; unsigned char *text2=(unsigned char*)230; #pragma MM_END RAM_Write(text1+0,'A'); RAM_Write(text1+1,0); puts(text1); } The trig and log functions are computed using CORDIC routines. This is a very efficient way to compute these functions for processors that cannot multiply or divide quickly. Instead, a lookup table is used with adds and shifts, which are much faster. I was able to speed the shifting up even more by using another lookup table that let me right shift 4 digits at a time. One way to measure the accuracy of calculations is with the calculator forensic found here: http://www.rskey.org/~mwsebastian/miscprj/forensics.htm. After setting accuracy to 24 places arcsin(arccos(arctan(tan(cos(sin(9)))))) evaluates to this:

 
The settings page allows the accuracy to be set from 6 to 32 decimal places. With the default of 12, trig functions calculate in about a second. With 32 decimal places calculations take 3-4 seconds. After setting the accuracy, the program finds the largest element in the CORDIC table that is still significant, so that no time is wasted on elements that have no effect on the answer. The settings page also shows the current battery charge.

 
When I began this project I wasn't sure how much I could fit into 16kB of firmware space. In the end it grew bigger than this and I had to use two MSP430s to hold everything. Part of this is due to all of the functions used to access external memory. The interface code also added a lot more to the size than I expected but I was able to add checks for most of the functions and add some meaningful error messages.

 
Hardware
My design uses two MSP430G2553s connected over UART. One of them (the master) reads the keyboard matrix, updates the LCD, and manages the interface. The other is connected to the data lines of 128k of parallel SRAM and does all of the calculating. The address lines of the SRAM are driven by two 74HC595 shift registers controlled by the second MSP430. The 17th address pin is controlled by the first MSP430 and allows the program to switch between two separate stacks. Here is the schematic: 

 
The keypad is formed from 42 tactile buttons arranged in a 6x7 matrix and read with a 74HC165 shift register by the master MSP430. The LCD and keyboard share the same pins since they are never used at the same time. Here is the layout of the keys.

 
The LCD is an HD44780 compatible 20x4 character LCD. It is rated for 5v but the logic works fine at 3.6v. The contrast needs to be close to 5v for anything to show up on the screen, so I used a 555 timer and some diodes to supply around -1.2v to the contrast pin. The result is very solid and clear.
 
The calculator runs on four AA batteries regulated by an LM1117 configured to supply around 3.5 volts. To run at 16MHz the MSP430s need at least 3.3 volts. The wiggle room between the two voltages will let me see when the batteries are starting to wear down. By the time the voltage gets down to 3.3v, the batteries will be down to 1.15v or so, which can be considered dead.
 
The PCB is made from perfboard. The top of the board contains female headers so that the keyboard and LCD can be unplugged. Part of the board had to be cut away so that it will fit in the case with the batteries. Although it is quite small, I ended up using over three meters of wire.

 
The case is soldered out of copper clad. I used a lot of solder on it and it feels very sturdy. I will give it a coat of paint tomorrow before assembling everything.