You are here: Home DOCUMENTATION Adapt9S12X Using Your Adapt9S12XDP Microcontroller Module - Software Considerations - XGATE

Technological Arts Inc.

Your Shopping Cart

Your Cart is currently empty.

Using Your Adapt9S12XDP Microcontroller Module - Software Considerations - XGATE

Article Index
Using Your Adapt9S12XDP Microcontroller Module
Overview of features
Getting Started
Setting Up the Hardware
Application Programming
Software Debugging
Software Considerations
Software Considerations - Memory Map
Software Considerations - Interrupts
Software Considerations - XGATE
Software Considerations - S12X Clock
Hardware Details
All Pages


The MC9S12XDP512 introduces the XGATE processor into the S12 line.  XGATE is a Reduced Instruction Set Computer (RISC) processor that is designed specifically to handle certain types of Input/Output (I/O) requirements that an application might have.  It is not just another CPU made for running programs.

Most user applications can use the standard S12X CPU by itself to handle their I/O needs.  It is for that reason that many development environments concentrate on the S12X, without providing XGATE support.  The only time one has to start thinking about the XGATE processor is if there is a need for it.

For example, if an application has a requirement to handle an interrupt source that occurs very often, then this could be a situation that requires the use of the XGATE processor.  Otherwise the S12X processor ends up using most of its processing power handling just this one interrupt.  Of course, if using XGATE still isn't fast enough, one may end up having to resort to a hardware solution, such as GAL, FPGA, or ASIC circuitry.  XGATE bridges that gap.

So if you have the need for speed with one or two I/O types, then XGATE is for you.  Don't use XGATE for a lot of different I/O requirements though.  It's not designed with that in mind.  The reason for this is because of the way it works.  Most of the time the XGATE processor actually just sits there doing nothing.  It only starts running when an interrupt destined for it gets triggered.  At that point, XGATE will begin execution of the routine to process that interrupt.  Since there was no program running to interrupt, it doesn't go through the process of saving the CPU registers to the stack the way a normal interrupt routine works.  It just jumps directly into doing the interrupt code.  This makes it very fast.  Should another interrupt come along though, the XGATE can not, by design, let that second interrupt jump in.  It has to finish the routine it is doing first.  Therefore if there are a lot of different interrupt types to handle, then it becomes more likely that two interrupt sources will trigger at nearly the same time.  One of the two interrupts will have to wait while the other one gets serviced first.  The whole purpose of XGATE is to provide a means of handling some external event in the shortest time possible, without burdening the S12X CPU with this one repeating task.  This objective gets defeated if the second interrupt now has to wait to be serviced.

XGATE code should also be written to be executed from RAM.  The memory map used by XGATE includes all of the 32K of RAM, and the Flash pages $E0 and $E1, minus 2K for registers.  However the most speed is obtained by running from RAM.  This is because XGATE has to access memory in the part of each bus cycle that the S12X CPU is not doing an access.  Since generally the S12X is executing from Flash, it spends most of its time doing memory fetches from Flash.  Because of this, the XGATE processor can take advantage of the rest of the cycle and do another RAM memory access.  The result is that XGATE appears to run close to twice the speed the S12X core is running at.

When using the XGATE, special attention has given to writing software for both the XGATE and S12X processors when they access the same memory locations.  Since both processors run simultaneously, it is possible for the XGATE to be updating a counter due to an interrupt at the same time the S12X is reading that counter.  The effects of this can be indeterminate, and cause strange and unpredicable results in your application.  The solution is to use what is called a Semaphore, so that when one processor needs access, it writes the Semaphore if it has not already been taken.  (Otherwise it has to wait for it to be released by the other processor.)  The XGATE hardware provides for eight hardware semaphore registers for this purpose.  This forces the processors to take turns when they need to access a resource, like memory, at the same time.

You can read a more detailed introduction to the XGATE with the Freescale Application Note AN3224.  Further information about how to set up and use the XGATE processor is in AN2685.

Last Updated ( Friday, 08 February 2019 18:19 )