So, I am attempting to expose some user-read/writable GPIOs on the CE's PCB, and came across this snippet while scrolling through the hardware docs on the wiki:

F50030-F5003F (R/W): Keypad GPIOs. Each register is 20 bits, with one bit per GPIO. The role of each register is unknown.

Does is there exist any more documentation on those GPIO registers, and if they are mapped to the keypad itself?

My first thought was to use the testing mode LED, but since that is locked down and not memory mapped, it wouldn't be a viable option.

My next thought was to hi-jack an existing bus on the PCB, maybe i2c if it exists.

Outside of the USB port, are there any examples of I/O that are exposed on the CE's PCB, either as test points or even as pins on IC packages, that can be driven high/low at will?

The keypad matrix can be abused to "write" data to the calculator, by using the unused areas of the keypad matrix, pressing "invisible" keys. But getting data off of the calculator can't (easily) be done the other way.
Dmalenke recently found that bits 3 and 4 of port 0009 are connected to test points TP06A and TP09A, at least on hardware revision C - the test point numbers might be different on newer revisions, or they might not exist anymore. Unfortunately, that port requires privileged access to write to.
On newer revisions, you might be able to remove the Python coprocessor and use its SPI or UART connection to communicate with the main processor. I don't think there is much documentation on this, though.
Interesting about TP06A and TP09A. I'd love to find something that is revision-agnostic.

It occurs to me that you can set the number of rows of the keypad to scan. Perhaps by changing this value, you can detect a lack of scanning on certain rows using external hardware.

For example, by varying between 6 and 7 rows scanned, and connecting rows 6, 7, and 8 to an external microcontroller, the external mcu could have interrupts fired on rising edges of rows 6, 7, and 8. Doing single scans of the matrix would form a sort of gray code /wrt which was the most recent interrupt firing.

Calculator side:
Disable continuous scanning
Rows to scan = 7
Single scan
Rows to scan = 6
Single scan
Single scan
Rows to scan = 8
Resume continuous scanning

On the microcontroller, we would see this:

//Interrupts on pins 6, 7 and 8 notated as I6, I7, I8
I6 fires |
I7 fires |-- happens when all 8 lines are scanned
I8 fires |

I6 fires |
I7 fires |-- happens when 7 lines are scanned

I6 fires |-- happens when 6 lines are scanned
I6 fires |-- twice

I6 fires |
I7 fires |-- happens when all 8 lines are scanned
I8 fires |

Some more though may go into this, but I'm fairly sure that this could be a way to get "data" off of the calculator.
Random question: can we use the SPI interface that the Python coprocessor uses on non-Python CEs? Unprivileged-ly?
KermMartian wrote:
Random question: can we use the SPI interface that the Python coprocessor uses on non-Python CEs? Unprivileged-ly?

Yes, it's mapped to 0xF80000. It's also present on older hardware revisions (to communicate with the LCD controller), but read-only for some reason?
Here are some things that I've found ( From testing with bit 0 of GPIO B ):
GPIO Direction seems like it could be controlling pull up/down resistors on the gpio. SET = Pull up enabled, RESET = Pull down enabled.

It seems like no mode switching is required to switch the "direction" of the gpio. in0 can read the level at any time, and out0 can set it.

As requested, this is a little more than sending HELLO WORLD over gpio, but that code is long gone.
Here is the code that's running on my calculator to hook into the parser and bit-bang the entered equation over GPIO B bit 0, then wait for a packet to come back and display it. I'm sure it can be improved, but it's fine Smile

Edit: I guess I should mention, my rev C calculator and algorithm can bit-bang uart out at a baud rate of 515464 and receive it at a baud rate of 393701. Results may vary though. I noticed in early testing when I wasn't running code from within the parser hook, it seemed to be able to run faster ( closer to 812500 sending baud ) with a worse algorithm. If anyone has ideas for why that is, let me know, I'm curious
My "NOT FOR SALE" teal TI-84 Plus CE (revision M) does not have TP06 and TP09, but does have TP07 and TP08 at the left of the ASIC (see mr womp womp's original PCB image). I tried attaching probe wires to these two, but I haven't yet found a port that reads differently when I leave them floating vs. shorting to ground (blue). I notice that they appear to idle on my multimeter between 0V and 2.9V with a USB cable plugged in, and both stay in the vicinity of 2.9V with the USB cable removed. However, shorting either to ground does not prevent USB connectivity, so they're not the USB lines. Reading F80000 and F90000 with Memory Editor doesn't show any changes for floating vs. grounded. Any suggestions?

Is it likely that those TP07 and TP08 are not memory mapped, and the ports are privileged? That seems to be the case with 06 and 09, having to be written/read with out/in
I'd be grateful if someone could provide a good-quality picture of the front/keypad side of a revision M PCB (Python-populated or not, doesn't matter).
Not sure if relevant but Ben Heck messes with UART on python model calcs:
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum