How I got started with the PIC
How I got started with the PIC
But all the simpler plans I tried had glitches and their analog circuitry was simply not very elegant. I also kept running into magazine articles, Web sites and Usenet postings describing ESCs based on a microprocessor.
The PIC microcontroller from Arizona Microchip has been around for a while, but the idea of getting involved with it was intimidating. I also have the "handicap" of using Macs and various Unix systems, trying to avoid PCs whenever I can; but nearly all software and hardware for programming those critters was available for DOS and Windows. Finally, ever since I had to do some assembly language projects during my undergraduate years, I've despised all kinds of low-level programming.
When Microchip came out with a decently priced ($7 apiece) electrically eraseable part, the 16C84 (now superceded by an almost identical 16F84), I ordered a few from Jameco. Now I had to have a way to program them.
I finally found a programmer which could be used with a Macintosh: the HyperCard stack written by Francis Deck, and the hardware he designed. The stack is nice but somewhat limited; fortunately, the hardware was claimed to work with a more mature programmer/simulator, Kevin Coble's MacPic.
But there was a chicken-and-egg situation: the hardware uses a 16C84 to control the programming of another PIC! So how do I bootstrap myself and put Deck's code into the controller chip? I could order one from MacSciTech, but remember, I'm a cheapskate, and a very impatient one at that. I rigged a minimal PC serial port programmer (something looking like this design by Jens Madsen) on a prototyping board, took it to a PC in the office, and dumped the hex code provided in Francis's stack into the master 16C84. At home I put together Deck's programmer circuit, again on a solderless breadboard (with a few dirty tricks to avoid using the relatively hard to find and expensive LM10 voltage reference); after a few minutes of fiddling with the Mac serial port lines which I haven't properly identified, it worked! I used the spider-like prototype for a few months; I recently made a variant of Deck's programmer on a neatly wired PCB and I'm very happy with it.
Added in May 2004: Kevin Coble is rewriting MacPIC from scratch - now it's an OS X only program, called MacrocASM.
I'm a little afraid to try to use Deck's programmer with the newer generation of PIC chips, such as the very nice 16F675. Besides, I soon won't have any Macs around with the old modem/printer serial port, so it's time to go USB. I just ordered the PICKit 1 from Microchip. It's supposed to work with MacrocASM, and also with some generic GNU tools. See this page [link rot!] for some more info. Specifically, search for Orion's usb_pickit tool for programming via the USB port. It compiles and works on OS X, but I've had problems using it on a PowerBook. There is also tweaked version which claims to be compatible with v.2 board firmware and to fix some of the USB problems. I'll describe my experiences with this setup soon. And here is another interesting OS X PIC page, and one more [dead!].
By the way, I tried rigging a ZIF socket that would connect to the PICkit 1's socket, and let me also program the older chips such as the 16F84, since I still have a couple of those. No go: the board simply refuses to do it unless you stick in one of the officially supported devices such as the 12f629, 12f675, etc. Oh, well... I still use that ZIF adapter all the time, it is gentler on the chips than the PICkit socket would be.
I've been using gpasm and the usb_pickit command line tool on OS X, with sometimes puzzling results. Unfortunately usb_pickit doesn't provide any useful feedback as to whether the hex upload succeeded. I dug up a copy of the unsupported OS X "Pickit 1" tool on Microchip's webpage (do an advanced search matching all words Pickit "mac os" on their main site), and it was showing "programming failed" about 3 times out of 4 or even worse. I tried a new 12f629 part, thinking that maybe the first one was bad; it successfully programmed a few times, but again started showing the same failures. Google seems to indicate that some of those messages may be bogus. A truly reliable programmer SW/HW combination for OS X is still sorely needed. Even when programming works as it should, debugging PIC code can be difficult; when programming also randomly fails, it's a real nightmare.
Hold the presses! [April 2005] A few hours after I wrote the above I discovered that going to "Board Control" and unchecking "Target Power" has increased my success ratio from low teens to about 100%. So if you are having problems with the Microchip Pickit 1 application, try that and see if it helps. If I hadn't wasted three days dicking around with it and tearing my last hairs out, I'd be a truly happy man now.
Another annoying thing was that the "Open hexfile" dialog kept opening the top level directory, while my code is usually buried several levels down. I fired up Apple's Interface Builder (part of Xcode tools), and modified the application so that the defalt for the "Target Power" checkbox is off, and the default for the file open dialog is the last directory used. Now I'm truly happy.
A useful site with OS X resources: http://www.1710.co.uk/picosx/
[These are older notes, I pretty much gave up on those solutions since I got Pickit 1 to work well]
I tried Coble's new MacrocASM v. 0.91, but it just wouldn't start on my OS 10.3! I don't know what's up with that. I installed it as a regular user first (no errors), then as a sudoer (no errors), and it simply doesn't start, or rather exits immediately and silently. Plus the lack of some major features, like #defines, is discouraging. I hope Kevin will find the time and energy to get to the point where the latest versions of MacPIC were.
In desperation I tried MPLAB on a Win 2K laptop. After several weird problems with installation, I got it to assemble and simulate decently well, but the simulator is in my opinion kludgey even compared to MacPIC's somewhat buggy one. And there are some really silly other "features", e.g. I couldn't find any way to disable case sensitivity as a default behavior. e.e. cummings would find that unacceptable, and i do too. By the way, MPLAB also has no clue about linebreaks other than Windoze "\r\n". So if you try to assemble anything which originated on Unix or a Mac, you will likely get a message "line 2: END expected" or some such. ;-) I also often wish all source code consisted of just one line.
And even though the MPLAB assembler and simulator are somewhat usable, the programmer kept giving me a "device mismatch" or some such, even though it has the Pickit 1 board as one of the recognized programmers, and the device I selected in MPLAB was certainly the same as the chip sitting in the socket. So forget that as a "nice and clean" solution.
gpsim would help, but I didn't have much luck there either. I don't want to clutter my older PowerBook with all the fink stuff, so I decided to install gpsim on a Solaris 7 machine in the office. After a couple of fairly simple tweaks I got the whole thing to compile and start. But after that it was just coredumping when I tried pretty much any command, whether GUI or command line. I tried to run it under gdb to see what's going on, and the debugger dumped core! That was a first for me. Even the file open dialog doesn't work right (as the developers seem to admit themselves; come on, guys, this isn't an 0.1alpha version anymore!)
Bugs, bugs, bugs everywhere... Very frustrating. Besides, the gpsim homepage seems to say that it still doesn't support the newer 12f629 and friends.
Modern radio-control equipment for models uses signals which are essentially digital (pulse width modulation with a leisurely 50 Hz rate), so a microcontroller typically running at 4 MHz or so can easily keep up with the information and do a lot of extra processing between the frames. Most receivers are powered by about 5V, which is exactly what the 16C84 likes most. In short, the PIC is perfect in this situation.
One of my favorite non-R/C gadgets is the somewhat wacky idea which shows what you can do with a bit of imagination and a PIC: Bob Blick's "propeller clock".
I'm now making a simple darkroom/enlarger timer
(trivial with a microcontroller!) - I'll try to make plans, photos
and software available
here when they are at a less embarrassing stage. I'm also thinking
about a Morse decoder (plug it into a S/W radio speaker jack,
tune in to a CW broadcast and get the letters on a computer
screen!), and a three- or four-motor helicopter-like gizmo, with
a tilt switch and a PIC controlling the individual motors' speed
to make the whole thing hover stably in the air (hmmm, might make
for some interesting moments during debugging!) Added 3/1/2008 EJB:
as usual,
Added 11/25/2000 EJB: the Morse decoder is already out there, I've seen it recently on one of the PIC sites, but I can't find it now. The helicopter is probably never going to get built.
If you are into astrophotography and want a good but simple circuit for driving your telescope motor, again the PIC (or similar) is perfect! Look at Michael Covington's Alcor. It uses a PIC to generate a tri-level signal (approximation of the sine wave), which is then converted with a transformer into a 110V AC with precisely controlled frequency.
One small Alcor modification which you may want to consider is an idea stolen from one of the radio control electronic throttle designs; namely, instead of connecting the FETs directly to the PIC, use optocouplers to do it -- something like in this circuit. This addresses two problems mentioned by Michael: first, it ought to eliminate the chance of inductive spikes getting back to the PIC and causing mischief. Second, by using the 12V supply on the FET side of the optocouplers, it should be possible to use any plain-vanilla MOSFETs such as the IRF510, rather than the special logic level ones. Of course using dual optocouplers as in my example would require using one or two I/O pins which are used for something else in the original design, and changing the code a little. I haven't experimented with it yet.
My newest creation is a beeping counter which uses the new 12F629 PIC.
[10/20/2006] A box with 3 AAA batteries, a PIC, a transistor and a pushbutton switch, which powers three red LEDs and resistors installed next to the setting circles of my old Celestron C8. The PIC sleeps most of the time. When the button is pushed, the LEDs gradually turn on, stay on for 10 seconds, then turn off. Since I happened to use a 12F675, one A/D input measures the voltage on the LED output relative to the power supply; since the drop across the transistor and the LEDs is constant, one can sense (just barely) whether the supply is in the 4.5 V range (alkalines) or 3.6 V (rechargeables). The LED brightness is controlled by varying the duty cycle, and adjusted to compensate for the different voltage. Code too trivial to post.
[11/15/2006] Being a time freak, I'm trying to make a good frequency reference based on the Rockwell/Navman/Connexant Jupiter 12 GPS board, along the lines of this project (and several variations that followed). The problem is that the GPS module does not have a simple indication of a lock on satellites. The only way to detect a 3D lock is to look for the NMEA message $GPGSA,A,3,... (or its binary equivalent, if there is one). That's what W1AUV implemented (see e.g. these documents), and I followed suit without the UART. A lowly 12F629 is listening to the 4800 baud NMEA serial stream and, using a variant of Nigel Goodwin's (?) serial receive routine, lights up a bi-color LED. Blinking red means no satellites, red means satellite(s) aquired, orange - 2D lock, green - 3D lock. I find the internal 4 MHz oscillator more than stable enough for slow speed serial communications.
[12/16/2006] Finally figured out (with help from Google and lots of people out there, e.g. Myke Predko) how to write to some 1x16 LCD displays I had lying around. Maybe this snippet will help you if you are also scratching your head. Note: 1x16 is pretty limiting; e.g. you can't display 20:17:42 12/16/2006 on it...
[1/7/2007] Many people, myself included, have a tough time keeping track of time when they talk on HF radio, and they are supposed to give their callsign every 10 minutes. It isn't as much of a problem on local FM repeaters, because the habit is to ID every one or two "go-arounds". I found a perfect fridge notes clip at a dollar store (five for a dollar) that is easy to rig as a 10 minute timer. A stroke of genius was to use the metal spring as a negative rail, connecting the battery minus with the circuitry on the top half ;-) Here's another picture.
To keep the battery going for as long as possible, I used the internal oscillator (not very precise) and the watchdog timer (even less precise). It's a bit of a challenge to keep all branches of the code equally long. The gizmo blinks once every ten seconds to tell you it's alive, and twice every minute. After 8 minutes is blinks three times every ten seconds, and after 9 minutes it's three times every five seconds to grab your attention. When 13 minutes have elapsed, it goes to sleep, until you press the reset button again. The blinks of the LED are actually composed of very short pulses lasting about 0.3 sec total. With pulses of roughly 40% duty cycle and a 47 ohm current limiting resistor the LED is quite bright even off of a 3V button cell.
Eric Behr's home page
