68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

Hi-
I'm using a MC9S12DP256B.
Does anyone have any sample Key Wakeup code?
I have been unsuccessful in getting it to work.
Thanks!
Sophi
[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hi Sophi!

Can you please tell me what do you mean with a sample Key wakeup code? Do
you just need some example code to get yourself running?

Waiting for your reply..

Mohammed El Korek
m...@ieee.org
On 4/29/06, Sophi Kravitz wrote:
>
> Hi-
> I'm using a MC9S12DP256B.
> Does anyone have any sample Key Wakeup code?
> I have been unsuccessful in getting it to work.
> Thanks!
> Sophi
> [Non-text portions of this message have been removed]
>



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hi-
Yes that's exactly what I mean. Just some sample code to get it going!
I am using a development board with MC9S12DP256B.
I am using these addresses for init- got them from a CD which came with the
board.
Not sure that they are correct because there have been other errors. Also
not sure that
the interupt vector address is correct....using FFD0.

PORTJ equ $0268
DDRJ equ $026A
KWIEJ equ $026E
KWIFJ equ $026F
RTICTL equ $0038
RTIFLG equ $0037

LDAA #$00 ;PORTJ Input
STAA DDRJ
LDAA #$03 ;KWIEJ Enabled on pin 0 and 1
STAA KWIEJ

SEI
LDAA #$FF
STAA KWIFJ
LDAA KWIFJ ;Load KW Flag
;do some stuff
STAA KWIFJ ;Reset Interupt Flag
CLI ;Enables interupts
org $FFD0 ;Sets KW ISR to KWHAN
fdb KWHAN

On 4/29/06, MK wrote:
>
> Hi Sophi!
>
> Can you please tell me what do you mean with a sample Key wakeup code? Do
> you just need some example code to get yourself running?
>
> Waiting for your reply..
>
> Mohammed El Korek
> m...@ieee.org
>
> On 4/29/06, Sophi Kravitz wrote:
> >
> > Hi-
> > I'm using a MC9S12DP256B.
> > Does anyone have any sample Key Wakeup code?
> > I have been unsuccessful in getting it to work.
> > Thanks!
> > Sophi
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> > >.
> ------------------------------
>
[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Ok Sophi,
find this code below. (delay generator)

#include "Reg9s12.h"

ORG $2000

LDAA #$00

STAA DDRB

START: LDAA #$FF

STAA PORTB

JSR DELAY_500_MS

LDAA #$00

STAA PORTB

JSR DELAY_500_MS

JMP START

DELAY_500_MS: PSHX

LDX #1000

JSR DELAY_500_US

PULX

RTS

DELAY_500_US: PSHX

LDX #2000

JSR DELAY_250_NS

PULX

RTS

DELAY_250_NS: NOP

NOP

DEX

BNE DELAY_250_NS

RTS

another example:

#include "Reg9s12.h"

ORG $2000

LDAA #$FF

STAA DDRB

STAA DDRJ

STAA DDRP

CLR PTJ

LDAA #$FF

STAA PTP

START: LDAA #$FF

STAA PORTB

JSR DELAY_500_MS

LDAA #$00

STAA PORTB

JSR DELAY_500_MS

BRA START

DELAY_500_MS: PSHX

LDX #1000

XX JSR DELAY_500_US

DEX

BNE XX

PULX

RTS

DELAY_500_US: PSHX

LDX #2000

JSR DELAY_250_NS

PULX

RTS

DELAY_250_NS: NOP

NOP

DEX

BNE DELAY_250_NS

RTS

If the addresses are causing you trouble, just try to include a header file
that includes them all by default (a .h file... If the problem persists,
maybe it's the development environment you are using.. there might be some
settings that need to be made in order for you to specify which mode you are
using (developing your code in the RAM or in the EEPROM???).

I am actually currently doing my senior design project on a MC9S12DP256B
board which is the Minidragon+. If your IDE supports C programs, tell me so
I can give you some examples from my own!

Good luck Sophi!

Mohammed El Korek

American Univ. of Sharjah

m...@ieee.org
[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, MK wrote:
>
> Ok Sophi,
> find this code below. (delay generator)
>
> #include "Reg9s12.h"
>
> ORG $2000
>
> LDAA #$00

I don't see the "Key wakeup" part of these examples. I think key
wakeup involves setting interrupts on a certain port to detect any key
pressed on a grid array.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

hello,
I agree with Jeff, KeyWakeups are interrupts on bits of ports H, J=20
and P. They relay to interrupt vectors respectively $FFCC, $FFCE and=20
$FF8E. The interrupt routine must test the status register of the=20
concerned port to know which pin had requested an interrupt.
Regards
JCL

--- In 6...@yahoogroups.com, "Jefferson Smith" =20
wrote:
>
> --- In 6...@yahoogroups.com, MK wrote:
> >
> > Ok Sophi,
> >=20
> >=20
> > find this code below. (delay generator)
> >=20
> > #include "Reg9s12.h"
> >=20
> > ORG $2000
> >=20
> > LDAA #$00
>=20
> I don't see the "Key wakeup" part of these examples. I think key
> wakeup involves setting interrupts on a certain port to detect any=20
key
> pressed on a grid array.
>

=20

=20

=20


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Thanks for the input-
I hadn't had a chance to try it again yet-
Are those the correct addresses for the interrupt vectors for the
MC9S12DP256B?
Thanks-
Sophi

On 5/4/06, JCL wrote:
>
> hello,
> I agree with Jeff, KeyWakeups are interrupts on bits of ports H, J
> and P. They relay to interrupt vectors respectively $FFCC, $FFCE and
> $FF8E. The interrupt routine must test the status register of the
> concerned port to know which pin had requested an interrupt.
> Regards
> JCL
>
> --- In 6...@yahoogroups.com, "Jefferson Smith" wrote:
> >
> > --- In 6...@yahoogroups.com, MK wrote:
> > >
> > > Ok Sophi,
> > >
> > >
> > > find this code below. (delay generator)
> > >
> > > #include "Reg9s12.h"
> > >
> > > ORG $2000
> > >
> > > LDAA #$00
> >
> > I don't see the "Key wakeup" part of these examples. I think key
> > wakeup involves setting interrupts on a certain port to detect any
> key
> > pressed on a grid array.
> >
> SPONSORED LINKS
> Fast track +track&w2=3DMicrocontrollers&w3=3DTechnical+support&w4=3DIntel+microprocess=
ors&c=3D4&s=3D88&.sig=3De25-7i8tBucE1eBf011Z9w>
> Microcontrollers &w1=3DFast+track&w2=3DMicrocontrollers&w3=3DTechnical+support&w4=3DIntel+mi=
croprocessors&c=3D4&s=3D88&.sig=3DbFu_qpuq1yUlwG8a0ni-jA> Technical
> support st+track&w2=3DMicrocontrollers&w3=3DTechnical+support&w4=3DIntel+microproce=
ssors&c=3D4&s=3D88&.sig=3D3agMLHUjB-tTW3k83uwUjA> Intel
> microprocessors sors&w1=3DFast+track&w2=3DMicrocontrollers&w3=3DTechnical+support&w4=3DInte=
l+microprocessors&c=3D4&s=3D88&.sig=3Dv-n-hyvV_R1inJCf7ENHxA>
> ------------------------------
> >.
> ------------------------------
>
[Non-text portions of this message have been removed]

=20

=20

=20


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Sophi Kravitz" =20
wrote:
>
> Thanks for the input-
> I hadn't had a chance to try it again yet-
> Are those the correct addresses for the interrupt vectors for the
> MC9S12DP256B?

Yes they are, but if you use D-Bug12 and the bootloader, you have to=20
put your interrupt vectors within $3E00-$3E7F, because it's the=20
bootloader which takes interrupts and redirects them to D-Bug12 which=20
will redirect them to this range of memory addresses.=20
The addresses I've posted are the very addresses of those interrupt=20
vectors.
See the getting-started.pdf doc you may have with your minidragon=20
board.

So long
JCL

> Thanks-
> Sophi
>=20
> On 5/4/06, JCL wrote:
> >
> > hello,
> > I agree with Jeff, KeyWakeups are interrupts on bits of ports H, J
> > and P. They relay to interrupt vectors respectively $FFCC, $FFCE=20
and
> > $FF8E. The interrupt routine must test the status register of the
> > concerned port to know which pin had requested an interrupt.
> > Regards
> > JCL
> >
> > --- In 6...@yahoogroups.com, "Jefferson Smith"
> >
> > wrote:
> > >
> > > --- In 6...@yahoogroups.com, MK wrote:
> > > >
> > > > Ok Sophi,
> > > >
> > > >
> > > > find this code below. (delay generator)
> > > >
> > > > #include "Reg9s12.h"
> > > >
> > > > ORG $2000
> > > >
> > > > LDAA #$00
> > >
> > > I don't see the "Key wakeup" part of these examples. I think key
> > > wakeup involves setting interrupts on a certain port to detect=20
any
> > key
> > > pressed on a grid array.
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS
> > Fast track t=3Dms&k=3DFast+track&w1=3DFast+track&w2=3DMicrocontrollers&w3=3DTechnical+=
suppo
rt&w4=3DIntel+microprocessors&c=3D4&s=3D88&.sig=3De25-7i8tBucE1eBf011Z9w>
> > Microcontrollers t=3Dms&k=3DMicrocontrollers&w1=3DFast+track&w2=3DMicrocontrollers&w3=3DTech=
nical
+support&w4=3DIntel+microprocessors&c=3D4&s=3D88&.sig=3DbFu_qpuq1yUlwG8a0ni=
-
jA> Technical
> > support t=3Dms&k=3DTechnical+support&w1=3DFast+track&w2=3DMicrocontrollers&w3=3DTec=
hnica
l+support&w4=3DIntel+microprocessors&c=3D4&s=3D88&.sig=3D3agMLHUjB-
tTW3k83uwUjA> Intel
> > microprocessors t=3Dms&k=3DIntel+microprocessors&w1=3DFast+track&w2=3DMicrocontrollers&w3=
=3DTech
nical+support&w4=3DIntel+microprocessors&c=3D4&s=3D88&.sig=3Dv-n-
hyvV_R1inJCf7ENHxA>
> > ------------------------------
> > >.
> >
> >
> > ------------------------------
> >
>=20
>=20
> [Non-text portions of this message have been removed]
>

=20

=20

=20


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hello,
I need information on the behavior of the stack pointer. It is not=20
initialized on reset - typically one of the first things user code does=20
is to set the stack pointer to top of RAM.

I would like my COP reset vector to use the contents of the stack=20
pointer and store part of the stack as a diagnostic aid in a field=20
service menu.

It seems that the stack pointer is being altered as part of the reset=20
process. Maybe this is particular to the COP, but as a RESET exception=20
it should not alter the stack (CPU, Table 7.1, exception processing=20
flowchart)

I've scoured the DGV,MMC and CPU refs without success, other than a=20
reference that the StackPointer is not initialized on reset.

I know my worst case stack size, so I can arbitrarily recover all of the=20
RAM contents in the stack area, but this is not as useful.

Anybody have any experience on this?

Dave

=20

=20

=20



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Dave,

I looked in various pieces of HCS-12 documentation, and could not find a
statement that the SP is cleared on a reset.

However, experiment shows that this is the case for MC9S12DP256 mask set
2K79X. I believe that it is generally true.

I did some tests with our full emulator COP reset test using a MC9S12DP256
mask set 1K79X. Looking in the trace window showed that no information was
pushed onto the stack by the COP reset, and the SP is cleared by the COP reset.

The reason that startup code always initializes the SP is that the initial
value of zero points it into the registers, and then the vectors in flash,
neither of which are useful values for the SP.

It would be better if it were set to the top of the available RAM after
reset, but it isn't. (I suspect that the variability of the top of
available RAM across different chips made this difficult.)

The PC, of course is now in the COP reset code, so you don't have much
information to help you track down what was going on when the COP timed out.

You may not agree with Freescale's design decisions, but this approach does
make the immediate recovery from the various conditions causing a reset to
be more reliable, even if it does lose debugging information that may be
helpful in preventing the problem in the future.

If you look at it from the point of view of a car manufacturer, they would
really like a system to recover as often as possible and go on, instead of
being dead on the road.

You could still dump the entire stack area and hope you can make some sense
of it, but that may not be practical.

Having major sections of the code log their time of entry and exit in a
circular buffer may give better and more compact debugging information.

Toward the end of Freescale application note AN2400/D there is a helpful
discussion of what values for unused flash give better debugging
information that the default value of 0xFF.

Hope this helps.

Steve Russell
Nohau Emulators
At 10:11 AM 5/8/2006, Dave Sivertsen wrote:
>Hello,
>I need information on the behavior of the stack pointer. It is not
>initialized on reset - typically one of the first things user code does
>is to set the stack pointer to top of RAM.
>
>I would like my COP reset vector to use the contents of the stack
>pointer and store part of the stack as a diagnostic aid in a field
>service menu.
>
>It seems that the stack pointer is being altered as part of the reset
>process. Maybe this is particular to the COP, but as a RESET exception
>it should not alter the stack (CPU, Table 7.1, exception processing
>flowchart)
>
>I've scoured the DGV,MMC and CPU refs without success, other than a
>reference that the StackPointer is not initialized on reset.
>
>I know my worst case stack size, so I can arbitrarily recover all of the
>RAM contents in the stack area, but this is not as useful.
>
>Anybody have any experience on this?
>
>Dave
>



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Thanks!
This is what I was seeing in the MC9S12E128, with less sophisticated
methods. A full emulator sure is handy to get to the root of the matter.
The flow chart (7.1) in the CPU ref is pretty clear on not stacking, but
the uninitialized SP had me hoping for a loophole.
Regards,
Dave

Steve Russell wrote:
> Dave,
>
> I looked in various pieces of HCS-12 documentation, and could not find a
> statement that the SP is cleared on a reset.
>
> However, experiment shows that this is the case for MC9S12DP256 mask set
> 2K79X. I believe that it is generally true.
>
> I did some tests with our full emulator COP reset test using a MC9S12DP256
> mask set 1K79X. Looking in the trace window showed that no information was
> pushed onto the stack by the COP reset, and the SP is cleared by the COP reset.
>
> The reason that startup code always initializes the SP is that the initial
> value of zero points it into the registers, and then the vectors in flash,
> neither of which are useful values for the SP.
>
> It would be better if it were set to the top of the available RAM after
> reset, but it isn't. (I suspect that the variability of the top of
> available RAM across different chips made this difficult.)
>
> The PC, of course is now in the COP reset code, so you don't have much
> information to help you track down what was going on when the COP timed out.
>
> You may not agree with Freescale's design decisions, but this approach does
> make the immediate recovery from the various conditions causing a reset to
> be more reliable, even if it does lose debugging information that may be
> helpful in preventing the problem in the future.
>
> If you look at it from the point of view of a car manufacturer, they would
> really like a system to recover as often as possible and go on, instead of
> being dead on the road.
>
> You could still dump the entire stack area and hope you can make some sense
> of it, but that may not be practical.
>
> Having major sections of the code log their time of entry and exit in a
> circular buffer may give better and more compact debugging information.
>
> Toward the end of Freescale application note AN2400/D there is a helpful
> discussion of what values for unused flash give better debugging
> information that the default value of 0xFF.
>
> Hope this helps.
>
> Steve Russell
> Nohau Emulators
> At 10:11 AM 5/8/2006, Dave Sivertsen wrote:
>
>> Hello,
>> I need information on the behavior of the stack pointer. It is not
>> initialized on reset - typically one of the first things user code does
>> is to set the stack pointer to top of RAM.
>>
>> I would like my COP reset vector to use the contents of the stack
>> pointer and store part of the stack as a diagnostic aid in a field
>> service menu.
>>
>> It seems that the stack pointer is being altered as part of the reset
>> process. Maybe this is particular to the COP, but as a RESET exception
>> it should not alter the stack (CPU, Table 7.1, exception processing
>> flowchart)
>>
>> I've scoured the DGV,MMC and CPU refs without success, other than a
>> reference that the StackPointer is not initialized on reset.
>>
>> I know my worst case stack size, so I can arbitrarily recover all of the
>> RAM contents in the stack area, but this is not as useful.
>>
>> Anybody have any experience on this?
>>
>> Dave
>>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

I also had a brief look at the stack pointer very early after the COP
vector handling code to identify what parts of my code had long delays,
and were causing COP to fire. As you have already discussed the outcome
was fruitless. I don't have any problems with my code that would cause
the COP to fire, I just wanted to be ready for that occurance.

Andrew Lohmann AMIIE
Design Engineer

PLEASE NOTE NEW EMAIL ADDRESS IS:
a...@bellinghamandstanley.co.uk

Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com

Dave Sivertsen wrote:

> Thanks!
> This is what I was seeing in the MC9S12E128, with less sophisticated
> methods. A full emulator sure is handy to get to the root of the matter.
> The flow chart (7.1) in the CPU ref is pretty clear on not stacking, but
> the uninitialized SP had me hoping for a loophole.
> Regards,
> Dave
>
> Steve Russell wrote:
> > Dave,
> >
> > I looked in various pieces of HCS-12 documentation, and could not
> find a
> > statement that the SP is cleared on a reset.
> >
> > However, experiment shows that this is the case for MC9S12DP256 mask
> set
> > 2K79X. I believe that it is generally true.
> >
> > I did some tests with our full emulator COP reset test using a
> MC9S12DP256
> > mask set 1K79X. Looking in the trace window showed that no
> information was
> > pushed onto the stack by the COP reset, and the SP is cleared by the
> COP reset.
> >
> > The reason that startup code always initializes the SP is that the
> initial
> > value of zero points it into the registers, and then the vectors in
> flash,
> > neither of which are useful values for the SP.
> >
> > It would be better if it were set to the top of the available RAM after
> > reset, but it isn't. (I suspect that the variability of the top of
> > available RAM across different chips made this difficult.)
> >
> > The PC, of course is now in the COP reset code, so you don't have much
> > information to help you track down what was going on when the COP
> timed out.
> >
> > You may not agree with Freescale's design decisions, but this
> approach does
> > make the immediate recovery from the various conditions causing a
> reset to
> > be more reliable, even if it does lose debugging information that
> may be
> > helpful in preventing the problem in the future.
> >
> > If you look at it from the point of view of a car manufacturer, they
> would
> > really like a system to recover as often as possible and go on,
> instead of
> > being dead on the road.
> >
> > You could still dump the entire stack area and hope you can make
> some sense
> > of it, but that may not be practical.
> >
> > Having major sections of the code log their time of entry and exit in a
> > circular buffer may give better and more compact debugging information.
> >
> > Toward the end of Freescale application note AN2400/D there is a
> helpful
> > discussion of what values for unused flash give better debugging
> > information that the default value of 0xFF.
> >
> > Hope this helps.
> >
> > Steve Russell
> > Nohau Emulators
> >
> >
> > At 10:11 AM 5/8/2006, Dave Sivertsen wrote:
> >
> >> Hello,
> >> I need information on the behavior of the stack pointer. It is not
> >> initialized on reset - typically one of the first things user code does
> >> is to set the stack pointer to top of RAM.
> >>
> >> I would like my COP reset vector to use the contents of the stack
> >> pointer and store part of the stack as a diagnostic aid in a field
> >> service menu.
> >>
> >> It seems that the stack pointer is being altered as part of the reset
> >> process. Maybe this is particular to the COP, but as a RESET exception
> >> it should not alter the stack (CPU, Table 7.1, exception processing
> >> flowchart)
> >>
> >> I've scoured the DGV,MMC and CPU refs without success, other than a
> >> reference that the StackPointer is not initialized on reset.
> >>
> >> I know my worst case stack size, so I can arbitrarily recover all
> of the
> >> RAM contents in the stack area, but this is not as useful.
> >>
> >> Anybody have any experience on this?
> >>
> >> Dave
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >.
> ------------------------------------------------------------------------
>

-----------------------------Disclaimer-----------------------------

This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this e-mail.

-----------------------------Disclaimer-----------------------------



______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hi Dave,

Indeed debugging the execution sequence that leads into COP Watchdog Reset,
can be very difficult.

As you found out, the COP Reset corrupts the SP register, so it is also
very difficult to look at the stack top to identify hints about what was
executed when the COP watchdog Reset happened.

If you are looking to debug around COP Watchdog Reset, a full-emulator can
be a big help. The emulator's trace-memory records up to 128Kframes of
execution history and data reads/writes leading to the COP Watchdog Reset,
going through the Reset, and out of the Reset. If you like, you can find a
simple example and screen-shots that demonstrates this in the following
article I wrote about debugging special HCS12 operating conditions (COP
Reset, power-downs, etc.) using a full-emulator:
http://www.nohau.com/products/hcs12_emulator_features.pdf

In lack of a full-emulator or for field-service, I guess you can change
your application to store in RAM memory the SP and other registers upon
entry into key function, so you can later analyze these RAM values after
the COP Reset startup (since the RAM content is not altered by a regular
Reset provided the operating voltage did not drop for a short while).

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

At 10:11 08/05/2006 -0700, you wrote:
>Hello,
>I need information on the behavior of the stack pointer. It is not
>initialized on reset - typically one of the first things user code does
>is to set the stack pointer to top of RAM.
>
>I would like my COP reset vector to use the contents of the stack
>pointer and store part of the stack as a diagnostic aid in a field
>service menu.
>
>It seems that the stack pointer is being altered as part of the reset
>process. Maybe this is particular to the COP, but as a RESET exception
>it should not alter the stack (CPU, Table 7.1, exception processing
>flowchart)
>
>I've scoured the DGV,MMC and CPU refs without success, other than a
>reference that the StackPointer is not initialized on reset.
>
>I know my worst case stack size, so I can arbitrarily recover all of the
>RAM contents in the stack area, but this is not as useful.
>
>Anybody have any experience on this?
>
>Dave
[Non-text portions of this message have been removed]





(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, Dave Sivertsen wrote:

> methods. A full emulator sure is handy to get to the root of
> the matter.

Unless of course the root of the matter is whether the emulator
completely recreates the real thing. It has been the main problem for
emulators in the past ;-)

Probably not a problem in this case since this MCU has a good
"emulator mode", and Nohau is indeed a good emulator. But the emulator
features on the MCU help me test it better without paying $10,000+
just for getting started with an emulator.

=20

=20

=20



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )