It is my fate to become involved with the PIC32 line.  Mostly because that's
where the USB host functions are, and USB is some sort of unstoppable curse
upon the land.  I ordered the PIC32 starter kit, and the USB starter kit,
and now I must somehow rise to the competency level I have with my PIC16 and
PIC18 parts.  This isn't really the right time to sit down with a cup of
coffee and the PIC32MX Family Data Sheet (646 pages) or maybe just the
PIC32MX Family Reference Manual (1138 pages).  Better to get my feet wet and
learn the landscape first.

I've been a happy CCS user for 9 years and now I must learn the Microchip
way of C.  CCS doesn't have a PIC32 compiler (yet?).  Also throw in an
upgrade to some recent MPLAB for good measure. Figure out how to install the
USB connection to these eval boards--this time-- (do I install the driver
first, or do I plug in the device first?  The answer likes to change and
it's hard to know if you've got the latest information--or even if it
matters anymore).

I'm looking for some connectedness with the 32-bit pioneers among us.  I
will be looking at the Microchip forum, too, but somehow that just doesn't
have the same feel as the good old PICList.  I've got a lot of experience
under my belt, and I'd have to say about 50% of it came from reading the
list.  So maybe I'll post a tidbit or two as I run across them.

So here's my startle moment for the day.  The starter kit comes with a few
sample programs. I spotted one, which was older, no longer used, apparently,
but included nonetheless.  It's a 3-button 3-lamp "Simon" game.  So I
brought that one up, and was poking around with the debugger. There's a
switch() statement that looks at _gameState...kind of obvious what's going
on there...but the switch statement only had like 2 cases.  So most of the
time it would just do nothing there.  In the outer loop were statements to
debounce the buttons, and then to set some flags based on the switches.  The
only other line is for that switch statement.  Where's the rest of the
logic??  I went back to the source code and did some searching on variables
and function names and in particular, all the enumerated states that
_gameState could have.  And then I found the rest of the code.

Inside the interrupt handler.

Granted, there weren't any delay loops in there, although there's a lot of
fiddling with the timer.  So I suppose the code executes OK and then gets
out...but still...we just try not to do stuff like that.  I suppose they
give projects like this to the new kids, and well, it works, doesn't it?
(I'm not sure. One of the reasons for poking around is to figure out how the
game is supposed to flow).

Anyway, if I suddenly pop in with a question, this might provide some
background.

Barry
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist