MC68HC11 question: (tentatively solved)

Thread Starter

metermannd

Joined Oct 25, 2020
343
I see that the 'HC11 MPU has some sort of timer functionality, and I am wondering if and how I could use that functionality to emulate a MC6840 timer IC.

The 6840 timers in my projects are set up so:

Timer 1 - programmable delay; 1/16 second per count (the number of counts was preloaded before calling the subroutine). No external signals were associated with this timer.

Timer 2 - IRQ timer; set so that it provided a continuous 2439Hz signal. The waveform was then fed into the MPU's IRQ pin.

Timer 3 - carrier generator; set so that it provided a 12.5kHz signal, which could be enabled during transmit intervals. This also had an external output.
 

RPLaJeunesse

Joined Jul 29, 2018
252
You can, but it will take some software effort since the HC11 has only 1 free-running counter that cannot be stopped or reloaded. All it takes is 3 (of the 5 available) compare registers, a bit of simple 16-bit math and judicious use of interrupts. LOTs of interrupts given you need one every 40us to generate a 12.5KHz square wave. On each TOCx interrupt bump the associated compare register by the interval value: just read, add a constant, write. The first interrupt at 40us causes an output pin to change state, that also requires setting the next output state (hi or low). Add another interrupt every 410us to get 2439.0244Hz. And one more every 62500us to get the 1/16 second period. Upon noticing HC11 reference manual (rev 3) section 10.4.2.2 there might be a way to use another timer such that you need only one interrupt per 12.5kHz cycle. Personally I'd look at using a 2MHz Eclk and the divide-by-4 prescaler into the timer's free-running counter, and really study up on section 10.4.2.2.
 

mlemcke

Joined May 11, 2013
6
I haven't used an HC11 for some time but I did a lot of work with them in their day.
I need a little clarification to understand more.
Are you using an HC11 and want to use the timer modules to do these functions?
If so, which HC11 are you using? example: A8? E9? F1? K4?
What is your EXTAL frequency?
What level of programming are you using? Assembly, C or other language?

Mike
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
RPL: With that amount of overhead I'd rather just leave the timer chip in place.
The firmware I have already has an interrupt driven by the timer chip, so I'd rather not add to its complexity.

mlemcke: To answer your questions:
Yes, I'm using a 68HC11F1 to replace a bespoke CPU.
The crystal frequency I intend to use is 4MHz (the original CPU was 1MHz).
I'm working with assembly (I played around with assembly back when I owned a Commodore 64 - just had to relearn a few things going from the 65xx family to the 68xx family).

After reading the other response, I have decided to leave the timer chip in place.
However, I'm looking at whether it is possible to eliminate the 6821 PIA instead, given that there are three I/O ports sitting there on the 'HC11 - specifically Ports A, D, and/or G. I need a total of 10 lines (7 inputs and 3 outputs).
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
Moving on from my question re: the 6840, I decided to see about moving the lines I have on the 6821 to the general purpose I/O ports on the HC11.

Here's what I have. I also made use of the programmable chip select lines and have one for the 8279 display controller, one for the 6840, and one for the EPROM. The four open general-purpose I/O lines on Port G were allocated to the more important I/O lines.

My question centers on the allocation of the lines on Port A, and how I can ensure the CPU doesn't get confused and think that I'm trying to use the timer functions (when I most definitely will not). Alternatively, would Port D be an acceptable substitute?
 

Attachments

MrChips

Joined Oct 2, 2009
30,706
Some of this you probably already know but just in case you don't, let's cover the basics of MCU technology.

The goal of an MCU is to create a powerful single chip computer system.
The push is always onwards for a feature rich MCU with ample ROM, RAM space, I/O pins and on-board hardware features.
Often there are conflicting requirements. The MCU manufacturer attempts to accommodate as many client demands as possible in order to increase chip popularity and sales.

The first order of business is to increase on-board memory. This eliminates the need for external memory address, data, and control lines and thus frees up I/O pins.

The second order of business is to provide a feature rich HW set. However this requires lots of I/O pins. The MCU manufacturer has to anticipate how all of these HW features can be accommodated with limited number of I/O pins. Thus I/O pins are configurable in order to select different I/O functions.

MC68HC11F1 though an old MCU chip is an example of a feature packed MCU. It is available in 68-pin PLCC and 80-pin TQFT packages. It has on-board 512 bytes EEPROM and 1024 bytes RAM which is tiny by today's standard.

There are six 8-bit I/O ports and one 6-bit port which are shared with various HW functions:
I/O port vs alternate HW functions
PORTA = TIMER input capture/output compare
PORTB = HIGH ADDRESS BUS
PORTC = DATA BUS
PORTD = SCI, SPI (6-bit port only)
PORTE = analog inputs or digital inputs
PORTF = LOW ADDRESS BUS
PORTG

MC68HC11F1.jpg



MC68HC11F1 Block Diagram.jpg

Now let us look at some of the port assignments.
Since there is only 512 bytes EEPROM, one is expected to provide external UVEPROM for program storage.
This takes away PORTB, PORTC, and PORTF from available I/O ports.
Memory interface requires E and R/W which are provide by dedicated pins 4 and 5.

PORTA can be used as GPIO (general purpose input/output) or it can interface to the internal TIMER.
If you do not require TIMER input capture or output compare, you can still use the HW TIMER and still use PORTA as GPIO.
(I would still recommend that you consider using the on-board TIMER in place of MC6840. If you let me know what are your timer requirements I am happy to lend a hand.)

PORTD is only a 6-bit port. In any case, if you need serial UART interface and SPI you want to keep PORTD for those purposes.

PORTE is for inputs only, analog or digital.

Hence your only other choice is between PORTA and PORTG as GPIO.
If PORTA and PORTG still leaves you short of GPIO pins, the MC6821 is still a viable option giving you two additional 8-bit GPIO ports.

(Of course, you are well aware that you are resurrecting age-old technology. Employing a newer chip with more memory will free up GPIO pins. I understand some of your rational with going this route. If you are attempting to replace the CPU with MC68HC11 I would seriously consider looking at MC68HC811 and MC68HC711 if these are still available. What is the estimated size of ROM and RAM required?)
 

MrChips

Joined Oct 2, 2009
30,706
I see you have covered some of my questions in your previous posts.

In post #4 you said that you need 10 pins (7 inputs and 3 outputs).
7 inputs are covered by PORTE.
3 outputs can come from PORTG.

That leaves PORTA free for TIMER and signal generation output.

MC68HC811E2FN2 has 2K bytes EEPROM and 256 bytes SRAM. Is this enough for your requirements?
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
My goal at this point is to just get a working copy of this piece of equipment (the original is cramped and just plain dangerous to go poking around inside), then I can start looking at something newer for the processor core.

The F1 version has 1K on-board SRAM and I already have an external 8K EPROM (the program runs ~6K bytes). As far as RAM goes, the requirement is probably somewhere near 200 bytes, so 1K is plenty.

The original does have a 6821 in the design, I just want to see if it's possible to replace it with some of the I/O pins on the HC11.

No need for the timer as I have the 6840 for that, and currently no need for the SCI / SPI interfaces either.

Also, RlyA-RlyD need to be a full nybble, so I'm thinking I need to swap that to Port G.
Sig_PIA needs to be bit 0 for now, and PA5 is actually an input.

First post has my requirements for the timer... response in Post 2 had me thinking it's better to leave the 6840 in place.
 

mlemcke

Joined May 11, 2013
6
My goal at this point is to just get a working copy of this piece of equipment (the original is cramped and just plain dangerous to go poking around inside), then I can start looking at something newer for the processor core.

The F1 version has 1K on-board SRAM and I already have an external 8K EPROM (the program runs ~6K bytes). As far as RAM goes, the requirement is probably somewhere near 200 bytes, so 1K is plenty.

The original does have a 6821 in the design, I just want to see if it's possible to replace it with some of the I/O pins on the HC11.

No need for the timer as I have the 6840 for that, and currently no need for the SCI / SPI interfaces either.

Also, RlyA-RlyD need to be a full nybble, so I'm thinking I need to swap that to Port G.
Sig_PIA needs to be bit 0 for now, and PA5 is actually an input.

First post has my requirements for the timer... response in Post 2 had me thinking it's better to leave the 6840 in place.
I agree that leaving the 6840 in place is a good choice given the amount of code you would need to write to use the limited flexibility of the 11's timers. With the I/O available on the F1 you should be able to eliminate the 6820. If pins for PG0-PG3 are available that is a good choice for a nybble. If not, then PD0-PD3 is your next best choice. Unused pins on ports A and D should meet your other needs.

Was your "bespoke CPU" a custom HC11 and are you starting with the original source code for the design? I only ask because the HC11 has a requirement to configure certain registers within the first 64 clock cycles after reset.
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
Here's how the I/O pins are currently allocated:

Relay A - D contact closures (in): PG0 - PG3
Sig_PIA (in): PA0
EIRQ (in): PA1
Mode jumper (in): PA2
Data (out): PA4
PAE (out): PA5
Init_En (out): PA6

The "bespoke" CPU was an MC6801 variant (in a DIP-40 package) that I understand was originally produced for automotive applications, but evidently was also made available to OEMs. The difference from the standard 6801 is that it has dedicated address / data pins instead of the multipurpose ports as used on the HC11 and other 6800 variants. I chose the HC11 mainly because it used the same instruction set / opcodes as the other CPU (minus the Y register, irrelevant for my needs).

Your question about setup actually leads into my next question, which centers on which registers I need to poke at in the setup portion of the firmware.

I've established that I need to write to the CSCTL register to enable / configure the chip selects (value: $A7), and to the Port A and Port G data direction registers (values $F7 and $F0 respectively).

I am wondering if I need to write to the config register, as I don't need the on-board EEPROM.
 
Last edited:

MrChips

Joined Oct 2, 2009
30,706
In comparing MC6840 PTM (Programmable Timer Module) and MC68HC11 Counter/Timer,
MC6840 has three independent 16-bit timers.

MC68HC11 timer is one free running 16-bit timer.
It has 5 output compare registers and 3 input capture registers. Each of the 5 output compare registers can be programmed to output a square or PWM signal or any random timing waveform on a GPIO pin, In effect, you can have 5 independent timer/generator functions.
 

mlemcke

Joined May 11, 2013
6
Here's how the I/O pins are currently allocated:

Relay A - D contact closures (in): PG0 - PG3
Sig_PIA (in): PA0
EIRQ (in): PA1
Mode jumper (in): PA2
Data (out): PA4
PAE (out): PA5
Init_En (out): PA6

The "bespoke" CPU was an MC6801 variant (in a DIP-40 package) that I understand was originally produced for automotive applications, but evidently was also made available to OEMs. The difference from the standard 6801 is that it has dedicated address / data pins instead of the multipurpose ports as used on the HC11 and other 6800 variants. I chose the HC11 mainly because it used the same instruction set / opcodes as the other CPU (minus the Y register, irrelevant for my needs).

Your question about setup actually leads into my next question, which centers on which registers I need to poke at in the setup portion of the firmware.

I've established that I need to write to the CSCTL register to enable / configure the chip selects (value: $A7), and to the Port A and Port G data direction registers (values $F7 and $F0 respectively).

I am wondering if I need to write to the config register, as I don't need the on-board EEPROM.
I don't see any problem with the I/O pins you have selected and the initialization of the DDR's (data direction registers).

The 6801 was posibily the first "Controller" chip because of the integrated I/O. Your "bespoke" CPU was first used by Delco Electronics Div. of General Motors and was called the "GMCM" Processor. It was used in the first Throttle Body Fuel Injection Systems introduced in the 1980 Cadillac's. I worked at Delco from 1977 to 1997 and was a Product Engineer on all the Cadillac Body Computer and Fuel Injection systems for my first 14 years there. I knew the GMCM well. It was pinned out like the 6800 with elimination of the VMA (Valid Memory Address) pin and of the Phase 1 Clock.

The GMCM Instruction Set was an enhanced version of the 6800 and is a Subset of the HC11. Early memory maps were set up with RAM starting at $0000, (I'm old school Motorola and don't use 0x for HEX). ROM was always addressed to end at $FFFF. An 8K EPROM would have addressed from $E000-$FFFF. I/O was addressed starting at $8000 to simplify the address decoding (in this case you would only need A14 & A15 to decode the RAM, I/O and EPROM blocks.

In the HC11 the I/O was moved to $0000 to take advantage of Direct Addressing Mode to the I/O and RAM to start above the I/O so often used RAM was also accessed as Direct Memory. The I/O and RAM can be moved and that is where the 64 clock cycles from RESET come in. Memory map allocation registers may only be written once and during the 64 clock cycles.

You will probably want to remove any code related to any configuration of the PIA (6820) and you will have to change the addressing of the moved I/O pins.

You may want to think about keeping the on-board EEPROM since it already works and you wouldn't need to write new software for the EEPROM
on the HC11 until you have everything else working.
 

MrChips

Joined Oct 2, 2009
30,706
I have used MC68HC811 (EEPROM) and MC68HC711 (OTPROM) extensively.

MC68HC811 has 256 byte RAM and 2K EEPROM
MC68HC711E9 has 512 bytes RAM, 12K OTPROM and 512 bytes EEPROM
MC68HC711E20 has 512 bytes RAM, 20K OTPROM and 512 bytes EEPROM

You can use the 68HC811 for testing segments of your code before burning into an HC711.
I can show you how to set up your code on an HC711 so that you can still make changes to your code without having to throw away a perfectly good HC711.
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
mlemcke: So I guess we are both talking about the SC44125 then. :)

I prefer $ notation for hex myself - as I said, I did some poking around in assembly on the 64... :)

The HC11's EEPROM is nowhere near big enough for the code - even after I went through and optimized the badly written code (and removed some unneeded sections), it is still a bit over 5K - $E000 to $F5xx.

So, if the EEPROM sits at $FE00 by default, so how would that work?

I've already commented out the 6821 setup and definitions in my source file, and updated the addresses throughout as well. I'll review the source one more time before I compile it and see how big the current version is.

The 68HC711 seems tempting, but doesn't that style require an external multiplex setup for D0-D7 / A0-A7?

Right now, A13-A15 are no longer needed outside the MPU, A4-A12 are only needed for the EPROM, A0-A3 for the 6840, and A0 for the 8279. Quite a bit simpler than what I began with!
 

MrChips

Joined Oct 2, 2009
30,706
MC68HC811E2FN has 2K bytes of EEPROM (code space) 52-pin PLCC
MC68HC711E9CFN2 has 12K bytes of OTPROM (code space) 52-pin PLCC
MC68HC711E20CFN2 has 20K bytes of OTPROM (code space) 52-pin PLCC

You do not need external memory to use these MCUs. There is no need to bring out A15-A0 and D7-D0.
Mind you, we are talking about obsolete components. I don't know where you can get these.
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
The data bus and address bus lines are needed for the external peripherals (6840 and 8279 display controller in particular).

So, it looks like I'm almost ready to finalize the updated gerbers and work out the parts I need to order.
The HC11 I have on hand is the remaining good one of two I'd ordered from Mouser.
 

mlemcke

Joined May 11, 2013
6
The data bus and address bus lines are needed for the external peripherals (6840 and 8279 display controller in particular).

So, it looks like I'm almost ready to finalize the updated gerbers and work out the parts I need to order.
The HC11 I have on hand is the remaining good one of two I'd ordered from Mouser.
It sounds like you are doing well.

If you decide to build more than 1 and want to eliminate the 6840 and possibly the 8279 (or up grade it to something newer),
I would suggest the MC9S12 family or the MC9S08 family of controller chips.

The S12 is the replacement for the HC11. It has Flash memory, improved and more timers plus other improved features,
so it could possibly be a single chip solution. It would be the easiest to port the software to because it is upward
source code compatible. The core is based on the 6809 which is significantly more powerful than the 11. The downside is
it is expensive and overkill.

The S08 has Flash memory, improved timers and features like the S12 and also possibly be a single chip solution. The
downside is it is not fully source code compatible because it is the latest improvement based on the old HC05 core which
does not have the B or D accumulators. It has plenty of RAM and BUS clocks speeds of 20MHz or higher.

I have used the 9S12's, but for the systems that I'm designing today I use 9S08's. They are more cost effective and it wasn't
that hard to adjust to having just 1 accumulator. The addressing modes and the basic Instruction Set are the same as the 11.
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
Just wondering if you'd missed my question on how to handle the HC11's on-board EEPROM since it occupies FE00-FFFF while I have ROM at E000-FFFF.

Thanks for the suggestions on newer MCUs to consider. I do ultimately want to replace the 8279 and LEDs with an LCD - do these newer MCUs have the capability for I2C interfacing?

As for working with a single accumulator, one common trick on the 6502 platform to get an extra accumulator was to repurpose one of the two index registers. (the way the index works on the 68xx seems backwards to me compared to the 65xx, though)
 

MrChips

Joined Oct 2, 2009
30,706
+1 agreed.

HC11 is obsolete. MC9S08 is a good replacement and so are many others.

For the record, I have extensive experience programming 1802, 6502, 6800, 6802, 6805, 6809, 68000, HC11, 9S08, 8004, 8008, 8085, 8086, 8088, Z80, MSP430, Atmel AVR, PIC, STM32, just to name a few that I can recall.

If you want to move forward, 9S08, MSP430, AVR, PIC, STM32L0 are all have viable candidates.
 

Thread Starter

metermannd

Joined Oct 25, 2020
343
Just looking at the specs for a representative sample of the 9S12 family and seeing what it has to offer makes me think that may be a suitable one-chip solution. The timer and PWM generators together look like they could replace the 6840 and having an I2C port means I can ditch the 8279 and LEDs completely in favor of an LCD, and of course all kinds of on-board memory.

But first things first. I still need a safe working copy of the fixture (the original is cramped and has a bad 'hot chassis' design). I have two different approaches I can take, I just need to make a decision and get the copy working, then I can turn my attention to the 9S12.
 
Top