Raspberry Pi Forums

my research have indicate raspberry pi limitation of usb 2.0 subsystem with limitation of 30-40 MB/sec available bandwidth (half-duplex), also microsd benchmark show similar limitation. I notice my raspberry pi have a camera connector (I dont use), I searched on Internet. According to blog post [ https://www.raspberrypi.org/blog/creati ... era-board/ ] link with the camera is via "CSI bus, a much higher bandwidth link which carries pixel data from the camera back to the processor" and it write "At 15fps (frames per second) that’s a maximum of 2592x1944x10x15 bits per second (approximately 750Mbps)". 750Mbps one-way = 93 MB/sec is 3x times the limit of the sdcard reader it seems as conferred with 30-40 MB/sec on the USB 2.0 subsytem.

3 questions please:

1) instead of pixel data could ribbons be used to transfer binary data - or is noisy link. is protocol encrypt?

2) does userspace has enough access to read from (for example is possible to save to tmpfs / ramdisk / use it it in memory) - i think yes since you can treat the pixel data, but maybe preprocessing in GPU pipeline make impossible? (corrupt binary data for userspace)

3) is mentioned CSI bus independents of the SDcard and USB subsystem? where is specification for CSI protocol?

obvious this only read access, write access is via second link used to communicate with the module described in the same above blog post. thanks for your advices,

-

raspberry pi owner

1. Yes, that is technically possible.
2. I don't believe so.
3. Yes. CSI is a HW specification, describes the physical connection. Not sure if the spec is public.

The CSI connects to the GPU, the GPU source is closed, so it's difficult/impossible for a third party to use it.

To elaborate.

1) Not encrypted, but closely tied to images. It transfers a line of image at a time with a defined "width", and then a defined number of lines per image, so you need to sort out how you are framing the data. There's no easy way to drop the data into tmpfs or similar - it will be delivered back as image buffers. I do recall one project where the image data was actually a JPEG already encoded. You then need a buffer header to provide the length of the buffer, as it isn't related to the width/height.
2) Sort of - see viewtopic.php?f=43&t=109137. Work is underway on integrating this properly into V4L2.
3) Go and pay your money to join the MIPI Alliance

You are going to need an FPGA to interface to CSI2 - it has been mentioned in these forums a couple of times before. Lattice for one provide a reference implementation.