i think i just quashed the last bug in my 'convert ****ty gamepad to wireless' project. spent several hours trying to figure out why the receiver wasn't picking up any data. what it came down to is the wireless module was loose in its socket and needed to have its pins bent so it fits in a little more snugly. once i figured that out i noticed my terminal window started displaying actual data packets instead of the random noise it was picking up earlier. the problem isnt totally solved though, but i figure all i got to do is plate the contacts with solder to make them fill that ***** up. worst case scenario i can just solder the ****ing transmiter directly to the mcu.
i had to use the dead bug mentality to get an mcu board small enough to fit in the game pad. to that end i ditched the board. i had a nice piece of strip board and i didnt want to cut it up. so i took a 28 pin mcu socket. soldered a crystal, caps, a pull up resistor for the reset pin, pulldowns for the matrix input. i ran out of 1/8th watt 10k resisters, so i had to use some ****ing huge 1 watt ones instead. i also put in a 6 pin icsp header. why the **** i never put these into my previous projects is beyond me. sure beats prying microcontrollers out of sockets and breaking pins in the process. i was also amazed at how much faster my $6 usb avr programmer is over that usb serial bridge. i wanted to put a low pass filter on the analog reference, but the datasheet said it would require an inductor that i didnt have. so i guess it will pick up noise from the regulator.
last part of the project i will do tomorrow, and that is to shorten the wires i use for testing and solder them to the socket directly instead of through the bread board ive been using for debugging. one more thing to do is to figure how much power it draws and build an appropriate supply. performance isnt bad, i stepped up the resolution from 8 to 10 bits, and i get a theoretical 100 refreshes a second, but with overhead its a little less than that. definately need to tune the debounce code, right now its a bit bouncey, probibly because the delay between samples is too short. i had it set up where the buttons required 3 refresh cycles to figure out the button state but that made it unresponsive but with very good debounce. now its responsive as **** with a high likelihood of bounce. somewhere in the middle is probibly desirable. if the chip has a spare timer i could use that to sample the buttons at a far more regular rate. tweaking the delay is probibly the best bet, but make it too high and you dont get enough updates a second out of it.
