Software Support > Automated Projects

12 position rotary switch > 2 keyboard encoder inputs, simple hardware solution?

<< < (2/5) > >>

melvinbates:

--- Quote from: BadMouth on January 20, 2017, 09:57:36 am ---Would using the Attiny45 get rid of the need for a custom PCB like the older microcontroller I linked to above?
I guess what I'm asking is are premade dev boards available for it that would work?

--- End quote ---

Yes and no, essentially it would be performing the same function as the attiny2313 that they used on that board, except that it wouldn't have a board and only be for one joystick so you would have to either use piece of a prototype board or attach the wires directly to the chip or a socket.  Though it also wouldn't be difficult to get a small board printed by oshpark.  The programming of the chip would be done with a standard zif socket programmer.  The advantage of it over a solution like you posted above is the cost per piece, an Artiny45 will set you back $1.25 or less plus a few cents for the cap.  It does require more external hardware to program it, but even that is pretty cheap $2- $5 on ebay. ex http://www.ebay.com/sch/?_nkw=avr%20usbasp.  If it was desired, it would be easy to create a entry at say OSHPark where you could print off 3 circuit boards for about $5.  So it could be as simple as hooking it up dead bug style with wires directly to the chip or print a professional board for less than $10 for 3.

TLDR: it's a chip with a filter cap and you could attach it to the wires in any number of different ways from printing a board to direct.

It just looked like it would be a fun quick project.  I don't get to play around with my electronics as much as I would like to and when I get a chance I don't know what to make...

BadMouth:
It sounds like a good solution for how I want things to work. 
Lets do it! (or rather you do it and then I'll buy the parts and enjoy the results of your work...)
I'll try to make more time to get the 3D printed parts closer to a final product.

  :cheers:

melvinbates:
Sounds good.  I'll get started experimenting.  At this point the outstanding unknown for me is how long to hold the left/right signal once the switch is turned.  I'll keep you posted on progress.

PL1:

--- Quote from: melvinbates on January 23, 2017, 11:58:02 am ---At this point the outstanding unknown for me is how long to hold the left/right signal once the switch is turned.

--- End quote ---
I'm not sure how long Jon held the signal for the KADE Rotary firmware, but he used extra cycles for debouncing.

From the main.c file, line 167:

--- Code: --- //ensure that we debounce the rotary inputs effectively by adding extra cycles

--- End code ---


Scott

melvinbates:
Thanks Scott, I'll take a look at what he did for debouncing the rotary switch.

Though I guess I didn't state my current theoretical issue very plainly.  The issue I'm thinking of (and it may not even really be an issue) is that we are designing a secondary encoder that would sit between say an ipac and a rotary switch that would take the input from the 3 wire interface and determine direction then out put it by pulling one of the L/R lines to ground.  My current concern is how long to pull down the L/R lines so that the keyboard/gamepad encoder recognizes it as an input/button press, but doesn't hold it more frames/poll cycles than necessary and counts one rotation twice.

Though this may never be a great solution because of that problem and if it can't be satisfactorily solved, it may just be easier to either figure out how to get the KADE firmware working on a cheap ATMEGA32U4 board, or use a digispark to create the interface board and have it attach as a usb keyboard.

Either way, it should be fun to figure it out and get something to play with.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version