HEY! don’t forget to support by contributing and/or sharing the Rasky KVM over IP project! thanks!

The Rasky video capture circuit is the harder part of the project from the hardware side, and the one that responsible to all precedent similar project fails. 

Even at relatively low resolution like 640×680@60Hz VGA signal timing needs a 27.150Mhz clock, not to say higher resolutions, and this make hard interface it with the relatively slow hardware on Raspberry, and harder cause of the non-realtime OS running on it to maintain such high speed clock for I/O stable and fully working.

Instead of using some ADC connected directly to the Rpi and then decode VGA frames directly from it, and inspiring on the great work done by desaster with he’s grabor project, i will use for Rasky the same approach, initially by predate the grabor project and then, after the initial prototypes, eventually switching to faster and/or different components/schematics.

The desaster approach i’m predating for Rasky is to use a Texas Instruments TVP7002 video ADC to decode VGA signals, and then passing the digitally decoded signals to a dedicated CPLD that will grab a full frame, pixel by pixel, and copy it on SRAM.

The main difference of Rasky compared to grabor is what happen to frames after they are on SRAM: in grabor they where read from RAM to a little arm CPU very slowly by a simple GPIO routine, and then exposed on web thanks to an embedded TCP/IP stack. Desaster does that on grabor clocking the GPIO routine that read from SRAM at 400KHz, and, according to what we know about grabor from the desaster blog and from the data from my test with my own grabor, this result in a frame rate on the final web streaming of ~ 0.2FPS, fairly slow for us.

Typically using a commercial KVM over IP or interfaces like iLO or iDrac you get 3 to 15FPS, depending on your side connectivity too. As for my own experience, a 10FPS is more than ok for a KVM over IP, and for sure enough to make it useful for all operations usually done with a remote KVM, so, the first goal for Rasky will be to reach that speed.

For resolutions, grabor assumes and work only at fixed 640×480@60Hz, but i consider it a little bit restrictive, so, we will try to go as higher resolution we can assuming to respect the 10FPS low limit for speed. According to the  TVP7002 product page, it can manage to work up to 165Mhz clock, and then it supports VESA standards up to UXVGA (1600×1200) resolution at 60Hz, fine!

What about the CPLD? The grabor project shows that it can work without glitches at 27.150Mhz clock, and according to the MaxII EPM240 datasheet, every I/O pin can be clocked up to 66Mhz for PCI compliancy, so, there are no issues for us with it, but in any case move to a faster FPGA instead in a second moment will not be too hard, so, i can start to test Rasky prototypes with it and then, eventually, move to an FPGA faster than the EPM240 CPLD if needed.

Same apply to the SRAM chip, the one in use doesn’t have speed issues, but it’s total size is 512KB, so, it can’t contain a full frame at resolutions higher than 800×600, and we will need to split the frames and transfer them in pieces ( up to at least 4 tranches ) to the Rpi board, or we will need to get a bigger, but also more expensive, SRAM chip like a 16Mbit one like this one: http://it.farnell.com/bsi-brilliance-semiconductor/bs62lv1600eip55/sram-16m-2mx8bit-3v-55ns-tsop44/dp/1488953. Changing SRAM is anyway fairly easy as nothing change except for size, so, it isn’t an issue we face now.

And there we are coming to the critical part: how fast can i transfer the grabbed frames from the SRAM to the raspberry pi?

The faster bus we can use on the raspberry for this purpose is, of course, the MIPI-CSI2 bus, the one dedicated to video input and usually used for cams. I don’t know how really fast it can run on the Rpi, but for sure it’s faster than any other option we have, so, this was my first option to investigate.

Sadly, the MIPI-CSI2 specifications are protected by patent, and even if there are apparently public specification released reading in the wild, i’m not able to found them. But this isn’t the worst part of the story, even if i don’t find a specifications document, i can eventually reverse the protocol and then write my own implementation from scratch. The bad part is that even if i have a working CSI2 implementation, i can’t distribute it cause of patents.

The only way to legally distribute such implementation would be to apply for membership in the MIPI alliance group, and this would mean to pay ~ $8000/year for a seat.

This, of course, isn’t acceptable for an open source project, expecially for an open source project without a very large userbase, and then the choice to abandon the idea to use CSI2 to move frames into  the raspberry. If anything will change in future on this matter, or if a dedicated hw chip that is enough cheap and that can be purchased individually even from private customers, i will reconsider it for Rasky, but i need to move to another bus for the moment.

Other busses on the Rpi includes UART, SPI ( eventually in DMA), I2C or raw GPIO.

UART and I2C are too slow, so, i can exclude to use those. Using GPIO is interesting, and thanks to WiringPI and native libraries it seems to be also relatively fast, someone says up to 25Mhz, other says 22Mhz. Those are amazing results, but i have some dubts about the stability and latence of such data, and probably to have a stable clock in the long run where you have also other things running on the raspberry, you should star a little bit lower, let me says aroung 16Mhz for example. No matter that, 16Mhz is also a excellent result, but maybe we can get something more with less effort and pin usage…

So, we come to SPI. The raspberry PI 2 have one SPI bus with 2 CS pins, and according to this post and many other  sources, it can run in a stable manner up to 32Mhz. So, this is our limit, 32Mhz. And SPI is our bus :)

How fast we can go with 32Mhz on SPI bus? Well, i prefer to say that only with real benchmarks and tests in empiric way, but i have some hopes it can be used to have a pretty fast frame rate, for sure we can go up to full 640×480 ad 60 frames per second, but in theory we can get up to 1600×1200 at 10FPS too. For the moment let us be conservative, and set a goal to 1024×760 at 10FPS, and then i will try to go faster and “bigger”  i can,  using a trial and error approach.