PIC (and other microcontroller) Use

[R.G.]

Here are my recommendations for gettting started with microcontrollers
1. Use PICs. At one time Microchips PICs were the only choice. They have been so successful that there are now competitors. The competitors such as Atmel AVR and others are similar to PICs, and if you have a compelling reason to do so, you can choose one of those. But PICs have been available so long that there are lots of freely available programs, fragments, and advice on PICs. There are many types of PICS from small (six pin SMD devices!) to large (40 pin DIP and 64 pin QFP). The most useful will be the 8 pin and 18 pin types. I judget the availability of previous software and help more important than trivial programming.
2. Use flash memory devices. These can be reprogrammed up to about 10K times without a special UV eraser.
3. Use a high level language like C or Basic. There are free versions of these languages for PICs. You can learn assembly language for a PIC easily (there are only 35 instructions to learn) but unless you're familiar with assembly language already, you'll likely give it up because you don't understand assembly language, not because you can't do the work.
4. Buy a programmer. I use the kitsrus programmer for flash parts, #128. The following links show what they are and where to get them.
http://kitsrus.com/upuc.html#k128
http://kitsrus.com/sales.html#usa
They're available relatively cheaply, $30 to $40 as a kit. You'll also want a breadboard to set up your test circuits before committing them to PCB - but that's always a good idea.
You could use one of the essentially zero cost flash programmers that you make up with parts connected to a parallel port, but I found that I wanted to spend my time on PICs, not wondering if my programmer worked.
5. As part of my professional work I recently had to buy the Pic Basic Pro compiler, which is an incredibly good starting point. However, it's about $250, and you may not want to jump that high to get started. For me, it was much less costly to buy it than spend the extra time on assembly coding. There are low cost and free languages available, but I needed a pro-style tool.

As to what you can do with a PIC.
- anything that requires digital signals and many things that require analog signals. There are limits, primarily on how fast you can process instructions. The PIC processes instructions as fast as 5 MIPs - million instructions per second - for the 20MHz parts. Substantially any digital function you can think of to do in an effect can be done with a PIC.

There's an old joke in the programming world that once you've thought of what to do, the rest is A Simple Matter Of Programming. The joke is that the programming may be mind-bendingly confusing and difficult to do, but it is - sarcastically- only a simple matter of programming. The PIC is like that. Can it do any footswitching you can think of? Sure. All's you gots to do is figure out how to tell it what to do. But there is no question that it can. I try to limit my remarks about what can or should be done with PICs to places where I have essentially already figoured out the program flow and algorithms in my head before replying, and I've done enough of this to know that pretty well.

Some good applications for PICs
- any kind of switching controls you can think of
- reading a pot (the PIC does this directly on a single pin) and doing something digital as a result
- reading an analog voltage (on an internal A to D in some PICs) and doing something digital or PWM analog or DAC as a result
- generating signals by PWM or shift register over the audio range or lower, as in LFOs; one interesting application is as a top octave generator for even tempered audio notes.
- generating AM or FM radio signals below the main clock frequency directly from the PIC
- generating really random noise via feedback shift register techniques. An 8 pin PIC can easily generate pseudorandom audio signals which sound like white noise and which will not repeat for centuries

Some poor applications for PICs
- direct use to do digital delay lines directly; PICs are not quite fast enough for this. Yet. They need external hardware to do it.
- general DSP applications

Elegance in PIC design consists in using just the PIC, with as little external hardware as possible, ideally not even resistors and caps. The fundamental limitations in PICs are the number of pins available and the instruction speed.

[troubledtom]

yes!!!!!!!!!!!!!!!
      THANX RG!.
        but we all need to agree on ................ the stuff we are gonna use. i mean the same stuff so we can help one another.
        peace,
             - tom

[R.G.]

Maybe.

Actually, any programmer will do. I use the Kitsrus programmer because it's simple - plug it into the USB port and fire it up. No power supplies, no special stuff for the printer port.

The real place you want to do exactly the same is the device chosen, the pinout definitions, and the PIC code, either in HLL or assembler.

If you really want to use exactly the same stuff, get the kitsrus programmer, and everybody agree on a language, then all go get that.

[amz-fx]

There is a PIC Basic compiler that allows up to 100 lines of code with the demo version, which should be plenty to program pedal controllers...  not suited for DSP unless you are doing 8 bits at low sample rates.

Somehow I got started with the Atmel chips so I'm much more fluent in the AVR assembly than with the PICs, though I suppose they are similar...

regards, Jack

[Peter Snowberg]

I mostly agree, but I'll add my 2 cents too.

Re:
(1) I've burned lots of PICs with lots of types of code and I would not send people towards PICs today as a starting point. If you want control programs that are written in BASIC, products like the Stamp series from Parallax (which are PIC based) give better performance, easier programming, and more flexibility than trying to write BASIC which is complied into PIC assembly. The limitations in the PIC architecture can play havoc with higher level languages. Today I really feel that the Atmel AVR is far superior because it has a much better assembly language which is optimized for C compilers, the range of parts is great (from 8 to 100 pins), the speed is fantastic, memory is plentiful, and you don't have to think about the things that stop most people from programming PICs in assembly like lots of bank switching (a nightmare). I know PICs have a debugging interface on them now and I have not used it, but I'm quite in love with JTAG on the ATmega chips.

(2) I agree 100%. Flash devices are the only way to go.

(3) For beginners, BASIC and C are great ways to go, but I prefer Assembly over C for ease of building simple apps (assuming the use of libraries for complex functions built-in to C). If you have a nice assembly language available, I think BASIC and then assembly is a good way to go. The chips speak assembly, so I think speaking to them in their native tongue really helps to understand what's going on. Maybe it's not an easier way, but you end up knowing the important stuff faster which I feel is better in the long run. PIC assembly is one of the last things I would recommend to anybody starting out. There are macros in some assemblers that give you a better set to work with, but it's still one of my least favorite things to code. Ubicom sells a PIC clone on steroids called the SX28. They also have a larger one. These chips are spec'ed at 50MHz with four times the cycle efficiency of a PIC so you can get 50 MIPS out of them. I've overclocked them to in excess of 75MHz without a glitch. The SX28 also has a couple of op-code changes that make coding quite a bit better, but it's still an early generation PIC on steroids.

(4) Buy a programmer. I agree 100%. Buy tools, build projects. It's often hard enough to debug a project but if you can't count on your tools you can get some big headaches. At the very least your first programmer for any new chip should be a solid device.

(5) Pro quality tools can make the difference between project success and failure. While free might sound like lower cost, I've had to deal with compiler bugs in the past and spent days wondering why my code didn't work. Ouch.


There are lots of micros available today and most of them can tackle most jobs. Knowing microcontroller assembly is somewhat like knowing a spoken language. Each specific chip is more like a dialect than a different language. The same could be said for BASIC and C too.

I hope we see more uC projects as time goes on.

[troubledtom]

i'm going for C, WISH ME LUCK!
              - tom

[R.G.]

I have to admit to some of my own predillections here.
- I mostly don't care what instruction set is involved with a processor. In my first career, I programmed everything from a single-instruction processor (yes, it exists, it's even kind of cool when you get into it) through the 6502, 6800, 68000, 8080, 8051, 80xxx, P-machine, and PICs in assembly. I wrote HLL in C, Basic, Pascal, Fortran, Java, APL (try that one if you think you're pretty snappy as a programmer), an Forth. I tend to write programs in language- and processor-free pseudocode, then transliterate it into whatever is at hand. This means that I'm terribly slow on the first program in a new language, but that the programs work as soon as I figure out the quirks of this new whatsit. After you've programmed for a while, you figure out that writing down clearly every single step you're going to do and where the data goes, and how it's ordered is 99% of programming. The rest is just figuring out how the locals talk.
-  I pick uCs for the I/O structure, availability and cost. I would be the last person to argue that PIC architecture is the best. I don't think there IS a best, and if there were, chances are that it would not be available from Mouser and Digikey for under $2.50. Atmel's AVR is good. 8051 has tons of support. ARM Thumb is good. Shoot, some of the Moto Power architecture controllers are GREAT from the standpoint of performance and I/O. You just can't buy them in less than 1000 unit lots. I used to sit and snicker in meetings where the Chief Architects would argue about instruction set efficiency. It was very much like the medieval theosophical discussions about the number of angels that could dance on the head of a pin. Go with what you can make work and actually get your hands on. If you can get AVRs cheaply, quickly and easily, that overshadows any hyper efficiency of another instruction set.
- The presumption I make is that I will never be pushing a uC to its limits. Hence, any processor is likely to do. This is not true for DSP processors, but not many people here are going into DSP until it gets much more available and easy to breadboard. I guess that puts me in the uC-as-super-555 camp. It's all of that and more. And look how successful the 555 was and is.

[Dean Hazelwanter]

I've just gotten back into a PIC project I put on the back burner last April. When they pull me out of the bell-tower wearing a clown suit and carrying a high-powered rifle, the only thing I'll be babbling repeatedly is 'A Simple Matter Of Programming'!

[Dave_B]

I can second the cheap programmer thing.  I built one last fall that worked great for a short time then suddenly got flakey.  Then Peter got me thinking about AVR's.  Now I just watch TV.

[David]

I vote for PICS.  There's a huge code base out there already.  MPLAB for assembly is free.  IC-PROG for burning PICS is free.  The JAL programming language is free, and XCBASIC is free.

[The Tone God]

Then Peter got me thinking about AVR's.  Now I just watch TV.

Yeah Peter will do that to you. Anyways sounds like a plan for the rest of today. Hey Futurama!

I vote for PICS.  There's a huge code base out there already.  MPLAB for assembly is free.  IC-PROG for burning PICS is free.  The JAL programming language is free, and XCBASIC is free.

AVRStudio for assembly and as IDE front end to GCC and has a programmer built in is free. GCC has been ported to AVR which is free. There a several other compilers that have either free or limited versions for non-commercial use.

Andrew

[Peter Snowberg]

My apologies Dave. I never want to push people to watch TV.... Oh wait.... Trailer Park Boys is on.... never mind.

Maybe it was just the stuff I was doing, but I've spent a lot of time up against the limitations of the PIC. I even had one product that used two PICs operating in parallel because there wasn't enough EPROM in one part.

There are a lot of good chips out there and for some task, just about every one has a place where it shines.

[Dave_B]

We used to get Trailer Park Boys here in the states, and that was on the long list.    

Truth be told, my last PIC experience killed my interest for a while.  I had a glitch in the code that would set off the watch dog.  Before I could find it, the programmer issues started in.  I plan to get back into it soon, but I need to figure out a better way.  I'm assuming an ICD-type programmer would make life a lot easier?

[R.G.]

I've spent a lot of time up against the limitations of the PIC. I even had one product that used two PICs operating in parallel because there wasn't enough EPROM in one part.

That would definitely color your thinking.

My approach is this: for effects work other than DSP, if you are even approaching the limits of a chip's processing speed, program capacity, or precision, you are using the wrong chip.

This is not true for professional stuff, where the economics are different. Out there in the real world, fighting to the death over nanoseconds is what the game is all about. Here in the sheltered, protected, world of electronics as it was 30 years ago, we have the luxury of just going out and getting a bigger horse.

I find that when I'm trying to do something right at the limits that I'm usually doing it the hard way. F'rinstance - there's a world of elegance in using only one PIC to do the entire job. But if you treat a PIC (in the generic sense of "any microcontroller") as a special function IC, then you can often use one PIC as a specialized peripheral for another one. So if you had a situation where doing a PWM output ate too much of the processor to leave enough to do the other functions, use one PIC as solely a smart PWM chip, fed I2C instructions by a master PIC that's doing the other stuff. It costs you an extra $2-$3 for a second PIC, and the programming gets easy without real time constraints and isochronous code.

Another example: One PIC can do a top octave generator, but there's only enough speed to do it two octaves down from the true top octave. Solution: Only generate half the notes with one PIC, and use a second PIC to generate the rest.

Truth be told, my last PIC experience killed my interest for a while.  I had a glitch in the code that would set off the watch dog.

I believe watchdog timers to be the work of the devil.

[Dave_B]

I had a glitch in the code that would set off the watch dog.

I believe watchdog timers to be the work of the devil.

And apparently the devil likes music in 16.23/4 time since that's about what it did to my circuit.   

[The Tone God]

Hi, I'm Andrew and I used to be a PIC user. I used for a long time because they were pretty much the only game in town at the time with the best price/feature ratio. After all the time with them I got frustrated with them and stop using all together. I got back into it with AVRs which have been nothing but a pleasure to use. Thats not to say PICs don't have some advantages over other platforms because they do. They bottom line is that you should use whatever tool is right for you and the job.

Watchdog timers are fine as long as you deal with them after you finish the core code so you know how long to set the thing for and figure out where to put the reset.

Boy if this is the best uC flame war we can come up with then things are pretty bad or is that good ?

What do you think Ricky ?



I don't know Andrew. You showed me this computer thing telling me its really cool and stuff but I don't understands much with all the transapitors and homes' law and stuff. All I do understand when reading is pots which even I know with my grade ten that you don't say with the "S" which goes to show that everybody here with all your books reading smarts and the thinking with the electro-nonics and the things around the...boltage...you know what screw it. I'm going to go get drunk and eat chicken fingers. Wanna come Bubs ?



Sound good Ricky. I don't know anything about dogs or watchdogs or whatever the hell you guys are talking about. I only know about kitty cats.

Andrew

[Peter Snowberg]

Opinions are good, but flame wars we don't need. It would be a boring world if we all thought the same.

What uC would Bubbles use for most projects? Was he into bubble memory in the 70s?



The guy on the left is Rush's Alex Lifeson.

I find that when I'm trying to do something right at the limits that I'm usually doing it the hard way. F'rinstance - there's a world of elegance in using only one PIC to do the entire job. But if you treat a PIC (in the generic sense of "any microcontroller") as a special function IC, then you can often use one PIC as a specialized peripheral for another one. So if you had a situation where doing a PWM output ate too much of the processor to leave enough to do the other functions, use one PIC as solely a smart PWM chip, fed I2C instructions by a master PIC that's doing the other stuff. It costs you an extra $2-$3 for a second PIC, and the programming gets easy without real time constraints and isochronous code.

I did a phone line switching system for the luxury boxes at Madison Square Garden about 10 years ago that did just that for I/O expansion. I've also done I2C slave chips for stepper motors, quadrature encoders, parallel I/O, and AC lamp dimmers. It works amazingly well and I2C is much more flexible than CAN when you only need to go a few feet. The early PICs didn't have all the interrupt niceties of present day chips so going parallel made for much easier code. I guess the same thing still applies to the smaller PICs.

I was working on networked, embedded I/O nodes in the early 90s. We sold a couple hundred a month to the Japanese market but fewer domestically because of a total lack of advertising combined with being a bit odd-ball. These boxes spoke Apple's AppleTalk protocols and networked with transformer isolated RS-485. That allowed programs like Director and Hypercard to serve as a font end. The protocol stack, the I/O routines, and the surrounding mess left exactly one byte and zero pins free. 

[R.G.]

I was working on networked, embedded I/O nodes in the early 90s... The protocol stack, the I/O routines, and the surrounding mess left exactly one byte and zero pins free.

That's either
(a) very elegant
-or-
(b) a recipe for *both* ulcers and migraines
-or-
(c) (b) when you're doing it and (a) when it's done.

[Dave_B]

I don't know enough about Amtel chips to have a preference, but I'm not a fan of the PIC page-switching architecture.  At times it's temped me to jump ship. 

As far as flame wars, from what I gather, a lot of us are posting on old PC's with dial-up connections.  I don't think we're candidates for that sort of thing. 

[Peter Snowberg]

I was working on networked, embedded I/O nodes in the early 90s... The protocol stack, the I/O routines, and the surrounding mess left exactly one byte and zero pins free.

That's either
(a) very elegant
-or-
(b) a recipe for *both* ulcers and migraines
-or-
(c) (b) when you're doing it and (a) when it's done.

C   

(it was all just a simple matter of programming  )