Adrian,

In case you haven't gotten the word, Freescale just put up:

AN3145 - "XGATE Library: Using the Freescale XGATE Software Library"
which 
has some general advice on XGate programming at the end.

AN3225 - "XGATE Library: PWM Driver" which covers doing PWN in the
XGate 
software.

I haven't digested them yet, but they are worth study.

    Steve Russell
    Nohau Emulators
	At 09:35 PM 3/2/2006, you wrote:
>Steve,
>
>Apologies for the late reply to this email, but I just reread it, and did
>not on the first time I read it realise the extra information embedded in my
>original questions.
>
>I have an evaluation board on the way to me, and I will use codewarrior
>Special edition in my first attempt. I may write the XGATE code in assembler
>not sure yet.
>
>Now in response to your email, you highlite some issues, and I may be
>oversimplifying things, but I have some ideas, and your feedback would be
>appreiated:
>
>* Now I have in mind to on first attempt at least, try to emulate the
>existing ECT of the S12. By this I mean that the like the standard ECT, the
>CPU will be the only thing able to modify "registers". The CPU
will set the
>time for a compare, and the control bits for a compare indicating what to do
>on the match, and the XGATE will never alter the registers. The only
>response of the XGATE would be to generate an interrupt on a compare match.
>I am hoping that by doing this, I should avoid any multiprocessor memory
>issues that require semaphores etc. I believe that the CPU can write to a 16
>bit compare time register in one instruction, so there should be no chance
>of the XGATE reading half the real value. I make a practise with standard
>ECT use in the S12 to update the compare time regeister first after making
>sure it is far enough in the future that a compare cannot be immediately
>generated before I can update the registers that say what to do when the
>compares occurs. These "registers" would only ever be accessed by
the XGATE
>when a compare match had been made. I am assuming that by doing it this way,
>I would not need to worry about semaphores... is this correct?
>
>* I see your point on making a less than or equal compare, but I intend to
>run the ECT timer relatively slowly... at about 5us resolution. On your
>calculations, the XGATE should be able to run about 300 instructions per ECT
>increment. I may be incorrect, but I believe the XGATE should be able to
>scan an array of 16 16bit compare "registers" comparing each to
the ECT
>timer within well under 300 instructions? I may be wrong on that, but I was
>planning not to use a loop to do this ( I believe jump instructions waste
>instructions in a RISC architecture), but actually hardwire the XGATE code
>to check 16 RAM words as one code segment, and then loop back and do it
>again. I may put something in that forces it to wait for a ECT increment
>before rechecking it to give consistent timing response for all channels.
>
>* You mention other timer interrupt sources other than the ECT (I really
>want to keep the 8 standard ECT channels for normal use, so do not want to
>lose one for the XGATE ECTs, but may go this way), but it is important for
>me for all the ECT channels including the XGATE emulated channels and the
>ECT peripheral module to be synchronised to the same counter. I basically
>plan to use the ECT peripheral channels as input capture channels, and I
>want 16 XGATE emulated output compare channels to be synchronised with the
>ECT input capture channels. In order to achieve this close synchronisation,
>the only way I can think that this can be achieved is to use one ECT channel
>as the XGATE interrupt source.
>
>* I believe the least complex approach is to use the XGATE to continuously
>pole the ECT timer. If I use an ECT channel to generate interrupts, I have
>to think of ways for the output compare channel info to be sorted in
>ascending time order so that the ECT channel being used is always updated
>with the next event due out of all 16 channels. I have to handle events
>where multiple channels match a compare at the same point in time. I believe
>that I would have to put alot of consideration into semaphore protection of
>memory for this technique. I have to think of a way to get the XGATE to
>update its ECT channel if I issue a new OC channel that is due to occur
>before the current channel that is waiting to match (so it would have to
>configure the new channel as the next match and add the old channel back to
>its list). It gets quite complicated this way, and would certainly reduce
>XGATE loading alot, but this is not a concern for me at the moment, and it
>does seem to be alot simpler to use the XGATE to just poll the ECT timer as
>the solution seems to be a lot simpler, easier to debug, and less unforseen
>conditions to have to handle. Can the XGATE be made to generate an interrupt
>on RAM locations changing? Could I force the XGATE to see an OC
"register"
>has changed and updates its data to handle this, or can I get the CPU to
>somehow force the XGATE to handle an interrupt when it makes changes to OC
>information and update its data to handle this.
>
>ANyway, I am asking way more than can be expected on a list like this, so I
>will research it myself, but thought I would put it out there anyway.
>
>Thanks heaps for the advice!!
>
>-- Adrian
>
>----- Original Message -----
>From: "Steve Russell" <stever@stev...>
>To: <68HC12@68HC...>
>Sent: Friday, February 24, 2006 11:09 AM
>Subject: Re: [68HC12] XGATE??
>
>
> > 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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
>Yahoo! Groups Links
>
>
>
>
	

Adrian,

I haven't studied the ECT, so I can't give much advice about the
details there.

On the other hand, I've had lots of experience writing and debugging 
interrupt code and I have some strong opinions, which I share below.

Since you are concerned about performance, it seems like you should plan to 
do some experiments and time them.  I think that there are simulators that 
can give you XGate performance reports, but they may not be able to 
accurately simulate the interference between the S12X and the XGate.

With a Nohau full Emulator, we can give you accurate timing information 
about the S12X execution, and detailed information about the S12X and XGate 
interactions.

If you can get a test that doesn't depend on your target, I'll try to
run 
it on our emulator and post the output.  I can also arrange a Webex 
demonstration, where you can control the emulator from a web browser while 
we both watch.

     Steve Russell
     Nohau Emulators
	At 09:35 PM 3/2/2006, Adrian Vos wrote:
>Steve,
>
>Apologies for the late reply to this email, but I just reread it, and did 
>not on the first time I read it realise the extra information embedded in 
>my original questions.
>
>I have an evaluation board on the way to me, and I will use codewarrior 
>Special edition in my first attempt. I may write the XGATE code in 
>assembler not sure yet.
>
>Now in response to your email, you highlite some issues, and I may be 
>oversimplifying things, but I have some ideas, and your feedback would be 
>appreiated:
>
>* Now I have in mind to on first attempt at least, try to emulate the 
>existing ECT of the S12. By this I mean that the like the standard ECT, 
>the CPU will be the only thing able to modify "registers". The CPU
will 
>set the time for a compare, and the control bits for a compare indicating 
>what to do on the match, and the XGATE will never alter the registers. The 
>only response of the XGATE would be to generate an interrupt on a compare 
>match.  I am hoping that by doing this, I should avoid any multiprocessor 
>memory
>issues that require semaphores etc.

This may be a good way for you to start developing, but I don't think the 
synchronization issues can be avoided, just moved around.  The semaphores 
and software interrupts are a good way to deal with them.

>I believe that the CPU can write to a 16 bit
compare time register in one 
>instruction, so there should be no chance of the XGATE reading half the 
>real value. I make a practise with standard ECT use in the S12 to update 
>the compare time regeister first after making sure it is far enough in the 
>future that a compare cannot be immediately generated before I can update 
>the registers that say what to do when the compares occurs. These 
>"registers" would only ever be accessed by the XGATE when a
compare match 
>had been made. I am assuming that by doing it this way, I would not need 
>to worry about semaphores... is this correct?
>
>* I see your point on making a less than or equal compare, but I intend to 
>run the ECT timer relatively slowly... at about 5us resolution.

My point on less equal compare was really a programming practice issue.

Over the years I've been afflicted with various causes of interrupts 
getting lost for one reason or another.

In these cases, it always turned out that doing something that restarted 
the I/O process that depended on the interrupts, even if it created a 
timing error was better than having the system stall or reset.

It may be better to indicate an problem of some kind when this occurs, but 
ignoring the problem and having the I/O stall until a restart seems to be 
the WORST thing you can do.  So don't even THINK about doing it!

>On your calculations, the XGATE should be able to
run about 300 
>instructions per ECT increment. I may be incorrect, but I believe the 
>XGATE should be able to scan an array of 16 16bit compare
"registers" 
>comparing each to the ECT timer within well under 300 instructions? I may 
>be wrong on that, but I was planning not to use a loop to do this ( I 
>believe jump instructions waste instructions in a RISC architecture), but 
>actually hardwire the XGATE code to check 16 RAM words as one code 
>segment, and then loop back and do it again. I may put something in that 
>forces it to wait for a ECT increment before rechecking it to give 
>consistent timing response for all channels.
>
>* You mention other timer interrupt sources other than the ECT (I really 
>want to keep the 8 standard ECT channels for normal use, so do not want to 
>lose one for the XGATE ECTs, but may go this way), but it is important for 
>me for all the ECT channels including the XGATE emulated channels and the 
>ECT peripheral module to be synchronised to the same counter. I basically
>plan to use the ECT peripheral channels as input capture channels, and I 
>want 16 XGATE emulated output compare channels to be synchronised with the 
>ECT input capture channels. In order to achieve this close 
>synchronisation, the only way I can think that this can be chieved is to 
>use one ECT channel as the XGATE interrupt source.
>
>* I believe the least complex approach is to use the XGATE to continuously 
>pole the ECT timer. If I use an ECT channel to generate interrupts, I have 
>to think of ways for the output compare channel info to be sorted in 
>ascending time order so that the ECT channel being used is always updated 
>with the next event due out of all 16 channels. I have to handle events 
>where multiple channels match a compare at the same point in time. I 
>believe that I would have to put alot of consideration into semaphore 
>protection of memory for this technique. I have to think of a way to get 
>the XGATE to update its ECT channel if I issue a new OC channel that is 
>due to occur before the current channel that is waiting to match (so it 
>would have to configure the new channel as the next match and add the old 
>channel back to its list). It gets quite complicated this way, and would 
>certainly reduce XGATE loading alot, but this is not a concern for me at 
>the moment, and it does seem to be alot simpler to use the XGATE to just 
>poll the ECT timer as the solution seems to be a lot simpler, easier to 
>debug, and less unforseen conditions to have to handle. Can the XGATE be 
>made to generate an interrupt on RAM locations changing?

The "software interrupts" are nominally part of the XGate, but they
can be 
configured just like the other interrupt channels to interrupt either the 
XGate or the S12X.  There are 8 independent channels.

The software that triggers a software interrupt channel can run on either 
the S12X or the XGate.  For simplicity, I would only trigger a particular 
channel from one processor.

There is no hardware, other than the XGate itself, that will trigger on a 
change in a RAM location, but if the XGate is running "one big loop"
it 
could compare the RAM location and generate a software interrupt to the 
S12X on a change.

>Could I force the XGATE to see an OC
"register" has changed and updates 
>its data to handle this, or can I get the CPU to somehow force the XGATE 
>to handle an interrupt when it makes changes to OC information and update 
>its data to handle this.

You can do these things, but it may be simpler to just have the XGate do 
more of the work by itself without having a lot of interrupts going back 
and forth.

As the XGate is faster at doing simple things than the S12X, the optimal 
way to use it seems to fill up all available RAM with XGate code that 
handles the most time critical I/O.  Put the remaining less time-critical 
code in the S12X.

>ANyway, I am asking way more than can be expected
on a list like this, so 
>I will research it myself, but thought I would put it out there anyway.
>
>Thanks heaps for the advice!!
>
>-- Adrian
>
>----- Original Message -----
>From: "Steve Russell" <stever@stev...>
>To: <68HC12@68HC...>
>Sent: Friday, February 24, 2006 11:09 AM
>Subject: Re: [68HC12] XGATE??
>
>
> > 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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
>
>Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
>Yahoo! Groups Links
>
>
>
>
	

Steve,

Apologies for the late reply to this email, but I just reread it, and did 
not on the first time I read it realise the extra information embedded in my 
original questions.

I have an evaluation board on the way to me, and I will use codewarrior 
Special edition in my first attempt. I may write the XGATE code in assembler 
not sure yet.

Now in response to your email, you highlite some issues, and I may be 
oversimplifying things, but I have some ideas, and your feedback would be 
appreiated:

* Now I have in mind to on first attempt at least, try to emulate the 
existing ECT of the S12. By this I mean that the like the standard ECT, the 
CPU will be the only thing able to modify "registers". The CPU will
set the 
time for a compare, and the control bits for a compare indicating what to do 
on the match, and the XGATE will never alter the registers. The only 
response of the XGATE would be to generate an interrupt on a compare match. 
I am hoping that by doing this, I should avoid any multiprocessor memory 
issues that require semaphores etc. I believe that the CPU can write to a 16 
bit compare time register in one instruction, so there should be no chance 
of the XGATE reading half the real value. I make a practise with standard 
ECT use in the S12 to update the compare time regeister first after making 
sure it is far enough in the future that a compare cannot be immediately 
generated before I can update the registers that say what to do when the 
compares occurs. These "registers" would only ever be accessed by the
XGATE 
when a compare match had been made. I am assuming that by doing it this way, 
I would not need to worry about semaphores... is this correct?

* I see your point on making a less than or equal compare, but I intend to 
run the ECT timer relatively slowly... at about 5us resolution. On your 
calculations, the XGATE should be able to run about 300 instructions per ECT 
increment. I may be incorrect, but I believe the XGATE should be able to 
scan an array of 16 16bit compare "registers" comparing each to the
ECT 
timer within well under 300 instructions? I may be wrong on that, but I was 
planning not to use a loop to do this ( I believe jump instructions waste 
instructions in a RISC architecture), but actually hardwire the XGATE code 
to check 16 RAM words as one code segment, and then loop back and do it 
again. I may put something in that forces it to wait for a ECT increment 
before rechecking it to give consistent timing response for all channels.

* You mention other timer interrupt sources other than the ECT (I really 
want to keep the 8 standard ECT channels for normal use, so do not want to 
lose one for the XGATE ECTs, but may go this way), but it is important for 
me for all the ECT channels including the XGATE emulated channels and the 
ECT peripheral module to be synchronised to the same counter. I basically 
plan to use the ECT peripheral channels as input capture channels, and I 
want 16 XGATE emulated output compare channels to be synchronised with the 
ECT input capture channels. In order to achieve this close synchronisation, 
the only way I can think that this can be achieved is to use one ECT channel 
as the XGATE interrupt source.

* I believe the least complex approach is to use the XGATE to continuously 
pole the ECT timer. If I use an ECT channel to generate interrupts, I have 
to think of ways for the output compare channel info to be sorted in 
ascending time order so that the ECT channel being used is always updated 
with the next event due out of all 16 channels. I have to handle events 
where multiple channels match a compare at the same point in time. I believe 
that I would have to put alot of consideration into semaphore protection of 
memory for this technique. I have to think of a way to get the XGATE to 
update its ECT channel if I issue a new OC channel that is due to occur 
before the current channel that is waiting to match (so it would have to 
configure the new channel as the next match and add the old channel back to 
its list). It gets quite complicated this way, and would certainly reduce 
XGATE loading alot, but this is not a concern for me at the moment, and it 
does seem to be alot simpler to use the XGATE to just poll the ECT timer as 
the solution seems to be a lot simpler, easier to debug, and less unforseen 
conditions to have to handle. Can the XGATE be made to generate an interrupt 
on RAM locations changing? Could I force the XGATE to see an OC
"register" 
has changed and updates its data to handle this, or can I get the CPU to 
somehow force the XGATE to handle an interrupt when it makes changes to OC 
information and update its data to handle this.

ANyway, I am asking way more than can be expected on a list like this, so I 
will research it myself, but thought I would put it out there anyway.

Thanks heaps for the advice!!

-- Adrian

----- Original Message ----- 
From: "Steve Russell" <stever@stev...>
To: <68HC12@68HC...>
Sent: Friday, February 24, 2006 11:09 AM
Subject: Re: [68HC12] XGATE??
	> 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
>>
>>
>>
>>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
> 

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

Adrian Vos wrote:

[...]

> * Is there better compiler options than
metrowerks? I kind of like working 
> in an IDE environment where I can debug my code at the click of an icon,
and 
> metrowerks provides this. I prefer this to writing make files and batch 

dou you use also other compilers, e.g. for other controllers or the 
PC? Maybe in the future?

Then I suggest to use _one_ "IDE" for all, not the compiler's
IDE.

Maybe more initial effort, but over the years much more efficient.

Oliver
-- 
Oliver Betz, Muenchen
	

Adrian,

There are currently two S12X/XGate C compilers that I am aware of: Cosmic 
and Freescale (formerly Metrowerks).
Both support C programs for both the S12X Core and the XGate co-processor.

On the future side:
There are some support plans at Imagecraft.
There was also an effort lead by Kim Lux (I think Jeff Smith was involved 
too), some 3-6 months ago to implement a free GNU compiler support for both 
the S12X and XGate. There was a lot of Bells and Whistles around this 
effort in this email list at the time, but I don't know what happened with 
it, or if it was completed at all. (At the time, I claimed the extensive 
development efforts would make it non-economical to develop a free S12X and 
XGate C compiler)

I believe Cosmic or Freescale would be the best S12X Compiler option 
available currently.

Hope this helps,
Doron
Nohau
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html
	At 12:05 28/02/2006 +1100, you wrote:
>Thanks Steve (and anyone else who contributed),
>
>I need to get an evaluation board and compiler to start myself running on
>the idea that have been discussed.
>
>As for the evaluation board... is EVB9S12XDP512 from freescale a good
>option, or are there better value for money options available elsewhere?
>
>For a compiler... I have used metrowerks in the past, and am leaning to
>upgrading what I have rather than moving to another compiler, but I have a
>few questions:
>
>* Is there compilers that compile C code for the XGATE?
>* Is there better compiler options than metrowerks? I kind of like working
>in an IDE environment where I can debug my code at the click of an icon, and
>metrowerks provides this. I prefer this to writing make files and batch
>files.
>
>Thanks for and advice!!
>
>Regards,
>
>Adrian
	
	

> Thanks Steve (and anyone else who contributed),
>
> I need to get an evaluation board and compiler to start myself running on
> the idea that have been discussed.
>
> As for the evaluation board... is EVB9S12XDP512 from freescale a good
> option, or are there better value for money options available elsewhere?
	I got DEMO9S12XDT512:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?codeO9S12XDT512

(It has onboard USB multilink and is powered from USB port).
	>
> For a compiler... I have used metrowerks in the
past, and am leaning to
> upgrading what I have rather than moving to another compiler, but I have a
> few questions:
>
> * Is there compilers that compile C code for the XGATE?
	Only Metrowerks and Cosmic do have C compilers for XGATE today.
	> * Is there better compiler options than metrowerks? I kind of like working
> in an IDE environment where I can debug my code at
the click of an icon, 
> and
> metrowerks provides this. I prefer this to writing make files and batch
> files.
	If C for XGATE is a must then choose between MW and Cosmic.
	>
> Thanks for and advice!!
>
> Regards,
>
> Adrian
>
> ----- Original Message ----- 
> From: "Steve Russell" <stever@stev...>
> To: <68HC12@68HC...>
> Sent: Friday, February 24, 2006 11:25 AM
> Subject: Re: [68HC12] XGATE??
>
>
>> Adrian,
>>
>> Notes below.
>>
>>     Steve Russell
>>     Nohau Emulators
>>
>> At 03:33 PM 2/23/2006, Adrian Vos wrote:
>>>Does the XGATE have the option to never return from an interrupt
that you
>>>trigger once on initial startup?
>>
>> Sure does.  The XGate has to execute an RTS instruction to terminate an
>> XGate thread.  No RTS, no termination.
>>
>>>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?
>>
>> You can.  Try working out the cycles, though.
>>
>> Because the XGate is a RISC architecture, you need to do a load and
then 
>> a
>> test to poll a timer, and then a store to change a bit, assuming you
have
>> pre-calculated the new value of the output port.
>>
>> I think that sending the timer interrupt to the XGate when the XGate is
>> idle takes maybe a few XGate cycles more than the load and test, if
any.
>>
>>>-- 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
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
	

--- In 68HC12@68HC..., "Adrian Vos" <vosadrian@...> wrote:
> 
> As for the evaluation board... is EVB9S12XDP512 from freescale a good 
> option, or are there better value for money options available elsewhere?
> 

See link - I used this module with some projects
http://www.technologicalarts.ca/catalog/index.php/cPath/50_154
	

The emphasis is definitely on "WILL." We don't have an extra
idea what form 
the support will look like, whether it is a full blown C support, or just 
the XGate asm support.

At 06:32 PM 2/27/2006, Rob Milne wrote:

>Imagecraft claims that there will be a V7 of their
ICC12 compiler which
>will have xgate support.  Way cheaper than a full license of metrowerks.
>
>----------

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com)
	

Imagecraft claims that there will be a V7 of their ICC12 compiler which 
will have xgate support.  Way cheaper than a full license of metrowerks.

Adrian Vos wrote:
> Thanks Steve (and anyone else who contributed),
> 
> I need to get an evaluation board and compiler to start myself running on
> the idea that have been discussed.
> 
> As for the evaluation board... is EVB9S12XDP512 from freescale a good
> option, or are there better value for money options available elsewhere?
> 
> For a compiler... I have used metrowerks in the past, and am leaning to
> upgrading what I have rather than moving to another compiler, but I have a
> few questions:
> 
> * Is there compilers that compile C code for the XGATE?
> * Is there better compiler options than metrowerks? I kind of like working
> in an IDE environment where I can debug my code at the click of an icon, 
> and
> metrowerks provides this. I prefer this to writing make files and batch
> files.
> 
> Thanks for and advice!!
> 
> Regards,
> 
> Adrian
> 
> ----- Original Message -----
> From: "Steve Russell" <stever@stev...>
> To: <68HC12@68HC...>
> Sent: Friday, February 24, 2006 11:25 AM
> Subject: Re: [68HC12] XGATE??
> 
> 
>  > Adrian,
>  >
>  > Notes below.
>  >
>  >     Steve Russell
>  >     Nohau Emulators
>  >
>  > At 03:33 PM 2/23/2006, Adrian Vos wrote:
>  >>Does the XGATE have the option to never return from an interrupt
that you
>  >>trigger once on initial startup?
>  >
>  > Sure does.  The XGate has to execute an RTS instruction to terminate
an
>  > XGate thread.  No RTS, no termination.
>  >
>  >>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?
>  >
>  > You can.  Try working out the cycles, though.
>  >
>  > Because the XGate is a RISC architecture, you need to do a load and 
> then a
>  > test to poll a timer, and then a store to change a bit, assuming you
have
>  > pre-calculated the new value of the output port.
>  >
>  > I think that sending the timer interrupt to the XGate when the XGate
is
>  > idle takes maybe a few XGate cycles more than the load and test, if
any.
>  >
>  >>-- 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
>  >> >>> >
>  >> >>> >
>  >> >>> >
>  >> >>> >>.
> 
> 
> 

Thanks Steve (and anyone else who contributed),

I need to get an evaluation board and compiler to start myself running on 
the idea that have been discussed.

As for the evaluation board... is EVB9S12XDP512 from freescale a good 
option, or are there better value for money options available elsewhere?

For a compiler... I have used metrowerks in the past, and am leaning to 
upgrading what I have rather than moving to another compiler, but I have a 
few questions:

* Is there compilers that compile C code for the XGATE?
* Is there better compiler options than metrowerks? I kind of like working 
in an IDE environment where I can debug my code at the click of an icon, and 
metrowerks provides this. I prefer this to writing make files and batch 
files.

Thanks for and advice!!

Regards,

Adrian

----- Original Message ----- 
From: "Steve Russell" <stever@stev...>
To: <68HC12@68HC...>
Sent: Friday, February 24, 2006 11:25 AM
Subject: Re: [68HC12] XGATE??
	> Adrian,
>
> Notes below.
>
>     Steve Russell
>     Nohau Emulators
>
> At 03:33 PM 2/23/2006, Adrian Vos wrote:
>>Does the XGATE have the option to never return from an interrupt that
you
>>trigger once on initial startup?
>
> Sure does.  The XGate has to execute an RTS instruction to terminate an
> XGate thread.  No RTS, no termination.
>
>>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?
>
> You can.  Try working out the cycles, though.
>
> Because the XGate is a RISC architecture, you need to do a load and then a
> test to poll a timer, and then a store to change a bit, assuming you have
> pre-calculated the new value of the output port.
>
> I think that sending the timer interrupt to the XGate when the XGate is
> idle takes maybe a few XGate cycles more than the load and test, if any.
>
>>-- 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
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
> 

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