why would i want a job? it amuses me to waste my talent on useless activities while simultaneously giving the finger to those capitalist whores who i will one day impale and then nuke. it will be a joyous day indeed.
i sort of finished the game pad. sort of meaning that i had intended to have an internal battery with an external charge header. however the battery pack i was going to use stopped working and will no longer take a charge, and i have no other cells on hand small enough to fit into this thing. so i just put in the voltage regulator board i made and ran the wires to the outside, where a battery pack (home made fo course with batteries from a dead laptop and no safety hardware at all) is suspended beneath the unit by velcro. the unit seems to only be drawing 300ma, if i read the meter correctly so this monster pack should last awhile.
it works but i think i may need to optimize my software some more. i setup my arduino to parrot anything that came in on the serial line and re-transmit it. communication is one way, so it doesnt matter that im using the same uart to go to and from two different devices. problem here is im getting considerable lag between when i hit a button and when something moves on the computer. i think this is happening because somewhere data is sitting in a fifo buffer and the is piling up, filling up the buffer faster than it can be emptied. data rate is only 4800 bps so a 256 byte buffer will take 420 ms to cycle every bit of data out of it.
i dont think the problem is in the ppjoy proggie i wrote to capture the serial data and post it to the virtual driver, since i explicitly set its buffer to 18 bytes (enough to hold 2 whole frames). though playing with the buffer size seems to have odd results. like drooping it below 13 bytes never returns a valid frame, setting it at 13 fails half the time but is the most responsive (of course thats 33 refreshes a second instead of 66). you can set it to 15 and it will only be bad once every dozen or so frames. but 18 seems to be the best one because it is never wrong it seems.
i may also be filling up the buffer too fast at the mcu in the game pad and its sitting in the buffer. i may just need to waste more cycles, i could add a delay at the end of each frame transmission, but id hate to stick a delay in there and waste time when i can use the time for more constructive tasks, for example take more button samples for the debouncer or wait longer between samples. thats changing a couple defines, which is easier than opening and closing the case again to get to the programming header. the arduino in the middle could be to blame as well, but it doesnt do much at all. figure out how big the recieve buffer is and take steps to decrease it.
the final thing that could be the issue is the operating system is not processing the data with any priority at all. even with the proggie at highest priority (its only a few k and doesnt use too much time) its still laggy, and im not sure changing the process priority does anything for it. its likely the roundabout way im getting the data into the computer. its not going through its own driver and the send rate doesnt go up at all. ditch the arduino for a usb capable mcu (or run a software usb stack) and go through the hid class. for now im going to ditch the man in the middle and try to control something else, like my r/c receiver board. gotta re-write its firmware to accept the new frame format though, and thats a project in of itself.
