Max data rate over I2C/SPI/UART


22 posts
by nghia » Sat Aug 27, 2011 12:32 am
Hello,

As everyone I'm look forward to getting this great HW. M-3, right?

I understand there is 1 UART for debug, 2 x I2C and 1 x SPI on a connector.

What are the max data transfer rate over each of these interfaces under Linux?

Thank you for your feedback
Rgds
Nghia
Posts: 18
Joined: Fri Aug 26, 2011 11:02 pm
by abishur » Sat Aug 27, 2011 1:56 am
Shouldn't the max speed for a piece of hardware be the same regardless of the OS? I mean it's not like ethernet or USB goes any slower or faster on Linux v Windows v Macintosh.
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4250
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by rew » Sat Aug 27, 2011 7:05 am
Yeah, it should.... but in practice the os sometimes puts up a barrier for the performance. For instance, the driver for the Fujitsu Firestream chips can handle the hardware speed under Linux, but the windows operating system is so inefficient that you cannot reach the full potential of the chip....
Check out our raspberry pi addons: http://www.bitwizard.nl/catalog/
User avatar
Posts: 396
Joined: Fri Aug 26, 2011 3:25 pm
by obarthelemy » Sat Aug 27, 2011 12:22 pm
some OSes are better at handling interrupts than others (think real-time OS vs Windows, regular linux falls inbetween), and some drivers are better than others. BTW, you're very wrong about even ethernet and USB. Back when I was working at Novell, I remember us boasting that the Netware could reach multiples of NT's ethernet and disk throughput, for a fraction of the CPU load. We didn't play with latency at the time, but I'm working now for a company that does sound software, and Windows's latency is big enough an issue for us to be porting to Linux, and for richer companies to do ... http://www.merging.com/product.....38;page=54
Posts: 1399
Joined: Tue Aug 09, 2011 10:53 pm
by abishur » Sat Aug 27, 2011 6:31 pm
Isn't that more an argument about efficiency? The max speed of any given device is the max speed regardless of OS. You're talking about how efficiently it actually utilizes that max speed. As you mentioned that can vary greatly within the same OS depending on the drivers being used.
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4250
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by obarthelemy » Sat Aug 27, 2011 7:46 pm
The max theoretical speed is the same, but the max actual speed can vary. People are usually interested in the actual speed. Or they should be: if you're consistently getting 50 mbps out of your "480mbps" USB HD because the driver sucks... there's no way you'll call the speed "480".

Plus speed is a fairly vague notion. Throughput+latency+CPU usage are more workable, for I/O. ie for an internet connection, if I'm interested in downloads, "speed" is throughput. If i'm into online games, "speed" is latency... and if any of those is achieved at the cost of 100% CPU use, we've got a problem: I remember my whole PC lagging like crazy (unresponsive UI, skippy sound, burning coasters), in the early days of USB2, when I was doing heavy USB I/O. I switched to firewire.
Posts: 1399
Joined: Tue Aug 09, 2011 10:53 pm
by Gert van Loo » Sat Aug 27, 2011 7:50 pm
There are many factors which determine the maximum speed.
On I2C this is the pull-up resistor. That is why some I2C devices shortly driving the pin high before releasing it. (Which is dangerous as the other side can pull it low wanting to extend the cycle. But now I am getting into too much I2C details).
Other factor is who provides the data how. If your CPU has to do it you are then limited to the CPU speed and what other things the CPU has to do. For transmit you loose data rate, for receive you have to look at FIFO depth, CPU latency etc. If you have DMA your limiting factor is system (DRAM) throughput.
Third factor is what your I/O can do. (Drive strength, slew rate) No use trying to output 500Mbits/sec if you have only a standard I/O port.
I am not yet sure how much details I can release from the BCM2835 (Yes! I can name it) but I think the (unsatisfactory) answer is "More then enough", Don't worry!
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2029
Joined: Tue Aug 02, 2011 7:27 am
by nghia » Sat Aug 27, 2011 8:40 pm
Hi Gert,

Thanks.
Do you think 4Mbits/s is achievable on the Raspberry Pi, assuming the CPU is doing the xfer?

Rgds
Nghia
Posts: 18
Joined: Fri Aug 26, 2011 11:02 pm
by Gert van Loo » Sat Aug 27, 2011 9:08 pm
Which interface?
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2029
Joined: Tue Aug 02, 2011 7:27 am
by nghia » Sun Aug 28, 2011 6:20 am
I meant I2C .
I m looking for the fastest simple interface (excluding usb) on the R-Pi for the CPU to xfer in/out data to another board . All this running under Linux.
Any suggestion?
Thx
Posts: 18
Joined: Fri Aug 26, 2011 11:02 pm
by Gert van Loo » Sun Aug 28, 2011 8:24 am
Nope! As I tried to explain before: I2C has inherent speed problems in the way it is defined. It was designed for 100KHz, extended to 400KHz and some people can get it to run up to 1MHz. (But not on a Raspi). Try SPI, that is also simple and will work fine at 4 MHz. UART might do too but has more protocol overhead.
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2029
Joined: Tue Aug 02, 2011 7:27 am
by Andre_P » Sun Aug 28, 2011 9:10 am
SPI 'can' be a little tricky. You will need to know the values for CPHA and CPOL values and program both sides appropriately.
Also you will need to ensure that you determine which side will be the Master (SPI being a Master/Slave type interface, yes the Master provides the clock).
So if there is a SPI on Raspberry Pi can the Master/Slave be defined and can the CPHA, CPOL values set ?
Posts: 241
Joined: Sun Aug 28, 2011 7:57 am
by Gert van Loo » Sun Aug 28, 2011 10:18 am
yes, yes, yes and yes.
User avatar
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2029
Joined: Tue Aug 02, 2011 7:27 am
by Andre_P » Sun Aug 28, 2011 11:20 pm
Excellent :)
Posts: 241
Joined: Sun Aug 28, 2011 7:57 am
by Andre_P » Sun Aug 28, 2011 11:40 pm
However one thing does come to mind. Does the SPI Clock run the logic or is it oversampled by the system clock ? If the registers are clocked by the SPI clock rather than sampled then things should be even better.
Posts: 241
Joined: Sun Aug 28, 2011 7:57 am
by Gradius » Mon Aug 29, 2011 4:36 am
How about xfer rates for each of the 16 GPIO pins? I've seen Broadcom materials which quote speeds up to 150MHz for similar chips, so presumably 150 mbps / pin might be a theoretical max per pin.

In other words, what do you guys see as a realistic achievable bandwidth via the GPIO ports? Focus would be a tree of Raspberry Pi devices, each connected to 15 children and one parent via a custom (simple) protocol on the GPIO pins... or perhaps a randomly connected p2p network...
Posts: 1
Joined: Mon Aug 29, 2011 3:23 am
by Enlightenment » Tue Aug 30, 2011 12:55 am
You do need to be careful of all pull-ups and pull-downs and inline series resistors on I2C and SPI. I you have any components on these lines, then you should tell us, so it can be discussed.
Posts: 34
Joined: Wed Aug 24, 2011 10:16 pm
by David » Thu Sep 15, 2011 3:29 pm
Hello!

I would also use SPI/I2C/USART to interface to the world. In my case, to microcontrollers, sensors, etcetera.
Is the presence of these ports a fact?
Is it known what uses will the other pins offer?
And what are the specs of the hardware for this specific use?

Thanks!

David
Posts: 1
Joined: Thu Sep 15, 2011 1:19 pm
by fordp » Thu Sep 15, 2011 6:47 pm
i2c is an order of magnitude slower than SPI. Classic i2C is 100KHz or 100K Bits per second peak. A faster version made it run at 400KHz and there are faster versions still but they are rare. SPI can hit 25MHz (25 MBits/s) or higher. These are still much slower than 100 MBit Ethernet!
Posts: 8
Joined: Fri Sep 09, 2011 12:07 pm
by Jason » Fri Sep 30, 2011 1:03 pm
I don't think I2C is suitable for high-speed. SPI has better quality signals, and I've seen 70Mhz clock rates. SPI may need an additional /CS signal (so CLK, MOSI, MISO and /CS.. and GND)

I'm currently using a NI sbRIO controller and are getting around 8Mhz clock (using the FPGA for clocking).
On SPI/I2C, its normally a hardware register providing the clock/bit shifting logic, so whilst a high-speed clock is probably achievable, it'll be down the interupt/driver response to ensure the register is populated as soon as possible.
Posts: 9
Joined: Sun Sep 11, 2011 9:48 am
by TonyD » Fri Sep 30, 2011 1:33 pm
I2C as a bus is 400Kbit/s while SPI is typically 10 - 20Mbits/s or faster
Tony
User avatar
Posts: 340
Joined: Thu Sep 08, 2011 10:58 am
Location: Newcastle, UK
by ChrisL » Sun Dec 23, 2012 7:58 pm
Does anyone know the actual spec for the slew rate on the Raspberry Pi GPIO?
Posts: 1
Joined: Sun Dec 23, 2012 7:51 pm