16-bit transfer to PC via RS-232

[Gordito]

Hi, I am looking for pointers regarding the design of an unidirectional interface between a digital sensor output and a PC (USB or RS-232). I give the specs below.

I am awaiting info on the software this is supposed to communicate with on the windows platform but i think it's enough to get started...

Questions:
1) Do protocols exist which cover serial 16-bit asynchronous rs-232 transfers db9 connectors? I am looking also looking for references on the matter if any is online, or examples. I haven't found much.

2) For a windows platform, in order to permit most pre-existing software to accept this serial data, is it easier to receive the serial 16-bit word via USB and have the custom device driver reformat the data as needed?

I suppose this requires USB specific IC's, but if it eliminates the need for a micro-controller....

3) If i have to go down the standard 8-bit RS232 road, then my best solution would be to use a micro-controller to generate and transmit the two 8 bit words from the 16-bit word received from the sensor. Or is there a simpler solution?

Thanks for your input!

Signal specs ---------
The sensor has 3 x balanced outputs (i presume this is the RS-422 standard?).
1) Clock (around 24Khz). Asymmetric, 12uS high time.
2) Read ("1" when data on signal line )
3) Signal: serial series of bits at clock rate. Non return-to-zero.
Bit 1: Control Bit (always 1)
bit 2: Reliability bit (1 when valid)
bit 3: LSB
...
bit 15:MSB
bit 16:Unused (0)

A 16-bit word is output from Signal every 41.5 msec (24hz) and lasts around 670 usecs.

 

[Nigel Goodwin]

Basically serial comms (and certainly RS232) is 8 bit only - for 16 bits you send it as two bytes, it's as simple as that.

Really it depends exactly what you want to send, and how fast you want it sent.

If speed isn't crucial, convert to ASCII before sending, and finish with a CR - this avoids any problems about the start of data, and allows VERY easy reception on a PC. If you want USB instead of serial, by far the easiest way is to just use a serial/USB converter.

I would suggest simply reading the data with a PIC, and sending it to the PC as ASCII over RS232.

 

[BrownOut]

I'm suspicious the OP has a SPI interface, though his discription would be slightly off, but I'm willing to take that chance. If I'm right, he'll probably want to convert it to normal URAT protocol, unless he can find a plug in that can read SPI directly.

 

[Pommie]

It does indeed sound like SPI. If it is then you may be able to bitbang it with the serial port. Do you have a data sheet available?

Mike.

 

[Gordito]

Thank you all for your replies and suggestions. I've decided to go with a PIC.

I have received additional specs and also have more questions

Data reception:
The data will not be received by a standard PC but by a "DAS", data acquisition system (stand alone chassis based pc with linux OS). The DAS has serial RS-232 inputs (EIA-232-D) with the following config options:

"Bit rate options include 9600, 14400, 19200, 28800, 38400, 57600 and 115200 bps. Parity options are none, even, and odd. The number of stop bits may be set to either 1 or 2. The number of data bits is fixed at 8."

There are 3 protocols: ASCII, Binary and raw. For simplicity's sake and to allow the time stamping of data i will go with ASCII. The ASCII protocol has features such as preamble bytes, offset and block length. Hardware handshaking is recommended but not required (i am sending data to the DAS 24 times per second).

Question 1: I presume it if helpful if i choose a PIC with an UART and an internal clock for the baud rate, I've searched for PICs and read posts asking for recommendations but am somewhat lost in all the choices. Which PIC would be a good choice? The program won't be too big and i am looking for the minimum pins (at least 3 pins input to the PIC + pins for the serial communication). A PIC with online resources and tutorials would also be helpful. I will address the selection of a PIC programmer later when i've had time to research the choices...

Question 2: Because data sent to the DAS is only a few bytes, and at 24hz, i believe i don't have to use hardware flow control. In case i must had flow control, only the CTS/RTS lines are required so everything still fits on one MAX232 chip? Am i forgetting other required control lines?


Data output from the sensor
Output is balanced differential signal (and return) on a twisted pair coming from a fairchild 9614 differential line driver. Voltages are ttl levels ( 2.4 to 4.5v for '1' and -2.4 to -4.5v for '0').

Question 3: Here i presume i need to use a differential line receiver IC to interface with the PIC, correct? I've found the SN65LBC175. Would this be a decent choice or are there cheaper options? I have three signals (clock, ready and data) to convert.

Thanks again for your time!

(Edit: I've checked in the sensor's specs and the protocol used for data output is not named anywhere)

 

[BrownOut]

1) just about any micro with an integrated UART will do the job. You're comm requirements won't determine your processor. If I was going to make one unit, I wouldn't worry so much about it, just PIC one and go. If I was building 1000's, then I'd find the chip that meets miminum requirements for speed, code size, power, development tools, etc. Remember to find a micro that offers a flash based devic for program development, and cheaper OTP if you go to production.

2) There are many RS232 tutorials on the web, and it's a very simple protocol. What you said sounds right, but you can easily verify it.

3) You'll need a differential receiver. Check out the offerings from Analog Devices, Fairchild and others.


Good luck!

 

[Nigel Goodwin]

You don't even need a PIC with a UART, software ones are simple and reliable - but as most PIC's have them, you may as well use one.

It's very rare to need flow control, and the slow speeds required here certainly don't need it.

 

[Gordito]

I will use the PIC16F688 (has a UART). Probably a SN75LBC175N quad diff line receiver (expensive, 2.70$ but low power) for input from the sensor and the max232.

Thanks again for your input