Electronic – Using a Logic Analyzer for Device Drivers (low level)

devicedriverembedded

Sort of a follow up to this question:
https://stackoverflow.com/questions/19760764/learning-to-write-low-level-drivers-linux/19761953?noredirect=1#comment29386523_19761953

For example I want to take a random peripheral (like an SNES Controller I used in the example above) and make a device driver out of it. With/Without a guide for the controller how do I really know how to read the inputs.

Take this as someone that knows very little about Device Drivers so what im saying may make little sense. It was mentioned using a Logic Analyzer to use if I had no instructions on the device.

Thanks

Best Answer

Basically what you would need to do is reverse engineer the protocol through observation.

Let's say you wanted to use a SNES controller. The first thing you should do is take apart the controller and figure out how it's wired up internally - how many buttons? How are they connected together? What sort of sensors are used for analog sticks? Is there any sort of force feedback/vibrators/etc? How many wires interface with the controller? Which ones are obviously signal/power/ground?

Once you have some idea of what's going on in the controller, you need to observe it in action. Connect it to an SNES and connect the logic analyzer to the signal lines and ground. The ground is rather important, without a good ground your readings will be meaningless.

Then you want to fire up the SNES and start wiggling around the knobs and pushing buttons. Look at the data you see on the pins. You'll need to figure out which end is generating the signals - is the SNES querying the controller, or is it just sending data at will? You'll then need to start piecing together the protocol. It's probably serial of some sort, so you'll need to determine the baud rate. That's just a matter of measuing the width of the narrowest bit. Then you need to figure out the format. Is it something like RS232? If so, how many start and stop bits? MSB or LSB first? Or perhaps it is more akin to I2C, where you have a clock and a shared data line that can be driven by either end. Once you have a good idea what the protocol is, then you can start figuring out what the actual data is. Decent logic analyzers can decode I2C and RS232. If you don't have one that can do this, you're going to have a LOT of work to do. Once you can get consistent data out of it, then it's just a matter of figuring out what data corresponds to what button or stick. Once you have all that, then you need to implement the controller side of the protocol on something to see if you got it right. If that works, then you should be able to go ahead and write your device driver.

Related Topic