Make sense of the core read loop #10
Description
At this time, the core of the program is based on a function I don't understand for a device that baffles me. It appears to be completely reliable and consistent, but that's not really good enough.
The FT232 has several operating modes, but at its core it is a serial UART. Because of that, and because of the characteristics of USB, the manufacturer chose to make it operate primarily as a buffered device. You don't ask "what is the state of the pins," you ask "what are the contents of the buffer" and receive a stream of bytes.
This would make sense to me if those bytes represented some kind of time series - a stream of samples of the input, which I could use to tell if the button had been pressed multiple times (or bounced) since the last sample, but that's not how it seems to be behaving.
Depending on the size of my input buffer and polling rate, every buffer I receive contains some arbitrary number of valid reads of the pin state (e.g. 646464646464646464) and then some number of invalid reads (so the whole thing looks like 646464646464646400000000000000000000). I haven't the faintest idea what's causing this.
At first I was unable to get the prototype to work at all because of this. I would get nothing but 0s, or I'd get oscillating valid and invalid data so my button would appear to "bounce" on every read. Eventually I found the magic numbers (baud rate, buffer size and polling frequency) that make it return buffers that are consistently correct in at least the first byte - this is all I need, so I'm proceeding with development as if all is well
It seems to work, but it still bothers me for two reasons. First, I just don't think I'm using it right. Maybe there's a hidden failure mode. Maybe I'll get garbage under high system load, or when sharing the USB with more things. Second, I think my latency could be better.
This device can operate at a minimum of 9600 baud. I haven't done the math but I'm pretty sure if I was using this for controlling a game I could get phenomenally low latency, opening the door for using this to build extremely cheap fightsticks and so on if I were to plug in XInput. Call me overzealous if you want, but I'm pretty sure it's within the realm of reason. So I'd like to see that capability realized.
The FT232 has a dizzying amount of functionality and I'm far from understanding it all. Some things that seem promising:
- It seems like the "MPSSE" mode might not be the one I'm operating in right now, and it may offer a simple bitbang interface
- There is something called CBUS mode, I think? I can't find the document again right now, but it offers a "get the current pin state, right now" API instead of a "read in the buffer" API. This seems to be intended for GPIO use and may offer better speeds.
All of this is low-priority. The intent of the application first and foremost is to "insert coins" and I need to have that ironed completely out before I bother with any of this. It's "good enough"