I don't usually blog because I am a horrible speller and my grammar is absolute garbage. But I wanted to talk about my mysterious project people keep asking me about at my school. These updates are for me to look back on and see what I did for my project and to have public record of what I was doing. In actuality its more of a status update on my project.
Around noon today I roll into school and wait for my project partner Cody Harris to come in. Skipping to the discussion about our project, we talked about what kind of communication protocol to use for our devices. For those of you who don't know what a communication protocol is, it's the physical line of communication between two hardware devices. In this case we have an FPGA (Field Programmable Gate Array) and a Beagle Bone Black communicating together with a communication protocol. We are sending camera data from the FPGA to the Beagle Bone Black, a one way communication.
We are sending 30 bits of RGB information over the lines which equates to one pixel. Originally we wanted to use SPI for our CP, however we quickly learned it was not optimal. We wanted to send 30 bits of information on a 16 bit bus going at 48mHZ. We wanted to use a compression algorithm of some kind to shrink the buffer size, but we quickly learned we would have to shrink the bits by 50%, which is a lot of error when we decompress. Also the compression would take a lot of time to do on the FPGA and BeagleBone.
Doing the math, we want real time camera information sent to the Beagle Bone Black. That means we want 60 Fps, we realistically are aiming for 30. The resolution we want is 800x480, the same resolution as the LCD screen we are using. We have 2 Bytes of buffer space. 800x480x30x2 gives us about 23 mBytes/s needed for real time video.
An SPI bus would require 8 bits for its buffer and we would clock it to about 48 mHZ. It takes one clock cycle to send a bit so we would be sending 48 mb/s. Note little b means bits. So we then divide that up by 8 to give us bytes. We then get 6 mB/s which in reality is way to slow still.
Unfortunately, even with a dual SPI bus, we would realistically get around 12 mB/s with those lines and we would still need double the bandwidth to match our speeds.
Another solution was to try Ethernet but that came with its own set of problems. First, if we take up the Ethernet module of the Beagle Bone Black then we no longer get internet access with that device. Also we would have to write an Ethernet module for the FPGA (which is not fun). Second, its still not fast enough for our speeds. Ethernet runs at about 100mb/s which if you divide that by 8 get 12.5mB/s. This is still not enough for what we need.
Cody didn't want to use the Beagle Bone Black's GPIO (General Purpose In/out) pins because he was afraid it take CPU cycles away from other things. At this point we have no choice. We cannot match the necessary speeds with the existing protocols. So we are copying the camera's 10 bit parallel communication. The TRDB-D5M camera we are using uses a 10 bit parallel protocol to communicate with the FPGA. Our solution is to simply pass that camera data straight to the Beagle Bone. You may be asking then, why use the FPGA at all? It's simple! Image processing is super slow and takes a lot of memory to use. We are using an FPGA to alleviate that time from the Beagle Bone's CPU. We are planning to do a power computer vision technique called Stereo Vision.
I'll talk more about this later.
-Johnny Sim
Around noon today I roll into school and wait for my project partner Cody Harris to come in. Skipping to the discussion about our project, we talked about what kind of communication protocol to use for our devices. For those of you who don't know what a communication protocol is, it's the physical line of communication between two hardware devices. In this case we have an FPGA (Field Programmable Gate Array) and a Beagle Bone Black communicating together with a communication protocol. We are sending camera data from the FPGA to the Beagle Bone Black, a one way communication.
We are sending 30 bits of RGB information over the lines which equates to one pixel. Originally we wanted to use SPI for our CP, however we quickly learned it was not optimal. We wanted to send 30 bits of information on a 16 bit bus going at 48mHZ. We wanted to use a compression algorithm of some kind to shrink the buffer size, but we quickly learned we would have to shrink the bits by 50%, which is a lot of error when we decompress. Also the compression would take a lot of time to do on the FPGA and BeagleBone.
Doing the math, we want real time camera information sent to the Beagle Bone Black. That means we want 60 Fps, we realistically are aiming for 30. The resolution we want is 800x480, the same resolution as the LCD screen we are using. We have 2 Bytes of buffer space. 800x480x30x2 gives us about 23 mBytes/s needed for real time video.
An SPI bus would require 8 bits for its buffer and we would clock it to about 48 mHZ. It takes one clock cycle to send a bit so we would be sending 48 mb/s. Note little b means bits. So we then divide that up by 8 to give us bytes. We then get 6 mB/s which in reality is way to slow still.
Unfortunately, even with a dual SPI bus, we would realistically get around 12 mB/s with those lines and we would still need double the bandwidth to match our speeds.
Another solution was to try Ethernet but that came with its own set of problems. First, if we take up the Ethernet module of the Beagle Bone Black then we no longer get internet access with that device. Also we would have to write an Ethernet module for the FPGA (which is not fun). Second, its still not fast enough for our speeds. Ethernet runs at about 100mb/s which if you divide that by 8 get 12.5mB/s. This is still not enough for what we need.
Cody didn't want to use the Beagle Bone Black's GPIO (General Purpose In/out) pins because he was afraid it take CPU cycles away from other things. At this point we have no choice. We cannot match the necessary speeds with the existing protocols. So we are copying the camera's 10 bit parallel communication. The TRDB-D5M camera we are using uses a 10 bit parallel protocol to communicate with the FPGA. Our solution is to simply pass that camera data straight to the Beagle Bone. You may be asking then, why use the FPGA at all? It's simple! Image processing is super slow and takes a lot of memory to use. We are using an FPGA to alleviate that time from the Beagle Bone's CPU. We are planning to do a power computer vision technique called Stereo Vision.
I'll talk more about this later.
-Johnny Sim