So, feels just a little bit like converting religions or something, but I’ve started looking into other kinds of microcontrollers for practical reasons as well as to just generally expand what sits in my prototyping sketchpad. I’ve been curious about the Parallax Propeller, which has a multi-processor (they call them “Cogs”) core and can do video and audio gymnastics. It uses its own proprietary language called “Spin” which is pretty legible if you’ve done any high level programming. Assembly is also an option. The idea of having a small “microcontroller” that has built in multi-processor capabilities feels a bit over-blown, but it’s actually fairly liberating in the design phase. Suddenly, projects start to look like parallel tasks that can be designed with object-oriented sensibilities in mind. All of the “task switching” (cog switching) is handled automatically. Timing and so forth is fairly static so it’s possible to predict precisely how often tasks will get run. The Propeller will also run wickedly fast — way faster than an Atmel 8-bit microcontroller. Normally, speed hasn’t been an issue for projects, but it’s nice to have some overhead — up to 80 MHz in this case (versus 20 MHz for the Atmel, which is more then enough for most things, but the lickity-split clock makes doing embedded video projects possible.
Anyway, this seemed like a good possible fit for the PSX project because I need to simultaneously read a joystick and service polling requests from the console. I probably _could_ do both of these tasks with an Atmel microcontroller running at 20 MHz, interrogating the controller in between the console’s polling. Experience thus far has led me to think that this may not be the easiest thing to do, even sequentially. I’ve tried just servicing the console using the built-in SPI hardware in an Atmel 8-bit microcontroller and the timing is a bit flakey. Perhaps someone with a little more expertise in these things could take this on.
[ad#ad-1]
In the meantime, I went for a few extra cylinders and some more octane, which works better than well-enough.
I found some code that Micah Dowty put together for a Playstation project called Unicone. He had some code there in the midst of that project that was easily adapted to my weird PSX controller-that-gets-tired project.. Works like a charm.
I can specify the data that’ll go across the wire very simply, as a pointer to a buffer of data and Dowty’s object takes care of all the rough-stuff communication to the console. I can even specify what kind of controller I’m emulating, if I want. What’s left is to create an object that polls the real controller, makes some decisions about how “tired” it should be and changes the analog control stick values based on that tiredness and places this data in the buffer. Because the Propeller’s “Cogs” can share data, this should be pretty easy..
This is a trace of communication when I use the code below. The buffer is sent across just as it is, and Dowty’s object is smart enough to send it as if it were a simple PSX analog joystick N.B. the first two bytes after 0xFF, 0x73, 0x5A pre-amble are the button settings, as a 16 bit word, followed by four bytes representing the analog joystick positions. In the DAT section of the code at the very bottom of the listing below, this is exactly what I want sent. Simple.
