what's wrong with a pic ?

Wrong. Yes, the TPU microcode is different--but we download our own from the flash so that is not a problem. The real problem is the peripherals. Ours have various combinations of RAM (e.g., up to 32KB of static RAM, four 512 byte overlay RAM areas, and 6KB of TPU RAM which is used by the micro in certain situations). We also have different peripheral mixes for communications (some have one or more TouCAN modules, some have DLCM modules (for Class 2 comms)). At least one uses a CPU32X CPU (same instruction set as a CPU32), a burst mode flash interface, and A-to-D. I mentioned it a little while ago on this ng because I thought it was commercially available and then couldn't find any mention of it by Freescale.

~Dave~

IIRC, my 1970 Vega ($2500 new) had no firmware to upgrade. But by

1984, my Nissan 200SX would keep track of mileage and say "Fuel Level is low!" without a trace of Japanese accent. I guess that gives us two data more points to track the intrusion of firmware into automotive hardware.

Mark Borgerson

I have no problem understanding the differences---it's just difficult that Motorola (Freescale) used the same part number (68332). I still do a lot of work with 68332 systems from Persistor Instruments, so I applaud the longevity of this offshoot of the M68K architecture.

The 68332 does have to qualify (in whatever form) as one of the longest- lived micros with sales in the 10 (or 100s) of millions of units. I still feel, as I did in 1985, when I wrote a simulator for a CS course, that the M68K architecture should stand as a good example of a well- defined and well-implemented micromputer system.

Mark Borgerson

We are gradually moving some of our old 68332 designs over to the ColdFire MCF5234. The M68k is still an excellent ISA design, and the ColdFires are fast, low-power modern devices - current top speeds are something like 400 MIPs at 200 MHz, with newer cores under development. Not bad, considering they use the same basic ISA as the 68000 from the early eighties.

We always knew them as GMPRX, GMPRX2, GMPTX, GMPWX, Excalibur, etc. We had the 68332 manual from Moto with Xeroxed copies of the documentation for the differences. For Excalibur (the CPU32X variant), we had a Xerox of a whole manual. Freescale may not have considered it a '332 variant.

Agreed. I got documentation from Moto in '79 or '80 on the 68000, did a design for class using it, and my first job out of college in '81 was doing 68K firmware (The Joy of EPROMs!) for a real-time embedded system. Life was good! ;-)

~Dave~

I remember getting a plug-in card for the Apple II that had a 68008 on board in about that time frame. The 68008 could take over the Apple II bus and was fun to play with---but I actually spent more time with a 6809 card that I designed. I didn't really spend much time with the M68K series until it showed up in the Macintosh. Most of my early embedded work was done with the M6802 and M6809. In the '80s I moved up to the 68Hc16, and actually did a few designs with low pin-count 8051 variants and some PICs. I used C on the PIC---I think it was from Keil. When writing C for the PIC I was always aware that I had to treat the language as an advanced assembler. The PIC controlled an oceanographic instrument and didn't use or need strings or anything in the stdio library, IIRC.

I have memories---not always fond ones---of EEPROMS also. It was a big step up in productivity when we got our first romulator--and even better when we graduated to the Dallas Semi non-volatile RAM.

//Old fogey mode on Kids today don't know how easy they've got it with those little chips with 256K of flash memory 16K of RAM, etc. etc! Back in my day we built whole instruments with 2K of ROM and 128 bytes of RAM! // end fogey mode

Mark Borgerson

Nothing is wrong with a PIC.

... snip ...

1702s were even more fun. Then the 2708, which reduced the power supply problems slightly and didn't require pulsing all the data lines to some ridiculous voltage, and at last pure joy with the 2716 and utter ease of programming. In those days we built our own programmers. Contrary to Intel specs I developed adaptive programming, and cut the programming time by about 4 or 5 times with no loss of reliability. I counted pulses on a location until it took, and then continued for a factor of three.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: 
Also see

They are just fine for an assembly programmer who is used to building hardware from gates. Not suitable for someone who thinks programming is writing code in C or higher level languages, notwithstanding the alleged C compilers for them.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: 
Also see

[snip]

oh yeah, i remember working with an 80186 and having to go back and forth with my "stash" of eproms, back and forth to the UV lamp. i'd start the day with a pile of blanks, write my code, burn it, test it, and by the end of the day i'd have a pile of burned eproms. i'd walk them down to the one UV lamp i had access to in the engineering department, put them under the lamp, next day start the whole process over lol. some memories are painful lol.

Yea, we thought it was so cool when we got a quick eraser that consisted basically of a strobe in a box just big enough to hold 1 part. 3-4 flashes and your part was erased. It was a miracle. Or so we thought until a few days later, when the parts ($300+ Intel 8751s) that had been strobed a few times all died. Back to the old UV lamp.

--
Grant Edwards                   grante             Yow!  TONY RANDALL! Is YOUR
                                  at               life a PATIO of FUN??
                               visi.com

Is it time for a "Four Yorkshire Men" parody again...

We'd have loved to have 2708's. Would have been bloody paradise. We had to burn our code into bipolar proms with pushbuttons for each bit and switches for the address lines.... And bloody thankful we were for that, not having to wire patchpanels....

I feel your pain. 156 controllers, each with 8-12 EPROMs. Some memories are best forgotten. :-/

~Dave~

another way to get around this problem of google not quoting text is to hit the reply button and it brings up an empty message. immediately hit preview and it shows you that empty message. then hit "edit", and instead of it letting you edit the empty message suddenly the message contains all the quoted text to whatever you are responding to, just like the way google used to work.

With more than 4 EPROMs in a system, I used jump tables in the beginning of each EPROM and used indirect calls through these tables. Thus, the routines within each EPROM could be altered, without generating a completely new version of the program.

This greatly reduced the daily EPROM consumption and hence EPROM programming time, but also reduced the linking time, since you would have to link a single EPROM at a time, which helped a lot with floppy disk based development systems :-).

Of course this required some extra administration time to decide which routine goes to which EPROM and adding the reference into the jump table at the beginning of the EPROM.

Paul

As others have noted, the architecture is mind-bending. Like scotch whiskey (I am told), PICs are an acquired taste.

I cut my micro teeth on Z80 and 80xx so long ago that I'm embarrassed to be specific, so I have a lot of history with them. Today though, I use PICs. I checked out the 16F84, my first PIC, because I was just starting a big project (read "debug will be long and nasty"), did *not* look forward to piles of EEPROMs and many 20-minute erasure cycles, and decided FLASH was the way to go. Yes, I missed being able to use the stack as a little scratchpad, railed at the measly math instructions and having to funnel *everything* through the W register. But I got over it pretty quickly.

I can't figure out how people put up with the arcane syntax of C. After coding in three assembly languanes and half a dozen high level interpretive and compiled languages, over nearly 30 years, I tried C. What a disaster. "=="? Say what?! Pointers to pointers .... to pointers. Can't begin to calculate the number of times I looked in on a colleague who had been tearing out his hair over a bug in his code and was told, simply, "Oh ... some pointers got screwed up ..."

If one can put up with C, one can certainly get used to the PIC. IMHO. ;-)

--
Michael

I agree with your statement whole heartedly. PIC's are quite good for assembly programming but are not too great for HLL code.

I used PIC's at first as an introductory unit (the 16F628) and as my hobbyist projects needed more features or code complexity increased, I quickly hit a ceiling. I then switched to the 8051 (hey its still scores better than PIC!!).

I did like the "single cycle" nature of the core and the predictable instruction timings. So honestly, I would only make use of the chip if I needed to do some timing sensitive stuff (like driving VGA signals or other things in which you need accurate timings under software).

-Isaac

Facinating. A friend gave me a non-working Dragon to fix in late '83, IIRC. I vaguely remember changing a bus controller device (?) without success. It wound up in the attic for a couple of decades... More recently, we've moved house - and right now the Dragon is sitting on a window ledge, still in the packaging...

Maybe I should open the box and talk to you ;).

Ruff Records? Also fascinating. One of my clients (Chris Wood) operates Ruf Records...

Steve

Dragon had a long battle with Motorola over this. The bus controller as you call it (I forget the official name) had a timing problem that was temperature dependent and Dragon had lots of returns from people whose Dragons stopped after they had been on a while. Finally a modification using an external D-type was introduced to re-time one signal which fixed the problems. Unfortunately I do not have the details of the fix.

Does he have a URL?

Ian