New to Embedded Development. Working on digital KVM

Question

I'm new to embedded development - but have been interested in the field for a while. I think this is close enough to being programming related; and I've seen enough people here show knowledge in this area, so I'll ask here.

I decided that a cool project that would cover many different areas of programming and hardware would be to develop a digital LAN based KVM. My end-game is to have a few "units" that contain many (I was thinking 4-8) VGA and PS/2 pair female ports and one Ethernet port. You would connect the unit the the LAN and to computers, then access it using a piece of software running on other windows based clients on the network. Each unit would have its own IP but respond to some sort of broadcast packet so that each client would have an entire list of all computers plugged into each unit. As you might guess, I'm not up to speed on network programming either (another reason I chose this project).

My initial idea was that each unit contain three micro-processors. One (that has a lot of analog I/O ports) would interface with the VGA and PS/2 I/O. That would convert the VGA into some sort of digital packet which would be sent off (IC2/USB/whatever) to the second processor. It would also receive a digital packed from the second processor containing the mouse/keyboard input sent from the client. It would then convert that into analog output and send them over the PS/2 ports.

The second processor receives the VGA output from each active computer and combine them into a single image and compress it using JPEG compression. The now-compressed image would then be sent off to the third processor.

The third processor will keep track of all active clients and interface with the Ethernet card. It would send the compressed monitor output to the correct clients, and also receive the keyboard/mouse input which would be dispatched to the second processor.

This is the first embedded project I have ever really thought about. I have the following questions. Note: I am more interested in how you came to the answer then the answer itself. This is a learning experience more then anything else. Though I do work in a tech-repair shop who's current analog KVM is failing and does not have enough ports for the amount of machines we constantly have on the bench; so if I can pull it off cheep enough it could be useful.

Question 1:

Is my current plan totally idiotic? Am I over or under thinking the problem?

Question 2:

How fast do each processors need to be? The first one will be converting a possible

165,888,000 Bytes (1440 * 900 * 32 * 4) (max resolution I want to support times max depth times 4 computers)

That's about 158 MB. What speed does a processor need to be in order to handle that much data 30 times a second?

Then the same goes for the second processor which has to compress 158 MB worth of pixels into JEPG. The LAN processor would have to work much less due to the compression though.

Question 3:

Where would I go to get the hardware required to build this? As far as the micro-processors go, they must have a C compiler available. I think I might go insane writing a JPEG compressing alogo in ASM.

Basically I am stuck. It's difficult if not impossible to find enough resources on the net to start in this field; so I wonder if anybody here could point me in the right direction.

Also, I am fairly limited in my knowledge of electronics.

EDIT

I don't understand why this question was downvoted. The way I see it this question may allow for answers that can help programmers get into embedded development. I have an idea and I know how processors and memory work well enough to code. However, there is a gap in my knowledge between knowing that and the ability for me to implement my own devices. It would be valuable for others who are in my position.

Answer 1

165,888,000 Bytes (1440 * 900 * 32 * 4) (max resolution I want to support times max depth times 4 computers)

• If 32 is the bit-depth then your calculation is off. 32bits = 4bytes therefore the incoming data bandwidth is (1440 x 900 x 4 x 4) = just under 20MB per frame.

• An 8-bit processor will probably need to be at least (1440 x 900 x 4 x 4 x 30) instructions/sec, i.e., 622MHz just to read the input. A 32-bit processor could be 4 times as slow = 156MHz. But this is the minimum speed remember

• Figure out how many cycles it takes to do whatever processing you need. Lets say you write a program that can process each output pixel in 10 cycles, you have (1440 x 900) pixels coming out so you would need a 32bit processor at a speed of (1440 x 900) x (10 cycles) x (30fps) = 389MHz

Answer 2

For the client protocol, you might want to look at interfacing using the VNC protocol. This would have the advantage of providing you with a built-in protocol and possibly client.

Tight VNC has a source code available.

Answer 3

My opinion: you're way off base with the 'end' of the problem you intend to work on. VNC is already too good for what you're describing. Let me describe the problems as I see them:

The processing requirements are prohibitive for an embedded application - as other people have mentioned the video alone is staggering. You'd almost certainly need to compress it which means more CPU power, you'll need RAM enough to store all of this information, and just for a second imagine how much data this is putting out - 20MB a frame or so. That's a lot of data. Plus if you implement this your 'computer' will have two IP addresses - one to control the video/keyboard and mouse, and another to say access files, etc. That just seems kludgy to me.

This doesn't solve the problem you are thinking of but I think you'd be better off implementing a thin client which only connects to a VNC server and processes the keyboard/mouse commands then encodes them to VNC compatible ethernet commands, and displays the video data on an attached monitor. You can even put a big button on it that switches between a list of IP addresses of computers (KVM-like). This could probably be done with a few hundred megahertz worth of ARM processing power plus possibly a separate video processing chip. TI and AVR make ARM processors so that's a good place to start. An example of an embedded ARM board that runs linux is here:

http://opencircuits.com/Linuxstamp

It has no video out but it does have ethernet, serial, USB, etc. It's a good starting place for embedded ARM Linux development, which I think is the direction you should take. Try also uCLinux, and good luck!

Answer 4

It's an interesting idea. It does have some uses over just remote desktop software - I could reboot a server and do bios things or even install an OS remotely.

Given the cost of the level of hardware you are going to need (CPU/VGA/OS/tcp) and the small quantities (you aren't going to sell millions) I would start with a small linux computer like beagleboard and use the TightVNC and/or RDP prototocol. (Getting VGA back from the remote PC is going to be interesting)

Given the astronomical prices for enterprise KVM switches you might be able to make money from this!

Answer 5

Q1. Besides being very ambitious, it sounds like it could work.

Q2. I would look into FPGAs, they are a good candidate for being able to handle the video capture. A good resource is FPGA4Fun. With the right FPGA, you should be able to run the capture and compression on a single FPGA. Something like this AVR 32bit Networking Processor Kit, might work for interfacing with the network.

Q3. Octopart is a good place to find suppliers.

Online Electronics References in no particular order

Electronics Wisc-Online

Tom Loredo's Electronics Bookmarks

Lessons in Electric Circuits

These are just a few I came across in my delicious electronics links. I haven't gone over those, but they should be able to point you in the right direction. Good luck.