“So, I found a display that I like, but it has to be hot-bar soldered, and I don’t think I’m set up to do that,” I said to Workplace Mentor.  “You’re looking at this the wrong way,” he replied.  “Choose the main processor first, then pick something that matches the right interface, and then concern yourself with how to attach it.  When you’re prototyping, it’s usually easy to roll around issues like how you’ll connect something.”  I hadn’t thought of that, and it sent me back to my desk.

I have been spending some of my free time trying to source parts for a new project.  I want to learn how to, from the ground up, build a platform and write a BSP from it.  This is something very much apart from what I do at work.  Generally speaking, I enter the process after we’ve already retained a vendor and our electrical engineers have had their turn, demanding the necessary hardware to support our features and so forth.  At that point, the evaluation boards have been cranked out and a sample BSP for a number of features exist.  Often, when I get involved in very low level work, it’s because the sample BSP presumed the existence of a chip that our hardware designers replaced in secret.

So, yeah…I could go out and buy an evaluation board for some ARM processor, complete with a rich boot loader and even a BSP and some sample apps.  I could.  Sparkfun has tons of them.  If I did, though, I wouldn’t really learn anything new.  Sure, I’d have some shiny pictures to put up here, but I’m still just following in someone else’s footsteps, and I do that at my job.

What Workplace Mentor said, though, sent me back to the drawing board a bit.  It wasn’t so much specifically a concern over interface versus hot bar soldering as much as it was a realization that I wasn’t thinking about all the various gating concerns.  I probably still am not, but it’s at least led me to settle in on some decisions.

First off, I flat out need to settle on a processor.  At this point, I think I’m going to go with an LPC2148.  I’ve come to this decision looking at a number of factors.  First off, it’s an ARM processor so I can leverage an existing stack of tools and have some expectation of how they’re going to work.  One of my frustrations with the SX and with the SX-Key tools was their poor reliability, and in the early phases of design here, I will very much be flying with one propellor (that one being a mix of wits and low-level tools) and I’d like to know that that one will serve me.

The next reason to choose an LPC2148 is that it’s used heavily in a number of SparkFun kits.  This means there’s a community of experimenters and hobbyists built around it.  It means that I can find sample schematics.  It means that I can ask questions and get input.  It means that I can look at sample code for boot loaders.  I may not want to follow in someone else’s footsteps, but it helps to have some signposts on the road.  I can get that with this particular model.  Yes, I could have gotten this with a number of different products.  I could have chosen an Atmel.  Well, I have an Atmel.  It’s on my Arduino.  I can hack at that if I want.  In fact, an Atmel might have been easier since I could get a DIP package for it.  But, I’d have had fewer pins and thus less flexibility.  So, I am choosing something that will challenge me where putting together hardware is concerned but which also has a community and which is a bit more, in my estimation, robust.

I could have chosen something with an embedded LCD controller if I wanted to head that way.  An LPC2478 would have been a good choice.  It has a similar architecture so I’d have gotten many of the similar benefits of familiar tools and similar code and maybe even a common community.  I’ve passed on this idea because I suspect it will be more complex to find parts necessary for prototyping.  At this point, I lack the requisite experience to prototype things without getting a solderless breadboard or at least a wire wrap board involved, and that means I need to be able to break out the leads of the processor readily.  The LPC2148 has an LQFP64 package, and I’ve not had much trouble finding breakout boards for it (such as this one).  The pickings for an LQFP208 package, however, have been much more slim.

What does all this mean for my overall project?  Specifically, what does it mean for driving a display?  Well, right now, I haven’t finished sourcing an appropriate display.  I do have some interesting leads, though.  One of them is this TFT QVGA LCD from Embedded Artists.  I like it because it largely because it’s already on a breakout board I can use for prototyping.  It otherwise comes with the usual features from a number of displays with an embedded controller– parallel and serial interface and a few other small bells and whistles.  Another interesting choice I’ve found is a funny little display controller called a PICASO.  This controller will handle the minutae of display, has an 8-frame buffer in QVGA mode, can take commands (including drawing commands) over standard serial connections, and even can interface a memory card via SPI.  It does a lot on only a few lines, and I like that, especially since the alternative is tying up several lines from the LPC2148 to handle display control.  On the other hand, it seems more geared to VGA display and I am not, at the present time, quite sure how it handles a small LCD TFT display.  The maker of the PICASO has an evaluation board with an LCD on it, but they have not responded to my questions regarding how they’ve hooked it up.

I’ve come to realize, though, that I have a ways to go before I MUST be concerned with this.  First, it’d be good to just get a prototype that can be programmed has a reset button, and can give me some debugging output via serial.  That alone is a huge leap in the right direction.

So, I guess that’s it for now.  Looks like I have some parts and new tools to buy.

My wife, the ever-wonderful Amy Hale, gave me a wonderful Christmas gift.  I now have an Arduino Duemilanove, an XPort shield kit, and a LED art kit.  Of course, the first thing I’ve considered is doing some web data-driven light art, so I just need to figure out what data I want to capture and visualize.  That’s the beauty of Arduino systems…everything is simple, componentized, and ready to use.  The high level language used to program the platform, Processing, really leaves you asking questions about the application of the platform instead of the implementation.  I don’t believe it’s the best way in the world to learn about the design of an embedded system, but for getting something done, it’s a system which is hard to beat.

A note to prospective gift buyers, though.  The XPort shield kit is just the platform for an Ethernet module but it is not an Ethernet module on its own.  The supplier may be offering the module as part of an extended kit, but the build instructions at Make suggest buying an XPort which will cost an additional $30 or so (after shipping, etc).  So, just remember this if you want to make the gift all-inclusive.

The other great thing is that now I have an Arduino, which I was actually planning on using to make a touch-screen prototype at work.  Again, the focus on componentization and a high-level programming environment makes this a good platform for quick prototyping.  When you can buy a TouchShield, drop it on the shield connector, and grab an extra Processing library and start looking at your prototype application…well, that’s a rapid prototyping dream.

I’ve been doing more part sourcing research on my completely made-from-scratch platform.  I’ll post about that separately.

While I do have some exercises left to do before I give my final review of the XGameStation Game Console Design Starter Kit, I’m also trying to look ahead to a future project.  There are a few reasons for this.  The first is the obvious one– it’s because I can.  Another reason, however, is because the XGS was mostly a process of getting my feet wet in prototyping, working with circuits, etc.  It’s important in a self-education process to first get the feeling that you’re not going to blow it big time.  Lacking a classroom environment, I basically picked something that would give me a structured process to learning how to read data sheets, work with circuits, program a microcontroller, etc.  Now that I feel more comfortable, I think I can start taking on projects that are a little more complex and a little more interesting.

There’s also the other factor that the XGS isn’t the easiest platform to program for.  Not only is it necessary to hand-count clock cycles to ensure you keep generating the NTSC signal correctly, but the SX has a memory architecture I find cringe-inducing.  The limitations on calls, the paging system…it makes the entire process more arcane than I think it needs to be.  Adding to this is the difficulty of producing color, which requires careful timing to get any given color.  The XGS Pico lacks the color helper hardware of the XGS Micro.

So, I’m looking ahead to the next fish to fry.  I guess I’m a product of my past in mobile devices, but I am fairly interested in something with a nice little LCD or OLED display.  I’d like an SD card interface, too.  USB would be handy.  For UI, maybe a touch screen and a few buttons.  Just a nice “screwing around” platform.

What’s interesting is that I have a few options for part sourcing on this.  The first and most obvious is to purchase an Arduino and the associated TouchShield.  This gets me off the ground in virtually no time and it also gives me a chance to play around with a very popular hardware platform.  The Processing language is also an interesting way to work in an high-level language when you’re coding for a microcontroller.  The downside, however, is that I’m not sure I’ll be learning all that much.  It seems like everything is pretty much done for me at that point, from the bootloader to the parts sourcing for the display shield.

At the other end, there is the choice of completely rolling my own from scratch.  This would mean selecting a microcontroller that I like (most importantly, something with in-system programming, sufficient I/O pins, and an instruction set I like), getting its programmer circuit set up, plopping down some USB and SD card support, and bringing on a touch screen part.  I’m fairly okay with the idea of doing that, but I get the feeling that going this route is going to incur too much of a learning curve issue.  Many of the desired parts are only available as SMT, and I don’t have tools or experience for that (yet).  On top of that, I’d probably need a TON of breakout boards to get this mocked up on a breadboard, because I don’t know what other prototyping tools I’d have at my disposal.  Not impossible, yes, but if I wander around in the woods too much then this blog will get very boring very quickly.

The middle-of-the-road idea is to get a prototyping board like this one from SparkFun.  This has a lot of advantages.  It goes ahead and takes care of a number of SMT and PCB creation concerns I have at the moment, gives me a nice through-hole prototyping area from which to work, and by the time I get things working with it, I’d probably be in a better position about rolling my own about SMT parts and my own PCB designs.  At least, that’s a hope.  Of course, I’d have more fun writing my own boot code, but hey…the eval boards here at work all come with sample bootloaders!

But, I still want to have an Arduino laying around, so why not do both?  I can get things humming along by sketching it out with an Arduino platform, then apply what I’ve learned in designs of my own?  It seems as feasible an idea as any, and with so many quick and easy things available for the Arduino platform, why not?

As I previously mentioned, I skipped Lesson 8.  It is generally reckless to solder something to a PCB without having first tried it out on a breadboard, but since most of the lessons already confirmed to me that the SX, the 7-segment LED driver, the resistor ladders, etc all work as advertised, I felt I didn’t want to keep doing it just to get more breadboard practice.

I’m not new to soldering.  I’ve got a half-completed 2m amateur radio transceiver in my closet (note to self: finish the thing already).  So, in light of that, this wasn’t a challenging lesson.  For that, I’m grateful.  As I’ve said before, when you’re learning to fly, it’s less important to know the mechanics of taking off as it is to know how to get out of a stall and spin.  Knowing a few things about how to solder, remove solder, test things, etc, was very handy.  For the most part, I didn’t get too many problems.  One of the “seats” in a DIP socket came out and the wires for the 9V battery broke repeatedly.  Other than that, it was smooth sailing.

So, below are some pictures of my completed XGS Pico Edition and it running a demo on my LCD TV.  Two things that are important to note– the LCD TV warning, while not as serious, should be followed.  When the Racer City game logic kicks in, my TV gets fussy and starts adding color noise; a standard CRT does not.  Second, the XGS PE uses the SX28 and the XGS ME (the PE’s “predecessor”) uses the SX52, which has more memory and more registers.  Most of the downloadable demos on the XGameStation site, therefore, require portage to work.

Some resisors for the 7-segment missing...TO RADIO SHACK!

My first run of the XGS PE

All in all, I’m pleased to have everything on a PCB.  I feel like I’ve learned a lot at this point, and now I’ll get to enjoy a few labs on programming this platform.  I’ll probably start tonight.

In the meantime, the parts of my brain dedicated to learning about hardware design can start scoping out a future project.

Regardless of what I mention in the previous post, it turns out my problems had nothing to do with the LCD screen I bought.  For reasons that are not entirely clear, the version of the SX-Key IDE which I have seems to not like the SX-Key that came in my kit.  It will program the SX just fine, but it doesn’t seem to generate a proper clock signal for it on the first try.  After trying the NTSC demo programs on a CRT TV, I became frustrated and decided to poke around with the manual clock control feature of the SX-Key IDE.  Well, merely engaging this feature seemed to cause the SX-Key to reset the SX and issue the correct clock signal.  I was then able to confirm correctness on my little LCD TV at home.

It’s still not a good idea to use an LCD screen apparently.  Some of them are just fussy, while older CRT screens will forgive you a bit more.

Anyway, the demos are pretty cool.  One is a monochrome test pattern, one is a color test pattern, and one is a scrolling star field that immediately made me go “Oooh!  I am building a game console!”  This is also the first time I’ve confirmed the correctness of a resistor ladder on a breadboard, which makes me feel good for my breadboarding skills.

This lesson definitely makes it worth it.  It also is a great reminder of using the XGameStation forums as part of the kit.  While I would really like to see Nurve add more material to the kit regarding ways to debug a circuit which is going wrong, they do a good job of tracking the forums and being patient with rookie questions and mistakes.

I’d encourage anyone having trouble with this lesson to follow the discussion thread I’d started over there.  It might give you some interesting ideas on how to debug an R2R ladder or how to poke about with the somewhat temperamental SX-Key.

Lesson 8 involves putting the entire XGameStation Pico on a breadboard.  I’m going to skip this and proceed to soldering it to the PCB.  I don’t feel I need the extra breadboard practice, and while it is a risk to solder down a circuit that hasn’t been tried out on a breadboard, I’m willing to take that risk.

I guess you could consider this a pre-review of lesson 7.  I can be pretty verbose, so I’ll give you the summary first.  Do not use this kit or the XGS Pico with anything but a CRT TV. Now, for the story…

The story begins with me realizing that lesson 7 covers generating NTSC signals with software.  To say that I’ve been salivating over giving these lab exercises a whirl is putting it mildly.  Anyone who knows me knows that I live for the moment when I make a device come to life, and for me, blinking some lights just doesn’t cut it.  So, this is the big one, Elizabeth!

I try to live a fairly compact life.  I own a single television set, which serves double-duty as both the family TV and the monitor for my PC.  I bought this TV with money from my Google internship back in 2005, and even today I don’t have that kind of “walkin’ around money”, so I’d be daft beyond daft to plug my homebrew circuit into my only TV and computer monitor.  Even if it’s designed safely, why risk it?  So, I popped down to Target to get the tiniest TV I could find.  This was a nice little 7″ LCD television.  I was pretty excited.  Not only will this serve as a good test screen, but maybe I can put it in an innocuous place in the apartment and find a good use for it.  $180 later, I strapped the thing to my bike and took it home.

Today, I woke up gleefully and after some much-needed late morning sloth, I wired up the NTSC signal generation circuit as described in the Game Console Design Kit materials.  At first, I got nothing, then figured out that I hadn’t set up the TV right (which I tested with my Playstation 2) and also discovered I’d had the “brightness” potentiometer dialed so high that there wasn’t much signal to detect.  After fixing those two things, I ended up with something like what you see in this video.  It would seem the red and blue “fuzz” is just general noise, which you’d expect from a breadboard circuit like this one.  The kicker, however, is the big white bars in the middle.

I played around with it all afternoon, desperately trying to figure out what I did wrong.  It turns out that nothing is wrong with my circuit.  What I did wrong is buy an LCD TV to test this out on.  It would seem that LCD TVs do not have good tolerances when it comes to compliance to the NTSC signal standard, and I’m running headlong into a problem caused by a fussy TV and software which cuts corners in its NTSC signal generation.  You can read all about it, including a diagnosis of the issue and a handy trick for debugging a resistor ladder, at this thread on the XGameStation forums.

Originally, I felt the hacker in me rise to the challenge of cleaning up the NTSC monochrome demo.  Then it dawned on me– EVERY XGameStation program generates an NTSC signal in software, meaning that every last one of them is likely broken, too.  While there’s also the upside in that I’d be getting the fun of rolling my own everything, I feel that this would rob me of time to devote to additional topics and immediately divorce me from an existing corpus of knowledge and experience.  I’m trying to broaden my horizons, and while I might enjoy the fun academic challenge of fixing the NTSC mono demo, I’d be taking the long way around the lake to continue that way forever.

So, the long and the short?  Don’t use an LCD TV with your kit. Go get an old CRT TV and use it.  You’ll thank yourself.   Some LCD TVs are ok, so if you have one that works, bully for you.  However, some are very uptight about NTSC compliance and being even a couple of clocks off is enough to ruin it.