Searching \ for 'Microchip PSP port and ISA-bus communications' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=port
Search entire site for: 'Microchip PSP port and ISA-bus communications'.

Truncated match.
PICList Thread
'Microchip PSP port and ISA-bus communications'
1999\01\16@120256 by Andy Kunz

flavicon
face
As much as I might dislike the idea (bad memories <G>), I'm involved in a
project which requires that a 40-pin PIC be communicating bi-directionally
with a PC on the ISA bus.

If anybody has done this _SUCCESSFULLY_ I'd appreciate hearing from you for
some pointers.  I received some code fragments a while back from somebody,
but I can't find them and I forget who it was.

Thanks.

Andy


  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\01\17@150913 by Chris Eddy

flavicon
face
Andy;

I have a customer that did this, but through the FPGA on the board (can you?).
I don't know a whole lot about the project, but I know that they use the part
as a PSP to the PC, a watchdog protocol through the port, and power up/down
functions through the pic.  That customer is STILL chasing errant shut downs in
the design at this point.  It is the last problem with the product!  They
called me in for an opinion and I told them as politely as possible not to
trust the PSP completely.  I too had the same bad experiences with a (64??)
where the PSP interrupts never came.  Wasn't that an erratta in the past?  My
contribution was enlightening them to the use of an emulator to catch fast
problems from inside of the part.  They were unaware that they were using a
sledgehammer (windowed parts).  Their current rev simply exchanges messages
fast enough so that the estimated ten percent of lost messages (as yet
unexplained) are overlooked.  Nothing like using a pickup truck and a chain to
take the watchdog for a walk!

Although I haven't done the ISA to PSP myself, I would seriously reconsider
it.  Or make sure Windblows in on the system and blame the bi-daily crashes on
that!

Chris Eddy
Pioneer Microsystems, Inc.

Andy Kunz wrote:

{Quote hidden}

1999\01\17@234215 by Harold M Hallikainen

picon face
On Sat, 16 Jan 1999 11:46:49 -0500 Andy Kunz <spam_OUTmontanaTakeThisOuTspamFAST.NET> writes:
>As much as I might dislike the idea (bad memories <G>), I'm involved
>in a
>project which requires that a 40-pin PIC be communicating
>bi-directionally
>with a PC on the ISA bus.
>
>If anybody has done this _SUCCESSFULLY_ I'd appreciate hearing from
>you for
>some pointers.  I received some code fragments a while back from
>somebody,
>but I can't find them and I forget who it was.
>


       I have successfully used PSP, though I used it to talk with a printer
port (PSP receiving 8 bits at a time from the printer port, then using
nibble mode to get stuff back to the PC).  I can send you a bit of PSP
code on Monday, if you wish.
       Something tricky on the ISA bus...  Are you putting the whole chip at
one ISA address, since the PSP only captures 8 bits?  I've tried to think
of ways around that, providing a few "register select" lines that can be
tied to the ISA bus, but haven't figured out how to do that.


Harold


___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\01\18@071743 by keithh

flavicon
face
I concur with the negative opinions of the PSP.

At first glance, I thought a PSP would be a great way to make
your own smart peripheral chips.

Having a byte-wide two-way data port, and interrupts when a device
(say a PC) read/writes the PIC is a good start.

Then you wonder about flow control.
Where's the status register for the PC to see if this one-byte
buffer is full? Or a control register?
Where's the line for the PC to select between data/status?

They're not there!

You can get away without flow-control on a slow serial where
you can reasonably expect micros to handle a character in the
time taken to transfer it, but the PSP takes just microseconds.

To be practical, I think you'd have to kludge on some flow control.

Alternatively how about using a small dual-port RAM with a
true semaphore - you can get them from IDT.

If you do, then you may be better off with a micro that can read
external RAM, e.g. an 8051 or Atmel 8515.

1999\01\18@093756 by Ralph Stickley

flavicon
face
While not a big fan of the PSP port, I was able to make it work reliably
on an ISA bus as a motherboard peripheral device.  The Protocol between
a pentium and the PIC was selected by someone else, but I was able to
make it work as described below.  Our emulator from Tech-Data (and even
from Microchip, I've been told) was useless for this development
effort.  However, the simulator was quite invaluable - simulate
everything on the PSP port!!

The protocol we used was an "Empty Mail Box" protocol, something like
this:
Pentium writes to PIC:
1.  PIC powers up and sets PSP port to zero (empty).
2.  Pentium reads the PSP port (zero) and writes to it
3.  Pentium polls the PSP port until it gets a non-zero value (write
verified by the PIC)
4.  Pentium polls the PSP port until it gets a zero (empty)
5.  Pentium writes another byte

Pentium reads PIC data
1.  PIC outputs non-zero value on PSP port.
2. Pentium reads non-zero value
3.  PIC outputs zero on the PSP port (empty)
4.  Pentium reads zero
5.  PIC outputs non-zero value

Since the Pentium can literally beat the PIC to death (i.e.. continuous
polling by the Pentium will generate PSP interrupts faster than the PIC
can respond thus preventing any code from executing on the PIC), the
polling rate must be regulated in the Pentium code.

The PIC does not have to respond to every read interrupt.  The PIC
interrupt code checks a flag to determine if a response to a read
interrupt is required.  If not, nothing is done.

The Pentium can not overwrite the PSP port if the protocol is properly
followed.  The overwrite bit should be checked just in case, and an
error value returned to flag any improper handshaking.

Likewise, the Pentium must perform a read to allow the PIC to output the
next data value, the PIC thus can not output data that is not read by
the Pentium.

Note, this precludes the possibility of the PIC outputting data values
of zero...Thus, the messaging layer of the protocol must specify that
zero values are assigned to some other number (sort of like a SLIP
protocol or something ).  Since our messages are not very sophisticated,
we generally send a 0x80 or something.  Also, the Pentium can write a
zero to the PSP port with no problem.

The key to the implementation is the "read enable" flag shared by the
PIC PSP interrupt code and the PIC main code.  This flag must be set
before we output our data.  If a polling interrupt occurs after this bit
is set and before the port data is set, we can see that we haven't
cleared the write buffer so we can ignore this.

The read enable flag can not be set after we output our data.  If a
polling interrupt occurs, the pentium has read our data but we haven't
enable the "read enable" yet.  Now we enable the read enable flag, but
the pentium has read our data and we don't know that it has been read.

My interrupt code merely sets an event flag for the main-line code to
check.  When this event flag is set, the PSP event handler state machine
gets executed.  The IDLE event reads the command value written by the
Pentium, and knows weather to 1. wait for a command parameter; 2. wait
for other data; 3. output data in response or 4. do nothing.  The
handshake goes something like this:

1. Pentium outputs Command byte
2. PIC gets PSP write interrupt - sets flag to process event
3. Mainline checks flag, starts PSP event state machine
4. Command value is parsed...output 0x01
5. Pentium reads 0x01
6. PIC PSP read interrupt enables PSP event...outputs 0x00
7. Pentium reads 0x00 (PIC ignores this read..we are waiting for a
write)
8. Pentium writes Parameter byte
9. PIC detects write, parses command/parameter as required..output 0x01
10. Pentium reads 0x01
11. PIC detects that read was performed...outputs 0x00
12.  Pentium reads 0x00
13. PIC gets interrupted by read, event handler is not scheduled
(nothing left to do).

Note: I also have an initial startup event that waits for the /CS /WR
and /RD lines to be asserted before the PSP interrupt is enabled.  If
you don't do this, you may get spurious interrupts / data from the BIOS
as it scans the ISA ports.

If this sounds like something you'd like to try or just want to see the
code, let me know. Good luck!

Ralph

1999\01\18@101122 by Andy Kunz

flavicon
face
>If this sounds like something you'd like to try or just want to see the
>code, let me know. Good luck!

Like to or not, I may have to.  Yes, I'd appreciate anything.  Send to me
private .....montanaKILLspamspam@spam@fast.net or mtdesignspamKILLspamfast.net

Thanks.

Andy


  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\01\18@112414 by myke predko

flavicon
face
Hi Andy,

I've used the PSP for a number of ISA Adapter applications and I'll try not
to reiterate Ralph's comments below and see what value I can add (an iffy
proposition at the best of times).

1.  I typically use four 74LC85 as the address comparators (address bits 15
to 0) and pass _IOR and _IOW directly to the PICMicro.  This is a fairly
fast interface.

2.  Decode all 16 address bits.  "Officially" the PC only decodes only the
least significant 10, but this really hasn't been true since the PC/XT.

3.  Use a fairly fast clock.  At least 10 MHz is good and you might as well
pick up the 14.31818 MHz that's available on the ISA bus and avoid the
hassle of putting on an oscillator in the first place.

4.  Depending on the prototyping card/Raw Card layout/PC you are using, you
might want to consider using +12 Volts and regulating it using a 7805.  This
is especially important if you are doing anything with analog signals.  I
have a '386 PC that I use for testing out designs before I put them into a
Pentium PC and it has 200 mV ripple on the motherboard.

5.  If the PICMicro is doing something for you, then let it drive an
interrupt onto the ISA bus rather than poll for a result.  The PC will
transfer data faster than the PICMicro can respond to it.  I found that
writing a VxD with an interrupt handler to facilitate the data transfer to
be the most efficient way of doing it in a Windows system.

6.  When the PICMicro is executing a request, disable PSP interrupts.  If
you are using a mailbox protocol, after reading the byte, echo it back to
the port (so the PC can read it).  When the operation is complete, request
the PSP interrupt and output in a byte indicating that the operation is
complete.

7.  Keep your interface simple.  I have gotten quite good results for
applications which just need to read and write single bytes of data
periodically.  If you have to transfer data at a rate faster than 1
KByte/sec then you should probably find another way of doing it.

Good luck,

myke

{Quote hidden}

Go on the drive of your life, this week in the book room:

http://www.myke.com/Book_Room/book1a.htm

Now Available!  "Programming and Customizing the 8051 Microcontroller".
Find out more at:

http://www.myke.com/My_Books/pac8051.htm

1999\01\18@122000 by Andy Kunz

flavicon
face
>1.  I typically use four 74LC85 as the address comparators (address bits 15
>to 0) and pass _IOR and _IOW directly to the PICMicro.  This is a fairly
>fast interface.

This one has a PLD.

>2.  Decode all 16 address bits.  "Officially" the PC only decodes only the
>least significant 10, but this really hasn't been true since the PC/XT.

Yes, and ALE is important too (found that the hard way some time back)

>3.  Use a fairly fast clock.  At least 10 MHz is good and you might as well
>pick up the 14.31818 MHz that's available on the ISA bus and avoid the
>hassle of putting on an oscillator in the first place.

Customer has 6MHz clock on the PCB.  Needed for the data rate they are using.

>4.  Depending on the prototyping card/Raw Card layout/PC you are using, you
>might want to consider using +12 Volts and regulating it using a 7805.  This

It's going on an embedded PC/104 system, and the PS is on the same PCB as
the PIC, feeding power into the PC that way.  Power should be just fine.

>5.  If the PICMicro is doing something for you, then let it drive an

No, we're just putting a PIC on the board because they look pretty <G>.
Seriously, I understand.  The PIC is doing some bit-bopping so it'll be
busy most of the time.  Which is part of the reason I don't like the PSP
method (I'd prefer a dual FIFO).

>be the most efficient way of doing it in a Windows system.

First version will be DOS-based, later it will use the Phar-Lap WinAPI for
embedded systems.

>6.  When the PICMicro is executing a request, disable PSP interrupts.  If
>you are using a mailbox protocol, after reading the byte, echo it back to
>the port (so the PC can read it).  When the operation is complete, request
>the PSP interrupt and output in a byte indicating that the operation is
>complete.

With the suggestions from the two of you for a mailbox, the PSP sounds like
a do-able albeit cumbersome method.

>7.  Keep your interface simple.  I have gotten quite good results for
>applications which just need to read and write single bytes of data

I'll be pumping 8-byte blocks out from the PIC to the RF serial line, but
the packets between PC and PIC will be longer due to the protocol standard
we use.

>KByte/sec then you should probably find another way of doing it.

How about 6250 KBps!

Andy
  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\01\18@144451 by kfisk

flavicon
face
Andy,

This is probably a stupid question, or perhaps proprietary, but how do you
get 6250 KBps from a 6 Mhz clock?

>
> Customer has 6MHz clock on the PCB.  Needed for the data rate
> they are using.
>
.. .snipped
>
> >KByte/sec then you should probably find another way of doing it.
>
> How about 6250 KBps!
>

Oh, one other question for the non low level PC literate. What is PSP (he
says risking scorn from the group ;)?

1999\01\19@062952 by James L. Williams

flavicon
face
Andy,  I'm not much with using the pic, however I have much experience with the
PC.  It seems to me that your main concern is loss of data.  The way that I
look at it is this, the PC ISA bus maxs at about 14Mhz tops.  If you are
clocking the pick at 20Mhz and you have a fast interrupt routine to move the
data, then you should be OK.

However,  the approach that I would take would be a interrupt driven buffer on
the PC side.  Hence,  have a buffer say 256 bytes in length, set up an external
interrupt that the pick can generate.  On each interrupt that the pick
generates, put the data on the bus, decrement the buffer counter.  Also, it is
a good idea to have a dual buffer on the PC, so that once one buffer is used
for the pic to read, the other is used for the pc to continue writing to.

Normally I try to fill the buffer full before I transmit the data, especially
if I can generate the data several times faster than the speed of the bus.  Or
at least fill it at until until the given data for any single operation is
completed then generate an interrupt on the pic side.  Consider this a
handshaking senerio.  In one form or another handshaking is used by most
perriferals, wether it be DMA or not.  Also, people talk about FIFO buffers as
being the way to go, but sometimes forget that it is just as easy to implement
the same hardware FIFO in software.  The only thing that is being sacrificed is
an IRQ line.  I always try to utilize what is on the PC first before I start
looking at complicated protocols for solving the inssues at the Pic side.

Andy Kunz wrote:

{Quote hidden}

1999\01\19@104805 by Andy Kunz

flavicon
face
>However,  the approach that I would take would be a interrupt driven
buffer on
>the PC side.  Hence,  have a buffer say 256 bytes in length, set up an
external

Thanks, that's already the way it works.


  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\01\19@115635 by myke predko

flavicon
face
Hey Andy!

<SNIP PLD/74LC85 Comparators>

>>2.  Decode all 16 address bits.  "Officially" the PC only decodes only the
>>least significant 10, but this really hasn't been true since the PC/XT.
>
>Yes, and ALE is important too (found that the hard way some time back)

I have not had issues with that except for 16 bit transfers (which I now
avoid).  Any hints on what you've seen?  I generally ignore ALE and haven't
had any problems with eight bit transfers.

<SNIP Clock, Power, PIC Activity and Mailbox>

>I'll be pumping 8-byte blocks out from the PIC to the RF serial line, but
>the packets between PC and PIC will be longer due to the protocol standard
>we use.
>
>>KByte/sec then you should probably find another way of doing it.
>
>How about 6250 KBps!

Sounds like an interesting project, any chance you can tell us more?

Thanx,

myke

This week's books, first find out what I don't like about Michael Eisner's
"Work in Progress" and then what I did like about P.T. Deutermann's "Zero
Option":

http://www.myke.com/Book_Room/book1a.htm

Now Available!  "Programming and Customizing the 8051 Microcontroller".
Find out more at:

http://www.myke.com/My_Books/pac8051.htm

1999\01\19@145050 by Andy Kunz

flavicon
face
>>Yes, and ALE is important too (found that the hard way some time back)

>I have not had issues with that except for 16 bit transfers (which I now
>avoid).  Any hints on what you've seen?  I generally ignore ALE and haven't
>had any problems with eight bit transfers.

Yup.  Missing bytes in the outbound direction, extra bytes in the outbound
direction.

We moved A0 to ALE and it worked great.

>>How about 6250 KBps!
>
>Sounds like an interesting project, any chance you can tell us more?

Sorry about the typo.  That's 62500 bits per second.

It talks to TV's and set-top boxes on an RF-LAN.  Bi-Dir.

Andy
  \-----------------/
   \     /---\     /
    \    |   |    /          Andy Kunz
     \   /---\   /           Montana Design
/---------+   +---------\     http://www.montanadesign.com
| /  |----|___|----|  \ |
\/___|      *      |___\/     Go fast, turn right,
                              and keep the wet side down!

1999\01\22@153711 by John Payson

flavicon
face
|While not a big fan of the PSP port, I was able to make it work reliably
|on an ISA bus as a motherboard peripheral device.  The Protocol between
|a pentium and the PIC was selected by someone else, but I was able to
|make it work as described below.  Our emulator from Tech-Data (and even
|from Microchip, I've been told) was useless for this development
|effort.  However, the simulator was quite invaluable - simulate
|everything on the PSP port!!

What about adding a little bit of external logic to augment the
PSP with those extra features:

[1] A latch which grabs A0 when the PC performs a write operation.

[2] A tri-state driver which drives D0 of the bus with a "ready"
   signal; this may either be generated directly by the PIC (e.g.
   having it toggle each time a request is completed) or by ext-
   ernal logic (a latch which the PIC can set, and which is cleared
   by a read of address zero or a write to either address.

These functions could probably combined with the address decoding in
a small PLD like a 22V10; doing so would probably make the PSP port
much more useful.



Attachment converted: wonderland:WINMAIL.DAT (????/----) (0002864A)

1999\01\24@061531 by Madis Kaal

flavicon
face
Although it has nothing to do with Microchip PSP, I have a
generic MCU to ISA bus interface design on my WWW page at
http://www.nomad.ee/micros/index.html. This exact design
is untested, although I have successfully used very similar
design (different data exchange method and address decoder).

btw, does anyone know how to get rid of this NetCenter crap
that the Communicator keeps showing me when I try to read my
mail? Any ideas how to use something other than Netscape for
my internet search engine? Or for that matter, does anyone
know how to disable any access to netscape site from Communicator?
(please respond to this OT question privately).

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...