Hello.  I am a nontrad college punk out here in the sticks of South 
Dakota.
  Can anybody help me with setting up the address mapping for the 
Tekmos PRU on a MC68HC11E9?  I would like to use Ports B & C of my 
microcontroller for my Sr Design project!  I've read (& re-read) the 
data sheet and I'm just not sure where the A8-A11 lines (that I'm 
supposed to pull low while mapping the addresses) are interfacing with 
the PRU????  Advice?  TJ
	

I don't have a lot of time right now to think about it, (doing about 
three things at once) but I could scan in a sketch of a circuit I used a 
while ago to interface the PRU if that would help

email me privately at nw.johnson@nw.j...
	regards,
	Nigel
	teejsd wrote:
>   Hello.  I am a nontrad college punk out here in the sticks of South 
> Dakota.
>   Can anybody help me with setting up the address mapping for the 
> Tekmos PRU on a MC68HC11E9?  I would like to use Ports B & C of my 
> microcontroller for my Sr Design project!  I've read (& re-read) the 
> data sheet and I'm just not sure where the A8-A11 lines (that I'm 
> supposed to pull low while mapping the addresses) are interfacing with 
> the PRU????  Advice?  TJ
>
>
>
>
>
>  
> Yahoo! Groups Links
>
>
>
>  
>
>
>
>
	-- 
Nigel Johnson
MSc., MIEEE, MCSE
VE3ID/G4AJQ

http://nigel.homelinux.net

You can reach me by voice on Skype:  TILBURY2591

If time travel ever will be possible, it already is. Ask me again yesterday

This e-mail is not and cannot, by its nature, be confidential. En route from me to you,
it will pass across the public Internet, easily readable by any number of system
administrators along the way. If you have received this message by mistake, it would be
ridiculous for me to tell you not to read it or copy to anybody else, because, let’s face
it, if it’s a message revealing confidential information or that could embarrass me
intensely, that’s precisely what you’ll do. Who wouldn’t?

Likewise, it is superfluous for me to claim copyright in the contents, because I own that
anyway, even if you print out a hard copy or disseminate this message all over the known
Universe. I don’t know why so many corporate mail servers feel impelled to attach a
disclaimer to the bottom of every e-mail message saying otherwise. If you don’t either,
why not e-mail your corporate lawyers and system administrators and ask them why they
insist on contributing so much to the waste of bandwidth.
	

--- In m68HC11@m68H..., "teejsd" <tmjorenby@...> wrote:
>
>   Hello.  I am a nontrad college punk out here in the sticks of South 
> Dakota.
>   Can anybody help me with setting up the address mapping for the 
> Tekmos PRU on a MC68HC11E9?  I would like to use Ports B & C of my 
> microcontroller for my Sr Design project!  I've read (& re-read) the 
> data sheet and I'm just not sure where the A8-A11 lines (that I'm 
> supposed to pull low while mapping the addresses) are interfacing with 
> the PRU????  Advice?  TJ

As I recall, the A12-A15 lines on the (Mot 68HC24) PRU are simply
connected to the address bus signals of the same name; e.g. A12-A15 on
the HC11 (PB4-PB7 if you prefer).  The internal logic of the PRU uses
these signals in conjunction with the setting of the HC11 INIT
register.  When reset, the PRU will map itself to the $1xxx page (e.g.
the default I/O register space).

One thing you have to be careful of when using a PRU is that unlike
the HC11, which fully decodes the I/O space such that it maps only to
$x000-$x03F, the PRU does not have access (and thus cannot decode)
address bits A8-A11.  Given this, the PRU will "appear" in the address
map across a 4K range - $x000 thru $xFFF.  If any other memory-mapped
devices - esp. read-capable devices - are present in this space, a bus
conflict could (and will) result.  If you require finer address
mapping, the PRU -CS input (in conjuction with external decode logic)
can be used to "narrow" the address space used by the PRU.  I have
used the PRU in some of my HC11 designs, including those that have RAM
and/or ROM mapped in the I/O page space.  I used a PLD to generate -CS
signals for the various memory-mapped devices, and designed the logic
for the decodes such that the memory device(s) in the I/O space were
disabled, and the PRU (I/O) address space "footprint" was reduced to
$0100 bytes.

A quick look at the Tekmos site citing their device indicates that
they will sell these parts direct.  Just the same, is this part
available through any of the usual mail-order distribution houses like
Digi-Key, Mouser, Allied, etc. ?  How did you acquire your device(s) ?
	

--- In m68HC11@m68H..., "Mark Schultz" <n9xmj@...> wrote:
>
> --- In m68HC11@m68H..., "teejsd" <tmjorenby@> wrote:
> >
> >   Hello.  I am a nontrad college punk out here in the sticks of 
South 
> > Dakota.
> >   Can anybody help me with setting up the address mapping for 
the 
> > Tekmos PRU on a MC68HC11E9?  I would like to use Ports B & C of 
my 
> > microcontroller for my Sr Design project!  I've read (& re-read) 
the 
> > data sheet and I'm just not sure where the A8-A11 lines (that 
I'm 
> > supposed to pull low while mapping the addresses) are 
interfacing with 
> > the PRU????  Advice?  TJ
> 
> As I recall, the A12-A15 lines on the (Mot 68HC24) PRU are simply
> connected to the address bus signals of the same name; e.g. A12-
A15 on
> the HC11 (PB4-PB7 if you prefer).  The internal logic of the PRU 
uses
> these signals in conjunction with the setting of the HC11 INIT
> register.  When reset, the PRU will map itself to the $1xxx page 
(e.g.
> the default I/O register space).
> 
> One thing you have to be careful of when using a PRU is that unlike
> the HC11, which fully decodes the I/O space such that it maps only 
to
> $x000-$x03F, the PRU does not have access (and thus cannot decode)
> address bits A8-A11.  Given this, the PRU will "appear" in the 
address
> map across a 4K range - $x000 thru $xFFF.  If any other memory-
mapped
> devices - esp. read-capable devices - are present in this space, a 
bus
> conflict could (and will) result.  If you require finer address
> mapping, the PRU -CS input (in conjuction with external decode 
logic)
> can be used to "narrow" the address space used by the PRU.  I have
> used the PRU in some of my HC11 designs, including those that have 
RAM
> and/or ROM mapped in the I/O page space.  I used a PLD to 
generate -CS
> signals for the various memory-mapped devices, and designed the 
logic
> for the decodes such that the memory device(s) in the I/O space 
were
> disabled, and the PRU (I/O) address space "footprint" was reduced 
to
> $0100 bytes.
> 
> A quick look at the Tekmos site citing their device indicates that
> they will sell these parts direct.  Just the same, is this part
> available through any of the usual mail-order distribution houses 
like
> Digi-Key, Mouser, Allied, etc. ?  How did you acquire your device
(s) ?
>

  Got a couple directly from the good folks at Tekmos, who gave us a 
free sample to use for our design project.
  So you're saying that the A8-A11 lines never do connect with the 
PRU (which is what I saw from the data sheet, also) and the whole 
set of directions in the data sheet where it says to pull A8-A11 low 
while writing INIT (so that INIT becomes write protected) will do 
the job for the memory mapping (the MC68HC11 will just follow itself 
to address $1000), but I need to watch out for bus contention with 
any other evices that I might try to map into the $1xxx memory 
block......and yeah, I could use CS' to refine my addressing.
  Don't think I will have anything in that block...running keypad 
and LCD off the built-in MC68 ports...The chip I'll be 
reading/writing with the "transparant" Ports B & C is strictly CS' 
before any read/write action, so I think we'll be good.  Thanks!
  Right now I'm running everything thru Buffalo...any advice &/or 
warnings for use of the PRU if I ever decide to try to set the mc68 
up for stand-alone?  TJ
	

--- In m68HC11@m68H..., "teejsd" <tmjorenby@...> wrote:

>   Got a couple directly from the good folks at Tekmos, who gave us a 
> free sample to use for our design project.
>   So you're saying that the A8-A11 lines never do connect with the 
> PRU (which is what I saw from the data sheet, also) and the whole 
> set of directions in the data sheet where it says to pull A8-A11 low 
> while writing INIT (so that INIT becomes write protected) will do 
> the job for the memory mapping (the MC68HC11 will just follow itself 
> to address $1000), but I need to watch out for bus contention with 
> any other evices that I might try to map into the $1xxx memory 
> block......and yeah, I could use CS' to refine my addressing.
>   Don't think I will have anything in that block...running keypad 
> and LCD off the built-in MC68 ports...The chip I'll be 
> reading/writing with the "transparant" Ports B & C is strictly CS' 
> before any read/write action, so I think we'll be good.  Thanks!
>   Right now I'm running everything thru Buffalo...any advice &/or 
> warnings for use of the PRU if I ever decide to try to set the mc68 
> up for stand-alone?  TJ

I think you've got it pretty much down... I never had to worry about
doing anything special with A8-A11 when using the PRU.  The
connections between the HC11 and PRU are pretty straightforward.  Port
C (AD0-AD7) connects directly to the PRU (NOT through the low-order
HC373 address latch).  PB4-PB7 (A12-A15) connect to A12-A15 on the
PRU, as do the bus control signals E, R/-W, and ALE.  Tie the PRU's
-CS low if you are not using it.

I think what the data sheet is attempting to convey with regard to
writing INIT is that it is important that when writing this register,
if no other, that you do not write to any of the "shadow" addresses
that the PRU would recognize (but the HC11 would not).  That is to
say, always write to $103D when setting INIT, do not attempt to write
it at, say, $143D.  The latter address would be recognized as valid by
the PRU (since it cannot 'see' A8-A11) so the INIT register in the PRU
would be written, but the HC11 would not update it's copy of INIT
because it is decoding all of the address lines.  Writing to a
'shadow' address such as $143D would result in the I/O mapping of the
HC11 and PRU to be out-of-sync.

The PRU is designed to emulate the operation of the resources lost
when using expanded mode as closely as possible for an external
device.  For the most part, it does a good job - some of the timing
for the parallel handshaking modes is subtly different, but not by
much, and I for one have never used that feature so it has never made
any difference in any of my designs.  The major difference between a
PRU and a HC11 in single-chip mode is the way that the I/O register
space is mapped.  Even in this case, the PRU is pretty good at
emulating HC11 behavior - the PRU defaults to using the $1xxx page for
I/O space upon reset, same as the HC11.  The PRU implements INIT
register functionality (for the I/O page) so the partial I/O page that
the PRU emulates (port I/O and DDR registers, port C latch, etc.) can
be moved, just as it can on a standalone HC11.  However, since the PRU
does not have access to A8-A11, nor access to the HC11 *internal* bus,
the I/O page is more "invasive" in the memory map than it is on a
standalone implementation.  In addition to what I mentioned before,
consider this difference: In a HC11 system without a PRU, you can map
RAM or ROM such that it overlaps the I/O page without any bus conflict
ramifications - the I/O page accesses are done using the HC11 internal
bus, and only write activity to the I/O page is reflected on the
EXTERNAL bus.  Obviously, write activity is not an issue if a ROM is
mapped within the I/O page space (it's read-only).  If you have RAM
mapped in this space, it will be written to when write operations to
the I/O page take place, but when the I/O page is read, the INTERNAL
data bus is read, and the EXTERNAL data bus is ignored.  When using a
PRU, you have to be more careful - reads to I/O registers that are
emulated on the PRU have to be read FROM the PRU - that is, they have
to be read from the external bus.  If any other read-enabled device is
present in the same address space, the PRU and the other (memory)
device will contend for the data bus, with predictably disasterous
(and potentially hardware-damaging) results.

Having said all this, most of it is a non-issue as long as you keep
the $1xxx page of the external address space clear, and do not attempt
to re-map the I/O space to any page where external memory-mapped
devices will be selected.

>   Right now I'm running everything thru Buffalo...any advice &/or 
> warnings for use of the PRU if I ever decide to try to set the mc68 
> up for stand-alone?  TJ

I presume by the above question you are asking if there would be
anything to watch out for if you were to somehow be able to run your
application using one of the single-chip modes, or in expanded mode
without the BUFFALO monitor present.  If you plan to try to run out of
the 512-byte EEPROM (at $B600) then there are a number of things you
have to watch out for - this is a long, lengthy subject that I won't
go into right now unless you want me to.  If you are running in
expanded mode with the program stored in external memory without
BUFFALO present, then the only thing you have to be careful about is
to remember to initialize ALL of the HC11 subsystems that you are
using, including the status register and stack pointer, to the
explicit configuration you wish to use.  BUFFALO does things like
setting the stack pointer to a 'safe' location for you when it starts
up; this is most certainly NOT the case when a HC11 is started up
'cold' from reset.  Failure to initialize the stack pointer is one of
the most common 'newbie' mistakes made when migrating an application
from a RAM-resident environment using BUFFALO over to a standalone
environment.  Another thing to watch out for is the difference in how
interrupt vectoring is handled.  In the BUFFALO environment, the
interrupt vectors reside in the BUFFALO ROM and are emulated in RAM;
to change an interrupt vector in the BUFFALO (or bootstrap mode)
environment you write JMP extended instructions to specific
pre-defined addresses in internal RAM.  When running in a
non-BUFFALO/bootstrap environment the interrupt vectors must be part
of your program image, stored as 2-byte address pointers in some form
of (usually external) memory at $FFC0-$FFFF.  The HC11 Reference
Manual discusses this topic in detail, so I won't repeat it here.  If
after reading the manual you still have questions, you are welcome to
ask for clarification or further details here.

Oh, I guess I should mention (in case it is not obvious to you by now)
that it is important that your program reside in a device (e.g. EPROM
or FLASH) that encompasses the very end of the address space
($xxxx-$FFFF).  This is necessary because the aforementioned interrupt
vectors - including the power-on RESET vector - are fetched from
various addresses in the $FFC0-$FFFF region.  In the case of the RESET
vector, this is fetched from $FFFE/$FFFF.
	

--- In m68HC11@m68H..., "teejsd" <tmjorenby@...> wrote:

>   Got a couple directly from the good folks at Tekmos, who gave us a 
> free sample to use for our design project.
>   So you're saying that the A8-A11 lines never do connect with the 
> PRU (which is what I saw from the data sheet, also) and the whole 
> set of directions in the data sheet where it says to pull A8-A11 low 
> while writing INIT (so that INIT becomes write protected) will do 
> the job for the memory mapping (the MC68HC11 will just follow itself 
> to address $1000), but I need to watch out for bus contention with 
> any other evices that I might try to map into the $1xxx memory 
> block......and yeah, I could use CS' to refine my addressing.
>   Don't think I will have anything in that block...running keypad 
> and LCD off the built-in MC68 ports...The chip I'll be 
> reading/writing with the "transparant" Ports B & C is strictly CS' 
> before any read/write action, so I think we'll be good.  Thanks!
>   Right now I'm running everything thru Buffalo...any advice &/or 
> warnings for use of the PRU if I ever decide to try to set the mc68 
> up for stand-alone?  TJ

I think you've got it pretty much down... I never had to worry about
doing anything special with A8-A11 when using the PRU.  The
connections between the HC11 and PRU are pretty straightforward.  Port
C (AD0-AD7) connects directly to the PRU (NOT through the low-order
HC373 address latch).  PB4-PB7 (A12-A15) connect to A12-A15 on the
PRU, as do the bus control signals E, R/-W, and ALE.  Tie the PRU's
-CS low if you are not using it.

I think what the data sheet is attempting to convey with regard to
writing INIT is that it is important that when writing this register,
if no other, that you do not write to any of the "shadow" addresses
that the PRU would recognize (but the HC11 would not).  That is to
say, always write to $103D when setting INIT, do not attempt to write
it at, say, $143D.  The latter address would be recognized as valid by
the PRU (since it cannot 'see' A8-A11) so the INIT register in the PRU
would be written, but the HC11 would not update it's copy of INIT
because it is decoding all of the address lines.  Writing to a
'shadow' address such as $143D would result in the I/O mapping of the
HC11 and PRU to be out-of-sync.

The PRU is designed to emulate the operation of the resources lost
when using expanded mode as closely as possible for an external
device.  For the most part, it does a good job - some of the timing
for the parallel handshaking modes is subtly different, but not by
much, and I for one have never used that feature so it has never made
any difference in any of my designs.  The major difference between a
PRU and a HC11 in single-chip mode is the way that the I/O register
space is mapped.  Even in this case, the PRU is pretty good at
emulating HC11 behavior - the PRU defaults to using the $1xxx page for
I/O space upon reset, same as the HC11.  The PRU implements INIT
register functionality (for the I/O page) so the partial I/O page that
the PRU emulates (port I/O and DDR registers, port C latch, etc.) can
be moved, just as it can on a standalone HC11.  However, since the PRU
does not have access to A8-A11, nor access to the HC11 *internal* bus,
the I/O page is more "invasive" in the memory map than it is on a
standalone implementation.  In addition to what I mentioned before,
consider this difference: In a HC11 system without a PRU, you can map
RAM or ROM such that it overlaps the I/O page without any bus conflict
ramifications - the I/O page accesses are done using the HC11 internal
bus, and only write activity to the I/O page is reflected on the
EXTERNAL bus.  Obviously, write activity is not an issue if a ROM is
mapped within the I/O page space (it's read-only).  If you have RAM
mapped in this space, it will be written to when write operations to
the I/O page take place, but when the I/O page is read, the INTERNAL
data bus is read, and the EXTERNAL data bus is ignored.  When using a
PRU, you have to be more careful - reads to I/O registers that are
emulated on the PRU have to be read FROM the PRU - that is, they have
to be read from the external bus.  If any other read-enabled device is
present in the same address space, the PRU and the other (memory)
device will contend for the data bus, with predictably disasterous
(and potentially hardware-damaging) results.

Having said all this, most of it is a non-issue as long as you keep
the $1xxx page of the external address space clear, and do not attempt
to re-map the I/O space to any page where external memory-mapped
devices will be selected.

>   Right now I'm running everything thru Buffalo...any advice &/or 
> warnings for use of the PRU if I ever decide to try to set the mc68 
> up for stand-alone?  TJ

I presume by the above question you are asking if there would be
anything to watch out for if you were to somehow be able to run your
application using one of the single-chip modes, or in expanded mode
without the BUFFALO monitor present.  If you plan to try to run out of
the 512-byte EEPROM (at $B600) then there are a number of things you
have to watch out for - this is a long, lengthy subject that I won't
go into right now unless you want me to.  If you are running in
expanded mode with the program stored in external memory without
BUFFALO present, then the only thing you have to be careful about is
to remember to initialize ALL of the HC11 subsystems that you are
using, including the status register and stack pointer, to the
explicit configuration you wish to use.  BUFFALO does things like
setting the stack pointer to a 'safe' location for you when it starts
up; this is most certainly NOT the case when a HC11 is started up
'cold' from reset.  Failure to initialize the stack pointer is one of
the most common 'newbie' mistakes made when migrating an application
from a RAM-resident environment using BUFFALO over to a standalone
environment.  Another thing to watch out for is the difference in how
interrupt vectoring is handled.  In the BUFFALO environment, the
interrupt vectors reside in the BUFFALO ROM and are emulated in RAM;
to change an interrupt vector in the BUFFALO (or bootstrap mode)
environment you write JMP extended instructions to specific
pre-defined addresses in internal RAM.  When running in a
non-BUFFALO/bootstrap environment the interrupt vectors must be part
of your program image, stored as 2-byte address pointers in some form
of (usually external) memory at $FFC0-$FFFF.  The HC11 Reference
Manual discusses this topic in detail, so I won't repeat it here.  If
after reading the manual you still have questions, you are welcome to
ask for clarification or further details here.

Oh, I guess I should mention (in case it is not obvious to you by now)
that it is important that your program reside in a device (e.g. EPROM
or FLASH) that encompasses the very end of the address space
($xxxx-$FFFF).  This is necessary because the aforementioned interrupt
vectors - including the power-on RESET vector - are fetched from
various addresses in the $FFC0-$FFFF region.  In the case of the RESET
vector, this is fetched from $FFFE/$FFFF.