element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum Minimum spec oscilloscope for rpi spi
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Suggested Answer
  • Replies 20 replies
  • Answers 7 answers
  • Subscribers 668 subscribers
  • Views 3088 views
  • Users 0 members are here
  • spi
  • oscilloscope
  • raspberry_pi
  • raspberry pi
Related

Minimum spec oscilloscope for rpi spi

Former Member
Former Member over 9 years ago

Hey,

I'm fairly new to the electronics scene and was wondering what the minimum specs for an oscilloscope would be if i needed to look at raspberry pi spi transactions?

thanks.

  • Sign in to reply
  • Cancel
Parents
  • Robert Peter Oakes
    0 Robert Peter Oakes over 9 years ago

    I agree with alot of what is being said here but if your not designing the SPI logic or interface then you should be able to trust the signal integrit to a certain extent and what matters more is are you sending the right commands and data to the remote device. this can be achieved with not much more than 2-4X the data bit rate (So you dont miss the edges and are able to decode the signal

     

    I have an MDO3054 (500Mhz 4 Channel with Logic Analyser ) with all the protocol stuff enabled and every time I have had an issue with SPI or I2C, it has come down to either having the wrong mode in my driver software or I forgot to terminate the signals with a suitable pullup

     

    So at the end of the day, slowing down the signal to even below 1Mhz will allow any scope to see what mode your running in and that the levels are where they should be, after that, slowly crank up the speed till it stops working or you get what you want. If it stops working and you can still see the signal on the scope reliably, is it still at the right logic levels. Make sure you have the pull ups on I2C.

     

    Also ask yourself why you need to be at 100+Mhz or even above 4Mhz, unless your driving a graphical display or trying to build a very fast high resolution ADC / DAC then you dont need to. You only need to be a little faster than your desired sample rate and most real world environmental measuring does not require more than a few samples per second, Audio sampling and generation would max out at 200 - 500Khz so still only a few Mbits/Second at best.

     

    Now I have to say, having a real nice scope As Michael says... more expensive than the car, is very welcome, but in many diagnostic scenarios not essential

     

    btw, logic analyzers like the Saliea do not capture the edges, typically they have a highspeed clock and sample the digital data into a RAM buffer at high speed, yes with a programable threashold in some cases to determin if logic 0 or 1 is present but they dont analyze the edges. so a 12Mhz analyzer only needs to sample at maybe 50Mhz but could be much less (24 even)

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Reply
  • Robert Peter Oakes
    0 Robert Peter Oakes over 9 years ago

    I agree with alot of what is being said here but if your not designing the SPI logic or interface then you should be able to trust the signal integrit to a certain extent and what matters more is are you sending the right commands and data to the remote device. this can be achieved with not much more than 2-4X the data bit rate (So you dont miss the edges and are able to decode the signal

     

    I have an MDO3054 (500Mhz 4 Channel with Logic Analyser ) with all the protocol stuff enabled and every time I have had an issue with SPI or I2C, it has come down to either having the wrong mode in my driver software or I forgot to terminate the signals with a suitable pullup

     

    So at the end of the day, slowing down the signal to even below 1Mhz will allow any scope to see what mode your running in and that the levels are where they should be, after that, slowly crank up the speed till it stops working or you get what you want. If it stops working and you can still see the signal on the scope reliably, is it still at the right logic levels. Make sure you have the pull ups on I2C.

     

    Also ask yourself why you need to be at 100+Mhz or even above 4Mhz, unless your driving a graphical display or trying to build a very fast high resolution ADC / DAC then you dont need to. You only need to be a little faster than your desired sample rate and most real world environmental measuring does not require more than a few samples per second, Audio sampling and generation would max out at 200 - 500Khz so still only a few Mbits/Second at best.

     

    Now I have to say, having a real nice scope As Michael says... more expensive than the car, is very welcome, but in many diagnostic scenarios not essential

     

    btw, logic analyzers like the Saliea do not capture the edges, typically they have a highspeed clock and sample the digital data into a RAM buffer at high speed, yes with a programable threashold in some cases to determin if logic 0 or 1 is present but they dont analyze the edges. so a 12Mhz analyzer only needs to sample at maybe 50Mhz but could be much less (24 even)

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
Children
  • Problemchild
    0 Problemchild over 9 years ago in reply to Robert Peter Oakes

    Yeah we aren't interested in seeing the relative rise fall times shapes of signals etc ..you are assuming that they have that bit right what are you trying to do is read the SPI bus and interpret the command words going to from the PI. since you have the clock edge provided to sample from the actual sample rate is actually the SPI clock frequency which is some significant divider value of the maximum of 125MHZ.

     

    I know this guy mentioned an Oscilloscope and they as we all know are really cool but remember he doesn't necessarily know what he wants and is explicitly admitting this in the question if a simple logic analyser is what the job needs then we should not get stuck up on his original request but suggest the most appropriate tool for the job.

     

    Not got one handy as any one got a pi taking over SPI to something?  Stick a scope on it and see what the clock rate is ... I bet it's much much slower than the maximum!

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • shabaz
    0 shabaz over 9 years ago in reply to Problemchild

    Hi John,

    From what I can tell, the processor peripheral goes to a very high speed (125MHz according to the BCM peripherals doc that was published), but the Linux driver may limit it (no idea) and then there is the general rule that any signal above 30MHz should always send warning alarms if it is apparent that they are constructed without care over routing those signals. I assumed no care was taken, because it routes to a typical DIL header, and no transmission line. (In a similar vein, any plastic breadboard design would be worriesome if designed for 30MHz+). With that guesstimate in mind, I nevertheless tested at 32MHz SPI clock (square wave, so needs more bandwidth than 32MHz for a nice shape) when I connected it to the XMOS startKIT board quite a while back. I don't have signal traces though : ( And perhaps there could be bit errors and unreliability. It might not be a very nice waveform. Probably higher values could be tried with experimentation (and attempts at minimising reflections), but going above 32MHz clock may not be very sensible without a lot of testing.

    For the SPI communication bursts over a short length ribbon cable between the RPI and XMOS board, 32MHz 'worked' (i.e. it might not be reliable at all over a longer period, or some changing conditions, and a lower value may be more prudent - but it was so long ago, I only have screenshots of the logic analyzer capture from that time, I don't seem to have scope captures from then.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube