Searching \ for 'PIC16C74 parallel slave port' 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: 'PIC16C74 parallel slave port'.

Truncated match.
PICList Thread
'PIC16C74 parallel slave port'
1997\03\06@194504 by Michael N. Steen

flavicon
face
Hello everyone,

Does anybody know how to use the PIC16C74 PSP, then please help.
I've tried by the book - I've read the data sheets from front to back and
back again, I've read the PSP application note, AN579, and the errata sheets
A and B.
Every register concerned is set accordingly and it still does not work.

I can measure CS and WR low pulses, RD high, (RE0, RE1 & RE2) but the PSPIF
interrupt flag is not set. I've tried both with and without PSP interrupt
enabled, but the PSPIF is not set no matter what.

The local Microchip representative have been working on it for about a week
now but haven't come up with any useful suggestions yet.
There must be somebody out there who have used this feature - or so I hope.

Thanks

Michael

1997\03\07@210018 by Michael N. Steen

flavicon
face
I've tried to post this to the PICLIST before, or at least I believe I did,
but it came back from some other address with a note saying that it could
not be delivered, so now I'm trying again. If I'm mistaken, please excuse me.
I wrote:

Hello everyone,

Does anybody know how to use the PIC16C74 PSP, then please help.
I've tried by the book - I've read the data sheets from front to back and
back again, I've read the PSP application note, AN579, and the errata sheets
A and B.
Every register concerned is set accordingly and it still does not work.

I can measure CS and WR low pulses, RD high, (RE0, RE1 & RE2) but the PSPIF
interrupt flag is not set. I've tried both with and without PSP interrupt
enabled, but the PSPIF is not set no matter what.

The local Microchip representative have been working on it for about a week
now but haven't come up with any useful suggestions yet.
There must be somebody out there who have used this feature - or so I hope.

Thanks

Michael

1997\03\07@221750 by Andy Kunz

flavicon
face
At 02:59 AM 3/8/97 +0100, you wrote:
>I've tried to post this to the PICLIST before, or at least I believe I did,
>but it came back from some other address with a note saying that it could
>not be delivered, so now I'm trying again. If I'm mistaken, please excuse me.
>I wrote:
>
>Hello everyone,
>
>Does anybody know how to use the PIC16C74 PSP, then please help.
>I've tried by the book - I've read the data sheets from front to back and
>back again, I've read the PSP application note, AN579, and the errata sheets
>A and B.
>Every register concerned is set accordingly and it still does not work.

Nobody replied before because Microchip did a poor job of implementing the
PSP, and it's not especially useful from what I understand.

Hook up a FIFO and let the PIC use that to get data quickly.  That's what I
did.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\03\08@202451 by Michael N. Steen

flavicon
face
At 21.02 07-03-1997 +0000, you wrote:
>
>Here's some code from a PIC16C64 project using PSP.  I tried
>including it in the message, but it didn't format very well, so I'm
>attaching it.  This was written with ByteCraft MPC.
>
>Hope you find it useful ...
>
>
>Randy Rasa
>spam_OUTrrasaTakeThisOuTspamsky.net

Thank you for your code. My first impression is that it looks pretty much
like mine.  I'll study it more careful when I get back to work and can
compare it with what I've tried, to see if there are any significant
differences.
I don't think the problem is with the interrupt service routine, the problem
is that the PSPIF bit does not get set in the first place despite low pulses
on !CS and !WR. I'm trying to interface the PIC to a 80C85 processor, !CS is
900 ns and !WR is 450 ns well within !CS.
I've had a timer running, it worked fine and the interrupt service routine
too, pulsing an output pin.

Andy wrote:
>Nobody replied before because Microchip did a poor job of implementing the
>PSP, and it's not especially useful from what I understand.
>
>Hook up a FIFO and let the PIC use that to get data quickly.  That's what I
>did.
Maybe Andy is right, I just don't hope it means that it don't work at all
because the PSP is an essential feature in my design.
The PIC is going to replace an obsolete multi communications part and for
that it is ideal, it has all the functions I need and more but my board is a
bit crowded and there is hardly space for any more circuitry.

Thank you for your inputs.  Do you, or anybody else, have an explanation for
the missing PSP interrupt flag, PSPIF in PIR1?

Regards
Michael

1997\03\08@213244 by rrasa

flavicon
face
> I don't think the problem is with the interrupt service routine, the problem
> is that the PSPIF bit does not get set in the first place despite low pulses
> on !CS and !WR. I'm trying to interface the PIC to a 80C85 processor, !CS is
> 900 ns and !WR is 450 ns well within !CS.
>
> Thank you for your inputs.  Do you, or anybody else, have an explanation for
> the missing PSP interrupt flag, PSPIF in PIR1?

You said you'd read the errata sheets, so I didn't include this, but
I saw a similar problem, and the cause of the problem was that use of
the RETURN instruction clears the PSPIF bit.  Note that this was in
May of last year when I was messing with this, and Rev A silicon was
supposed to have fixed this problem, but I have not verified this
personally.

My solution was to avoid use of the RETURN function.  Since I
couldn't control how the compiler used it, I simply forced a return
with a "RETLW 00h" just before the end of a function.

Here's the note from my source:

//
// The PIC16C64 and PIC16C65 have a bug that affects the operation of
// the parallel slave port (PSP).  The bug is that the IBF (Input
// Buffer Full) flag is cleared whenever the processor executes a
// RETURN instruction.  Since the compiler uses this instruction a
// lot, the following #define is used to enable insertion of a RETLW
// #0 instruction just before the compiler-generated RETURN.  This
// ends up wasting a few bytes, but allows the PSP to work ...
//

#define PSP_BUG_WORKAROUND TRUE

#if PSP_BUG_WORKAROUND == TRUE
 #define PSP_Return()  #asm " RETLW 00h"
#else
 #define PSP_Return()
#endif


The way this is used is like this:

void function (void)
{
 // ... do something ...
 PSP_Return();
}

The problem with this, of course, is that it makes it difficult to
return values from functions, except by using global variables.  In
my application this was not a big deal, but your mileage may vary ...

The weird thing for me was that the program worked perfectly when
running from the emulator (Advanced Transdata RICE16), but didn't
work stand-alone, in a real PIC.

But as soon as I replaced all my RETURNs with RETLWs, the PSP
magically started working ...

Randy Rasa
.....rrasaKILLspamspam@spam@sky.net
http://www.sky.net/~rrasa

1997\03\09@170513 by Michael N. Steen
flavicon
face
At 20.30 08-03-1997 +0000, you wrote:
>>
>> Thank you for your inputs.  Do you, or anybody else, have an explanation for
>> the missing PSP interrupt flag, PSPIF in PIR1?
>
>You said you'd read the errata sheets, so I didn't include this, but
>I saw a similar problem, and the cause of the problem was that use of
>the RETURN instruction clears the PSPIF bit.  Note that this was in
>May of last year when I was messing with this, and Rev A silicon was
>supposed to have fixed this problem, but I have not verified this
>personally.
>
>My solution was to avoid use of the RETURN function.  Since I
>couldn't control how the compiler used it, I simply forced a return
>with a "RETLW 00h" just before the end of a function.
>
( .... )
{Quote hidden}

In fact I have read the errata sheets but I'm not sure which version silicon
I'm using and I don't know if there are any ways to tell, either.
I've tried to avoid the use of RETURN instructions, too, but in view of your
findings I'll study my code and my whole setup more careful first thing in
the morning.

Returning values is no problem as I'm using Forth and assembler.  I return
values on the stack anyway.

Maybe I should get me a couple of new devices (newly made) hoping they fixed
the problems in the silicon.

I'll definitely look into those RETURN instructions and let you know if I
get it up and running.
If not, I'll probably have some more questions.

Regards
Michael

1997\03\10@185242 by Michael N. Steen

flavicon
face
Just to tell that my PSP project is still alive, or should I say beginning
to come out of the coma.  Today I got a little code running, a small main
loop, like:
       Start   TRISE := $17    ; Enable PSP
               TRISA := $00    ; PortA as output
               PIE1 := $80     ; Enable PSP interrupt
               ADCON1 := $07   ; Set PortE as digital I/O
               INTCON := $C0   ; Enable interrupts
       Loop    If  Indata.flag is set
               then  increment counter
               Output counter to PortA
               Clear Indata.flag
               goto loop

and an interrupt routine checking for PSP interrupt and PSP write, then
setting the Indata.flag

The crucial part is to set PortE as digital I/O by setting ADCON1 properly,
otherwise PortE will be inputs for the A/D converter, a relation that was
not clearly stated in the old data sheet I was relying on but is obvious
from the most recent one. (DS30390E - can be downloaded from Microchips
website).

I've tried replacing the RETURNs in my regular code with RETLW $00, like
Randy Rasa suggested, but I havn't got it working yet.  There might still be
something  I have overlooked.

Thank you for you help so far, I'll be back when I know more.

Regards
Michael

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