XGATE??

Started by Adrian Vos February 23, 2006
Hi All,

I am in need of more output compare style ECT outputs than the standard S12 
supports. I was thinking that I could achieve this by dedicating one 
standard OC channel to do all the timer work and generate interrupts, and 
then using a clever software approach with linked lists of pending timer 
events with a pointer to a general purpose output that it would perform the 
timer event upon during the interrupt. There would be some overhead in this, 
and a delay time to toggle an output, but in theory I could then produce as 
many outputs as I have general purpose outputs spare.

I was just looking at data sheets for an XGATE processor, and it states that 
the XGATE can be configured to respond to interrupts, do very fast 
processing based upon the interrupt, and then manipulate peripherals such as 
general purpose outputs. I was wondering if anyone who has used the XGATE 
could comment on whether the XGATE could be configured (programmed) to 
simulate more ECT style output compares as mentioned above with minimal CPU 
overhead, and minmal delay in the time from a couter value being reached to 
the output toggling. Basically the XGATE would respond the an ECT OC 
interrupt, and then access RAM to find out which pin needs to be toggled and 
in which direction, and then do this toggle, and then setup the OC channel 
for the next OC event which could be worked out from a data structure in 
RAM.

Is this possible??

Of course, I could just go to a different processor with more timer outputs, 
but I like working with the S12, and it has everything I need except more 
output compare channels, and it is cheap!!

-- Adrian 

Send instant messages to your online friends http://au.messenger.yahoo.com 

Adrian,

Yes, you an use the XGate to generate more Output Compare outputs, and the 
XGate code would probably be also pretty compact.

However, the timing generated, would not be 100% accurate, and that's 
because the XGate instruction processing depends on the S12X CPU usage of 
the memory resources.
For example, if when the XGate executes from the internal RAM, it will 
usually execute 2 XGate instructions during every S12X ECLK cycle. During 
ECLK cycles in which the S12X CPU accesses the internal RAM however, the 
XGate will execute only 1 instruction during the specific ECLK cycle. Thus 
there is some variance in the exact XGate execution time depending on how 
much the S12X CPU happens to access the internal RAM at the moment the 
XGate processes the timer interrupt.

There are even more XGate timing complications, when the XGate executes 
from the internal Flash, or when the XGate accesses one of the PRU register 
(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).

Also keep in mind that the interrupt latency is variable, and that on the 
current S12XD family the XGate can only process one interrupt at a time, so 
it would not service another interrupt until it completes processing the 
previous interrupt (on future S12X devices, there would be provision to 
nest XGate interrupts to one level).

So the bottom line is, yes the XGate can generate output-compare outputs, 
but there would be some variance in the response time from the the timer 
interrupt, till the appropriate output changes (normally up to 1uSEC, but 
could get much higher if the XGate would be configured to serve several 
interrupt sources, with no appropriate interrupts synchronization to the 
timer interrupt).

Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 14:57 23/02/2006 +1100, you wrote:
>Hi All,
>
>I am in need of more output compare style ECT outputs than the standard S12
>supports. I was thinking that I could achieve this by dedicating one
>standard OC channel to do all the timer work and generate interrupts, and
>then using a clever software approach with linked lists of pending timer
>events with a pointer to a general purpose output that it would perform the
>timer event upon during the interrupt. There would be some overhead in this,
>and a delay time to toggle an output, but in theory I could then produce as
>many outputs as I have general purpose outputs spare.
>
>I was just looking at data sheets for an XGATE processor, and it states that
>the XGATE can be configured to respond to interrupts, do very fast
>processing based upon the interrupt, and then manipulate peripherals such as
>general purpose outputs. I was wondering if anyone who has used the XGATE
>could comment on whether the XGATE could be configured (programmed) to
>simulate more ECT style output compares as mentioned above with minimal CPU
>overhead, and minmal delay in the time from a couter value being reached to
>the output toggling. Basically the XGATE would respond the an ECT OC
>interrupt, and then access RAM to find out which pin needs to be toggled and
>in which direction, and then do this toggle, and then setup the OC channel
>for the next OC event which could be worked out from a data structure in
>RAM.
>
>Is this possible??
>
>Of course, I could just go to a different processor with more timer outputs,
>but I like working with the S12, and it has everything I need except more
>output compare channels, and it is cheap!!
>
>-- Adrian
>
>Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
>Yahoo! Groups Links
>
>
>
>
	
	
Adrian,
Doron's answer is good as usual. Another alternative you could consider
would be to keep the OC pin control in the S12X CPU. You would use a high
interrupt priority and re-enable interrupts in all of your lower priority
ISRs. I haven't tried this, so I can't comment on the relative delay but at
least the latency would be more consistent and predictable. Maybe then you
could consider using the Xgate for your other interrupts instead.

Doron (or anyone else), do you have any information on the relative
interrupt latencies of these two alternatives?

-Dan White

-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
Doron Fael
Sent: Thursday, February 23, 2006 6:24 AM
To: 68HC12@68HC...
Subject: Re: [68HC12] XGATE??
	Adrian,

Yes, you an use the XGate to generate more Output Compare outputs, and the
XGate code would probably be also pretty compact.

However, the timing generated, would not be 100% accurate, and that's
because the XGate instruction processing depends on the S12X CPU usage of
the memory resources.
For example, if when the XGate executes from the internal RAM, it will
usually execute 2 XGate instructions during every S12X ECLK cycle. During
ECLK cycles in which the S12X CPU accesses the internal RAM however, the
XGate will execute only 1 instruction during the specific ECLK cycle. Thus
there is some variance in the exact XGate execution time depending on how
much the S12X CPU happens to access the internal RAM at the moment the
XGate processes the timer interrupt.

There are even more XGate timing complications, when the XGate executes
from the internal Flash, or when the XGate accesses one of the PRU register
(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).

Also keep in mind that the interrupt latency is variable, and that on the
current S12XD family the XGate can only process one interrupt at a time, so
it would not service another interrupt until it completes processing the
previous interrupt (on future S12X devices, there would be provision to
nest XGate interrupts to one level).

So the bottom line is, yes the XGate can generate output-compare outputs,
but there would be some variance in the response time from the the timer
interrupt, till the appropriate output changes (normally up to 1uSEC, but
could get much higher if the XGate would be configured to serve several
interrupt sources, with no appropriate interrupts synchronization to the
timer interrupt).

Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html

At 14:57 23/02/2006 +1100, you wrote:
>Hi All,
>
>I am in need of more output compare style ECT outputs than the standard S12
>supports. I was thinking that I could achieve this by dedicating one
>standard OC channel to do all the timer work and generate interrupts, and
>then using a clever software approach with linked lists of pending timer
>events with a pointer to a general purpose output that it would perform the
>timer event upon during the interrupt. There would be some overhead in
this,
>and a delay time to toggle an output, but in theory
I could then produce as
>many outputs as I have general purpose outputs spare.
>
>I was just looking at data sheets for an XGATE processor, and it states
that
>the XGATE can be configured to respond to
interrupts, do very fast
>processing based upon the interrupt, and then manipulate peripherals such
as
>general purpose outputs. I was wondering if anyone
who has used the XGATE
>could comment on whether the XGATE could be configured (programmed) to
>simulate more ECT style output compares as mentioned above with minimal CPU
>overhead, and minmal delay in the time from a couter value being reached to
>the output toggling. Basically the XGATE would respond the an ECT OC
>interrupt, and then access RAM to find out which pin needs to be toggled
and
>in which direction, and then do this toggle, and
then setup the OC channel
>for the next OC event which could be worked out from a data structure in
>RAM.
>
>Is this possible??
>
>Of course, I could just go to a different processor with more timer
outputs,
>but I like working with the S12, and it has
everything I need except more
>output compare channels, and it is cheap!!
>
>-- Adrian
>
>Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
>Yahoo! Groups Links
>
>
>
>
	
	Yahoo! Groups Links
	
Adrian and Dan,

A note on interrupt latency below.

     Steve Russell
     Nohau

At 10:18 AM 2/23/2006, "Daniel White"
<d_white@d_wh...> wrote:
>Adrian,
>Doron's answer is good as usual. Another alternative you could consider
>would be to keep the OC pin control in the S12X CPU. You would use a high
>interrupt priority and re-enable interrupts in all of your lower priority
>ISRs. I haven't tried this, so I can't comment on the relative delay but at
>least the latency would be more consistent and predictable. Maybe then you
>could consider using the Xgate for your other interrupts instead.
>
>Doron (or anyone else), do you have any information on the relative
>interrupt latencies of these two alternatives?

The real problem on interrupt latency is what other interrupts are interfering.

I believe that if there are no other XGate interrupts enabled, the XGate 
will be faster to the first instruction of the interrupt service than the 
highest priority S12X interrupt.

However, the important issue in this case is how long until the tasks 
required to insure consistent timing of the output and the next interrupt, 
so you have to sketch out the code on each processor to get an answer.

When you may have to wait for another XGate interrupt to complete or a 
higher priority S12X interrupt to complete, the situation is more 
complicated, but you can be confident that the latency will be much worse.

I suggest starting with the allowable latency and jitter for the individual 
interrupt response, and the allowable errors in timing.  Sketch out the 
code to deal with these issues on the XGate and S12X and see whether there's:
   1) No problem
   2) Looks promising
   3) No hope
and proceed from there.
	>-Dan White
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
>Doron Fael
>Sent: Thursday, February 23, 2006 6:24 AM
>To: 68HC12@68HC...
>Subject: Re: [68HC12] XGATE??
>
>
>Adrian,
>
>Yes, you an use the XGate to generate more Output Compare outputs, and the
>XGate code would probably be also pretty compact.
>
>However, the timing generated, would not be 100% accurate, and that's
>because the XGate instruction processing depends on the S12X CPU usage of
>the memory resources.
>For example, if when the XGate executes from the internal RAM, it will
>usually execute 2 XGate instructions during every S12X ECLK cycle. During
>ECLK cycles in which the S12X CPU accesses the internal RAM however, the
>XGate will execute only 1 instruction during the specific ECLK cycle. Thus
>there is some variance in the exact XGate execution time depending on how
>much the S12X CPU happens to access the internal RAM at the moment the
>XGate processes the timer interrupt.
>
>There are even more XGate timing complications, when the XGate executes
>from the internal Flash, or when the XGate accesses one of the PRU register
>(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).
>
>Also keep in mind that the interrupt latency is variable, and that on the
>current S12XD family the XGate can only process one interrupt at a time, so
>it would not service another interrupt until it completes processing the
>previous interrupt (on future S12X devices, there would be provision to
>nest XGate interrupts to one level).
>
>So the bottom line is, yes the XGate can generate output-compare outputs,
>but there would be some variance in the response time from the the timer
>interrupt, till the appropriate output changes (normally up to 1uSEC, but
>could get much higher if the XGate would be configured to serve several
>interrupt sources, with no appropriate interrupts synchronization to the
>timer interrupt).
>
>Hope this helps,
>Doron
>Nohau
>HC12 In-Circuit Emulators
>www.nohau.com/emul12pc.html
>
>At 14:57 23/02/2006 +1100, you wrote:
> >Hi All,
> >
> >I am in need of more output compare style ECT outputs than the standard
S12
> >supports. I was thinking that I could achieve this by dedicating one
> >standard OC channel to do all the timer work and generate interrupts,
and
> >then using a clever software approach with linked lists of pending
timer
> >events with a pointer to a general purpose output that it would perform
the
> >timer event upon during the interrupt. There would be some overhead in
>this,
> >and a delay time to toggle an output, but in theory I could then
produce as
> >many outputs as I have general purpose outputs spare.
> >
> >I was just looking at data sheets for an XGATE processor, and it states
>that
> >the XGATE can be configured to respond to interrupts, do very fast
> >processing based upon the interrupt, and then manipulate peripherals
such
>as
> >general purpose outputs. I was wondering if anyone who has used the
XGATE
> >could comment on whether the XGATE could be configured (programmed) to
> >simulate more ECT style output compares as mentioned above with minimal
CPU
> >overhead, and minmal delay in the time from a couter value being
reached to
> >the output toggling. Basically the XGATE would respond the an ECT OC
> >interrupt, and then access RAM to find out which pin needs to be
toggled
>and
> >in which direction, and then do this toggle, and then setup the OC
channel
> >for the next OC event which could be worked out from a data structure
in
> >RAM.
> >
> >Is this possible??
> >
> >Of course, I could just go to a different processor with more timer
>outputs,
> >but I like working with the S12, and it has everything I need except
more
> >output compare channels, and it is cheap!!
> >
> >-- Adrian
> >
> >Send instant messages to your online friends
http://au.messenger.yahoo.com
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
	
Dan,

Interrupt latency is complex to explain, but I will try.

Assuming no other interrupt is being processed currently, the XGate 
interrupt latency is much shorter than the S12X's. Reason is the S12X first 
needs store its CPU registers on the stack (registers PC, D, X, Y, and 
CCR), at the ECLK bus-speed rate, before it starts processing the actual 
interrupt. The XGate on the other hand, does not need to store any register 
on any stack - it immediately starts executing the interrupt service 
routine - most of the time at twice the ECLK bus speed - when executing 
from the internal RAM.

Another factor influencing the interrupt latency on the S12X, is that the 
current instruction must be completed before the CPU would start the 
register stacking for the new interrupt that has arrived. The S12X CPU is 
CISC, meaning different instructions have different execution time (some 
only 1 ECLK, some can reach even 10 ECLKs or more), so there is variance in 
the S12X interrupt latency based on the currently executed instruction at 
the moment a new interrupt arrives.

So, assuming only one interrupt service routine exists, the XGate interrupt 
latency is much better than the S12X interrupt latency, and is more 
predictable too.
	Things get more complicated when the applicable CPU already processes an 
interrupt:

In the case of the S12X, a new interrupt cannot be processed before the 
S12X clears the I bit in the CCR register during a currently handled 
interrupt service routine,  to allow processing a new interrupt while 
already processing the current interrupt - so the latency in this case can 
vary a lot depending on what is the current execution stage of the S12X in 
the currently handled interrupt (before the clear of the CCR register
"I" 
bit or after). This is also subjected to the new interrupt having a higher 
priority than the currently handled interrupt - as assigned in the S12X 
interrupt controller module.

In case of the XGate, on the current S12XD family, a new interrupt will 
simply not be handled by the XGate until the previous interrupt service 
routine is completed. So the latency can be very long if another interrupt 
is handled by the XGate when the new interrupt arrives. On a future S12X 
family currently in late cooking stages, things would be better, and XGate 
interrupts will have the ability to be nested one level deep based on the 
assigned interrupt priority - with very fast (immediate) switching of the 
interrupt service routines, and no need for register stacking.

I agree with Steve Russell (as always), that best way would be to sketch 
the needed interrupts, their assignment to the S12X or XGate, the expected 
resulting interrupt latency from the interrupt assignment, and calculating 
and experimenting around the worst case jitter in the generated output 
following the interrupt.

Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
	At 13:18 23/02/2006 -0500, you wrote:
>Adrian,
>Doron's answer is good as usual. Another alternative you could consider
>would be to keep the OC pin control in the S12X CPU. You would use a high
>interrupt priority and re-enable interrupts in all of your lower priority
>ISRs. I haven't tried this, so I can't comment on the relative delay but at
>least the latency would be more consistent and predictable. Maybe then you
>could consider using the Xgate for your other interrupts instead.
>
>Doron (or anyone else), do you have any information on the relative
>interrupt latencies of these two alternatives?
>
>-Dan White
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
>Doron Fael
>Sent: Thursday, February 23, 2006 6:24 AM
>To: 68HC12@68HC...
>Subject: Re: [68HC12] XGATE??
>
>
>Adrian,
>
>Yes, you an use the XGate to generate more Output Compare outputs, and the
>XGate code would probably be also pretty compact.
>
>However, the timing generated, would not be 100% accurate, and that's
>because the XGate instruction processing depends on the S12X CPU usage of
>the memory resources.
>For example, if when the XGate executes from the internal RAM, it will
>usually execute 2 XGate instructions during every S12X ECLK cycle. During
>ECLK cycles in which the S12X CPU accesses the internal RAM however, the
>XGate will execute only 1 instruction during the specific ECLK cycle. Thus
>there is some variance in the exact XGate execution time depending on how
>much the S12X CPU happens to access the internal RAM at the moment the
>XGate processes the timer interrupt.
>
>There are even more XGate timing complications, when the XGate executes
>from the internal Flash, or when the XGate accesses one of the PRU register
>(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).
>
>Also keep in mind that the interrupt latency is variable, and that on the
>current S12XD family the XGate can only process one interrupt at a time, so
>it would not service another interrupt until it completes processing the
>previous interrupt (on future S12X devices, there would be provision to
>nest XGate interrupts to one level).
>
>So the bottom line is, yes the XGate can generate output-compare outputs,
>but there would be some variance in the response time from the the timer
>interrupt, till the appropriate output changes (normally up to 1uSEC, but
>could get much higher if the XGate would be configured to serve several
>interrupt sources, with no appropriate interrupts synchronization to the
>timer interrupt).
>
>Hope this helps,
>Doron
>Nohau
>HC12 In-Circuit Emulators
>www.nohau.com/emul12pc.html
>
>At 14:57 23/02/2006 +1100, you wrote:
> >Hi All,
> >
> >I am in need of more output compare style ECT outputs than the standard
S12
> >supports. I was thinking that I could achieve this by dedicating one
> >standard OC channel to do all the timer work and generate interrupts,
and
> >then using a clever software approach with linked lists of pending
timer
> >events with a pointer to a general purpose output that it would perform
the
> >timer event upon during the interrupt. There would be some overhead in
>this,
> >and a delay time to toggle an output, but in theory I could then
produce as
> >many outputs as I have general purpose outputs spare.
> >
> >I was just looking at data sheets for an XGATE processor, and it states
>that
> >the XGATE can be configured to respond to interrupts, do very fast
> >processing based upon the interrupt, and then manipulate peripherals
such
>as
> >general purpose outputs. I was wondering if anyone who has used the
XGATE
> >could comment on whether the XGATE could be configured (programmed) to
> >simulate more ECT style output compares as mentioned above with minimal
CPU
> >overhead, and minmal delay in the time from a couter value being
reached to
> >the output toggling. Basically the XGATE would respond the an ECT OC
> >interrupt, and then access RAM to find out which pin needs to be
toggled
>and
> >in which direction, and then do this toggle, and then setup the OC
channel
> >for the next OC event which could be worked out from a data structure
in
> >RAM.
> >
> >Is this possible??
> >
> >Of course, I could just go to a different processor with more timer
>outputs,
> >but I like working with the S12, and it has everything I need except
more
> >output compare channels, and it is cheap!!
> >
> >-- Adrian
	
	
Thanks for the excellent responses.

Currently I am able to do everything I need to do in a 25MHz S12 with ECT, 
so I imagine that I should have plenty of processing power in the CPU of a 
40MHz S12X to do everything I need plus more if the XGATE is handling 
everything related to ECT functions. My plans would be to only use the XGATE 
for ECT functions, so it would only be handling one interrupt. I can cope 
with up to about a 5us delay from a OC match to the toggling of the pin (but 
I suspect I can achieve much better than this). I would plan to run the 
timers with a resolution of about 5us anyway, so this is only one timer bit.

Now I am trying to grasp an understanding of the workings of the XGATE, and 
my assumption is that to implement an OC in the XGATE, I would have to do 
the following:

* I can't see that the XGATE has any resources within itself to do timing 
events, so one OC of the general ECT would have to be allocated to be 
controlled by the XGATE, and it could use this to generate interrupts at 
required times... this is the biggest question for me... must the XGATE use 
an OC channel of the ECT to generate interrupts sychronised to the ECT 16 
bit counter? Is it an option (if the XGATE is doing nothing else)to use the 
XGATE to poll the ECT freerunning counter, and therefore not use interrupts 
at all, and perform the OC logic by brute force polling technique... no 
interrupt latency, just processing time latency. Basically the XGATE would 
spend all of its time running through an array of OC events setup by the CPU 
and comparing the times to the ECT freerunning counter. If it senses a 
match, it would then act upon that by toggling pins and generateing CPU 
interrupts. Given the realtively slow ECT timer resolution of 5us, the XGATE 
should be able to scan through tens of 16bit OC timer compares per ECT timer 
increment. Basically it would poll the ECT timer to wait for a transition, 
and then compare the new ECT timer value to all the OC channels? Is this 
possible??
* Implement some ram that is used by the CPU to store desired OC info such 
as mode (toggle/rising/falling edge) and time of compare and whether an 
interrupt is generated.
* When the XGATE generates an output edge, can it trigger an interrupt that 
the CPU can respond to like it responds to a generic ECT OC... basically an 
interrupt of known source (OC channel) so it can then generate a new OC in 
response? Ideally there would be multiple interrupt sources that can be 
generated by the XGATE to generate different vectored interrupts in the CPU, 
but almost as effective is a single interrupt source, and using some RAM for 
the CPU interrupt to work out the interrupt source inside the interrupt.

Now is all this possible, or is my understanding of how the XGATE works a 
dream that could not be achieved?

Thanks again for the help!!

-- Adrian
	----- Original Message ----- 
From: "Steve Russell" <stever@stev...>
To: <68HC12@68HC...>
Sent: Friday, February 24, 2006 7:31 AM
Subject: RE: [68HC12] XGATE??
	> Adrian and Dan,
>
> A note on interrupt latency below.
>
>     Steve Russell
>     Nohau
>
> At 10:18 AM 2/23/2006, "Daniel White" <d_white@d_wh...>
wrote:
>>Adrian,
>>Doron's answer is good as usual. Another alternative you could consider
>>would be to keep the OC pin control in the S12X CPU. You would use a
high
>>interrupt priority and re-enable interrupts in all of your lower
priority
>>ISRs. I haven't tried this, so I can't comment on the relative delay but

>>at
>>least the latency would be more consistent and predictable. Maybe then
you
>>could consider using the Xgate for your other interrupts instead.
>>
>>Doron (or anyone else), do you have any information on the relative
>>interrupt latencies of these two alternatives?
>
> The real problem on interrupt latency is what other interrupts are 
> interfering.
>
> I believe that if there are no other XGate interrupts enabled, the XGate
> will be faster to the first instruction of the interrupt service than the
> highest priority S12X interrupt.
>
> However, the important issue in this case is how long until the tasks
> required to insure consistent timing of the output and the next interrupt,
> so you have to sketch out the code on each processor to get an answer.
>
> When you may have to wait for another XGate interrupt to complete or a
> higher priority S12X interrupt to complete, the situation is more
> complicated, but you can be confident that the latency will be much worse.
>
> I suggest starting with the allowable latency and jitter for the 
> individual
> interrupt response, and the allowable errors in timing.  Sketch out the
> code to deal with these issues on the XGate and S12X and see whether 
> there's:
>   1) No problem
>   2) Looks promising
>   3) No hope
> and proceed from there.
>
>
>>-Dan White
>>
>>-----Original Message-----
>>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
>>Doron Fael
>>Sent: Thursday, February 23, 2006 6:24 AM
>>To: 68HC12@68HC...
>>Subject: Re: [68HC12] XGATE??
>>
>>
>>Adrian,
>>
>>Yes, you an use the XGate to generate more Output Compare outputs, and
the
>>XGate code would probably be also pretty compact.
>>
>>However, the timing generated, would not be 100% accurate, and that's
>>because the XGate instruction processing depends on the S12X CPU usage
of
>>the memory resources.
>>For example, if when the XGate executes from the internal RAM, it will
>>usually execute 2 XGate instructions during every S12X ECLK cycle.
During
>>ECLK cycles in which the S12X CPU accesses the internal RAM however, the
>>XGate will execute only 1 instruction during the specific ECLK cycle.
Thus
>>there is some variance in the exact XGate execution time depending on
how
>>much the S12X CPU happens to access the internal RAM at the moment the
>>XGate processes the timer interrupt.
>>
>>There are even more XGate timing complications, when the XGate executes
>>from the internal Flash, or when the XGate accesses one of the PRU 
>>register
>>(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).
>>
>>Also keep in mind that the interrupt latency is variable, and that on
the
>>current S12XD family the XGate can only process one interrupt at a time,

>>so
>>it would not service another interrupt until it completes processing the
>>previous interrupt (on future S12X devices, there would be provision to
>>nest XGate interrupts to one level).
>>
>>So the bottom line is, yes the XGate can generate output-compare
outputs,
>>but there would be some variance in the response time from the the timer
>>interrupt, till the appropriate output changes (normally up to 1uSEC,
but
>>could get much higher if the XGate would be configured to serve several
>>interrupt sources, with no appropriate interrupts synchronization to the
>>timer interrupt).
>>
>>Hope this helps,
>>Doron
>>Nohau
>>HC12 In-Circuit Emulators
>>www.nohau.com/emul12pc.html
>>
>>At 14:57 23/02/2006 +1100, you wrote:
>> >Hi All,
>> >
>> >I am in need of more output compare style ECT outputs than the
standard 
>> >S12
>> >supports. I was thinking that I could achieve this by dedicating
one
>> >standard OC channel to do all the timer work and generate
interrupts, 
>> >and
>> >then using a clever software approach with linked lists of pending
timer
>> >events with a pointer to a general purpose output that it would
perform 
>> >the
>> >timer event upon during the interrupt. There would be some overhead
in
>>this,
>> >and a delay time to toggle an output, but in theory I could then
produce 
>> >as
>> >many outputs as I have general purpose outputs spare.
>> >
>> >I was just looking at data sheets for an XGATE processor, and it
states
>>that
>> >the XGATE can be configured to respond to interrupts, do very fast
>> >processing based upon the interrupt, and then manipulate
peripherals 
>> >such
>>as
>> >general purpose outputs. I was wondering if anyone who has used the

>> >XGATE
>> >could comment on whether the XGATE could be configured (programmed)
to
>> >simulate more ECT style output compares as mentioned above with
minimal 
>> >CPU
>> >overhead, and minmal delay in the time from a couter value being
reached 
>> >to
>> >the output toggling. Basically the XGATE would respond the an ECT
OC
>> >interrupt, and then access RAM to find out which pin needs to be
toggled
>>and
>> >in which direction, and then do this toggle, and then setup the OC 
>> >channel
>> >for the next OC event which could be worked out from a data
structure in
>> >RAM.
>> >
>> >Is this possible??
>> >
>> >Of course, I could just go to a different processor with more timer
>>outputs,
>> >but I like working with the S12, and it has everything I need
except 
>> >more
>> >output compare channels, and it is cheap!!
>> >
>> >-- Adrian
>> >
>> >Send instant messages to your online friends 
>> >http://au.messenger.yahoo.com
>> >
>> >
>> >
>> >Yahoo! Groups Links
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
> 

Send instant messages to your online friends http://au.messenger.yahoo.com 

No, you can not poll in the XGATE. It only runs in response to an
interrupt.
Configure your OC interrupt to be handled by the XGATE. That part is not
hard.

Yes, you can trigger an S12X CPU interrupt from the XGATE in its ISR.

I also have another idea for you. This would only work because you said that
the XGATE would only be handling one interrupt. If you really need tight
synchronization with the ECT timer, you could set the OC to start the XGATE
one (or more if your timer was running faster) timer tick before it actually
needs to update. Then your XGATE thread would wait for the timer change to
the correct value before toggling the appropriate port pin. With a 5uS timer
tick, you probably don't need this but, I give it to you anyway.

This sounds like a good application for the XGATE because you don't need
nested or multiple interrupts.

-Dan

-----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
Adrian Vos
Sent: Thursday, February 23, 2006 5:55 PM
To: 68HC12@68HC...
Subject: Re: [68HC12] XGATE??
	Thanks for the excellent responses.

Currently I am able to do everything I need to do in a 25MHz S12 with ECT,
so I imagine that I should have plenty of processing power in the CPU of a
40MHz S12X to do everything I need plus more if the XGATE is handling
everything related to ECT functions. My plans would be to only use the XGATE
for ECT functions, so it would only be handling one interrupt. I can cope
with up to about a 5us delay from a OC match to the toggling of the pin (but
I suspect I can achieve much better than this). I would plan to run the
timers with a resolution of about 5us anyway, so this is only one timer bit.

Now I am trying to grasp an understanding of the workings of the XGATE, and
my assumption is that to implement an OC in the XGATE, I would have to do
the following:

* I can't see that the XGATE has any resources within itself to do timing
events, so one OC of the general ECT would have to be allocated to be
controlled by the XGATE, and it could use this to generate interrupts at
required times... this is the biggest question for me... must the XGATE use
an OC channel of the ECT to generate interrupts sychronised to the ECT 16
bit counter? Is it an option (if the XGATE is doing nothing else)to use the
XGATE to poll the ECT freerunning counter, and therefore not use interrupts
at all, and perform the OC logic by brute force polling technique... no
interrupt latency, just processing time latency. Basically the XGATE would
spend all of its time running through an array of OC events setup by the CPU
and comparing the times to the ECT freerunning counter. If it senses a
match, it would then act upon that by toggling pins and generateing CPU
interrupts. Given the realtively slow ECT timer resolution of 5us, the XGATE
should be able to scan through tens of 16bit OC timer compares per ECT timer
increment. Basically it would poll the ECT timer to wait for a transition,
and then compare the new ECT timer value to all the OC channels? Is this
possible??
* Implement some ram that is used by the CPU to store desired OC info such
as mode (toggle/rising/falling edge) and time of compare and whether an
interrupt is generated.
* When the XGATE generates an output edge, can it trigger an interrupt that
the CPU can respond to like it responds to a generic ECT OC... basically an
interrupt of known source (OC channel) so it can then generate a new OC in
response? Ideally there would be multiple interrupt sources that can be
generated by the XGATE to generate different vectored interrupts in the CPU,
but almost as effective is a single interrupt source, and using some RAM for
the CPU interrupt to work out the interrupt source inside the interrupt.

Now is all this possible, or is my understanding of how the XGATE works a
dream that could not be achieved?

Thanks again for the help!!

-- Adrian
	----- Original Message -----
From: "Steve Russell" <stever@stev...>
To: <68HC12@68HC...>
Sent: Friday, February 24, 2006 7:31 AM
Subject: RE: [68HC12] XGATE??
	> Adrian and Dan,
>
> A note on interrupt latency below.
>
>     Steve Russell
>     Nohau
>
> At 10:18 AM 2/23/2006, "Daniel White" <d_white@d_wh...>
wrote:
>>Adrian,
>>Doron's answer is good as usual. Another alternative you could consider
>>would be to keep the OC pin control in the S12X CPU. You would use a
high
>>interrupt priority and re-enable interrupts in all of your lower
priority
>>ISRs. I haven't tried this, so I can't comment on the relative delay but
>>at
>>least the latency would be more consistent and predictable. Maybe then
you
>>could consider using the Xgate for your other interrupts instead.
>>
>>Doron (or anyone else), do you have any information on the relative
>>interrupt latencies of these two alternatives?
>
> The real problem on interrupt latency is what other interrupts are
> interfering.
>
> I believe that if there are no other XGate interrupts enabled, the XGate
> will be faster to the first instruction of the interrupt service than the
> highest priority S12X interrupt.
>
> However, the important issue in this case is how long until the tasks
> required to insure consistent timing of the output and the next interrupt,
> so you have to sketch out the code on each processor to get an answer.
>
> When you may have to wait for another XGate interrupt to complete or a
> higher priority S12X interrupt to complete, the situation is more
> complicated, but you can be confident that the latency will be much worse.
>
> I suggest starting with the allowable latency and jitter for the
> individual
> interrupt response, and the allowable errors in timing.  Sketch out the
> code to deal with these issues on the XGate and S12X and see whether
> there's:
>   1) No problem
>   2) Looks promising
>   3) No hope
> and proceed from there.
>
>
>>-Dan White
>>
>>-----Original Message-----
>>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
>>Doron Fael
>>Sent: Thursday, February 23, 2006 6:24 AM
>>To: 68HC12@68HC...
>>Subject: Re: [68HC12] XGATE??
>>
>>
>>Adrian,
>>
>>Yes, you an use the XGate to generate more Output Compare outputs, and
the
>>XGate code would probably be also pretty compact.
>>
>>However, the timing generated, would not be 100% accurate, and that's
>>because the XGate instruction processing depends on the S12X CPU usage
of
>>the memory resources.
>>For example, if when the XGate executes from the internal RAM, it will
>>usually execute 2 XGate instructions during every S12X ECLK cycle.
During
>>ECLK cycles in which the S12X CPU accesses the internal RAM however, the
>>XGate will execute only 1 instruction during the specific ECLK cycle.
Thus
>>there is some variance in the exact XGate execution time depending on
how
>>much the S12X CPU happens to access the internal RAM at the moment the
>>XGate processes the timer interrupt.
>>
>>There are even more XGate timing complications, when the XGate executes
>>from the internal Flash, or when the XGate accesses one of the PRU
>>register
>>(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).
>>
>>Also keep in mind that the interrupt latency is variable, and that on
the
>>current S12XD family the XGate can only process one interrupt at a time,
>>so
>>it would not service another interrupt until it completes processing the
>>previous interrupt (on future S12X devices, there would be provision to
>>nest XGate interrupts to one level).
>>
>>So the bottom line is, yes the XGate can generate output-compare
outputs,
>>but there would be some variance in the response time from the the timer
>>interrupt, till the appropriate output changes (normally up to 1uSEC,
but
>>could get much higher if the XGate would be configured to serve several
>>interrupt sources, with no appropriate interrupts synchronization to the
>>timer interrupt).
>>
>>Hope this helps,
>>Doron
>>Nohau
>>HC12 In-Circuit Emulators
>>www.nohau.com/emul12pc.html
>>
>>At 14:57 23/02/2006 +1100, you wrote:
>> >Hi All,
>> >
>> >I am in need of more output compare style ECT outputs than the
standard
>> >S12
>> >supports. I was thinking that I could achieve this by dedicating
one
>> >standard OC channel to do all the timer work and generate
interrupts,
>> >and
>> >then using a clever software approach with linked lists of pending
timer
>> >events with a pointer to a general purpose output that it would
perform
>> >the
>> >timer event upon during the interrupt. There would be some overhead
in
>>this,
>> >and a delay time to toggle an output, but in theory I could then
produce
>> >as
>> >many outputs as I have general purpose outputs spare.
>> >
>> >I was just looking at data sheets for an XGATE processor, and it
states
>>that
>> >the XGATE can be configured to respond to interrupts, do very fast
>> >processing based upon the interrupt, and then manipulate
peripherals
>> >such
>>as
>> >general purpose outputs. I was wondering if anyone who has used the
>> >XGATE
>> >could comment on whether the XGATE could be configured (programmed)
to
>> >simulate more ECT style output compares as mentioned above with
minimal
>> >CPU
>> >overhead, and minmal delay in the time from a couter value being
reached
>> >to
>> >the output toggling. Basically the XGATE would respond the an ECT
OC
>> >interrupt, and then access RAM to find out which pin needs to be
toggled
>>and
>> >in which direction, and then do this toggle, and then setup the OC
>> >channel
>> >for the next OC event which could be worked out from a data
structure in
>> >RAM.
>> >
>> >Is this possible??
>> >
>> >Of course, I could just go to a different processor with more timer
>>outputs,
>> >but I like working with the S12, and it has everything I need
except
>> >more
>> >output compare channels, and it is cheap!!
>> >
>> >-- Adrian
>> >
>> >Send instant messages to your online friends
>> >http://au.messenger.yahoo.com
>> >
>> >
>> >
>> >Yahoo! Groups Links
>> >
>> >
>> >
>> >
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

Send instant messages to your online friends http://au.messenger.yahoo.com
	Yahoo! Groups Links
	
Does the XGATE have the option to never return from an interrupt that you 
trigger once on initial startup? I know this does not sound efficient, but 
if the XGATE is doing nothing else, why not have it sit and poll the ECT 
timer?

-- Adrian

----- Original Message ----- 
From: "Daniel White" <d_white@d_wh...>
To: <68HC12@68HC...>
Sent: Friday, February 24, 2006 10:24 AM
Subject: RE: [68HC12] XGATE??
	> No, you can not poll in the XGATE. It only runs in response to an 
> interrupt.
> Configure your OC interrupt to be handled by the XGATE. That part is not
> hard.
>
> Yes, you can trigger an S12X CPU interrupt from the XGATE in its ISR.
>
> I also have another idea for you. This would only work because you said 
> that
> the XGATE would only be handling one interrupt. If you really need tight
> synchronization with the ECT timer, you could set the OC to start the 
> XGATE
> one (or more if your timer was running faster) timer tick before it 
> actually
> needs to update. Then your XGATE thread would wait for the timer change to
> the correct value before toggling the appropriate port pin. With a 5uS 
> timer
> tick, you probably don't need this but, I give it to you anyway.
>
> This sounds like a good application for the XGATE because you don't need
> nested or multiple interrupts.
>
> -Dan
>
> -----Original Message-----
> From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
> Adrian Vos
> Sent: Thursday, February 23, 2006 5:55 PM
> To: 68HC12@68HC...
> Subject: Re: [68HC12] XGATE??
>
>
> Thanks for the excellent responses.
>
> Currently I am able to do everything I need to do in a 25MHz S12 with ECT,
> so I imagine that I should have plenty of processing power in the CPU of a
> 40MHz S12X to do everything I need plus more if the XGATE is handling
> everything related to ECT functions. My plans would be to only use the 
> XGATE
> for ECT functions, so it would only be handling one interrupt. I can cope
> with up to about a 5us delay from a OC match to the toggling of the pin 
> (but
> I suspect I can achieve much better than this). I would plan to run the
> timers with a resolution of about 5us anyway, so this is only one timer 
> bit.
>
> Now I am trying to grasp an understanding of the workings of the XGATE, 
> and
> my assumption is that to implement an OC in the XGATE, I would have to do
> the following:
>
> * I can't see that the XGATE has any resources within itself to do timing
> events, so one OC of the general ECT would have to be allocated to be
> controlled by the XGATE, and it could use this to generate interrupts at
> required times... this is the biggest question for me... must the XGATE 
> use
> an OC channel of the ECT to generate interrupts sychronised to the ECT 16
> bit counter? Is it an option (if the XGATE is doing nothing else)to use 
> the
> XGATE to poll the ECT freerunning counter, and therefore not use 
> interrupts
> at all, and perform the OC logic by brute force polling technique... no
> interrupt latency, just processing time latency. Basically the XGATE would
> spend all of its time running through an array of OC events setup by the 
> CPU
> and comparing the times to the ECT freerunning counter. If it senses a
> match, it would then act upon that by toggling pins and generateing CPU
> interrupts. Given the realtively slow ECT timer resolution of 5us, the 
> XGATE
> should be able to scan through tens of 16bit OC timer compares per ECT 
> timer
> increment. Basically it would poll the ECT timer to wait for a transition,
> and then compare the new ECT timer value to all the OC channels? Is this
> possible??
> * Implement some ram that is used by the CPU to store desired OC info such
> as mode (toggle/rising/falling edge) and time of compare and whether an
> interrupt is generated.
> * When the XGATE generates an output edge, can it trigger an interrupt 
> that
> the CPU can respond to like it responds to a generic ECT OC... basically 
> an
> interrupt of known source (OC channel) so it can then generate a new OC in
> response? Ideally there would be multiple interrupt sources that can be
> generated by the XGATE to generate different vectored interrupts in the 
> CPU,
> but almost as effective is a single interrupt source, and using some RAM 
> for
> the CPU interrupt to work out the interrupt source inside the interrupt.
>
> Now is all this possible, or is my understanding of how the XGATE works a
> dream that could not be achieved?
>
> Thanks again for the help!!
>
> -- Adrian
>
>
> ----- Original Message -----
> From: "Steve Russell" <stever@stev...>
> To: <68HC12@68HC...>
> Sent: Friday, February 24, 2006 7:31 AM
> Subject: RE: [68HC12] XGATE??
>
>
>> Adrian and Dan,
>>
>> A note on interrupt latency below.
>>
>>     Steve Russell
>>     Nohau
>>
>> At 10:18 AM 2/23/2006, "Daniel White" <d_white@d_wh...>
wrote:
>>>Adrian,
>>>Doron's answer is good as usual. Another alternative you could
consider
>>>would be to keep the OC pin control in the S12X CPU. You would use a
high
>>>interrupt priority and re-enable interrupts in all of your lower
priority
>>>ISRs. I haven't tried this, so I can't comment on the relative delay
but
>>>at
>>>least the latency would be more consistent and predictable. Maybe
then 
>>>you
>>>could consider using the Xgate for your other interrupts instead.
>>>
>>>Doron (or anyone else), do you have any information on the relative
>>>interrupt latencies of these two alternatives?
>>
>> The real problem on interrupt latency is what other interrupts are
>> interfering.
>>
>> I believe that if there are no other XGate interrupts enabled, the
XGate
>> will be faster to the first instruction of the interrupt service than
the
>> highest priority S12X interrupt.
>>
>> However, the important issue in this case is how long until the tasks
>> required to insure consistent timing of the output and the next 
>> interrupt,
>> so you have to sketch out the code on each processor to get an answer.
>>
>> When you may have to wait for another XGate interrupt to complete or a
>> higher priority S12X interrupt to complete, the situation is more
>> complicated, but you can be confident that the latency will be much 
>> worse.
>>
>> I suggest starting with the allowable latency and jitter for the
>> individual
>> interrupt response, and the allowable errors in timing.  Sketch out the
>> code to deal with these issues on the XGate and S12X and see whether
>> there's:
>>   1) No problem
>>   2) Looks promising
>>   3) No hope
>> and proceed from there.
>>
>>
>>>-Dan White
>>>
>>>-----Original Message-----
>>>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
>>>Doron Fael
>>>Sent: Thursday, February 23, 2006 6:24 AM
>>>To: 68HC12@68HC...
>>>Subject: Re: [68HC12] XGATE??
>>>
>>>
>>>Adrian,
>>>
>>>Yes, you an use the XGate to generate more Output Compare outputs,
and 
>>>the
>>>XGate code would probably be also pretty compact.
>>>
>>>However, the timing generated, would not be 100% accurate, and
that's
>>>because the XGate instruction processing depends on the S12X CPU
usage of
>>>the memory resources.
>>>For example, if when the XGate executes from the internal RAM, it
will
>>>usually execute 2 XGate instructions during every S12X ECLK cycle.
During
>>>ECLK cycles in which the S12X CPU accesses the internal RAM however,
the
>>>XGate will execute only 1 instruction during the specific ECLK
cycle. 
>>>Thus
>>>there is some variance in the exact XGate execution time depending
on how
>>>much the S12X CPU happens to access the internal RAM at the moment
the
>>>XGate processes the timer interrupt.
>>>
>>>There are even more XGate timing complications, when the XGate
executes
>>>from the internal Flash, or when the XGate accesses one of the PRU
>>>register
>>>(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).
>>>
>>>Also keep in mind that the interrupt latency is variable, and that
on the
>>>current S12XD family the XGate can only process one interrupt at a
time,
>>>so
>>>it would not service another interrupt until it completes processing
the
>>>previous interrupt (on future S12X devices, there would be provision
to
>>>nest XGate interrupts to one level).
>>>
>>>So the bottom line is, yes the XGate can generate output-compare
outputs,
>>>but there would be some variance in the response time from the the
timer
>>>interrupt, till the appropriate output changes (normally up to
1uSEC, but
>>>could get much higher if the XGate would be configured to serve
several
>>>interrupt sources, with no appropriate interrupts synchronization to
the
>>>timer interrupt).
>>>
>>>Hope this helps,
>>>Doron
>>>Nohau
>>>HC12 In-Circuit Emulators
>>>www.nohau.com/emul12pc.html
>>>
>>>At 14:57 23/02/2006 +1100, you wrote:
>>> >Hi All,
>>> >
>>> >I am in need of more output compare style ECT outputs than the
standard
>>> >S12
>>> >supports. I was thinking that I could achieve this by
dedicating one
>>> >standard OC channel to do all the timer work and generate
interrupts,
>>> >and
>>> >then using a clever software approach with linked lists of
pending 
>>> >timer
>>> >events with a pointer to a general purpose output that it would
perform
>>> >the
>>> >timer event upon during the interrupt. There would be some
overhead in
>>>this,
>>> >and a delay time to toggle an output, but in theory I could
then 
>>> >produce
>>> >as
>>> >many outputs as I have general purpose outputs spare.
>>> >
>>> >I was just looking at data sheets for an XGATE processor, and
it states
>>>that
>>> >the XGATE can be configured to respond to interrupts, do very
fast
>>> >processing based upon the interrupt, and then manipulate
peripherals
>>> >such
>>>as
>>> >general purpose outputs. I was wondering if anyone who has used
the
>>> >XGATE
>>> >could comment on whether the XGATE could be configured
(programmed) to
>>> >simulate more ECT style output compares as mentioned above with
minimal
>>> >CPU
>>> >overhead, and minmal delay in the time from a couter value
being 
>>> >reached
>>> >to
>>> >the output toggling. Basically the XGATE would respond the an
ECT OC
>>> >interrupt, and then access RAM to find out which pin needs to
be 
>>> >toggled
>>>and
>>> >in which direction, and then do this toggle, and then setup the
OC
>>> >channel
>>> >for the next OC event which could be worked out from a data
structure 
>>> >in
>>> >RAM.
>>> >
>>> >Is this possible??
>>> >
>>> >Of course, I could just go to a different processor with more
timer
>>>outputs,
>>> >but I like working with the S12, and it has everything I need
except
>>> >more
>>> >output compare channels, and it is cheap!!
>>> >
>>> >-- Adrian
>>> >
>>> >Send instant messages to your online friends
>>> >http://au.messenger.yahoo.com
>>> >
>>> >
>>> >
>>> >Yahoo! Groups Links
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
> 

Send instant messages to your online friends http://au.messenger.yahoo.com 

Adrian,

First a disclaimer:

I have only tinkered a little XGate C code and read the documentation 
several times over the last couple of years.  I may not deal with all the 
details of the XGate correctly, but I'll try.

The XGate and Interrupt sections of the S12X documentation are a small part 
of the whole pile of documentation.  Its worth while to read them in detail 
now, AND later.  My impression is that the documentation is accurate but a 
little terse.  I have not detected any major confusions on the part of the 
authors.

The most confusing parts of the S12X documentation are those things that 
are covered in several different sections.  Helpful references to the other 
sections are not always very prominent.  The XGate interrupt descriptions 
have some of these problems.

Pay careful attention to the examples from Freescale and other sources.

Notes and suggestions below.

I see that some further Emails on this subject have come in while I was 
writing this.  I'll respond to them in a bit.

What compiler and/or assembler are you planning to use?

Please tell us more about your progress.

    Steve Russell
    Nohau Emulators
	At 02:54 PM 2/23/2006, "Adrian Vos" <vosadrian@vosa...> wrote:
>Thanks for the excellent responses.
>
>Currently I am able to do everything I need to do in a 25MHz S12 with ECT,
>so I imagine that I should have plenty of processing power in the CPU of a
>40MHz S12X to do everything I need plus more if the XGATE is handling
>everything related to ECT functions. My plans would be to only use the XGATE
>for ECT functions, so it would only be handling one interrupt.

This should give you good response time.

>I can cope with up to about a 5us delay from a OC
match to the toggling of 
>the pin (but I suspect I can achieve much better than this). I would plan 
>to run the timers with a resolution of about 5us anyway, so this is only 
>one timer bit.

My first guess is that if you run the S12X at 40 MHZ bus clock, you should 
be able to get about 60 XGate instructions executed per microsecond, but 
your mileage may very.

>Now I am trying to grasp an understanding of the
workings of the XGATE, and
>my assumption is that to implement an OC in the XGATE, I would have to do
>the following:
>
>* I can't see that the XGATE has any resources within itself to do timing
>events, so one OC

Note that there are a couple of other timers on the S12X, and that any 
interrupt on the S12X can be routed directly to the XGate, so you could use 
the PIT or the RTI or possibly a PWM channel if you don't have a better use 
for them.

>of the general ECT would have to be allocated to be
controlled by the 
>XGATE, and it could use this to generate interrupts at required times... 
>this is the biggest question for me... must the XGATE use an OC channel of 
>the ECT to generate interrupts sychronised to the ECT 16 bit counter?

No, you can use the PIT, for example.

>Is it an option (if the XGATE is doing nothing
else)to use the XGATE to 
>poll the ECT freerunning counter, and therefore not use interrupts at all, 
>and perform the OC logic by brute force polling technique...

You could, but I don't think that you gain much over using an XGate 
interrupt with the XGate dedicated to one task.  I believe that when the 
interrupt signal comes in, it will get to the XGate in a few clock cycles, 
and the XGate will be off on the first instruction of your code.

>no interrupt latency, just processing time latency.
Basically the XGATE 
>would spend all of its time running through an array of OC events setup by 
>the CPU and comparing the times to the ECT freerunning counter. If it 
>senses a match, it would then act upon that by toggling pins and 
>generateing CPU interrupts. Given the realtively slow ECT timer resolution 
>of 5us, the XGATE should be able to scan through tens of 16bit OC timer 
>compares per ECT timer increment.

This will probably work, but I think that you should at least compare for 
time less than or equal to the current ECT counter so as to avoid killing 
the channel forever if the interrupt service is a little late.

I haven't looked at the fine print, but make sure that the counter that 
your are reading is arranged to give you an accurate number when a carry is 
occurring.  (If the hardware is as simple as just read the counter, reading 
in the middle of a long carry will give you a bad value.  Some counters are 
arranged with buffering that is specially noted in the documentation that 
avoids this problem.)

If you keep the event times in a sorted list or a "heap" (see
textbooks on 
data structures) you may get faster and more consistent response.

>Basically it would poll the ECT timer to wait for a
transition, and then 
>compare the new ECT timer value to all the OC channels? Is this possible??

See just above, about carries.

>* Implement some ram that is used by the CPU to
store desired OC info such
>as mode (toggle/rising/falling edge) and time of compare and whether an
>interrupt is generated.

This is a sticky part.  There are the usual problems about communicating 
with asynchronous interrupt code.  There is also the problem that you would 
like all the manipulation of the data structure to be done by the S12X so 
that the XGate responses aren't stalled by sorting events or other 
housekeeping.

When the S12X is just finishing up making a new entry, and several XGate 
operated compares go off, you have some kind of crisis.  Handling it 
gracefully is a challenge.

My first guess would be to buffer the data so that each processor has its 
own "private" copy of the data, and gives it to the other after its
all 
updated and consistent.

The XGate hardware "Semaphores" are designed to help with this style
of 
communication.

>* When the XGATE generates an output edge, can it
trigger an interrupt that
>the CPU can respond to like it responds to a generic ECT OC... basically an
>interrupt of known source (OC channel) so it can then generate a new OC in
>response? Ideally there would be multiple interrupt sources that can be
>generated by the XGATE to generate different vectored interrupts in the CPU,
>but almost as effective is a single interrupt source, and using some RAM for
>the CPU interrupt to work out the interrupt source inside the interrupt.

The XGate software interrupts will work well for this, but there are only 8 
of them.

The XGate has access to the CPU register block, to if the only action 
required is to toggle an output bit, the XGate can do that in a few cycles 
if the bits are in a PRU port, and fewer cycles if the bit is in another 
port that doesn't force the XGate to take 2 cycles per access.

>Now is all this possible, or is my understanding of
how the XGATE works a
>dream that could not be achieved?

Possible, yes, quick no.  There's a lot to learn.

>Thanks again for the help!!
>
>-- Adrian
>
>
>----- Original Message -----
>From: "Steve Russell" <stever@stev...>
>To: <68HC12@68HC...>
>Sent: Friday, February 24, 2006 7:31 AM
>Subject: RE: [68HC12] XGATE??
>
>
> > Adrian and Dan,
> >
> > A note on interrupt latency below.
> >
> >     Steve Russell
> >     Nohau
> >
> > At 10:18 AM 2/23/2006, "Daniel White"
<d_white@d_wh...> wrote:
> >>Adrian,
> >>Doron's answer is good as usual. Another alternative you could
consider
> >>would be to keep the OC pin control in the S12X CPU. You would use
a high
> >>interrupt priority and re-enable interrupts in all of your lower
priority
> >>ISRs. I haven't tried this, so I can't comment on the relative
delay but
> >>at
> >>least the latency would be more consistent and predictable. Maybe
then you
> >>could consider using the Xgate for your other interrupts instead.
> >>
> >>Doron (or anyone else), do you have any information on the relative
> >>interrupt latencies of these two alternatives?
> >
> > The real problem on interrupt latency is what other interrupts are
> > interfering.
> >
> > I believe that if there are no other XGate interrupts enabled, the
XGate
> > will be faster to the first instruction of the interrupt service than
the
> > highest priority S12X interrupt.
> >
> > However, the important issue in this case is how long until the tasks
> > required to insure consistent timing of the output and the next
interrupt,
> > so you have to sketch out the code on each processor to get an answer.
> >
> > When you may have to wait for another XGate interrupt to complete or a
> > higher priority S12X interrupt to complete, the situation is more
> > complicated, but you can be confident that the latency will be much
worse.
> >
> > I suggest starting with the allowable latency and jitter for the
> > individual
> > interrupt response, and the allowable errors in timing.  Sketch out
the
> > code to deal with these issues on the XGate and S12X and see whether
> > there's:
> >   1) No problem
> >   2) Looks promising
> >   3) No hope
> > and proceed from there.
> >
> >
> >>-Dan White
> >>
> >>-----Original Message-----
> >>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
> >>Doron Fael
> >>Sent: Thursday, February 23, 2006 6:24 AM
> >>To: 68HC12@68HC...
> >>Subject: Re: [68HC12] XGATE??
> >>
> >>
> >>Adrian,
> >>
> >>Yes, you an use the XGate to generate more Output Compare outputs,
and the
> >>XGate code would probably be also pretty compact.
> >>
> >>However, the timing generated, would not be 100% accurate, and
that's
> >>because the XGate instruction processing depends on the S12X CPU
usage of
> >>the memory resources.
> >>For example, if when the XGate executes from the internal RAM, it
will
> >>usually execute 2 XGate instructions during every S12X ECLK cycle.
During
> >>ECLK cycles in which the S12X CPU accesses the internal RAM
however, the
> >>XGate will execute only 1 instruction during the specific ECLK
cycle. Thus
> >>there is some variance in the exact XGate execution time depending
on how
> >>much the S12X CPU happens to access the internal RAM at the moment
the
> >>XGate processes the timer interrupt.
> >>
> >>There are even more XGate timing complications, when the XGate
executes
> >>from the internal Flash, or when the XGate accesses one of the PRU
> >>register
> >>(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).
> >>
> >>Also keep in mind that the interrupt latency is variable, and that
on the
> >>current S12XD family the XGate can only process one interrupt at a
time,
> >>so
> >>it would not service another interrupt until it completes
processing the
> >>previous interrupt (on future S12X devices, there would be
provision to
> >>nest XGate interrupts to one level).
> >>
> >>So the bottom line is, yes the XGate can generate output-compare
outputs,
> >>but there would be some variance in the response time from the the
timer
> >>interrupt, till the appropriate output changes (normally up to
1uSEC, but
> >>could get much higher if the XGate would be configured to serve
several
> >>interrupt sources, with no appropriate interrupts synchronization
to the
> >>timer interrupt).
> >>
> >>Hope this helps,
> >>Doron
> >>Nohau
> >>HC12 In-Circuit Emulators
> >>www.nohau.com/emul12pc.html
> >>
> >>At 14:57 23/02/2006 +1100, you wrote:
> >> >Hi All,
> >> >
> >> >I am in need of more output compare style ECT outputs than the
standard
> >> >S12
> >> >supports. I was thinking that I could achieve this by
dedicating one
> >> >standard OC channel to do all the timer work and generate
interrupts,
> >> >and
> >> >then using a clever software approach with linked lists of
pending timer
> >> >events with a pointer to a general purpose output that it
would perform
> >> >the
> >> >timer event upon during the interrupt. There would be some
overhead in
> >>this,
> >> >and a delay time to toggle an output, but in theory I could
then produce
> >> >as
> >> >many outputs as I have general purpose outputs spare.
> >> >
> >> >I was just looking at data sheets for an XGATE processor, and
it states
> >>that
> >> >the XGATE can be configured to respond to interrupts, do very
fast
> >> >processing based upon the interrupt, and then manipulate
peripherals
> >> >such
> >>as
> >> >general purpose outputs. I was wondering if anyone who has
used the
> >> >XGATE
> >> >could comment on whether the XGATE could be configured
(programmed) to
> >> >simulate more ECT style output compares as mentioned above
with minimal
> >> >CPU
> >> >overhead, and minmal delay in the time from a couter value
being reached
> >> >to
> >> >the output toggling. Basically the XGATE would respond the an
ECT OC
> >> >interrupt, and then access RAM to find out which pin needs to
be toggled
> >>and
> >> >in which direction, and then do this toggle, and then setup
the OC
> >> >channel
> >> >for the next OC event which could be worked out from a data
structure in
> >> >RAM.
> >> >
> >> >Is this possible??
> >> >
> >> >Of course, I could just go to a different processor with more
timer
> >>outputs,
> >> >but I like working with the S12, and it has everything I need
except
> >> >more
> >> >output compare channels, and it is cheap!!
> >> >
> >> >-- Adrian
> >> >
> >> >Send instant messages to your online friends
> >> >http://au.messenger.yahoo.com
> >> >
> >> >
> >> >
> >> >Yahoo! Groups Links
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
>Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
>Yahoo! Groups Links
>
>
>
>
	
Dan and Adrian,

Notes below.

     Steve Russell
     Nohau Emulators
	At 03:24 PM 2/23/2006, "Daniel White" <d_white@d_wh...> wrote:
>No, you can not poll in the XGATE. It only runs in
response to an interrupt.

The XGate can be started without an interrupt by manipulating the control 
registers.

Also you don't have to execute the XGate RTS instruction, so you can loop 
indefinitely in the XGate if you want to (or if you make a mistake).

>Configure your OC interrupt to be handled by the
XGATE. That part is not
>hard.
>
>Yes, you can trigger an S12X CPU interrupt from the XGATE in its ISR.
>
>I also have another idea for you. This would only work because you said that
>the XGATE would only be handling one interrupt. If you really need tight
>synchronization with the ECT timer, you could set the OC to start the XGATE
>one (or more if your timer was running faster) timer tick before it actually
>needs to update. Then your XGATE thread would wait for the timer change to
>the correct value before toggling the appropriate port pin. With a 5uS timer
>tick, you probably don't need this but, I give it to you anyway.
>
>This sounds like a good application for the XGATE because you don't need
>nested or multiple interrupts.
>
>-Dan
>
>-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
>Adrian Vos
>Sent: Thursday, February 23, 2006 5:55 PM
>To: 68HC12@68HC...
>Subject: Re: [68HC12] XGATE??
>
>
>Thanks for the excellent responses.
>
>Currently I am able to do everything I need to do in a 25MHz S12 with ECT,
>so I imagine that I should have plenty of processing power in the CPU of a
>40MHz S12X to do everything I need plus more if the XGATE is handling
>everything related to ECT functions. My plans would be to only use the XGATE
>for ECT functions, so it would only be handling one interrupt. I can cope
>with up to about a 5us delay from a OC match to the toggling of the pin (but
>I suspect I can achieve much better than this). I would plan to run the
>timers with a resolution of about 5us anyway, so this is only one timer bit.
>
>Now I am trying to grasp an understanding of the workings of the XGATE, and
>my assumption is that to implement an OC in the XGATE, I would have to do
>the following:
>
>* I can't see that the XGATE has any resources within itself to do timing
>events, so one OC of the general ECT would have to be allocated to be
>controlled by the XGATE, and it could use this to generate interrupts at
>required times... this is the biggest question for me... must the XGATE use
>an OC channel of the ECT to generate interrupts sychronised to the ECT 16
>bit counter? Is it an option (if the XGATE is doing nothing else)to use the
>XGATE to poll the ECT freerunning counter, and therefore not use interrupts
>at all, and perform the OC logic by brute force polling technique... no
>interrupt latency, just processing time latency. Basically the XGATE would
>spend all of its time running through an array of OC events setup by the CPU
>and comparing the times to the ECT freerunning counter. If it senses a
>match, it would then act upon that by toggling pins and generateing CPU
>interrupts. Given the realtively slow ECT timer resolution of 5us, the XGATE
>should be able to scan through tens of 16bit OC timer compares per ECT timer
>increment. Basically it would poll the ECT timer to wait for a transition,
>and then compare the new ECT timer value to all the OC channels? Is this
>possible??
>* Implement some ram that is used by the CPU to store desired OC info such
>as mode (toggle/rising/falling edge) and time of compare and whether an
>interrupt is generated.
>* When the XGATE generates an output edge, can it trigger an interrupt that
>the CPU can respond to like it responds to a generic ECT OC... basically an
>interrupt of known source (OC channel) so it can then generate a new OC in
>response? Ideally there would be multiple interrupt sources that can be
>generated by the XGATE to generate different vectored interrupts in the CPU,
>but almost as effective is a single interrupt source, and using some RAM for
>the CPU interrupt to work out the interrupt source inside the interrupt.
>
>Now is all this possible, or is my understanding of how the XGATE works a
>dream that could not be achieved?
>
>Thanks again for the help!!
>
>-- Adrian
>
>
>----- Original Message -----
>From: "Steve Russell" <stever@stev...>
>To: <68HC12@68HC...>
>Sent: Friday, February 24, 2006 7:31 AM
>Subject: RE: [68HC12] XGATE??
>
>
> > Adrian and Dan,
> >
> > A note on interrupt latency below.
> >
> >     Steve Russell
> >     Nohau
> >
> > At 10:18 AM 2/23/2006, "Daniel White"
<d_white@d_wh...> wrote:
> >>Adrian,
> >>Doron's answer is good as usual. Another alternative you could
consider
> >>would be to keep the OC pin control in the S12X CPU. You would use
a high
> >>interrupt priority and re-enable interrupts in all of your lower
priority
> >>ISRs. I haven't tried this, so I can't comment on the relative
delay but
> >>at
> >>least the latency would be more consistent and predictable. Maybe
then you
> >>could consider using the Xgate for your other interrupts instead.
> >>
> >>Doron (or anyone else), do you have any information on the relative
> >>interrupt latencies of these two alternatives?
> >
> > The real problem on interrupt latency is what other interrupts are
> > interfering.
> >
> > I believe that if there are no other XGate interrupts enabled, the
XGate
> > will be faster to the first instruction of the interrupt service than
the
> > highest priority S12X interrupt.
> >
> > However, the important issue in this case is how long until the tasks
> > required to insure consistent timing of the output and the next
interrupt,
> > so you have to sketch out the code on each processor to get an answer.
> >
> > When you may have to wait for another XGate interrupt to complete or a
> > higher priority S12X interrupt to complete, the situation is more
> > complicated, but you can be confident that the latency will be much
worse.
> >
> > I suggest starting with the allowable latency and jitter for the
> > individual
> > interrupt response, and the allowable errors in timing.  Sketch out
the
> > code to deal with these issues on the XGate and S12X and see whether
> > there's:
> >   1) No problem
> >   2) Looks promising
> >   3) No hope
> > and proceed from there.
> >
> >
> >>-Dan White
> >>
> >>-----Original Message-----
> >>From: 68HC12@68HC... [mailto:68HC12@68HC...]On Behalf Of
> >>Doron Fael
> >>Sent: Thursday, February 23, 2006 6:24 AM
> >>To: 68HC12@68HC...
> >>Subject: Re: [68HC12] XGATE??
> >>
> >>
> >>Adrian,
> >>
> >>Yes, you an use the XGate to generate more Output Compare outputs,
and the
> >>XGate code would probably be also pretty compact.
> >>
> >>However, the timing generated, would not be 100% accurate, and
that's
> >>because the XGate instruction processing depends on the S12X CPU
usage of
> >>the memory resources.
> >>For example, if when the XGate executes from the internal RAM, it
will
> >>usually execute 2 XGate instructions during every S12X ECLK cycle.
During
> >>ECLK cycles in which the S12X CPU accesses the internal RAM
however, the
> >>XGate will execute only 1 instruction during the specific ECLK
cycle. Thus
> >>there is some variance in the exact XGate execution time depending
on how
> >>much the S12X CPU happens to access the internal RAM at the moment
the
> >>XGate processes the timer interrupt.
> >>
> >>There are even more XGate timing complications, when the XGate
executes
> >>from the internal Flash, or when the XGate accesses one of the PRU
> >>register
> >>(PORT and DDR A, B, C, D, E and K, PUCR, RDRIV and more registers).
> >>
> >>Also keep in mind that the interrupt latency is variable, and that
on the
> >>current S12XD family the XGate can only process one interrupt at a
time,
> >>so
> >>it would not service another interrupt until it completes
processing the
> >>previous interrupt (on future S12X devices, there would be
provision to
> >>nest XGate interrupts to one level).
> >>
> >>So the bottom line is, yes the XGate can generate output-compare
outputs,
> >>but there would be some variance in the response time from the the
timer
> >>interrupt, till the appropriate output changes (normally up to
1uSEC, but
> >>could get much higher if the XGate would be configured to serve
several
> >>interrupt sources, with no appropriate interrupts synchronization
to the
> >>timer interrupt).
> >>
> >>Hope this helps,
> >>Doron
> >>Nohau
> >>HC12 In-Circuit Emulators
> >>www.nohau.com/emul12pc.html
> >>
> >>At 14:57 23/02/2006 +1100, you wrote:
> >> >Hi All,
> >> >
> >> >I am in need of more output compare style ECT outputs than the
standard
> >> >S12
> >> >supports. I was thinking that I could achieve this by
dedicating one
> >> >standard OC channel to do all the timer work and generate
interrupts,
> >> >and
> >> >then using a clever software approach with linked lists of
pending timer
> >> >events with a pointer to a general purpose output that it
would perform
> >> >the
> >> >timer event upon during the interrupt. There would be some
overhead in
> >>this,
> >> >and a delay time to toggle an output, but in theory I could
then produce
> >> >as
> >> >many outputs as I have general purpose outputs spare.
> >> >
> >> >I was just looking at data sheets for an XGATE processor, and
it states
> >>that
> >> >the XGATE can be configured to respond to interrupts, do very
fast
> >> >processing based upon the interrupt, and then manipulate
peripherals
> >> >such
> >>as
> >> >general purpose outputs. I was wondering if anyone who has
used the
> >> >XGATE
> >> >could comment on whether the XGATE could be configured
(programmed) to
> >> >simulate more ECT style output compares as mentioned above
with minimal
> >> >CPU
> >> >overhead, and minmal delay in the time from a couter value
being reached
> >> >to
> >> >the output toggling. Basically the XGATE would respond the an
ECT OC
> >> >interrupt, and then access RAM to find out which pin needs to
be toggled
> >>and
> >> >in which direction, and then do this toggle, and then setup
the OC
> >> >channel
> >> >for the next OC event which could be worked out from a data
structure in
> >> >RAM.
> >> >
> >> >Is this possible??
> >> >
> >> >Of course, I could just go to a different processor with more
timer
> >>outputs,
> >> >but I like working with the S12, and it has everything I need
except
> >> >more
> >> >output compare channels, and it is cheap!!
> >> >
> >> >-- Adrian
> >> >
> >> >Send instant messages to your online friends
> >> >http://au.messenger.yahoo.com
> >> >
> >> >
> >> >
> >> >Yahoo! Groups Links
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
>Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>