Ancient
Who still remembers the good ol’ days of the PlayStation One?
I certainly do. It has been the only game console (the venerable gameboy aside) that I’ve ever owned, and back in the day, I used to play on it a lot. I never got any other consoles afterward though, but that’s mostly because I’m not too much of a gamer anyway (an occasional game I enjoy, but not much more than that) and I don’t want to spend a fortune on a console, another fortune on accessories, another fortune on games, and even more fortunes if you want to be able to play said games online. Especially not if all of those fortunes are not going to be used more than once or twice a week, at best.
Anyway, on a little side project, this week I took an old PSX controller for something different. What else than play PlayStation games can one do with a PSX controller, you might ask? Well, hook it up to a microcontroller and use it to control whatever you want, of course!
The something else to control is kind of missing in this picture, but you get the idea. There’s a PlayStation controller hooked up to a PIC18F2520 (its a PIC18F2520 because I happened to have it at hand, and it’s running at 40 MHz – not because that much is needed to read a few buttons, but because all my delay routines and template configuration files are based on that and I was too lazy to adjust everything). There’s a few LEDs for testing purposes, RS232 connection which sens the state of the controller out to my PC, and my trusty USB logic analyzer (which is awesomely useful in projects like this).
Interfacing the PSX controller isn’t all that difficult. There are nine wires – two for power to the controller (red and black for +5V and GND, respectively), two for power to the vibration motors (various sources state 7-9 V, but they run on 5 V just as well), and five wires for communication (one for bits sent to the host, one for bits sent to the controller, clock, attention (like the chip select in SPI), and an acknowledge signal from the controller). The clock runs at 250 KHz (500 KHz for the newer PS2 controllers, though the protocol for those is identical). During a transmission the attention line is made low by the host, data is clocked in at the rising edge of the clock signal, and after each byte the controller pulls the acknowledge line low for a short period – in other words, fairly simple stuff. The only thing that is kind of annoying is that it is a synchronous protocol (i.e. data is sent to and received from the controller at the same time), but otherwise, it’s not hard.
The PIC asks the controller ‘how are you?’ about 50 times a second, and the controller responds with 6 bytes of useful data – 2 bytes for all of the buttons (there are exactly 16 buttons, so that’s convenient) and 2 for each of the analog sticks. The PIC compares the data to an internal buffer to detect if something has changed, and if so, the output on the serial console is updated. It poops out the status of all buttons, with some VT100 terminal control codes to clear the screen and make the output look pretty. On powerup, there is even a pretty screen with the classic “Press Start” message (in blinking text, woohoo!).
Unfortunately that is about as far as it goes right now. If I had more of these controllers and a little graphical LCD, you could do fun things with it though! (I need to keep that in mind 
)
Furthermore, I am also starting to play a bit with ARM microcontrollers. Got an evaluation copy of CrossWorks for ARM (which is an awesome piece of software – expensive, but awesome!), and a bunch of LPC2103/2138 chips (LQFP packages… not a lot of fun, but quite doable with a bit of practice). These chips are an awesome platform for a lot of things, thanks to their speed and memory size, which would put any PIC or AVR to shame, and with a much more efficient instruction set as well. But more on that later.
Playing (part 3)
Wheee! Things are starting to take shape on my little PIC project here
The code to control a character LCD is progressing nicely… it can now automatically align text on the screen and stuff like that. It’s also handling custom characters quite well. The nice thing with these screens is that you can display most ASCII characters on them, but also a number of customized characters (which are displayed by using the ASCII values that are normally non-printable characters, eg 0×00, 0×01, 0×02, etcetera).
Obviously, since I’m working in C the 0×00 one can be a bit of a problem at times, because in C it’s also the string termination character (but I can still send a 0×00 manually to the screen… so no big deal).
Also, in addition to powering the LCD, I also have a flashing LED once again! Only this time, it’s flashing at a pretty accurate 1 second interval, and is doing so using timers and interrupts. Once every 50 000 microseconds, an interrupt tells a variable to go up by one; once it reaches 25, we know that a second has passed 
(If you’re wondering what the hell an interrupt is: when certain events happen, such as a timer reaching its maximum value or the state of a pin changing, that may generate an interrupt, at which point the processor jumps to a certain location in the program to handle it. Basically it’s calling the processor’s attention away from whatever it’s doing to handle something that is urgent and which probably should be handled right now. Afterwards it’ll get back to what it was doing before the interrupt happened. It’s like you’re walking in the grocery store and your phone rings: you stop to pick it up, and when you’re done you continue shopping. It’s the same principle really (you’re the processor, and your phone just generated an interrupt to get your attention to the fact that someone’s calling you). Your PC also does this, but you don’t notice it normally.)
That may seem a bit elaborate, and well, erm, it is elaborate, really. It takes a good amount of code, as well as a bunch of calculations to make sure that the timer runs properly. But I’m learning the PIC to tell what time it is, and I’m just using the flashing LED to make it indicate to me that a second has passed. For some reason that remains unexplained sprintf() doesn’t seem to be working (and it’s a bigass function too… you’ll probably never notice it on a PC, but on a PIC the size of it is significant), so it’s going to be difficult making it actually show the time. But I’ll find a way
Playing (part 2)
As I mentioned in my post ‘Playing’, debugging PIC software is quite often not nearly as easy as debugging PC based software. My (current ) lack of experience with both PICs and C didn’t help a lot either. Though I have managed quite easily to pass the ‘hello world’ equivalent of blinking a LED on and off, the next step – actually displaying ‘Hello World!’ on an LCD – was less easy.
I had the basic code for writing instructions, and the actual instructions, to the LCD correct. It’s a standard 16×2 character LCD with a HD44780-compatible controller (you can control one of those using the parallel port on a PC actually). I have a great little simulation tool which has a module to simulate the display, but of course I couldn’t take the easy path for my actual hardware implementation.
My actual hardware implementation was a bit more tricky, because I wasn’t connecting the LCD directly to the PIC as the simulator assumes. I’m using a shift register for the data lines, which greatly reduces the number of pins needed on the PIC, which is good news because it doesn’t have a whole lot of I/O pins. I had a couple things wrong in sending data out of the shift register. (Basically, a shift register is a simple chip that accepts a serial input (2 lines) and translates that to a parallel output (8 lines).) It may have included sending the bits in the wrong order.
Obviously, because the instructions that did arrive at the LCD arrived in reverse order, they didn’t mean a whole lot and the most interesting thing I was able to do was blink the backlight on and off.
But a bunch of LEDs and some added delays allowed me to see exactly what was going on, and now finally, I have a display that shows ‘Hello World!’ 
I’ll take a picture later.
(And, further debugging should be relatively easy, because I now have a way to let the PIC tell me what it’s doing ).
And another thing… There’s a new menu item on the top, ‘PIC programming’. I’m writing a load of PIC-related stuff which could possibly be interesting to someone. Partially because even at this point, where there isn’t much actual content in it, it’s already gotten me up at least 5 ranks on WhatPulse (I’m 803rd of the world as I type this ^^). For the moment it remains inaccessible to anyone but me, but some day…
Playing
Lately I have, largely out of a lack of better things to spend time on, been playing around with PICs a bit. Since you are probably asking questions such as ‘what the hell is a PIC?’, or ‘why does it sound like a Dutch word for penis?’, here’s a short explanation. A PIC is a small chip that is essentially a tiny computer. It has a CPU, memory to store a program in, RAM, and usually a number of peripherals like an UART (a module to communicate on an RS-232 line), USB, timers, EEPROM memory for more long-term storage of data (such as configuration), and so on. They vary from the extremely small PIC10F200, which has only 4 pins that can be used for I/O (say, blinking a LED) to large 32-bit chips that run at 80 MHz or more and have more than 100 pins. The most popular series however are the PIC16, and more recently, the PIC18 series.
As for why it sounds like a Dutch word for penis, I have no idea. PIC could stand for Programmable Integrated Circuit, Peripheral Interface Controller, or a whole lot of similar acronyms (but according to Microchip, it doesn’t really mean anything).
Developing stuff on a PIC is a whole lot different than normally developing software. For starters, you’re not just developing software, but the hardware as well. This means that at least a basic knowledge of electronics is invaluable, and with that comes things like knowing which parts or ICs may be useful for your project and probably at some point you’ll want to be able of designing your own printed circuit board (and making those/having them made for you). Second, it’s great to have software on your PC, but you’d probably rather have the software on the PIC – so you need a programmer. A programmer is a device that does exactly that – it ‘uploads’ software to the PIC. There are lots of programmers on the market, but what I’ve been using so far is the Wisp648 sold by voti.nl, combined with Bumblebee as PC-side software.
The fun part however is the actual programming for the PIC. Microchip offers some free development tools (MPLAB), but I never liked that, and you’re going to be stuck to using assembly. Writing a program in assembly isn’t as bad as it sounds – especially if you have programming experience and the program remains small – but on a larger chip, say, a PIC18F4550, assembly quickly becomes a huge, unmanagable mess. That is when you will realize that a higher programming language would be great, and for this type of thing, C is probably the best choice. There are a number of C compilers for PICs on the market, but most are staggeringly expensive, and come with a lot of proprietary stuff, so you’ll be stuck with that particular package for the remainder of your natural life. There is, however, a great alternative: SDCC, the Small Device C Compiler. It supports all the most common PIC16/PIC18 devices, but there’s a great lack of documentation and source code, so you’ll have to figure out a lot on your own.
Not that figuring out stuff on your own is uncommon: developing hardware (and software) can be pretty much a trial-and-error process.
Installing SDCC is pretty simple, both for Linux and Windows (yes, it works on more than one platform! hooray!). To work, SDCC will also need the gputils package, which is again pretty straight forward to install. I do strongly suggest that you enable the option to include the binaries in the PATH variable in Windows, it makes life easier. After installation, you’ll probably be thinking ‘okay, what next?’ and that’s were it gets funny.
Since you’re doing stuff for an embedded device, this version of C is not something you can really compare to what you use to write software for your PC. Sure, the syntax is identical, and most of the standard C libraries are implemented (printf, math, stdio, …) but that’s about it. Half of the code you write will be directly accessing registers on the PIC (since they control all functions of the device). Half of the time you’ll be looking up stuff in the datasheet (which is usually over 400 pages) and the other half you’ll be wondering how the heck you are going to debug your code – after all it’s running on a small, isolated chip and getting anything at all on your computer screen isn’t quite as easy as with ‘regular’ software. Then there’s the limitations of the device – you probably have a lot of functionality you’d like to include, and only so much I/O pints to work with, and only a limited amount of code memory and RAM. Especially when using C, it’s easy to run out of any of those. Also, everything you’re doing is quite low-level code – you’re directly telling the chip which pins are doing what, handling interrupts, and so on – no fancy multithreading or whatever.
For debugging/testing purposes, I’ve also been playing with this tool. It simulates a PIC processor on your PC and behaves (almost) identical to it. You can see what each register and memory locations (or ‘general-purpose register’) is doing as your program runs, how much time everything is taking, and so on. Of course you can never rely 100% on a simulation (after all, on the PIC there are loads of variables that the simulation tool does not include) but it is extremely useful. Unfortunately it’s not a free tool, but the basic home-use version is only € 29 and it seems to be the best PIC simulator I’ve seen so far (and also by far the most user-friendly, which is great because I want to be developing the software, not spending 3 weeks learning to use the simulation tool).
Altogether there’s an amazingly steep learning curve, but that only makes the satisfaction all the greater when you’ve got your first ‘blink a LED’ (the PIC equivalent of ‘hello world’) working. And, of course, there’s a huge number of useful things you can do.
Note: as said before, there is an amazing lack of documentation and source code for this kind of stuff. Also for the electronics part: my father works with electronics, so I had already picked up a thing or two, but if you have zero knowledge on this kind of thing, you’re mostly on your own. Depending on how much time I have and whether I feel like it, I might be writing some tutorials and sample code/libraries for use with SDCC, which will probably show up in the menu bar on the right (but when something goes online, it’ll be posted here too, of course ).