Art Interface Device logo   Project description  Development   Mailing List  Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AID: RE: peripherical card

From: cis (by way of Michelle Kasprzak)   cisartsens.org
Date: Tue, 12 Nov 2002 06:25:41 -0800

: Sent via the Art Interface Device mailing list: aid@interaccess.org
: Use your "Reply All" to  reply to the list, "Reply" for private response

>  There should be a note somewhere, though, that one should probably NOT
>  place the address on the address bus AND assert /R in the same instruction.
>  This would be possible, since they share the same port, but could result in
>  spurious reads from peripheral boards.

Yes,
it must be sequential, and you must keep in mind that in some PIC
(because of the internal technic of bcf, and bsf instructions and 
pipelines specifications)
it is not recommended to access 2 times consecutively to the same external port
it is better to put a nop (or any instruction) between puting adress and read
if you code in C in differents fonctions for place adress and put read
  if they are non inline fonctions, the call to the function and 
return from function will do the wait for you

>  This works as a hold, to ensure that the data on the bus is that which
>  was in the 373 when the /R signal was asserted (or, about 31ns thereafter).
>  I would leave the creative use of LE up to individual designers, myself.
>  I can see applications where you'd want the latches transparent during the
>  read or write, and others where you might not want that.

if you prefer,
but
if you want another data, you just need to read again by puting read 
up and read down,
and you will have the next most recent data
  I don t thing you want so big data traffic that you need to not 
loose time on puting up/down a pin
moreover, this could be a synchronisation between card

but I have always the same question :
how the main card knows the sort of card it is reading
and it must do with the data

cis@artsens.org

:      messages saved at http://www.interaccess.org/aid/list
:      unsubscribe/help requests to mailto:Majordomo@interaccess.org