Forward Migration from 68HC11

[Dubhe]

Our company has a significant investment in code and product using the 68HC11F1 product. Now that it appears that these have come to the end of its life, what new part might be available that we can migrate to with a minimum of fuss and bother?

[thisobj]

The '12 series is the best way to go.  I faced this decision about 6 yrs ago when the 'HC11E2 was phased out.  The product was an engine controller written mainly in 'C' with some assembly code for OS context switching. We also used an '08 chip for a lower-end product.  I can tell you from experience, that if you have even the slightest concern about the bandwidth on the 'HC11, or have plans to add new features, the '08 is not a good choice.  The port from '11 to '12  required about 2 weeks. 

With that said, it's best to compare the architecture and specifications of the two chips with your requirements in mind.
 
Frank   

[Lundin]

Those who suggest to use HCS08 are clearly not familiar with the HC11. Since you are using HC11, HCS12(X) is really the only choise, because it is backwards compatible with HC11. Both the instruction set and the peripherals are compatible.

The SCI should be fully compatible, and there are plenty of derivates with dual SCI. The AD and timers are different. IO pins won't be a problem and the ports are compatible with HC11 apart from additional features such as internal pull-down (on some ports), interrupt possibilities and so on.

I would advise against using the external bus on the HCS12. The external bus is the weakness of the chip: it is made unnecessary complicated and messy. But perhaps you have no other choise.

At least there shouldn't be a need for external EEPROM of 32k. The HCS12 comes with 2-4k internal EEPROM, and more importanly, flash memory. Depending on the application, you may or may not be able to use the flash memory instead. The main difference between the HCS12 flash and regular EEPROM is that you must erase sectors of 512 bytes if you want to store data in it at runtime, so the flash is inconvenient for data storage in runtime, but perfect for program memory and constant data.

If you want to use the flash for data storage in runtime, I would strongly recommend using a part with 128k flash or more, because these parts have the possibility to run code from one flash bank which writes to another flash bank. Devices with less flash memory can't do this since they only have one bank, and that leaves you with the questionable procedure of running code from RAM.

You should also consider going straight to HCS12X, since Freescale is already flagging the HCS12 as "legacy", and dumping the price on the S12X to make everyone move away from S12. There are likely many years to go before the S12 will become obsolete, but Freescale will probably start to slowly raise the prices on it to force migration, as they have been doing with HC11 for some years now.

Message Edited by Lundin on 2008-04-25 08:53 AM

[mke_et]

I would suggest something from the '12 series. While I like the '08, it can be a bit
of a step back. The '12 can be a BIG step forward, but you can usually take things forward without much in the way of problems.

I took a project that used the HC11 with a WaferScale part (that had paged flash) and went to a single 9212. I lost some features like the 'decode' that was built into the WaferScale part, and had to do some mucking, but it was surprisingly easy. I even managed to convert the math library over to the 12 with mostly 'search and replace' editing. And most of that was due to the tools involved.

Mike

[JimDon]

You want to use the HCS08 family.

There are many many members of this family. If you give us more specifics, we could give a better recommendation.

[Dubhe]

We use the 68HC11F1 in its full multiplexed form with external 32K EEPROM and 32K Static Ram. Almost all of our implentations make heavy use of 1-3 input timers, 4-5 output timers, the SCI, the A/D and as many I/O pins as are available. It was the PERFECT implementation for what we were doing in the early '90's and what we are still doing today. All code has been written in assembly. All of our implementations are low volume / special purpose applications.

The ideal replacement would look very similar (maybe with the addition of more on-board volatile and non-volatile memory and a dual channel SCI) and employ a similar instruction set at the assembler level.

So, just how bad off are we?

--Jon

[bigmac]

Hello Jon,

Since you are using assembly, the better choice would be the HCS12 because of a degree of backward compatibility of the instruction set with that of the HC11.  To change HC11 assembly code to HC08 would be a major undertaking.

Regards,

Mac

[JimDon]

I have to agree if it is low volume, cost and power is not a super issue, also if you wish to port asm language, then HCS12 is a great choice.

Since it is asm language, you can use the Codewarrior Special Edition with out limits (free!)

The only issue is if you truly  need more than 12K of ram, you will have to either use an "X" (banked RAM) or use external ram. Life will be easier if you can live with 12K of ram. If you use external ram, you have to give up IO pins. The banked ram will require page register management.

[bigmac]

Hello,

Another alternative to the allocation of an expansion bus for external EEPROM and RAM could be the use of serial SPI communications, assuming the slower access can be tolerated for data that requires less frequent access.  A contender might be the FRAM device (Ramtron) that provides non-volatile storage, with fast write operation.

Regards,

Mac