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:



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?


EDIT:
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:
Code:


On the microcontroller, we would see this:
Code:


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?

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
https://github.com/dnmalenke/ESPCalc-Public/blob/main/Calc/esp.asm

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: https://www.youtube.com/watch?v=DXvJ8duZqdA