As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options

[Let's Make] A USB Game Controller for the PS3 - Part 7 - Writing a USB stack

ecco the dolphinecco the dolphin Registered User regular
Everyone has different hobbies. Some people paint. Some people play video games. Some people write stories. I play with and build electronics.

A few months ago, I got it into my head that I wanted to make something that could act as a game controller on the PS3... just for fun. A few days ago, I wrapped up the bulk of it and am now just waiting for a few things before I put the finishing touches on.
img8126scaledandcroppedro5.jpg

While I wait, I thought some of you guys might be interested in seeing what's involved in making a USB game controller. If there's enough interest, I plan to make a series of posts describing the steps I took to make my controller, some of the decisions I made, and a few interesting technical tidbits.

Here's where you come in. If you're interested in any particular part of the development process, ask! I'll try and provide answers to the best of my technical capabilities. I'm also not sure how technical you guys are. I've written the first part, but am I being too technical? Not technical enough? Should I cut down on the background information? Go into more detail, but not be that technical? Include more links to relevant sites? Tell me!

Here's a rough guide to the steps that I went through and plan to talk about:
  1. Microcontrollers and You (hardware related) - (here)
  2. Development boards (hardware related) - (here)
  3. Firmware and development tools (software related) - (here)
  4. USB, HID, and TLAs (software/protocol related) - (here)
  5. Tying it all together to work on the PS3 - (here)
  6. A one man, three instrument band on Rock Band [strike](still waiting to see who has a video camera that I can use)[/strike] - bought a webcam - (here)
  7. So you want to write your own USB stack - Device States - (here)

Technical disclaimers:
* The resulting game controller is best described as USB compatible, not USB compliant. It complies to enough of the USB standard that most hosts (like the PS3 or my computer) won't care, but it wouldn't even begin to be able to pass any of the compliance tests from the USB organisation.
* Some of the decisions I made were made from a hobbyist perspective, as opposed to that of, say, a professional engineer/developer. So technically, they won't always make the most sense, nor will they necessarily provide the most optimal solution. But then, no one's paying me for my time on this, so meh. :P

Penny Arcade Developers at PADev.net.
ecco the dolphin on
«1

Posts

  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    Part 1: Microcontrollers and You

    Ahh, the good old microcontroller. Think... a computer, but much smaller, slower, and self contained. Whereas your computer's processor might be running at 2.4GHz with 2Gb of RAM and 160Gb of hard drive space, a microcontroller might be running at 12MHz with 512 bytes of RAM and 4kb of space for programmes.

    They're useful little things, and unlike the computer processor market which is divided between two competitors - Intel and AMD - the microcontroller market is divided between quite a few manufacturers - NXP, Atmel, Microchip, Silicon Labs, Texas Instruments, Cypress - to name a few. Also, unlike the computer processor market where pretty much only one architecture - the x86 - is used, there are a wide variety of architectures available in the microcontroller space - ARM, 8051, AVR, PSoC, PICs etc. And to make things more interesting, microcontrollers will often have different inbuilt peripherials (e.g. a few may have inbuilt floating point units (FPU), another few may support USB, another few may have waveform generation blocks necessary to drive a three phase motor, etc) that are targetted towards different applications.

    So, while there's a lot of choice when picking a microcontroller, and it's not surprising that a lot of the decision on choosing which microcontroller to use will rest on the application. If you want to do something simple (e.g. control a dc motor with minimal feedback), you might just want any 8-bit controller running at 10MHz, but if you wanted to do something a bit more complex (e.g. real time processing of colour images captured by a camera), you might want to use a 32-bit ARM at 100MHz with an inbuilt FPU, say.

    So where do I fit into all this? Well, since I wanted something with USB functionality, I wanted a microcontroller which had a built in USB controller. If it didn't have a USB controller, it would make it harder (but admittedly, not impossible - see here) to use the microcontroller to talk to the PS3/computer via USB. There's actually quite a few microcontrollers around now with inbuilt USB controllers (this wasn't true a few years ago), so there were choices to be made.

    Now when I started this project, I had already been dealing with AVRs for quite a while, and was keen to try using the ARM platform. Despite it being perfectly feasible to use an 8-bit microcontroller (I probably would've used this, had I gone down this route) to do what I want, I decided to go overboard and use an ARM7 from NXP - the LPC2144* to be precise.

    I ended up using the LPC2144 because I had a few lying around which I had always meant to get around to using, but never did. Plus, I had already made a development board for them last year which I never really got around to using either. Seemed like the perfect choice, really.

    I'll save the development board for next time, but here's a picture of the LPC2144 soldered into the board (it's the black IC on the left). I've placed a penny (for you American people) and a ruler (for us metric people) as a size reference. They're small, aren't they?
    img8131croppedandscaledgl7.jpg

    * Look at those specs - 128kb of flash memory (all code is kept on the flash, so my overall firmware cannot be greater than 128kb without trickery) and 16kb of RAM. That is so overkill for this (not sarcastic). Plus, I can operate the ARM7 at 60MHz. Crazy! But the really good thing is that it's programmable via the serial port.

    It's very common for microcontrollers to require external programming hardware to write the code to flash memory at least once. ARM processors will often use a "JTAG dongle". Low quality (but admittedly, perfectly servicable) dongles are cheap, but once you start talking about decent quality JTAG dongles, they start getting pretty expensive. Since I'm a cheap bastard, the fact that the LPC2144 can be programmed without needing a JTAG dongle really appealed.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    VelmeranVelmeran Registered User regular
    edited December 2008
    Being an ex-electronics hobbyist (programmed PICs back in high school and such) this is relevent to my interest, you may continue to entertain me.

    Velmeran on
    Vechloran.png
  • Options
    TechnicalityTechnicality Registered User regular
    edited December 2008
    I built a USB driving setup at uni, with a proper clutch and gears. I look forward to reading your details on step 4, as all the USB protocol stuff I did was very rushed and I never did really make sense of it all.

    The whole thing was modular, with a master PIC talking to the PC and translating inputs from an I2C bus. I was pretty damn fortunate it all worked in the end. Much respect for finishing off something like this for fun.

    Oh, and I want to hear all about the worst bits that went wrong! Tales of epic failure followed by success I just find fascinating.

    For example:
    When I was setting up my I2C bus, I couldn't get the master device to do its thing. Since I didn't have access to a scope for a few weeks, and a bunch of spare pins on the micro, I decided to connect one of the spare inputs on the same chip up to the bus to see what was going on. It turned out to be something trivial, and the master soon started doing its thing, but now the slaves weren't acting right. I spent weeks fiddling with them to no avail, until I finally got access to a scope and checked the bus out. The data line was incredibly noisy and dancing around like crazy, so I methodically start to check for shorts or loose connections. Eventually I come across the wire running into another input pin and slowly realize that this has to be the source of all my suffering. One quick snip, and everything lights up like a Christmas tree and starts merrily chatting away.

    Technicality on
    handt.jpg tor.jpg

  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    I built a USB driving setup at uni, with a proper clutch and gears. I look forward to reading your details on step 4, as all the USB protocol stuff I did was very rushed and I never did really make sense of it all.

    Can do! =)
    Oh, and I want to hear all about the worst bits that went wrong! Tales of epic failure followed by success I just find fascinating.

    Ha. Oh yeah. Had plenty of them.

    The number of times I went, "F*ck, did I just blow up about $100 worth of stuff?!"

    Urgh.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    Development Boards

    Development boards, or dev boards for short, are to a microcontroller what a motherboard is to a computer processor. Sure, I selected my microcontroller, but now it needs power and some external hardware to access all its peripherial functions.

    You can buy premade ones, such as the AT90USBkey or this one for the LPC2148 from Sparkfun (as an aside, Sparkfun sells a lot of cool things for your electronics hobby - now if only my local currency would strengthen against the USD!). These tend to be made by people who know what they're doing and are really well done... as opposed to my effort at making my own custom dev board (in hindsight, there were a few design mistakes related to placement of components that I would change - see if you can spot them!).

    I pretty much had to make my own dev board since I had bought the microcontrollers and they were surface mount devices. Luckily, NXP, like any decent manufacturer, provided a reference schematic for an example development board which I copied. Or tried to, at least:
    part2armdevboardscaledat2.jpg

    If you look beside the USB port, you can see two green wires. Whoops! Turns out I didn't copy the reference schematic exactly, after all! Funny story about how I found this problem - those two wires are for the RX and TX signals from the MAX232 to the microcontroller (technically a MAX3243 because of a few other reasons, but I thought more of you guys would know what a MAX232 was than a MAX3243). Remember how I said that the LPC2144 could be programmed via its serial port?

    So, yeah. When I first assembled the board and plugged it in, I tried the running the programmer utility to see if it could identify the LPC2144. Nothing. At this point, I had invested in the vicinity of $100 (~USD$55 based on current exchange rate) buying the components and getting the board made, and I was starting to get this sinking feeling in my stomach - you know - the whole, "Oh my god... did I just... did just waste $100 on a piece of junk?".

    So I brought out the 'scope (luckily, where I work, I have access to awesome, awesome scopes) and found that the the TX signal from the computer to the MAX chip was changing as expected, but it wasn't doing that from the MAX chip to the micro. Double checking the schematic informed me that I had tied the TX pin of the MAX chip to the TX pin of the micro so that, apparently, they could duel it out in a battle for absolute supremacy to see who was the true transmitter.

    But really, in a battle like that, no one wins. Especially not me, so I cut the tracks and flipped it around so that TX was connected to RX, as it should be, and all was well.

    So, now armed with a dev board that I could programme, I was ready to take my first steps in the world of ARMs.
    Actually, there were three other "incidents" directly related to the development board that I can recall off the top of my head. I accidentally bent off part of a pin on the MAX3243 when I was soldering it on and had to use a really thin piece of wire to reconnect it to the other bit. Man. I don't know why I continue to solder surface mount stuff by hand. I could just use the oven, like any other sane person, you know? :P

    Another one was actually a defect in the board! It wasn't until much later when I was testing USB functionality that I discovered this one because it involved the track to one of the USB data lines, of all things. Turns out that one of the vias in the track hadn't been properly plated through, so I actually had a break in the track! A simple wire through the via and solder on top and bottom fixed that.

    The final one was a bit of a doozie. I had hooked up the +5V line from the USB bus to a signal pin on the micro to be used as a "Has this board been connected to the USB bus?" indicator. If 5V was there, then the answer would be yes. If not, then no. In a monumental facepalm (in terms of design), I failed to take into account what would happen if I disconnected the dc power source while keeping the board connected to the USB bus.

    Turns out that (in hindsight, it was totally to be expected) that Vcc to the micro went to 0V when the dc plug was removed, while +5V from the USB bus kept on being applied to the pin on the micro. This exceeds all sorts of electrical specifications, and it was absolutely no surprise that the microcontroller got stinking hot when this happened (I imagine that there was most likely some sort of internal clamping diode on the I/O pin to keep it from exceeding a certain voltage above Vcc, and when Vcc dropped to 0V, I was probably just taking the entire brunt of the USB bus through that particular diode).

    First time this happened I was really confused because I had just removed the dc plug... and the microcontroller was becoming uncomfortably hot. "But... I just removed the power source... where... where is the power to heat the microcontroller up coming from? Did I just create energy from nothing? Oh wait... there's potentially [strike]250mA[/strike] 500mA from the USB bus... which is connected to a pin.... ohmygodohmygod unplug it from the USB bus quickquickquick! Did I just destroy my micro through that pin?!"

    Turns out, no, I didn't destroy it. Man, this micro is surprisingly rugged. Quick hack solution was to disconnect that pin by cutting that track. Not doing that again!

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    TechnicalityTechnicality Registered User regular
    edited December 2008
    Haha, I remember those "is it me, or is this chip slightly warm? Maybe its just my imagin.. Argh! Argh! Burning my finger! Pull the plug!" moments.

    Technicality on
    handt.jpg tor.jpg

  • Options
    VelmeranVelmeran Registered User regular
    edited December 2008
    Electrical Engineering, not for the light of heart.

    I remember in high school for my senior year I was given an RC truck by the teacher of my electronics class for a senior project. I had to gut its stuff except for the power/motor internals and set it up to work on simple IR signals so it could follow a path with no human input. Sounds easy when your 17 and have no idea about all this. My teacher, the nice guy he is, never even told me it was going to be almost impossible and just kept helping me with what ever problem I had.

    about 3/4ths of the way through the year I've got it generally working on the breadboard, but when ever I put it all together on the circuit board it just acts stupid and won't read the IR signals.

    One moring at the school (it was actually a "Skills Center" that three local high schools had access too so we could take all sorts of cool classes there) was having some visiting guest from Japan and they were looking at senior projects. I was the only senior in that morning and so it was "hey, show them your car". I was thinking "oh great, its going to sit there and do absolutely nothing"

    So I power it up, put it on the ground, its guts are jsut hanging on barely so I zip tied them down quickly and then got one of my transmitters to wave in front. All the while someone's translating for me about my project and what its suppose to do (be an automated delivery system for the school, I think thats what my official papers said).

    Show time comes, and I'm sitting them moving the "forward" command IR in front of it, for about 2-3 seconds nothing. Then suddenly the little bugger takes off at full speed. Backwards... Which I didn't even have programmed in...

    So I go chasing after it in the room since it wasn't likely to stop any time soon and when I got closer it started to turn in a circle. At which point I caught it and turned it off and was like "See, it kinda works, just some programming needs to be done" luckily I hadn't told them anything about just getting it to go forward, so they all clapped and finally moved on.

    When it was over my teacher was happy it worked but we had a good laugh about the whole thing since he knew it wasn't suppose to go backwards either.

    End of story, it never really got past the breadboard stage, but with the breadboard on it, I got it to move around the class room about 60% of the time so I passed the class.

    Velmeran on
    Vechloran.png
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    Haha, I remember those "is it me, or is this chip slightly warm? Maybe its just my imagin.. Argh! Argh! Burning my finger! Pull the plug!" moments.

    Hehe, oh yes. And then the inevitable, "Is it... is it okay? What went wrong? Does it still work?! Please tell me it still works."

    They do say hope springs eternal... :P
    Velmeran wrote: »
    Electrical Engineering, not for the light of heart.

    I remember in high school for my senior year I was given an RC truck by the teacher of my electronics class for a senior project. I had to gut its stuff except for the power/motor internals and set it up to work on simple IR signals so it could follow a path with no human input. Sounds easy when your 17 and have no idea about all this. My teacher, the nice guy he is, never even told me it was going to be almost impossible and just kept helping me with what ever problem I had.

    about 3/4ths of the way through the year I've got it generally working on the breadboard, but when ever I put it all together on the circuit board it just acts stupid and won't read the IR signals.

    One moring at the school (it was actually a "Skills Center" that three local high schools had access too so we could take all sorts of cool classes there) was having some visiting guest from Japan and they were looking at senior projects. I was the only senior in that morning and so it was "hey, show them your car". I was thinking "oh great, its going to sit there and do absolutely nothing"

    So I power it up, put it on the ground, its guts are jsut hanging on barely so I zip tied them down quickly and then got one of my transmitters to wave in front. All the while someone's translating for me about my project and what its suppose to do (be an automated delivery system for the school, I think thats what my official papers said).

    Show time comes, and I'm sitting them moving the "forward" command IR in front of it, for about 2-3 seconds nothing. Then suddenly the little bugger takes off at full speed. Backwards... Which I didn't even have programmed in...

    So I go chasing after it in the room since it wasn't likely to stop any time soon and when I got closer it started to turn in a circle. At which point I caught it and turned it off and was like "See, it kinda works, just some programming needs to be done" luckily I hadn't told them anything about just getting it to go forward, so they all clapped and finally moved on.

    When it was over my teacher was happy it worked but we had a good laugh about the whole thing since he knew it wasn't suppose to go backwards either.

    End of story, it never really got past the breadboard stage, but with the breadboard on it, I got it to move around the class room about 60% of the time so I passed the class.

    Hahaha, nicely done. I remember back at 17, I had no clue what capacitors *really* looked like beyond the parallel lines schematic symbol (I'm not sure I had clicked on to the fact that you could have polarised capacitors yet). Or really, what a capacitor was even used for.

    I take my hat off to you, sir, for actually getting something running.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    CmdPromptCmdPrompt Registered User regular
    edited December 2008
    I got an Arduino for Christmas, so this is really interesting stuff. Thanks eecc!

    CmdPrompt on
    GxewS.png
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    CmdPrompt wrote: »
    I got an Arduino for Christmas, so this is really interesting stuff. Thanks eecc!

    Oh man, the Arduinos are awesome! A friend and I were thinking of making shields for that and trying to convince Sparkfun to produce them for us, but that never got off the ground. =/

    If you were ever interested in using your Arduino for USB but didn't have the hardware, you might want to bookmark this site. Converts an AVR into a low-speed software based USB controller - you only need to provide the physical USB plug and a few I/O pins.

    Edit: *gasp* I am so out of date. Looks like they've an FTDI chip nowadays, so I guess you can just treat it as a serial port.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    DaedalusDaedalus Registered User regular
    edited December 2008
    I just started getting into microcontrollers around this year, so I'm keeping an eye on this thread as I was sort of planning to do something similar to make an arcade stick or something.

    (too bad it's impossible to make it work on the 360, though. Fucking Microsoft.)

    Hell, I've got a couple of ATTiny2313 chips lying around, maybe I'll check out this software USB thing.

    Daedalus on
  • Options
    TechnicalityTechnicality Registered User regular
    edited December 2008
    If you want to make an arcade stick thats compatible with the 360, just gut a cheapo 360 controller. It is rather a cop out, but unless space is at a premium or you really want to change the circuitry/firmware its a huge time saver (and just wiring it all up will take a long time on its own, trust me).

    pic of my current project. One of a matching pair. Still not quite finished, but then SF4 isn't here yet ;-)

    Technicality on
    handt.jpg tor.jpg

  • Options
    DaedalusDaedalus Registered User regular
    edited December 2008
    If you want to make an arcade stick thats compatible with the 360, just gut a cheapo 360 controller. It is rather a cop out, but unless space is at a premium or you really want to change the circuitry/firmware its a huge time saver (and just wiring it all up will take a long time on its own, trust me).

    pic of my current project. One of a matching pair. Still not quite finished, but then SF4 isn't here yet ;-)

    yes, of course that would work, but then I'm not the person that's writing the software, making it significantly less fun of a project.

    Also a wired 360 controller costs like forty dollars, but I suppose you could just go with whatever cheap used third-party thing you can find.

    Daedalus on
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    Firmware and Development Tools

    So, having got the dev board working and the flash programming utility successfully communicating with the dev board, I now needed a compiler. ARMs, like 8051s, are multi-vendor microcontrollers, so you generally wouldn't expect the vendor to supply you with a compiler (as opposed to the AVRs or PICs).

    Luckily, gcc has been ported over to the ARM platform. Unluckily, there appears to be quite a few ports - WinARM, Yagarto, and GNUARM. I'm not quite sure of the exact details and relationships between them - I ended up choosing to use Yagarto since it appears to have native Win32 binaries and was last updated this year.

    There are a few commercial ARM C compilers as well - Keil sells one with their IDE, and there's another one called Crossworks which seems to be highly recommended. I've only ever used the Keil IDE with their 8051 compiler, but darn, that was awesome. At the time, I was given access to a JTAG programmer for the 8051, and so I could set a hardware breakpoint and inspect internal register values, just like I could in, say, Visual Studio. Those were good times. Nowadays, I get by with a flashing LED and perhaps a serial port. :P

    Anyway, one of the reasons that you might want to consider getting a commercial IDE is to save the hassle of manually setting up the memory map for the linker. Unlike, say, the port of gcc for AVRs which has the memory sizes and addresses for every AVR microcontroller (well, if not every, then an extremely large portion), Yagarto's gcc port requires you to manually put in where code space started, where the SRAM starts, and their relevant sizes. I imagine if you use a commercial IDE, you simply select the ARM model from a drop down box and you're all set.

    You would not have had the problem I had where, I admit, not knowing anything about the linker's memory map file format but knowing that I had to provide one, I just grabbed an example programme from somewhere, and tried to use that. Turns out that the example programme used an LPC2148 - I was using a LPC2144 which has less flash and RAM. Now, code executes from flash from address 0 and goes upwards in memory so technically this wasn't a problem for the flash. The programme stack, on the other hand, is typically placed at the end of RAM and grows downwards...

    Since I had forgotten to adjust the size of RAM in the memory map for the linker, it had happily assumed that I had 32kb of RAM, when I only had 16kb. So you can imagine what happened when I wrote my first programme that used the stack. "Oh hey, we'll save a few variables and the return address on the stack before we call this function... that is to say, saved on the stack at memory locations that don't exist. Oh hey, let's fetch that return address now... from non-existant memory locations". No surprise that programme crashed and burned and had me very, very confused.

    But after sorting that out, I did the next programme - a "Hello world" equivalent, if you will. I tried to write a programme that blinked an LED - we've all done it. It's like a basic test - "Yes, I can actually drive an I/O pin and make the microcontroller do what I want" (the actual "Hello World" comes later when you're brave enough to test the serial port).

    So I wrote a programme that just turned the LED off. That worked. Another programme that turned the LED on. That worked too! I, at this point, felt pretty brave, confident, and reckless and decided to combine the two and make something that blinked the LED! (I know, such hubris :P). So I did what any lazy programmer would do to make a delay between the code to turn the LEDs on and off:
    for(nTemp = 0; nTemp < 100000; nTemp++);
    

    Compiled the programme, flashed the micro... and... huh. The LED stays on. Hm. Why? Oh hang on, let's do a quick sum here, the micro's running at... well, 12MHz at the moment, and let's say there's an instruction in the ARM instruction set that loops in one clock cycle. So that loop would execute in 100,000 clocks... and the LED would be flashing at around 60Hz. Oh. Right. Yeah. I'm not going to see that as a blinking LED. Duh. So, let's try again, except... 10 times slower! 6Hz!.
    for(nTemp = 0; nTemp < 1000000; nTemp++);
    

    Huh. Still a pretty solid light. Let's make it even slower!
    for(nTemp = 0; nTemp < 10000000; nTemp++);
    

    Okay. 0.6Hz. ... nope... pretty solid. Oh wait - I got it - I got it - I've gone backwards. The loop actually takes like, I dunno, 20 clocks or something because it has to flush its pipeline or something, and that's always a heavy performance penalty. So I've actually coded it to like 0.00006Hz or something silly like that. Oh well, I'm not patient enough to test that out - let's just make the delay smaller.
    for(nTemp = 0; nTemp < 1000; nTemp++);
    

    Nope.. still not working. Right. That's it. I'm looking at the assembly output to look at the instructions and count how many cycles I should be expecting.

    Oh. Crap. The loop's not there in the assembly output. What the...?

    Oh. Oooooh. Hey, I turned optimisations on. Heh. Whaddya know? Let's look at it from the optimiser's perspective:

    "Oh. Right. You've enabled me, so clearly, you want the code to run fast. And here's a loop that... just seems to delay execution of code and make it slower. The variable nTemp isn't referred to anywhere else... so... hmmm... I'll just remove that loop for you - it'll make the programme run a lot faster, I swears it."

    Yes, Mr Optimiser, good job. You did exactly what I told you to do. Well done. :P

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    wabbitehwabbiteh Registered User regular
    edited December 2008
    That's a wonderful bug.

    Also, how did I not notice this thread? I've been trying to make a PS2->USB adapter (mostly for fun) and a lot of this stuff is perfect for figuring out how to do it. Much thanks for taking the time to post it!

    wabbiteh on
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    USB, HID, and TLAs

    Ahh, USB. Boon for the end user. Complexity for the developer. Personally, I especially like how if you create a device which meets a USB class standard, USB hosts (like your computer... or, say, the PS3) will be able to talk to the device and it will all Just Work. One of the USB classes that's pretty much used every day - the Mass Storage class - has been pretty successful by any measure. Of course, I'm interested in another class for this project - the Human Interface Device (HID).

    HIDs include keyboard, mice, joysticks... pretty much anything that, well, a human can use to interface with the computer. Luckily, the Rock Band peripherials for the PS3 all register as USB HID devices when you plug them into a computer, which was what led me to believe that I could make my own compatible versions of the instruments.

    A problem with USB is the amount of overhead that's involved for the developer. Looking at the USB related potions of my code, a rough breakdown gives about 5% related to HID class specific items, 35% related to interfacing with the USB controller itself, and 60% related to the initial negotiation/configuration phase that only occurs when you first plug in the device. You can't just ignore this phase either, because it's the phase where you inform the USB host what you are, what you're capable of, and the host acknowledges that it knows what to do with you.

    If you're on Windows, you can see this negotiation the first time you plug in a new USB device - it'll pop up a little tooltip in the bottom right hand corner - something along the lines of: "New USB device found." (at this point, Windows is interrogating what the new device is) "It's a mass storage device!" (Windows: Alright! I know what to do with one of them - I'll just load up the relevant drivers for you) "You can now use your mass storage device." Ta-da! The magic of USB has been worked!

    If you ignore this phase, the host will go, "Hey - what are you? ... Hello? Are you there? Are you ignoring me? Don't you love me?! =(" and report that the USB device [strike]wasn't quite upholding their end of the relationship, you know? The communication just wasn't there, I mean I tried to talk to her, but she just wouldn't listen or respond[/strike] has malfunctioned. By comparison though, once you and the host have made it clear [strike]what you both want out of this relationship[/strike] that you're a HID and how many buttons/axis/any other features you have, all you have to do is send back a report on what the button states/axis locations are every time the host asks you to. Yeah, I realise I'm ignoring stuff like USB suspend, but you've got to start somewhere.

    Now, there are a few people who might be interested in more technical details - specifically things like what to expect from the USB host (e.g. setup packets, standard device requests, etc), USB configuration descriptors, HID descriptors - I hadn't intended to actually go to this level of technical detail, but if you guys are interested, I can give a more technical description of how USB works at a lower level, a trick or two, and some reference materials? I don't claim to be utterly proficient at USB, so you might want to keep in mind that I may have misinterpreted a few things.
    Ironically, there aren't that many TLAs apart from USB, HID and PS3.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    wabbiteh wrote: »
    That's a wonderful bug.

    Also, how did I not notice this thread? I've been trying to make a PS2->USB adapter (mostly for fun) and a lot of this stuff is perfect for figuring out how to do it. Much thanks for taking the time to post it!

    I wish I had more bugs like that.

    "Halp! My programme's running too fast!" :P

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    MaxxxPowerMaxxxPower Registered User new member
    edited December 2008
    I've been developing a ps3 compatible gamepad myself, great to see someone developing one at the same time!

    My last mystery is getting the PS button to work... I have some PIC source code that supposedly has it figured out, but i am not exactly sure what's going on with it yet, as I work with AVR's and my controller is based on the AVR-USB firmware you mentioned above :)

    If you have any technical information you'd be willing to share, it would be very much appreciated!

    I am looking forward to the rest of your write up!

    MaxxxPower on
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    MaxxxPower wrote: »
    I've been developing a ps3 compatible gamepad myself, great to see someone developing one at the same time!

    My last mystery is getting the PS button to work... I have some PIC source code that supposedly has it figured out, but i am not exactly sure what's going on with it yet, as I work with AVR's and my controller is based on the AVR-USB firmware you mentioned above :)

    If you have any technical information you'd be willing to share, it would be very much appreciated!

    I am looking forward to the rest of your write up!

    Hey, welcome to the PA boards! I hope you enjoy your stay.

    From memory, the PS button was just button number 13... I don't recall having any problems with it, but then maybe I didn't test it and so didn't notice? I'll double check tonight and write part 5 - stuff on New Years have kept me away from updating this.

    I'll write up a series of more technical posts after part 5, although much of what I'll be saying can be found on sites like Beyondlogic if you want to skip ahead. That's actually quite a decent site for USB related information, in general.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    MaxxxPowerMaxxxPower Registered User new member
    edited December 2008
    Well I just built my firmware for a x-y axis and 16 buttons, i connected the wires for #13 and nothing happens. I would have been kind of angry if it had worked, though, having missed something like that!

    I found a page where someone makes their own "universal" guitar hero/rock band guitar. They basically added in a 2nd controller board. Apparently they got everything working except the PS button...

    I take it your controller actually tries to pretend its a PS3 controller and not a standard HID device, correct?

    MaxxxPower on
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited December 2008
    MaxxxPower wrote: »
    Well I just built my firmware for a x-y axis and 16 buttons, i connected the wires for #13 and nothing happens. I would have been kind of angry if it had worked, though, having missed something like that!

    I found a page where someone makes their own "universal" guitar hero/rock band guitar. They basically added in a 2nd controller board. Apparently they got everything working except the PS button...

    I take it your controller actually tries to pretend its a PS3 controller and not a standard HID device, correct?

    The latter, actually. My HID's set up with 13 buttons and a hat, so I can navigate menus in Rock Band. Didn't bother with the analogue sticks (x/y/z axis) since I have no need for them.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    MaxxxPowerMaxxxPower Registered User new member
    edited December 2008
    Well, at least I know I'm almost there...

    MaxxxPower on
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited January 2009
    Tying It All Together to Work on The PS3

    So, after having gotten the dev board to successfully convince my computer that it's a HID, I now need to make it pretend that it's an HID with the right number of buttons and features for the PS3. Plus, it would be nice to know which buttons are what.

    The easiest way to do this, I figured, was to plug in what I was going to emulate - the Harmonix Drum Kit:
    part5windowshidfordrumsfh7.png

    I started tapping the drums, and found that:

    Button 1: Blue Drum Pad (Also square)
    Button 2: Green Drum Pad (Also cross)
    Button 3: Red Drum Pad (Also circle)
    Button 4: Yellow Drum Pad (Also triangle)
    Button 5: Kick pedal (Presume that it maps to another button - maybe a trigger? Easiest way to check would be to plug in the Dualshock 3 and do it that way)
    Button 9: Select
    Button 10: Start
    Button 13: Home button*
    Hat: The d-pad

    So where does this leave us now?

    Well, all** I need to do is make my dev board claim that it has 13 buttons, and a d-pad (further experimentation found that I didn't need to claim to have an x/y/z axis, nor z rotation for this to work) and map those 13 buttons to inputs that I wanted.

    As a test, I wrote a quick programme that spat button data down my serial port from the computer, so that effectively I had mapped the number keys 1, 2, 3, 4 to the red, yellow, blue and green drum pads and left control the kick pedal. Worked a treat!

    The current plan is to leave it communicating through the serial port to my computer, since my computer has many drivers already installed for other input devices... such as, say... a dance mat.

    One man, three instruments?
    Two feet, two drum sticks?

    Well, if I can borrow a camera of some description at least. :P


    * Heh, MaxxxPower, you were right - I can't get the Home button to work either. I'm not particularly fussed, since it's not something I plan to use in my project, but I can see why it might be annoying.

    ** Well, not technically all - there was a trick I had to pull to get Rock Band to recognise my HID as a Drum Kit, as opposed to a normal controller, which I felt was rather dirty. I'd like to apologise to Harmonix and Sony for unlicensed usage of their VID/PID on the Drum Kit. Let it be known that I would not do this commercially, nor would I recommend this be done if I were in a professional role.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    DaedalusDaedalus Registered User regular
    edited January 2009
    ** Well, not technically all - there was a trick I had to pull to get Rock Band to recognise my HID as a Drum Kit, as opposed to a normal controller, which I felt was rather dirty. I'd like to apologise to Harmonix and Sony for unlicensed usage of their VID/PID on the Drum Kit. Let it be known that I would not do this commercially, nor would I recommend this be done if I were in a professional role.

    Well, hey, how do you think Mad Catz or Nyko does it?

    edit: Well, Mad Catz is licensed by Harmonix to make Rock Band peripherals, but Nyko (and everyone else, for that matter) is not.

    Daedalus on
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited January 2009
    Daedalus wrote: »
    ** Well, not technically all - there was a trick I had to pull to get Rock Band to recognise my HID as a Drum Kit, as opposed to a normal controller, which I felt was rather dirty. I'd like to apologise to Harmonix and Sony for unlicensed usage of their VID/PID on the Drum Kit. Let it be known that I would not do this commercially, nor would I recommend this be done if I were in a professional role.

    Well, hey, how do you think Mad Catz or Nyko does it?

    edit: Well, Mad Catz is licensed by Harmonix to make Rock Band peripherals, but Nyko (and everyone else, for that matter) is not.

    I'm guessing that they're officially Sony licensed peripheral developers, and if not, then they use their own VIDs at the very least. If they didn't, then I'd expect the legal arm of the USB organisation/whichever vendor's ID they've illegally used to have hit them with lawsuits by now.

    As opposed to what I've done, which is just "Yoink! Stole your VID/PID!" which couldn't possibly be legal*.

    As an aside, I'm guessing that Sony allows you to buy game controller ASICs from them, and I'm guessing that Red Octane/Harmonix have done so. This guess is based on the VID of the guitar controller on both the GH and RB sets being the same (also on the RB drum set as well - I don't have a GH drum set to check with), as well as all the other USB descriptors/endpoints being exactly identical. The manufacturer string is also "Licensed by Sony Computer Entertainment America" for those peripherals. Couldn't be a coincidence.

    Either that, or both Red Octane and Harmonix have third partied their hardware development to the same guys.

    As another aside, the microphone is just a Logitech one. Works pretty well on the computer too. =)

    * I can't afford the $2,000 for a VID. Couldn't justify it either. Well, not unless I open up my own consultancy or custom development service offering USB peripherals. But that's not going to happen in the near future.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited January 2009
    Alright.

    It's been a while in coming, but here it is:

    http://www.vimeo.com/2783867

    Me trying to sing, play the guitar, and play the drums simultaneously (with the drums hooked up to a dance mat).

    I tried for hours on easy/easy/easy Wonderwall before I got up to 80% - by which time I was too tired to do any more.

    I had big plans initially - big plans - to do expert vocals, expert guitar and easy drums. Perhaps medium drums if, you know, it turns out that my feet were truly awesome. Turns out that no, I am actually most likely doing it wrong. :P

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    MaxxxPowerMaxxxPower Registered User new member
    edited January 2009
    Good work, but Oasis? o_O Reminds me of when I hacked an NES powerpad into a PSX DDR Dance mat. Didn't work very well :P

    Anyways, I put together a ps3 controller this weekend using the firmware i've written and an old NES controller. The point-to-point wiring wasn't fun!!! No PS home button either, but I can get away with it on this controller. Here's a quick write-up with pictures:

    http://maxxxpower.simcup.net/projects/NES-USB/NES-USB.html

    MaxxxPower on
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited January 2009
    MaxxxPower wrote: »
    Good work, but Oasis? o_O Reminds me of when I hacked an NES powerpad into a PSX DDR Dance mat. Didn't work very well :P

    Anyways, I put together a ps3 controller this weekend using the firmware i've written and an old NES controller. The point-to-point wiring wasn't fun!!! No PS home button either, but I can get away with it on this controller. Here's a quick write-up with pictures:

    http://maxxxpower.simcup.net/projects/NES-USB/NES-USB.html

    Hahaha, all this for Megaman 9? Class. =)

    Of course, I'm one to talk...

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    InfidelInfidel Heretic Registered User regular
    edited January 2009
    eecc, I was just browsing shit and came across this and was like AWESOME.

    ...cause I'm doing my real-time systems project on a "MIDI to USB HID convertor" using an Amtel AVR board, which in actuality means hook up instruments to Rock Band. :D I'm planning on having it display the MIDI stream info on the board digital display and LEDs, with it sending out appropriate and reprogrammable HID info on the USB. I'll be implementing this from scratch, I cannot use any libraries or code not my own so it should be fun. :) A bonus feature will be making it into a software synth as well if I can manage it, where I take the instrument # / velocity info and mix together the loaded PCM instruments, sending it to a stereo output jack. 8-)

    I may pick your brain if I run into any technical difficulties. :^:

    Infidel on
    OrokosPA.png
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited January 2009
    Infidel wrote: »
    eecc, I was just browsing shit and came across this and was like AWESOME.

    ...cause I'm doing my real-time systems project on a "MIDI to USB HID convertor" using an Amtel AVR board, which in actuality means hook up instruments to Rock Band. :D I'm planning on having it display the MIDI stream info on the board digital display and LEDs, with it sending out appropriate and reprogrammable HID info on the USB. I'll be implementing this from scratch, I cannot use any libraries or code not my own so it should be fun. :) A bonus feature will be making it into a software synth as well if I can manage it, where I take the instrument # / velocity info and mix together the loaded PCM instruments, sending it to a stereo output jack. 8-)

    I may pick your brain if I run into any technical difficulties. :^:

    Hahaha, that was my next idea, actually. Well, one of them. Lots of ideas floating around right now.

    I was going to hook a MIDI keyboard up, and map 10 keys to the guitar and bass, so you could play those two at the same time.

    The other idea which I'm drawing plans up for is an improved "drum mat" using IR sensors.

    But yeah, would you like a more technical write up then? Details on USB itself, which I've skipped over?

    Edit: Also, hi5 on real time systems! Whoo!

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited January 2009
    So You Want To Write A USB Client Stack

    Acknowledgements:
    * usb.org
    * BeyondLogic.org
    * Sample code for the LPC2144 courtesy of NXP and Keil

    Note: I will only be focussing on what is needed to get a minimally functioning USB stack to work as a USB HID device.

    So. Let's suppose you want to write your own USB stack for whatever reason. Perhaps you require a license free stack for development purposes. Perhaps you wish to get up close and personal with USB. Perhaps you are just plain awesome. Let's see what you'll need.

    First off, grab the USB 2.0 standard from usb.org itself. You can grab the USB 3.0 standard, but... hmmm.... well, given that nothing supports it at this stage, I wouldn't bother. I will refer to specific portions in the USB 2.0 standard by citing (USB-chapter.section.subsection-page_number). So for example, (USB-9.1.2-271) would refer to chapter 9.1.2 (bus enumeration), on the 271st page (according to the page counter in your PDF viewer, as opposed to the bottom corner of the page which is offset by 28 pages).

    Secondly, grab "USB in a Nutshell" from beyondlogic.org - or read it online there. It gives a nice overview of USB, and I'll end up repeating a lot of what they say in there because they do a pretty darned good job of summarising USB - and here's the important part - they also point out which parts of the USB standard a firmware developer should focus on.

    Now, I'm going to assume that you've given USB in a Nutshell at least a brief read and know that:
    * USB is a host controlled bus
    * Each client is given a unique address by the host
    * Each client that is attached has endpoints
    * Endpoints are what transmit or receive data

    I'm also going to start top-down from what data you should send to the actual nitty-gritty of how to send said data. USB in a Nutshell goes from bottom-up, so I hope that this contrast adds a different viewpoint on things.

    So let's get started!

    USB Device States - (USB-9.1-267)

    So, in general, if you look at the firmware for embedded devices, you've got a few states that you go through after you first power on. You initialise all your peripherials, set up all your variables, and then finally run your main programme in a loop. USB is similar.

    You're "Attached" when you're first plugged in (but have not yet received +5V). You're then "Powered" once you've received +5V and then given at least 100ms to initialise all that you need to before you are meant to be in the "Default" state. Going from Attached to Default is all just in your firmware and is basically you setting up your USB controller correctly to receive data.

    Next, the host will give you an address to move you into the "Addressed" state. Finally, the host will talk to you about your capabilities and if it recognises what you can do, it'll ask you to go into a certain configuration. Once that happens, you're in the "Configured" state. Moving from Default to Configured is like setting up your variables. Once you're Configured, it's equivalent to running your main programme.

    I'm going to ignore the "Suspend" state - but Suspend is actually no big deal.

    So what does this boil down to for the firmware designer?

    Things You Will Need
    * A variable to store your current state in (and possibly an enumeration or defines of the available states)
    * A variable to store your USB address
    * A variable to store your current configuration status

    Next time - how the host asks you to move from Default to Addressed, and Addressed to Configured.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    InfidelInfidel Heretic Registered User regular
    edited January 2009
    This project is just for university and personal use, so I don't really give a damn, but the reason I have to hijack someone's VID (either the official controllers or third party, same thing regardless) is because it hardcodes the "here are your only valid drum controllers" in the game correct? And I assume that Guitar Hero World Tour does the same checks to see if you're using Rock Band or World Tour controllers, just based on specific devices.

    If it actually does have a "hey I'm a Rock Band compatible drum controller" and you come across it, please post! <3

    The first stage of my project will be wiring up a MIDI port to the UART and trying to process the stream, if you don't mind me hijacking some of your thread I could keep you (and anyone else interested) up to date here. :)

    Infidel on
    OrokosPA.png
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited January 2009
    Infidel wrote: »
    This project is just for university and personal use, so I don't really give a damn, but the reason I have to hijack someone's VID (either the official controllers or third party, same thing regardless) is because it hardcodes the "here are your only valid drum controllers" in the game correct? And I assume that Guitar Hero World Tour does the same checks to see if you're using Rock Band or World Tour controllers, just based on specific devices.

    I think so. I think it might also be a combination of the VID and the product string though. When I had a random VID and my product string as "Harmonix Drumkit for Playstation3(R(" (yeah, I typo'd my product name wrong with that last bracket), RB thought it was a standard controller, but when I switched my VID/PID over to the ones for Harmonix's drum kit, it decided it was good enough.

    I guess I should play around to see if it's VID/PID or VID+product string or a combination of both.
    Infidel wrote: »
    If it actually does have a "hey I'm a Rock Band compatible drum controller" and you come across it, please post! <3

    The first stage of my project will be wiring up a MIDI port to the UART and trying to process the stream, if you don't mind me hijacking some of your thread I could keep you (and anyone else interested) up to date here. :)

    Haha, that'd be fine.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    tribuzztribuzz Registered User regular
    edited January 2009
    Most USB device is recognition is done with either the VID/PID of the device descriptor or the Class/subclass/protocol of the interface descriptor(s). Assuming that rock band controllers are HID devices, there are HID specific descriptors that tell the PS3 what the incoming data is. Mostly you'll just need to find out what data the guitar/drum supplies for this and copy it.

    tribuzz on
  • Options
    mcdermottmcdermott Registered User regular
    edited January 2009
    Haha, I remember those "is it me, or is this chip slightly warm? Maybe its just my imagin.. Argh! Argh! Burning my finger! Pull the plug!" moments.

    Hehe, oh yes. And then the inevitable, "Is it... is it okay? What went wrong? Does it still work?! Please tell me it still works."

    The real fun doesn't start until a week later, when it starts doing something funny and you can't figure out why, and after exhausting all troubleshooting options you're stuck wondering if it's from that one time you almost melted the fucking thing down.

    Especially when you're working with a surf-mount part, which isn't exactly easy to just swap out (assuming the money isn't an issue).

    Pain in the ass.


    Anyway, fascinating thread.

    mcdermott on
  • Options
    InfidelInfidel Heretic Registered User regular
    edited March 2009
    Update from my end!

    So I have made a circuit to interface the MIDI DIN-5 connector with my FPGA, I just take the TTL input on one of the pins and just designed a UART myself on the FPGA. Success! I have it driving a 7-segment display (4 hex digits) and some LEDs in a strip, showing the Note # and the Velocity (two digits each) when it receives a Note On message and showing the velocity as well on the LEDs (0 to 9 lights depending on how hard you hit it, and they decay of course like a normal meter)

    So now that I have the input/MIDI side done I need to sort out the USB. I'm working through the docs now and I'll have to figure out how to accomplish my firmware without a CPU which would have been a lot easier I think. :D After sorting out the issues I had with the FPGA I'm way more comfortable with developing for it now so I think I can pull it off.

    Infidel on
    OrokosPA.png
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited March 2009
    Infidel wrote: »
    Update from my end!

    So I have made a circuit to interface the MIDI DIN-5 connector with my FPGA, I just take the TTL input on one of the pins and just designed a UART myself on the FPGA. Success! I have it driving a 7-segment display (4 hex digits) and some LEDs in a strip, showing the Note # and the Velocity (two digits each) when it receives a Note On message and showing the velocity as well on the LEDs (0 to 9 lights depending on how hard you hit it, and they decay of course like a normal meter)

    So now that I have the input/MIDI side done I need to sort out the USB. I'm working through the docs now and I'll have to figure out how to accomplish my firmware without a CPU which would have been a lot easier I think. :D After sorting out the issues I had with the FPGA I'm way more comfortable with developing for it now so I think I can pull it off.

    Go you! Which FPGA are you using, just out of interest? I was going to recommend you use a softcore from opencores.org if you want a CPU, but I remembered you're not allowed to use libraries not your own.
    Hint: When trying to remember the name of opencores.org, Googling softcore is not necessarily what you want to do.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    InfidelInfidel Heretic Registered User regular
    edited March 2009
    rofl @ softcore googling

    Yeah, I'm using a Cyclone II for my actual project, we only got to use the AVR for assignments! D:

    I have to do all the synthesis and coding and development myself. I've used opencores.org to help me dive into designing for the damned thing but I can't straight up use anything especially if I don't actually understand it. I can't even use the NIOS II cpu softcore that comes factory with the Cyclone FPGA. :)

    It's been a lot of fun but dear god the debugging is painful. I had a random frame error in my UART problem that took me a while to sort out until I realized I had a small bug in my clock divider. :| If you have any tips on implementing a USB device in Verilog/FPGA style I'm all ears heh.

    Infidel on
    OrokosPA.png
  • Options
    ecco the dolphinecco the dolphin Registered User regular
    edited March 2009
    Infidel wrote: »
    rofl @ softcore googling

    Yeah, I'm using a Cyclone II for my actual project, we only got to use the AVR for assignments! D:

    I have to do all the synthesis and coding and development myself. I've used opencores.org to help me dive into designing for the damned thing but I can't straight up use anything especially if I don't actually understand it. I can't even use the NIOS II cpu softcore that comes factory with the Cyclone FPGA. :)

    It's been a lot of fun but dear god the debugging is painful. I had a random frame error in my UART problem that took me a while to sort out until I realized I had a small bug in my clock divider. :|

    Haha, I remember stuff like that. Hope you've at least got an oscilloscope with digital inputs - they're godsends, honestly.
    Infidel wrote: »
    If you have any tips on implementing a USB device in Verilog/FPGA style I'm all ears heh.

    I just checked - opencores has a few USB controllers under their "communication controller" category, it seems. Might be something to look at?

    Also, if you're familiar with Linux, use that as the USB host. The kernel logs provide useful debugging information when you connect a USB device in - e.g. tells you what address it's attempting to assign your USB device, what descriptors it thinks it's getting from your device - all sorts.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • Options
    InfidelInfidel Heretic Registered User regular
    edited March 2009
    I develop on Linux at university but I only have Windows machines at home right now. I'm sure there's a tool I can use that will give me some useful debug info though.

    I don't have an oscilloscope so that made things real fun. I could hijack one at school but again I don't have enough time there to develop, I need to do much of this from home.

    At least I have a multimeter! :P

    Infidel on
    OrokosPA.png
Sign In or Register to comment.