Generic startup

[R.G.]

1. Decide what you are going to program. It makes little actual difference about the uP, architectures, etc. What matters is the stuff surrounding the chip - the available programmers, languages, and pre-programmed snippets of code that you don't personally have to invent. Easy availability of the chips, the languages, and code snippets are far more valuable than whether the register-to-register moves are one or seventeen clock cycles.
2. Assemble all your junk. Get a chip, get a programmer, get a language. You like assembler? Get an assembler. You like basic? C? Get them. Having a chip without these things is almost as much use as a bicycle with no wheels.
3. Learn some programming concepts. Some of you work in the programming field, so this is easy. For those of you who have not programmed before, get a book on introduction to programming. Programming a computer is much like telling an idiot savant how to tie shoes - i.e. first, "These are shoes. These are your feet..."
4. When you have assembled all the paraphernalia, learn to light an LED. Use a breadboard, put the chip in the breadboard, set up the power supply on the breadboard, etc. Put the LED on one output pin. Now go write a program that blinks the LED. Program the chip, verify that the LED blinks. It's almost impossible to overstate how important being able to demonstrate that you can make a pin flip states on a uC is.

I programmed up the automatic biasing of output tubes in the Workhorse series of amps largely by using LED blinking as an indicator that I had the programming going. That includes reading currents, reading switches, analog biasing of the grids, closed loop controls. {We took the auto biasing out, not because it didn't work, but because we made manual biasing so easy that it didn't make sense to put the uC in.}

A blinking LED can tell you things like:
Yes, the pin is active.
Yes, I can read what that switch is doing.
Yes, I can make the LED blink at different rates depending on the pot position.
Yes, I can make the LED blink at different rates depending on what the analog voltage I read is.
Yes, I can blink the LED if the input I read is over X frequency.
Yes, I can tell the program reached ...this... point in operation because the LED came on.
It just goes on.

[aron]

Please tell me that the enviroments include a debugger. Why people would make compilers without debuggers is a mystery to me....

ok, printf....

[The Tone God]

Please tell me that the enviroments include a debugger. Why people would make compilers without debuggers is a mystery to me....

There is software emulation that you can load and test your code for debugging purposes. To do hardware debugging you either need more and sometimes fairly more expensive hardware or the other option is to learn to put various indicators as you go along. This will probably be in the second lesson I do.

Everything else R.G. has mentioned is pretty much what I was planning on doing anyways.

Andrew

[R.G.]

Please tell me that the enviroments include a debugger. Why people would make compilers without debuggers is a mystery to me....

Oh, yeah, the simulation environments include a debugger. That's OK as far as it goes.

What the debuggers can't do is tell you if you are really driving the outside hardware correctly. F'rinstance, I used a dual digital pot to set the bias for the autobiasing. I could tell easily enough in the debugger that I was toggling the pins and that the right words were going out, but I could not verify that the pot voltage was actually changing. It was far simpler to write a very dumb program that simply ramped the digipots up and down, calling a digipot output subroutine to do the actual talking to the pots and using a simple variable being incremented on a timer inside the uC. That way I can ensure that the subroutine that does the digipot output works because if it does, the pots' voltages do this nice stepped triangle wave. And if it does that, then I can quit worrying about the subroutine's function and concentrate on the innards of the program.

Come to think of it, that's a much more fundamental programming technique for such I/O intensive and intertwined programs as one does in effects.

(a) Define **every** I/O action as a subroutine, either callable or inline as a macro
(b) Test every I/O subroutine/macro with trivial calling programs to prove correctness of the I/O stuff.
(c) Have **every** test of an I/O sub/mac include an LED blink for an iteration (or ten, or 1K so humans can see it). That cuts down external debugging hardware to a DVM and your eyes. You can probably dispense with a scope.

Once all that works, go play in the control program sandbox. When the cp is right in the debugger and the I/O's already been done, you stand a chance of having it all work.

This prevents the problem of sitting there having the uC doing ...nothing... and not knowing if it's hung, just taking a long time, or off in some dark corner of memory counting its toes in octal.

Did I ever tell you how I developed these techniques?


No, don't ask   

[bioroids]

That's a clever way of getting things to work, R.G. thanks!

I'm starting with the emulators until I can buy the programmer and chips.

Miguel

[Transmogrifox]

I am on RG's boat.  I have been able to determine all kinds of stupid airheaded "oh I forgot to do that", to "oh....my logic is bad.  It is doing exactly what I told it to do, and what I told it to do is not what I want it to do" type mistakes in programming.  EDIT:  That is, by just turning LED's on and off at certain points in the program and watching to see if they behave as expected.

In addition, I love the MPLAB simulator.  It has saved me hours of hair-pulling time.  The debugger helps me learn things without having to spend a ton of time browsing the datasheet for this little caveat...for instance, I could not use certain pins for inputs when in PWM mode.  When my chip didn't work, and the LED's didn't blink as they should, and I knew I was using the same code (that worked previous to enabling PWM), then I knew what to watch in MPLAB.    I don't think I could have done without the simulator when writing an RS-232 protocol and maintained sanity.  The scope was a life saver, too, since I was using an RC oscillator instead of a Crystal resonator, so I had to be able to tune the frequency.  Watching the registers and observing what happened at each instruction told me something about the chip's operation and some caveats.  Unfortunately, uC hardware doesn't always let you have your cake and eat it.