VisualApplets can be used to transfer serial data over the IOs of the frame grabber. Application areas are for example
- Control eject mechanism like valves for bulk material sorting.
- Object x- and y- position output. For example for laser welding and control the position of piezo controlled mirrors.
- Value output for digital to analog converters for example to control a laser intensity
VisualApplets does not have dedicated operators for the communication. Instead the existing operators are used to generate the output stream or analyze a stream at a digital input of a frame grabber. The implementations can be adapted to many requirements and protocols.
Many applications can be solved. For more complex requirements like complex protocols with handshakes a custom solution might be necessary.
The following VisualApplets design shows a simple approach for serial output and serial input. I hope that other designs and protocols will follow after this one.
In our example I defined a simple protocol.
We transfer 8 bit data words. The serial stream is in the format
- 1 Start bit (high)
- 8 Data bit
- 1 Parity bit (XOR of all data bits)
- 1 Stop bit (high)
followed after a gap of a minimum of two clock cycles the next data can come.
The CTS (Clear to Send) data is send backwards from the receiver to the sender. It is 1 if new data can be received and 0 if the input buffer is full.
Moreover in this example the CTS signal is used for re-synchronization. Suppose the data receiver is out-of-sync and a start bit is not detected as the start of the data. The CTS signal is disabled from time to time (e.g. once a second) for more than the period of one data transfer i.e. 1 + 8+ 1+ 1+ 2 clock cycles. The sender will detect this re-synchronization gap and can start from the beginning.
I could test the connection link with a bitrate of up to 20 MHz when I directly connect the extension IOs of one frame grabber with a second frame grabber using a short cable of 10cm length. The maximum speed depends on the electrical characteristics of your cable.
In this demo we simply transfer generated image data from one frame grabber process using a loopback cable to the second frame grabber process. So we transfer image data between process 0 and process 1 over an external loopback cable. We than compare the DMA output of both frame grabbers. If a parity error is detected the output pixel will be red.
The serial output box contains of three H-Boxes and has two parameters.
The first parameter is the bitrate which has to match with the receiver. The second parameter is the source for the CTS signal of the demo. You can either use an external input or an FPGA internal loop so you don't need to connect any cables to test the applet.
In OutputBuffer the data is buffered first in a small BRAM fifo. The most important box is SerialDataStream. Here the 8 bit data values are converted into the serial data stream. Check the following explanations and screenshot.
First the 8 bit data is extended by the start bit, parity and stop bit plus 2 dummy gap bits. So our 8 bit signal is extended to 13 bit. Next every pixel is converted into a single line i.e. 1 pixel per image line.
Now we need to serialize the 13 bit parallel data. This can be easily done using a CastParallel and PARALLELdn operator. After the PARALLELdn the 13 bit data are transferred one bit after each other starting with the LSB..
The following CTS_Valve H-Box contains an ImageValve operator to only allow the output of data if the CTS signal is valid.
After the valve we could directly output the data. However at this moment data would use the speed of the FPGA clock which usually is 125MHz. So we would have a bitrate of 125MHz. As we need a slower bitrate we simply replicate ever bit i.e. every pixel using operator PixelReplicator to get the desired bitrate.
Now the data generation is completed and can be converted to a signal and output on one of the GPOs. This is done in H-Box GPO_Output
The serial input box of process 1 now needs to receive the signals, analyze the integrity and output the data. Again, this H-Box has parameters to set the baudrate and the source for the serial data.
In GPI_Input the physical input is selected and output as a signal to StartDetectionFilter. Here the signal is analyzed for a start condition i.e. for a rising edge which is supposed to be the start bit. Once it detected a rising edge the implementation will record all bits of the sequence. If the receiver is asynchronous to the sender. For example because it was started after the sender it might falsely detect a bit to be the start bit. To re-synchronize the CTS signal adds some gaps from time to time which will automatically cause a re-synchronization. See explantion above.
In H-Box DataExtract the start bit condition and the defined bitrate are used to lath the data in a new empty line using CreateBlankImage and PixelToImage.
In DataErrorDetect now the serial data is analyzed for start bit, stop bit and correct parity. The output of this H-Box is still a serial stream of the data with a second bit which has to have value 0 in the last pixel of the line what indicates that no error was detected.
Finally in H-Box Parallelize we can parallelize the serial data. This is simply done using a PARALLELup operator. Now we can remove the start, parity and stop bit to get our 8 bit data value. Bit 1 contains the error flag which is output on a second link.
H-Box OutputBuffer includes a BRAM FIFO. If the processing after the serial input gets stopped this buffer could run into overflows and some serial data can get lost. To avoid this the fill level of the buffer is measured and at a certain point the CTS output signal is set to low i.e. not cleared to send data so that the sender will stop sending data.
This is continued in CTS_Output. Here the Resync gap is added to the stream.
Applet Usage in microDisplay
The applet is pre-configured to be directly used in microDisplay. It will use the internal loop and the internal image pattern generator. So you can directly load the applet and start it in microDisplay.
First you can see that both DMA channels transfer data. DMA 0 is coming from process 0 and transferring the original data. DMA 1 is showing the data from process 1 which is the transferred data over the serial interface and protocol. As you can see it the data is correct. We get about 24.1 fps. At an image size of 256x256 this results in 1.5 MByte/s. For the bitrate of 48ns this is a reasonable output. (1 / (1.5 MPixel/s * 13 bit)
If you change the bit rate in either the sender or receiver you can see that the data gets incorrect. Once you correct it the re-syncronization works and data integrity is correct. (Obviously the frame generation puts the wrong pixel at the wrong position as we do not transfer the frame parameters like frame start.)
Next we want to have a look at the data. For this we use our logic analyzer applet which had been presented in this forum thread: LINK
From the waveform we see on channel 0 the serial data and in channel 1 the CTS signal. As you can see the CTS re-synchronization gap is about 2 data word periods long. After the rising edge of the CTS signal the sender starts sending the data.
On channel 2 we can see a debug output. It shows the start condition detection. On channel 3 we can see the position where data is latched.
In the drawing the bitrate was reduced to 480ns.
Attached you can find the VA file. You need VisualApplets 3.1 to use the file. If you don't have a license for the parameters library or debugging operator library you need to remove those operators. The serial communication will still work correct.