Industral Game Controller design

In short, I’m designing a game controller.

I want it to look as non-game-controller-like as possible, but still want it done so most people can use it to play games comfortably.

3 posts were split to a new topic: Do you like Broccoli?

How exactly does one design a game controller that doesn’t look like a game controller?

1 Like

By making it look like something else … oh how about a game controller that looks like a can opener!

By, say, make the handle look weird. Or to not include a handle altogether.
Or make the layout strange. Add levers and stuff.
After several days of thinking, I stumbled upon hexagons, and came up with this:
IMG_9560
It have two analog stick, two analog slider (VTOL and Trim or throttle and collective or anything in between), 6 buttons (abcxyz), Dpad, L1R1L2R2 shoulder, and a set of select, menu, start buttons.

But I agree that right now this look very cramped and might be quite difficult to operate.
Also, I need to figure out a way to place a “large” sized Arduino at the bottom while not having the USB to be in the way of the user.
Or maybe I can squeeze it into a “small” sized Arduino, but I’ll certainly need ADCs.

Windows default driver ask for 16 bit precision anyways.


I have difficulty piecing together what that will look like.
But I assume it would look like the small section of the Wii controller thing.


Edit:
Of course there are 6 lane 16 bit ADCs. And also as expected they are by Linear Technology.
But what that make things tricky is that they are QFP packaged.
But it also seemed that Ti had made some ADC080Xs.
I’ll need to look into it.

If you’re using a processor to read the ADCs and pass the values to USB, you could always use 12 bit or 8 bit ADCs and then have the processor scale and provide 16 bit values. I doubt you actually need 16 bit resolution.

The ADC in a microcontroller would probably be sufficient for the purpose.

I doubt it too. Modern production game controllers likely don’t have the bulky 16-bit ADCs in the first place.
Which actually make a standalone Arduino Leonardo barely capable of handling everything – save for a few buttons.

I’d start by trying a Pro Micro with a MCP23017 I²C port expander. Use the ATmega32U4’s 10 bit ADC pins for the analog inputs. The port expander could handle 16 digital inputs beyond what’s left on the Pro Micro.

True. A small sized Arduino does not make a lot of sense here.
Plus the Digital IO expander over SPI for the buttons I think it’ll do.
If it ever come short we can also have a 8 lane ADC over SPI.

To be honest, that still looks like a game controller to me.

The most non-game-controller game controller that I’ve ever seen is a fishing rod controller:

FishingRod

I think pretty much anything will start looking like a game controller once you start adding buttons though.
If you had a means of hiding the buttons then it might be able to pass for a not-a-game-controller.

1 Like

For quite some time, I think the silhouette resemble most closely, a UFO.
The buttons somewhat give it away, though.

It’s somewhat difficult to make it look like something else if you want the user to hold somewhat comfortably, since that will probably ask the layout to be a “pancake” with you holding onto the two sides

We can lay the controls vertical, so it appear like a super-weird TV remote (potentially with RGB led in disguise) or a industrial wired-robot controller

The left hand on the top and right hand at the bottom. Maybe.

Or, we can stretch this idea a bit more further and choose to forgo any ergonometric altogether, and have a long “bar” instead.

Because remember, I am not going to spend extra money and make the buttons different colors (or the Dpad into a single piece). Most buttons are going to look the same. I just draw it this way for reference.

Insert fleshlight joke here

2 Likes

Or a parallel-to-serial IC like a 74HC589

It’s the kind of chip they used in NES/SNES controllers.

You toggle the latch pin to capture the buttons then SPI-read the 8 bits, the SPI-clock pumps the bits in.

Daisy-chain them for however many 8-buttons you want (just do N x 8bits SPI-reads after a latch operation)

Even with a resistor network it’s cheaper than an MCP23017

https://www.digikey.ca/en/products/detail/on-semiconductor/MC74HC589ADG/13501416

And most controllers I’ve seen are 8-bits ADC internally. On top of that the bottom bit is so noisy it’s almost worthless tho you can filter that last bit out over time and get 2 more effective bits if you really really want precision.

The driver just scale up the 8bits value to Windows’ 16bits API.

Even if you use a 16bit ADC the game controller potentiometers (and finger movements) are very noisy themselves.

you’ll likely need to use the lower precision ADC setting at a higher frequency and filter out the odd-ones-out, then average the other samples.

The pots will cause random glitch values and you don’t want to send those over to the PC/console.

say within 1ms you read: [ 127, 128, 12, 135, 20, 140, 138, 139], you want to throw out the 12 and 20 then send the average.

It is 70% cheaper. I’ll look into it.

Personally thinking, 8 bit is about okay.

Right. I had not been thinking of that. Mechanically speaking the pots aren’t terribly accurate, either.
But I think the latter two are on the software side, which make them of lower-priority than figuring out what goes on the board (and what does the board look like).

I think I will go with the “thin bar(horizontal)” layout.
Then the parallel-to-serial IC.

I still had not decided on whether I should use the 74HC589 or the 74HC165.
I understand that the 74HC165 is a “dumb” 8-bit parallel load register (so it don’t have a latch or something) and so I will likely have to bit-bang the code for reading the register.
But I cannot understand half of the 74HC589 datasheet, and why having a latch will allow me to use it in a bus interface like the SPI.

So I went to the drawing board and started laying out parts.
image
Looks quite okay, although I’m not sure if the abcxyz buttons will be within comfortable reach. The ThumbPointer™ is quite tall.

I fought hard with the datasheets to try and put together footprints as imperial as possible. I hope they fit.
Now, only tracks awaits…

Either one would probably work for you. For your purposes, the difference to consider is that the 589 has a tri-state output but 165 doesn’t. This is something to consider if you plan to put one on the same SPI bus with other components, such as the OLED display you’ve pictured.

Ordinarily, without a tri-state output you couldn’t share the SPI bus with another device. However, in your case the OLED display is input only (needs only MOSI) and the shift register is output only (needs only MISO). Therefore, with only these two on the SPI bus there won’t be a conflict as long as you can dedicate a separate chip select (CS) for each.

Therefore, between the 74HC589 and 74HC165, use whatever is cheaper or easier to obtain. Note though, that if you plan to put a third device on the SPI bus, the 589 is a better choice.

2 Likes

When I looked the 74HC165 in a lot of place was obsolete / replaced by the 74HC589 and prices were fairly identical. A tri-state output has to be “free” to add to an IC with the technological improvements since the 74HC589 & 74HC165 were created.

If someone had a bulk-savings deal and really really really wanted to use a 74HC165 AND another SPI device in some case you still could if you pump the bits daisy-chained through the 74HC165 so for every read you got the delay of throwing away a dummy read.

eg:
MCU MOSI -------------------------------> SPI Flash
MCU MISO <------ 74HC165 <------- SPI Flash

chip-select flash
SPI send read command & address bytes
SPI dummy read throw-away (first 8 bits from flash now loaded into 74HC165)
SPI read actual 1st valid byte
SPI read 2nd byte
SPI read …
chip-select off just before the last byte. (not necessary for flash but maybe for some other device)
SPI read last byte.

Which means you gotta write custom code to deal with the read delay.

The mass-production stars would need to align to be profitable and worth the effort but for fun it’s doable :grinning_face_with_smiling_eyes:

1 Like

If you plan to use a Pro Micro for the controller board, you will probably need two shift register chips. The 8 inputs on a single shift register along with the pins available on a Pro Micro likely aren’t enough for everything you want, unless you were to multiplex some of the digital buttons which probably isn’t desirable for a game controller.

This isn’t a problem, it’s easy to cascade two 74HC589 or 74HC165 chips to get 16 inputs. It’s just something to keep in mind for design and layout.

actually it’s no joke (NSFW). But that video Is kind of funny.

Ok back on topic.

There’s also the MCP23S17 This version can be directly hooked to the SPI bus. Have a look at the Datasheet

I’m thinking of adding two registers, so I might need the 74HC589.
I think bit-bang with a 165 will be slower, although getting the byte out of either register still requite 8 steps.

intriguing.

In general, 32U4 don’t.

Right. Their inheritent daisy-chain ability can come in handy. Even if I wire them parallel I still need to issue 16 read instructions.
I’ll look into it.

Yes, I noticed the MCP32S17 (as a alternative to 23017) since I2C can be a bit slow, but as said earlier, the IO port expander is somewhat expensive