I have an image sensor module which has an UART output format. Now, I want to get it work and transport the image data to PC for testing! What need I do to get it? The sensor works at least 460KBaud.
I need the fast way to get it work, any suggestion would be great appreciated!
I mean the device output the image data through UART.
So need I make a board by USB + DSP/FPGA + image device? If so, I have to develop the firmware, driver and my application. But I have no exerience in firmware and driver development.
If by USB-serial converter one means a packaged module rather than a chip then higher baud rates can be problematical because 232 was never inteded for these speeds. However, if one uses chips and directly interface at
5v/3v3 then good results are definitely possible.
My own experience is that they can work well and that they generally support higher baudrates - signal integrity, as describe above, being the main problem.
Since the OP asked for at least 460KBaud (though I think they meant
460kBaud) and PC serial port go to 115 there would be a problem.
First some clarification. COM port is the name Microsoft calls the serial port at the back of an IBM PC. Apple used to call them Modem port on older Macs and most other vendors simply call them Serial Ports. All these serial ports have in common is that they use a UART chip to convert the data from the CPU to the format transmitted on the wire. So your "UART" output simply means COM port output. But be careful, since they specify "UART" output instead of "RS232" output it most probably means that your device signal level is 0-5V or 0-3.3V instead of the PC COM port's +/-12V. So connecting them directly may damage your device. Read the datasheet.
Which means that you should ignore the previous advice of "use a PC with serial ports". Standard serial ports on PCs only go up to 115k. Instead I'd either get a USB to RS232 converter that supports high baud rates or a PCI serial card that supports high baud rates.
For USB to serial look for ones using FTDI chipsets, preferably the newer FT232R variant. Forget the horror stories, FTDI chips are very reliable and only has problems on Mac OSX (some features not supported). I remember Dontronics selling embedded versions that directly output 0-5V or 0-3.3V instead of RS232. However, you may need to write some VB code to get the high baud rates because although these devices can achieve 1Mbps Windows COM port API can only configure up to 115kbps. But they have nice sample code on their website on how to do it (heck, it's a zipped project directory, just modify their code). I believe their newer FT232R chip can be configured to remap baud rates so you can make 460k on the wire look like 115200 on windows.
For PCI serial most boards for the industrial market can go up to
1Mbps but your common PCI serial port card can only go up to 115k. Look at Moxa for some nice boards (tend to be expensive). Again, due to Windows API limitation you may need to write your own code to configure the board to go beyond 115k.
Again the word of warning. Since your device vendor state UART output as opposed to RS232 output you should carefully read the datasheet to see if you need a transceiver/voltage converter before wiring it up to a COM port.
There may be "RS-232 compatible" transceivers, but I very much doubt that you could run those speeds within the minimum voltage swing, maximum slew rate and current limit (with any practical load capacitance) of the RS-232 standard.
Since the OP is talking about an image sensor, this would indicate that there is some distance between the sensor and the PC, so I would suggest using a more appropriate interface, such as RS-422/485. If the image sensor delivers asynchronous characters with TTL levels, just connect an RS-422 (or RS-485) transmitter chip to it and use any RS-422/485 PCI interface card on the PC (most of which supports the
460 kbit/s speed). Use a twisted pair between the image sensor and PCI card to cancel out most external noise.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.