• AVR Freaks

Hot!SPI acceptable slew rate

Author
acharnley
Super Member
  • Total Posts : 613
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
2020/08/14 06:29:00 (permalink)
4 (1)

SPI acceptable slew rate

Hi,

I have a poor-mans level translator (the resistors are swapped to 2k) and stuck a scope on it. The slew isn't great and my question is what is acceptable? I'm not exactly sure how it works but imagine having a slew shifts the point at which the clock is recognised and a data shift begins, so if the data line has a worse slew then the value may not get picked up?

I'll change the approach on my next prototype revision but hoping to make this one work for demonstration purposes.

Thanks, Andrew

Attached Image(s)

#1

5 Replies Related Threads

    ric
    Super Member
    • Total Posts : 28378
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: SPI acceptable slew rate 2020/08/14 14:15:56 (permalink)
    0
    Which is the "active" edge?
    If your SPI is configured correctly, the data should be changing on the opposite edge.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    acharnley
    Super Member
    • Total Posts : 613
    • Reward points : 0
    • Joined: 2016/05/01 06:51:28
    • Location: 0
    • Status: offline
    Re: SPI acceptable slew rate 2020/08/14 14:42:29 (permalink)
    0
    Both are Mode 0. It was working correctly previously but I changed the level translator implementation which introduced this slew, hence the question to see if it's the problem.
    #3
    ric
    Super Member
    • Total Posts : 28378
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: SPI acceptable slew rate 2020/08/14 14:53:57 (permalink)
    +1 (1)
    PIC datasheets do not use "Mode #" terminology.
    Wikipedia says that "Mode 0" corresponds to CKP=0, CKE=1, SMP=0
    So output data changes on the rising edge, and input data is sampled on the falling edge of the clock signal.
     
    You should watch both data and clock together, and see if data has settled before the clock signal falls.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #4
    acharnley
    Super Member
    • Total Posts : 613
    • Reward points : 0
    • Joined: 2016/05/01 06:51:28
    • Location: 0
    • Status: offline
    Re: SPI acceptable slew rate 2020/08/15 03:57:12 (permalink)
    0
    PIC datasheets may not but MCC does, certainly 'mode 0'.

    So far I haven't been able to make it work, but from what you say the rising edge timing wouldn't matter that much, so long as the slew is sharp enough to be detected as a rising edge.
    #5
    Aussie Susan
    Super Member
    • Total Posts : 3756
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: SPI acceptable slew rate 2020/08/16 19:39:37 (permalink)
    +2 (2)
    "In theory", the edge used to capture the value should not really worry too much about any slew on the signal, unless the slew is SO bad that the data (which should have changed with the other clock edge) is still changing - if that is the case the you need to slow your clock down.
    I can't see any ringing or other problems on that could cause false clock transitions being picked up.
    Susan
    #6
    Jump to:
    © 2020 APG vNext Commercial Version 4.5