Encoder Front Page
SRS Home | Front Page | Monthly Issue | Index
Search WWW Search seattlerobotics.org

The Vice-Prez Sez

Karl Lunt


The Need for Speed

I’ve been working hard on getting SBasic ported over to the 68hc12, and finally, in early January, got the first draft finished. SBasic version 2.0, available on my web page (www.seanet.com/~karllunt), generates output files compatible with my as12 assembler.

The combination of SBasic 2.0 and as12 lets you write code for a 68hc12 MCU in Basic. The executable can be ported to the MCU’s EEPROM and run directly. No fussing with assembly language, no arcane register manipulation, no wading through the pink (actually, purple) book; just write, compile, load, and go.

What’s even cooler is the SBasic source files are nearly identical for the 68hc11 and 68hc12. Some of the I/O register names have changed, of course. For example, the 68hc11’s SCI status register is SCSR; the same register on the 68hc912b32 is SC0SR1. 68hc12 variants can have more than one SCI port and each such port is complex enough to require two status bytes.

And there are a lot more I/O registers on the 68hc12. The ‘b32 I/O map contains nearly 250 active I/O registers, versus less than 60 for most 68hc11 variants. Even some of the I/O setups are more complex. For example, the ‘b32 general purpose ports, such as port A, have additional control bits for controlling the amount of output drive provided.

But many of the common I/O registers use the same name between the two chips, letting you compile your 68hc11 SBasic programs for the 68hc12 with little modification. And wait until you see how fast those programs run on the new chip!

Right off, you’re going to see a minimum 4x boost in speed. Many 68hc12 MCUs will use a 16 MHz crystal, up from the standard 8 MHz rock common to 68hc11s. Besides running with twice the crystal speed, the 68hc12 uses a divide-by-2 to generate its internal clocks, compared to the 68hc11’s divide-by-4.

But this 4x speed gain is only the beginning. The fastest 68hc11 instructions all require two clock cycles to execute. A NOP, for example, takes two cycles of a 500 nsec internal clock, or 1 usec execution time.

The 68hc12, however, executes its fastest instructions with a single 125 nsec internal clock cycle. Thus, the same opcode that requires 1 usec to execute on your present 68hc11 system will run eight times faster on your new 68hc12.

68hc12 speed boosts come from other instructions, as well. The designers have removed the 68hc11’s one-cycle penalty for instructions using the Y-register. On the 68hc11, a CPY-immediate requires five clocks, or 2.5 usecs, while a CPX-immediate only takes four cycles. The 68hc12, however, executes either instruction in just two cycles, or 250 nsecs. This yields a ten-fold speed boost over the 68hc11’s fastest Y-register instructions.

But to see a real speed boost over the 68hc11, you need to factor in the 68hc12’s much stronger addressing modes. The 68hc12 offers powerful register options such as "CPY, indexed with 16-bit offset from the PC, indirect," a six-cycle instruction that would require several separate 68hc11 operations to duplicate.

When 68hc12 compilers finally appear that target this chip specifically, and optimize for the stronger programming model, I think you will see typical speed gains of 10x or higher for the same source files. But even using SBasic, not yet optimized for the 68hc12, you will see an immediate speed gain of 6x to 8x for the same source file.

Granted, the 68hc12 is not widely available, yet. But Motorola is pushing hard to get newer versions, such as the 68hc912b32, out the door and samples could be available as early as February, 1997. So keep your eyes on the Web, and call Motorola now and then to check the schedule. I predict that, barring any allocation problems, the ‘b32 variant, with its 32K of on-chip flash EPROM, will spell the death of the 68hc11. You heard it here first!

Keep on keeping on...