When is PIN sampled during an inp?

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I saw that this question had been asked before, but I can't find
an answer. I need to know at what point is the pin sampled
during an inp instruction. As near as I can tell it seems to be
during the falling edge of the clock, but I'm just guessing since
that may be causing me some problems.

The part I'm using is a 2313. Is there a timing diagram of the
i/o pins somewhere? Doesn't appear to be in the doc0839.pdf.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to confuse things for me even further, I've just read that
the pins are sampled at the end of the previous instruction. OK,
now I *really* need the timing diagrams.

I just posted my question on Atmel's web form. If I get a
response I'll follow up my post here.

I'm also wondering whether two AVRs tied together with the same
clock can read/write to one another. Can you execute an outp on
one and and inp on the other during the same clock and get valid
data? I ask this because I'm bit-banging a codec and it takes
my output without problems, yet when I try to read I get unstable
data. On the scope the i/o is precisely lined up with the center
of the bit at the peak of the oscillator.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mmmkay, here is a document that describes i/o timing. Page 2.

http://www.atmel.com/atmel/acrob...

So it looks like inp samples at the beginning of the clock, and
outp at a minimum latches after about 1/4 clock. So really you
can't i/o between two AVRs without having one of them be one
clock ahead or behind the other.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

The input pin signal is samples on the positive edge of the I/O clock. There is a latch and a flip-flop, making the worst-case time for the signal to reach the PIN register, 1.5 clock cycles.

Best regards,

Morten, AVR tech. support, Atmel FAE

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Regarding Chris's posting...

This document describes the AVR core, not the I/O pin in an actual device. Timing diagrams will be available in datasheets for new parts.

Best regards,

Morten, AVR tech. support, Atmel FAE

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> What about a bit of handshaking with your data transfers, using
> a spare I/O line? Otherwise, how does the micro that's
> receiving the data, know precisely at which clock cycle to
> perform a read ?
>
> Or, if you've already worked this out, why not wait for one
> clock cycle, before reading, while the data settles.

What I'm doing is communicating with a codec at one bit per
clock. The codec sends/receives 16 bits during a frame which
occurs every 256 clocks. Normally I would communicate slower,
but in this case it affects the sample rate of the audio, and
I'd like to run with a 3.6864Mhz crystal. If I were to reduce
the rate of communications, then I'd have to go to 7.3728 which
I wouldn't like to do.

Thankfully the codec has a slave mode, so I'm able to provide the
framing signal which hasn't been a problem. I had to use an
inverted clock for the codec to get the timing right, and it
worked right away for sending bits to the codec. Was having
problems on reading but I think I have it going now -- at least
it worked a couple of times, enough to convince me to make a
cleaner prototype.

I use an inverted clock on the codec to get the timing proper.
And to achieve the bit rate I load up 16 registers and I outp
them consecutively. For the receive, I also use timer1's IC1 as
the frame start signal so that I can get the frame signal to
occur simultaneously with my consecutive inp instructions.

Ironically this wasn't necessary as I found out yesterday that
I can get good data if I wait 2 clock cycles before I start
reading pin. Not sure why its 2 clock cycles. Was supposed to
only be one since I expected my inp to coincide with the last 1/3
of the codecs output bit -- which is why I suspected that I'd
only need to run one clock behind.

At any rate, thanks Jack and Morten.

admin's test signature