My interest in electronics started because I would like to build calculators like the ones I used to collect. Now I plan to build a scientific RPN calculator. A three inch graphical LCD would work well for this but most cell phone screens I can easily find are a little bit too small. For the time being I will continue using the 16x2 LCD I found.
For this project I intend to use an MSP430. The challenge of this will be that the MSP430G2553s I have only have 512 bytes of RAM. To begin with I decided to start on the programming since this will probably be much more work than the hardware. Although I want this calculator to use RPN, it would also be good if it could evaluate algebraically as well like the HP-49G. It will hopefully also be useful to have a small parser that works on a microcontroller for some other projects I want to do. Here is the parser running on my LaunchPad and evaluating the equation 13*(4+25*13)/((67-33)*2^3):
For this project I intend to use an MSP430. The challenge of this will be that the MSP430G2553s I have only have 512 bytes of RAM. To begin with I decided to start on the programming since this will probably be much more work than the hardware. Although I want this calculator to use RPN, it would also be good if it could evaluate algebraically as well like the HP-49G. It will hopefully also be useful to have a small parser that works on a microcontroller for some other projects I want to do. Here is the parser running on my LaunchPad and evaluating the equation 13*(4+25*13)/((67-33)*2^3):
At first I wanted to use recursion because this can really simplify parsing but that's not really an option since it would use a lot of stack space. Instead, it evaluates any expressions it can and stores the result in memory then writes a pointer to that memory in the place where the expression was. Doing it like this instead of tokenizing the whole string before evaluating saves memory. The results of operations are stored starting at the end of the string that holds the expression so that as the expression is evaluated and becomes smaller, memory is freed which can be used to store more results. So far this parser fits in about 2k of Flash.
The second part I worked on is a Binary Coded Decimal format. This will be more accurate than floating point since it will be able to store any number that will fit in available memory. Each byte of data contains two numbers from 0 to 9. Now numbers are limited to 512 digits in length but this can easily be increased, although it probably wouldn't be useful on such a small screen. I have code for adding and subtracting, so multiplication and division should be easy to implement using these. I was able to fit this into less than 2k of Flash so with the parser I should still have about 12k of flash for other functions. Here is an example using numbers small enough to fit on the screen:
No comments:
Post a Comment