PIC programming, Cadillac style!

Posted on 2009-08-26 by M. Eric Carr

I’ve been working with the PIC18F4620, and am impressed by how easy it is to program, compared to the smaller PICs. I think I’m in love. Or at least in lust.

Here are some of the improvements from an embedded developer’s point of view, as contrasted to the (still very cool) 16F887.

32MHz max internal clock speed instead of 8MHz
This alone would be worth it — a PIC running at 8MIPS! It will go to 10MIPS with an external 10MHz clock, but 32MHz with no external parts needed is very cool. For us PIC16 afficionados, it’s like finding out that your new car can go 400km/hr on the freeway, legally, when the old one only did 100.

MULWF and MULLW instructions
You can tell the PIC16 programmers in the audience; they just started drooling. Hardware multiply — and not only that, but hardware multiply that executes in a single instruction cycle. I see a re-writing of some of my math libraries in the cards!

(almost) NO MORE PCLATH!
Ding, dong, the witch is (almost) dead! GOTOs and CALLs on PIC18s access the entire memory space directly. So, unless you’re doing a computed GOTO, you don’t have to worry anymore about the value of the high bits of the program counter. No more save-the-old-PCLATH-value-then-set-the-new-one-then-call-the-routine-then-return-then-restore-the-old-PCLATH business. Just GOTO or CALL your routine! And with PIC18s, you really don’t want to do computed GOTOs anyway, because now, you have…

TBLRD* and TBLWRT* instructions
PICs are Harvard architecture parts — meaning they have separate memory spaces for instructions and data. Before the PIC18s, there was no way to access the program memory at runtime — lookup tables were handled by a series of RETLW statements, whether specific or produced by the assembler from “dt” statements. The TBLRD* and TBLWRT* instructions allow PIC18s to read from and write to program memory. One use of this is to use the (relatively huge) 64kB of program space Flash memory (32 kWords, but addressable as bytes for data use). Large, verbose diagnostic messages can now be programmed relatively easily, with just a little more work than calling printf() from C.

ADDWFC
Add W to F with Carry. This is a bigger deal than it sounds. It will speed up the ADD32 and SUB32 libraries quite a bit, I think.

MOVFF instruction
With MOVFF (which takes two instruction cycles), you can copy a byte directly from one memory location to another, without going through the W register. This doesn’t always save time (although it’s always at least as fast as the old way), but not having to go through the W register can be very helpful.

Branch instructions
Branch-if-zero. Branch-if-not-zero. Branch-if-carry. Branch-if-not-carry. Branch-if-the-moon-is-in-the-seventh-house, for all I know. Well, maybe not that last, but PICs now have more branch statements than just BTFSS and BTFSC. This doesn’t quite rank up there with MULWF or TBLRD as far as I’m concerned, but I’m told it makes the compiler guys happy.

RRNCF and RLNCF
Rotates that don’t go through carry. Huh. And RRF/RLF are now RRCF/RLCF, just to break older code, I suppose.

TSTFSZ
Test F, Skip if Zero. Sounds like it could be useful.

DCFSNZ and INFSNZ
Now you can increment or decrement and skip if *not* zero. I’m confused now; this is backwards from how these are normally used. This smells like something a compiler would like to have available.

CPFSEQ/CPFSGT/CPFSLT
Compare F with W, Skip if equal, greater-than, or less-than. Hmm. Equality tests sound useful.

BTG
Bit Toggle, to go with BSF and BCF. Well, I guess it was the missing option…

DAW
Decimal Adjust W. Something to do with BCD math. Sounds possibly useful.

PUSH and POP
More to the point, there’s a real, honest-to-goodness stack now! This is a good thing. Low-range and mid-range 8-bit PICs have an 8-entry hardware stack. Except in simulation, it was anybody’s guess just how deep into the stack a program already was when a particular subroutine was called. This made for very conservative use of the CALL statement — and has prompted me more than once to do things with macros that I really shouldn’t have.

RCALL
Relative Call. This sounds like a segfault waiting to happen. I hope it’s not what I think it is…

Two NOP opcodes
To quote Bob from Frontier: First Encounters, “My, oh my, what happened here?”

RESET
There’s probably a legit reason for this, but it escapes me at the moment. Why not just GOTO 0x0000?

MOVLB

Move Literal to BSR? *looks up what BSR is, anyway*

LFSR
Move Literal to FSR? *looks up what FSR is, too*

OK, now for some of the drawbacks:
Nonhomogenous instruction size
In other words, some instructions are two words long, and others are one. This means that you can’t just cavalierly do a GOTO $-5 to jump back five instructions anymore, without at least thinking about which instructions are which. If you inadvertently point to a location in the middle of an instruction, the assembler will tell you. If it happens to line up on another one, it won’t know anything is wrong until you run it and it doesn’t work as intended. Best is to come up with a consistent labeling scheme and make liberal use of good, mnemonic labels, aiming the GOTOs at them instead of using relative jumps. This will also stop you from breaking the code when you add more lines in the middle of the loop, later. (Anyone else been bit by this one?)

They’re a bit more expensive
Waah. They’re worth it.

Posted in Coding, Digital, PIC Microcontrollers | Leave a comment

Paleotech, through the eyes of a Millenial…

Posted on 2009-08-13 by M. Eric Carr

What happens when you give a modern teenager a Walkman? You get some interesting insights about technology. It’s amazing how far technology has come — and a reminder that yes, there really is such a thing as paleotechnology. (For us children of the 70s, the fact that cassette tapes have two sides is completely intuitive. For someone seeing a Walkman for the first time, perhaps not.) For how many other forms of technology might we forget some of the nuances, or even some of the important things?

Fellow paleotechnology expert DOSquatch writes about the subtle yet extremely important art of troubleshooting. He definitely has a point. I would also add that it’s important to document technologies as they are developed, lest we end up having to reinvent them all over again to get them to work (or end up breaking them inadvertently).

Actually, the comparison between a Walkman and modern mp3 players is a good example of how technology is not only progressing, but accelerating. When my grandparents went on a trip to Japan and brought back one of the first electronic calculators, it was definitely new — but easily understood in a few minutes. When cassettes started to take over some of the role of record players*, they too were relatively easily understood. Increasingly, though, the capabilities of new devices are breaking down old barriers and requiring new ways of thinking about things. (This isn’t necessarily a Bad Thing, but it bears mentioning.)

For instance, try explaining the subtle relationship between mp3 files and playlists to someone who doesn’t truly grok filesystems, shortcuts, and links. You might be able to explain it, but it will take a lot of explaining. Try a more advanced topic, like why a satellite-modem connection works fine for streaming audio but is horrible for interactive websites — and the explanation can take much longer. Bring DRM, P2P, streaming, file sizes, bitrates, codecs, protocols, IP addresses, connectivity, lag, bandwidth, Bluetooth, AC3 and oversampling into the conversation, and suddenly you’re speaking a foreign language.

Technological progress is definitely accelerating, and every year, I hear more and more people talk about the Singularity. I’m even starting to believe it myself. A lot of it does sound farfetched — yet technical progress in many fields is starting to look asymptotic. We definitely live in interesting times: they say that by 2025, supercomputers should be sufficiently powerful to run realtime simulations of the human brain. With computer speeds doubling every year or two, we could well end up as spectators to the fastest and most profound changes in history.

As long as we can control the direction things take, though, I, for one, welcome our new robotic overlords.

* Yeah, yeah. Nobody, least of all me, is going to claim that cassettes beat LPs for audio quality. I draw the line at CDs, though. Maybe 44.1kHz/16bit isn’t optimal, but it sure beats dragging a rock through a plastic groove.

Posted in Analog, Digital, Nostalgia | Leave a comment

Digital blasphemy?

Posted on 2009-08-10 by M. Eric Carr

When is a 555 not a 555?

When it’s really a PIC!

The design of the DrACo/Z80 computer calls for a 555 timer (a great piece of paleotech, even if it still isn’t sure after 38 years whether it’s really a digital or analog part.) However, for running higher-speed programs on the DrACo, I wanted to have the option to, as Emeril might say, “kick it up a notch.” I figured that a PIC12F683 would do nicely, since it could be programmed to provide a nice, stable TTL clock output without any external components.

The only problem was, the PIC’s ground lead is on Pin 8 and its power lead is on Pin 1; the 555 has the opposite configuration. The solution? Possibly the single ugliest soldering job I’ve done in a long time (and that’s saying something, folks.)

Yet, it works — and is a nice, drop-in replacement for the 555, swapping the astable oscillator mode for a much faster 2MHz clock output.

This is also the single shortest program I’ve ever written for a PIC:

   org 0x00
   banksel OSCCON
   movlw 0x70
   movwf OSCCON

   goto $

It sets the clock to 8MHz, then sits in a single-instruction loop and contemplates its navel. So, for that matter, when is a PIC not a PIC? When it’s not doing any computing at all — but just providing a 2MHz CLKOUT signal.

But sometimes, the smaller the MCU, the more creative the applications. I’ve heard of people using microcontrollers in fireworks to provide split-second timing for the pyrotechnics. At 30 cents each for something like the 10F200, it only sounds crazy until you think about it.

…and yeah, this project could have been very easily done with a less expensive PIC — but 12F683s are so versatile that I keep a couple dozen of them on hand for various things. They’re like digital LEGO…

Posted in 555, Analog, Digital | Leave a comment

Thatsa lotta beer!

Posted on 2009-08-10 by M. Eric Carr

The statute of limitations is up on this by now, I think…

Back in the day, several ne’er-do-well CS students were enrolled in a certain CS150/151 class/lab, taught by a certain D. Ray with a certain M. Ghose as a lab TA. As the legend goes, they were bored in lab one day (having finished the ridiculously easy assignment in a few minutes, but not being allowed to leave early). They got the idea to put into practice their newfound knowledge of unsigned long integers (32 bits of nonnegative goodness, on those machines) by writing a technological take on the age-old “bottles of beer” song known and loathed by school-bus-drivers everywhere.

The technological take was to make the computers “sing” the verses of “Four billion bottles of beer on the wall” by writing the verses out to a disk. The code looked something* like the following:

#include <stdio.h>
int main(){
   unsigned long long beernum;
   for(beernum=4000000000;beernum>0;beernum–){
      printf(“%llu bottle”,beernum);
      if(beernum!=1) printf(“s”);
      printf(” of beer on the wall,\n”);
      printf(“%llu bottle”,beernum);
      if(beernum!=1) printf(“s”);
      printf(” of beer,\n”);
      printf(“Take one down,\n”);
      printf(“Pass it around,\n”);
      printf(“%llu bottle”,beernum-1);
      if(beernum!=2) printf(“s”);
      printf(” of beer on the wall…\n\n”);
      }
   return(0); //Outta beer, outta here!
   }

They finished writing it, so the story goes, just before the lab period ended, and set it in motion, telling their friend in the next section that it might be a good idea to save his work. Apparently the sysadmins hadn’t heard of disk quotas, because the drives rapidly filled up with the verses of what had to be the world’s longest song. According to aforementioned friend, one of the sysadmins ran into the lab about halfway through the next section, asking for certain students by name.

The interesting thing is, Moore’s Law being what it is, while such files might not fit in a user’s disk quota, they probably wouldn’t crash the server, either; at about 124 bytes per verse, the “song” would take up about 496GB (depending on whose definition of a GB you use.) This would actually fit on the free space on my 1-TB drive on my workstation at home (MSRP of just under a hundred bucks.)

Moore’s Law rocks.

* OK, so this isn’t the original code by a long ways — but it gives the flavor. The original:

  • was written in Pascal, not C;

  • wrote to the disk instead of standard I/O, and

  • probably didn’t have the fancy “bottle” / “bottles” code

Posted in Coding, Humor, Nostalgia | 1 Comment