Possibly the most important, and most overlooked, aspect of any embedded software shop (including board bringup and BSP development) is the software tool chain.  It’s hard to imagine that we live in an age when the availability of processing power has grown to such phenomenal ends yet people continue to use a tool chain barely updated since its invention in the 1980s.  In fact, a friend of mine (let’s call him Code Monster) who develops for a major game console company, has patents on nothing more than software tools.  We both agree a life spent making better embedded software engineering tools would be a life that hasn’t been wasted.

At work, we essentially use a variant on the “not since the 1980s” technology.  Most of the engineers use a text editor that provides text coloring and some searching, then switch over to Platform Builder for flashing and debugging.  Debugging is basically a mix of logging over Ethernet and a Microsoft-built system for injecting debug breaks and doing stack and memory analysis.  In short, it’s your standard debugger.  Now, granted, we could be using a more integrated system through Visual Studio, but we opt not to because it gives us a bit more control over the build process.

In fact, I understand the need for control like that, and that pushes most engineers to almost worship a minimal tool system, even if tools would make them more productive.  I do not, however, think it’s necessary to get control only through giving up productivity, and I’m trying to reflect that choice in my own tool stack at home.

In another life, I was a Java developer, and probably the most powerful tool for any Java developer, outside of Java itself (which is its own tool stack), is Eclipse.  I remember when I switched to Eclipse.  I was easily doing my work in half the time.  Its incredible powers to check my code without a recompile, place compiler errors in the IDE so code could be reviewed quickly, and auto-hint valid expressions (with documentation) all changed my work life.  I was no longer hunting through docs to remember a parameter list, or trying to remember what returned what.  I was free to focus on the things requiring real intelligence — algorithm design and general subsystem architecture.  If my team had been large enough to need tools for source control, bug tracking, and code review, Eclipse could have handled it, too.  To this day, I still haven’t seen a more rich tool set, and I think everyone should try it for at least a few months.  My mantra at work has often been “I’d get so much done if my tools stopped getting in my way.”  I’ve rarely opined that about eclipse.

Of course, if you escalate all warnings to errors, C and C++ have a type strength close to Java (within reason), so you could a very similar tool stack, even for embedded development.  Others seem to have caught on, and Eclipse has, for a few years, been working to make inroads on C developers through the Eclipse CDT project.  I figured I’d give it a try over the weekend, especially since you can adapt this IDE to become an Arduino development environment and I would, in the near future, like to start poking around in its boot code.

Unfortunately, it seems every project I create hangs Eclipse shortly after it makes the project folder and some of its metadata.  I don’t know what’s wrong yet.  I have a bug in with the CDT team and I will see if it’s Vista related by trying to install CDT from my computer at work.  The problem must be something simple because they’d have never released code with such a basic feature broken.  Watch this space!

My darling wife raided Makershed for my Christmas gifts.  Among them was a fun little project called the USB7, a set of 6 7-segment displays that are powered by, and interface through, a USB port.  It’s powered by an ATMega, not unlike an Arduino.  The kit itself just requires solder assembly, so a soldering iron, needle-nose pliers, and diagonal cutters will suffice for tools.  The PCB is phenomenally easy to work with, with clear silk-screen markings to tell you which components go where and in what orientation.  It’s probably the most user-friendly kit board I’ve ever seen!

As for the final result?  It’s actually very handy.  Getting the drivers for it installed was a touch fussy, but after that, it exposes a simple COM port and you can interact with the project using a terminal program.  Six characters and a newline…that’s all it takes to update the display.

What’s great about the simple protocol is that it actually lets you do some fairly complex things.  For example, you can use whitespace characters to create simple scrolling animation effects.  You can also configure LCD Smartie to work with it, exposing interesting goings-on in your host machine to the display.  The board also has a header for reprogramming the microcontroller.  I’m certainly going to have fun mucking about in the code because the USB interactions appear to be 100% in software.

In short, it’s a fun way to spend a couple hours and you get a really neat component at the end.  I highly recommend it, especially for beginners.

Picture below is from the creator’s site.  My digital camera is AWOL at the moment.

The USB7 in red (mine's in green). It lights up way better than the picture suggests.

“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.

This set of labs represents the “front nine” of the XGameStation Game Console Starter Kit.  I’ve looked ahead a bit, though, and it’s also fair to say that this is the penultimate lesson on hardware.  Lessons 8 and 9 are about prototyping the entire console on a breadboard and assembling the PCB.  Lessons 10-12 are on programming for the console.  While I do look forward to learning more about coding from the Parallax SX28, as I have wanted to do more embedded systems programming in my spare time, I can’t help but feel that much is missing.  There’s a 30-pin expansion header, and no lab that will cover it.  I also find it sad that, despite how the lesson slides allude to cartridge-based systems, boot code to load and copy cartridges, etc, that the XGS Pico seems to not have the necessary hardware for it.  That is, the XGS Pico appears to require reprogramming to change games.  What’s more, the kit ships with a copy of “The Black Art of Video Game Console Design” which was written for and about the XGS Micro, which seems to include a lot of very interesting hardware (like a keyboard), making me feel like I’m not getting the full experience.

Anyway…none of this makes the kit bad.  It does, however.  Having missed opportunities to teach more doesn’t mean it’s failing to teach.

Lesson 6 is basically all about audio.  The three labs deal with making sound first through the old school methods of an oscillator and frequency divider and then with software synthesis techniques– pulse width modulation and pulse code modulation.  I actually put off this lesson for a little while because I wanted to buy a second breadboard to put the basic synthesizer on.  After placing my SX, I wanted to keep it there, and the first lab requires removing it.  A minor frustration, sure, but not insurmountable.  If nothing else, it’s good practice for wiring up the SX in a jiffy.

A basic 4-tone synthesizer.

In working on this lab project, I encountered a familiar problem with this kit– the labs are clear and straightforward but lack information that would be invaluable when troubleshooting.  In this case, when I first pressed a button, the speaker would “POP” but not make any apparent sound.  As I don’t own an oscilloscope and signals in the kilohertz range are too fast to see on a multimeter, I fumbled with some extra capacitors and made the 555 timer IC output a much slower (~1Hz) signal, then replaced the speaker with some LEDs and confirmed each button was providing a correct division of the source signal.  Once I knew that the circuit worked, I suspected the speaker, and I found that the tin on the wires (to prevent fraying) looked a little suspect and didn’t seem to fit in the breadboard well.  So, I clipped the ends off and used some alligator clips to attach the speaker to some new leads.  Pressing a button then gave different faint, almost inaudible buzzes.  I still suspect the circuit needs an amplifier in there somewhere, but I’m not trained enough to know.

Pulse width modulation circuit

The next lab features the Parallax SX28 again.  In this case, you’re working with Pulse Width Modulation (PWM) audio.  I may state this somewhat incorrectly, but essentially, the microcontroller can send square wave pulses of different widths, and as they go through a specially designed RC circuit before reaching the speaker, you gen non-square-wave sounds coming out.  It’s neat, though a touch limited, of course.  I found that this lab went off without a hitch, and I actually had a great deal of fun playing around with the sample code to generate sounds.

Pulse code modulation circuit

Finally, we come to the PCM audio lab.  PCM audio is the kit’s first treatment of an D/A converter.  That is, it’s a means of taking a number of digital outputs and converting them into a single analog value.  This is, of course, pretty critical in generating stuff like audio and video.  The lab itself has an ingenious presentation, offering you the chance to record some audio on your personal computer and play it back in 4-bit PCM on your nascent game console hobby kit.  To do this, you first record some audio using a special tool on your PC, then run it through a program provided by the kit’s creator.  This generates assembly code that can be programmed onto your SX.  I didn’t get the results I expected…the output audio was completely different from the input.  I suspect this may be my own fault, however, as I used a different version of the sound recording tool or perhaps just saved my file at the wrong sampling rate or something similar.  The lab does come with a ready-made program that contains recorded sound, but I didn’t think to try that until I was at work the next day.  My hat is at least off the the authors on including that program, though, as that’s a level of troubleshooting support that the rest of the projects should be at.

Hey!  It’s microcontroller “Hello World!”  How fun is that?  The labs for lesson 5 introduce the student (that’d be me in this case) to the fundamentals of working with a microcontroller.  That is, hooking it up to power and ground, building its programming circuit, and using its programmer tools to load a binary onto it.  There are three labs in this one; all are essentially flavors of the same fundamental lab.  The easiest one delivers you some blinkenlights (pictured below).  Another demonstrates use of the microcontroller as a seven-segment display driver.  The final one is a sort of crude one-dimension pixel game played with some LEDs and a pushbutton.

It’s great to finally feel like I’m getting to the meat of the project, that is, using a microcontroller to do things.  All in all, these lessons are fun and definitely produce an air of excitement.  There’s nothing quite as much fun as plugging in the programmer key and watching it all work.  I also can now definitely understand the author’s choice in microcontroller (the Parallax SX).  It’s very easy to program and its debugging is easy to control.  It’s a good beginner’s chip.

Of course, inevitably, I have to mention what seem like the road blocks to learning.  Both of these are minor complaints and should be taken as such.  The first is that I don’t think enough attention is paid to what could possibly go wrong.  Specifically, this is the first lab in the entire kit that both has a large number of “moving parts” and which also carries the warning about how easy it is to break some of them (like the SX Key).  This lesson could greatly benefit from some material on how to debug common problems safely.  In my case, I had a problem with my programmer circuit.  The result was that the SX Key Editor could sense the SX Key and would attempt to program the microcontroller, but would then die complaining “Could not create VPP”.  I knew the problem was with my programmer circuit, but the error didn’t give me much to go on and there wasn’t much help to be found through web searches, since most of the material I found was about having oscillators on the same line as the programmer pins for the microcontroller.  I eventually decided to dissect the programmer circuit, and finally found that I’d accidentally run a wire to the wrong pin.  Lesson learned, of course, but it would have been a huge help to even see the lab materials contain information about common errors you can encounter and what you should check.  It’s nice to feel like you’re not completely out in the weeds on your own.

My other complaint is that the author provides sample code sufficient for the student to finish the lab without digging into SX assembly at all.  In fact, it brushes it aside as unnecessary to have because there’s plenty of information out on the Web.  I understand the author’s perspectives and priorities here, but there’s plenty of information on basic circuit theory on the web, too, and that got 4 dedicated lessons, each with several labs in them.

I’m going out on a limb here, but I used to teach so I feel qualified being out here.  Teaching programming by dissection is a pedagogical failure.  It’s roughly the equivalent to learning Japanese by listening to the same handful of J-pop albums over and over again.  You learn the songs, sure, but you don’t know Japanese.  Seeing how a functioning program works isn’t the same as learning how to build one on your own, and it generates little more than a shallow parroting of known idioms.  Is sample code essential to a learn-at-home kit?  Absolutely.  What’s also essential, though, are extra labs without code that push the student through writing code on his/her own.

That said, the lesson achieves its effect, which is to get your feet wet with the microcontroller and drills into you the most important rule of working with a new microcontroller — do not do anything before you first get power, a programmer, and a blinking LED to work.  That’s “Hello world!” and it’s essential to do it every time.  If you don’t, you’re just asking for trouble.  I can deal with this.  It’s pretty common for me to write a “Hello world!” for every driver, service, and application, proving first that I at least have the boilerplate structure right.  It’s good to see someone teaching this responsibly.

Blinking LEDs from Lesson 5, Lab 1

Oh!  You’ll notice an extra LED in this photo, off to the left.  That’s not part of the lab at all.  Basically, the barrel connector I was sent is mildly defective and sometimes the wall wart doesn’t make enough contact, causing issues.  I got tired of constantly testing to see if I had a power supply problem, so I put an extra LED on to let me know that the power’s on.  I also added a simple switch so I could turn the power on and off without unplugging the wall wart.  It’d be nice to see these added to the labs in general.  It’s convenient and easier on your parts.