About a month ago I started learning assembly programming for the z80 processor in the TI-83 plus and TI-84. One of the things that I had in mind to do with the new skill I was acquiring was giving the calculator the capability to communicate over its link port using Universal Asynchronous Transmit Receive (UART) protocol, which is used by many of the devices, modules, and integrated circuits that I use in my projects. Giving my calculator that ability would allow it use data from bluetooth, gps, SD card, and many other modules.
The project is complicated by two factors. The first is that the z80 processor doesn't really work well with UART in the state it is in inside the calculator, because I can't use interrupts to handle incoming data. This means that to receive data the calculator has to go into a very tight loop until data starts coming in, which can be a serious limitation. The second complication is the fact that the calculator executes less clock cycles per second as the batteries becomes weaker, which means that the timing has to be dynamic or it will become inaccurate as the batteries die.
To Do
Get low-level control of the linkport.
Hard code an on-off sequence to send a byte.
Figure out the required timing for receiving data at any baudrate.
Figure out the required timing for receiving data at any baudrate.
Write a routine to allow dynamic timing correction.
Write a routine that can send any byte.
Write a routine that can receive any byte.
Write an assembly program to allow UART through BASIC.
Figure out a way to allow interrupt-based UART.
Timeline
2/21/10 (10:56 AM)-I found a TI 2/21/10 (11:05 AM)-Having trouble running Telnet83 on my TI 2/21/10 (11:13 AM)-Gave up on Telnet83. All shells are incompatible with the program. Either I am going to look at the code and try to port it or I'll go look for another example.
2/21/10 (11:19 AM)-I found a version of Telnet83 for the TI 2/21/10 (1:23 PM)-I have completely given up on Telnet84. It does not to appear to use actual UART, and does not operate at 9600bps using that protocol. If I had a graphlink cable it might work, but I don't want the extra hardware to be in the final design anyway. I am going back to my original code to see if I can get the timing right.
2/21/10 (3:28 PM)-HUGE SUCCESS! The calculator is communicating at a stable 9600bps. I figured out the timing issues so it is now using just the right number of clock cycles per bit. Currently it is hardcoded to send decimal 85 over the port, but it shouldn't be too hard to add a byte send routine now.
2/22/10 (8:31 AM)-I DID IT! I now have an assembly routine that can send any value between 0 and 255 over the linkport using UART. Next I will hook it up to an Arduino and see what fun can be had.
2/22/10 (9:00 AM)-Communication with the Arduino is working fine. Calculator can turn on and off an LED connected to the Arduino by sending a specific byte over the serial port. Next I will try adding some more interesting communication routines and try to make the code and ui cleaner.
3/7/10 (9:00 AM)-Starting work on a serial debugger program for the calculator to help shed some light on the problems with the byte receive routine I am writing. The debugger will draw a short section of the signal plot to the screen after being triggered by the serial line going low (indicating message about to be received). The first thing I need to do though is figure out how to plot pixels in assembly 3/7/10 (9:24 AM)-Created a small program based on "TI ASm in 28 Days" routines that draws pixels to the screen. Now I can move onto adding the ability to store port values to memory to be drawn later.
3/7/10 (8:05 PM)-Serial debug program can now wait for the rx line to go low, record a series of samples, and then plot those samples on the screen. I've sent data to the calculator and recorded it successfully with the program, but the samples are strange. They are consistent, so it probably isn't a serious timing issue, but they don't really match the expected data. I'll make a table of the expected and received signals to try to sort it out.
3/8/10 (8:55 PM)-I fixed a couple timing issues with the serial debugger program. THe strange signal plots are gone, I am seeing accurate representation of the signals that should be received. Now all that is left is to take the timing from the plots and use it to fix the original receive routine.
3/8/10 (9:06 PM)-BYTE RECEIVE ROUTINE WORKS! THe calculator is receiving bytes sent to it at 9600bps, standard UART! Now I just have to clean up the code and I am done everything I need for perfect calculator serial communication with the plethora of devices that use UART. I've already got an idea for how to make the program work on rates other than 9600bps. I think the calculator is capable of much faster rates.
3/8/10 (9:26 PM)-I finished a small program using the working UART code that allows me to draw a picture on a paint program (written with Processing) on the computer and have it appear in real time on the calculator. It works OK but often pixels show up in the wrong places. This appears to be a slight inaccuracy in the timing that I think can be easily fixed.
4/4/10 (7:05 PM)-Put the code up. I cleaned it and commented it and added extra love. Hope it helps some people make some cool things.