|
----- Original Message ----- From: "Kerry Berland" <> To: < > Regarding the 68HC811-- > > There used to be a significant hole in Motorola's line-up, as between > the 68HC11 product line, and the 68HC12, and a lot of people didn't want > to make the jump, me included! > > However several years have gone by and I think they've done a great deal > to close the gap. Especially with the newer MC9S12 family. > > The budgetary price for a 68HC11E1 is $4.88 for 1K units; this is a part > with a 2 MHz E clock in a 52-pin PLCC. It has no program memory, so you > have to add an external memory for the programming. If you use a > reprogrammable 27E512 from Winbond for program memory, only about $1.00, > plus a socket for the Winbond, plus a 74HC373 address latch, you're up > to around $6.50 for a 2 MHz microcontroller with external reprogrammable > program memory. > > Or you could use the 68HC711E9 with one-time programmable memory for > $7.93 (Motorola budgetary 1K). Haven't used this part for a long time > because the above combo is more cost-effective (assuming you have the > PCB space and don't mind the expanded bus from an EMC point of view), > and because you get to reprogram the Winbond as many times as you like > whenever there's a firmware upgrade. > > If you need the port pins lost by the expanded bus, then you replace the > 74HC373 and Winbond with an ST PSD813 (newer version of obsolete > PSD913), which provides the port pins, plus a lot of flash memory and > extra RAM, and costs around $6.00. > > Those are the strategies we have used to keep the 68HC11 going. But > looking forward, they make less and less sense, with the newer MC9S12 > parts. > > The budgetary price for the MC9S12E64CFU on Motorola's website is $6.20 > for 1K units. That unit has 64K of flash memory, and 4K of RAM, and > comes in an 80-pin QFP package with a rich collection of peripherals and > plenty of port pins, and has a BDM debugging port that reduces the cost > of emulation tools. You can get other versions with larger packages and > more memory. It runs at 25 MHz bus speed, 12.5 times as fast as the > example 68HC11 above. This single chip MC9S12 is far more powerful, and > less expensive. > > The number of us 68HC11 stragglers is continuing to ramp down, and I > doubt any semi manufacturer could ever be tempted to come out with a new > variation of the 68HC11.... Maybe so. However, at a very recent 'seminar' by Philips I learnt that 16-bit MCUs are considered (at least by Philips) to be a dead end. Although they promised not to drop current 16-bit products, they also said they will not be updating their 16-bit MCUs any more. Their greatest sales is 8-bitters with the 32-bit market being the preferred option for all non 8-bit jobs. Now, if this is based on global trends (and I believe coming from Philips, it is), it means the HC12 (classified in the 16-bit category by Motorola) is not going to have any better future. To some extent this is observed in the disproportionate increase in interest for the HC08 compared to that for the HC12. And it is my personal view also, regardless of how big corporations' marketing people see it, if a job is way too big for an 8-bitter, a 32-bit is a better option than a 16-bitter. The 8-bit MCUs aren't going to go away any time soon (if ever, within our lives) simply because there are so many 'little' projects that don't need any more power (e.g. an alarm clock will never need anything bigger -- as long as it remains only an alarm clock and not a do-it-all machine that includes an alarm clock). And if one really needs power, then 32-bit MCUs are a safer choice for upgrading the design without moving to a 32-bit (new language) mid-way during your product's life. Your example with prices between a HC12 and HC11/PSD in favor of the HC12 is valid for the case you only use the PSD for adding reprogrammable code memory. But there are many situations where the on-chip RAM isn't enough (even in the HC12) and the design needs to go expanded mode. In that case, cost is again in favor of the HC11/PSD combination, because you can't avoid a similar cost for the HC12. Also, I don't think it's accidental that Motorola isn't producing any HC[S]08's with expanded mode capabilities (except I think for one model which they did this 'secretly' just so they could provide a means for building emulators -- a need that's gone with the introduction of the HCS08). This seems to show that they're worried that if they give expanded mode to the HC[S]08, their HC12 business will go way down. With the HC11 being no longer updated with new members, anyone wanting no more than a 8-bit Motorola MCU but with expanded mode capability (for adding LCD, external RAM, etc on the bus) is 'pushed' toward the HC12. If the HC[S]08 had it, I'm sure the majority would go down to the HC08 instead of up to the HC12. And I would have no problem with the HC12 except that is not compatible (at the object level) to the HC11 so I cannot consider it an upgrade but a complete change. Because if I have to go through the pain and cost of changing my tools/libraries, I can choose any other MCU out there, not out of spite for Motorola but out of fear that after the HC12, Motorola will again do the same when they come up with the HC13[?]. I loathe Microsoft for locking out (being incompatible with) previous versions of their products in the name of 'progress' (quite questionable in my view) and I don't think I should applaud anyone else (Motorola) for doing the same. If Intel has managed to keep compatibility from the time of the 8086 to the most recent Pentium, I don't see why Motorola had to be any 'smarter', although they apparently were careful doing just that from the HC05 to the HC08. Seems to me it's more marketing than what we really need. > Kerry Berland > |
Re: 68HC811 [was 68HC24 PRU]
Started by ●November 19, 2003
