Yeah, I am going to use a microcontroller to setup and clock the DAC.
But I have to get the right SDI out of the PC COMM Port first.

This is not an SDI, this is a Tx pin... they are entirely different protocols. The μC will read this and know what it means... all you need to do is output the SPI data to the DAC at that point...

 

kj4g09. You are wasting your time, and ours. The interface to that chip will not work off a USB-to-serial cable, and it has nothing to do with ASCII. It could be run with 2 successive characters from an SPI port, or by being bit-banged by a microcontroller.

In this document, refer to Figure 3, which shows the input requirements.
http://www.ti.com/lit/ds/symlink/dac7614.pdf

If your budget will run to it, I suggest that you stop trying to design something and buy a module like this:
http://buy.advantech.com/USB-4704-AE/USB-4704-AE/model-USB-4704-AE.htm

It would save you a lot of trouble, in the long run.

 

I told OP this at post #2. OP does not understand serial ports.

 

i think we need a schematic here. There's too much confusion, I can't get no relief.

 

OP is sending ASCII via USB -> RS-232 adapter,
then connecting to DAC SPI input.
OP has been told you cannot do this. SPI is clocked serial data.

 

This is not an SDI, this is a Tx pin... they are entirely different protocols. The μC will read this and know what it means... all you need to do is output the SPI data to the DAC at that point...

I just want to make sure I understand it correctly.
Tx can't be used here is because its not clocked, and start and stop bit will be sent when a byte is sent. Also Tx can only send one byte at a time.
By send two bytes to microcontroller, the microcontroller can then send SPI data to DAC to fullfil the task.

Is that right?

 

I just want to make sure I understand it correctly.
Tx can't be used here is because its not clocked, and start and stop bit will be sent when a byte is sent. Also Tx can only send one byte at a time.
By send two bytes to microcontroller, the microcontroller can then send SPI data to DAC to fullfil the task.

Is that right?

The idea is correct, though your terminology isn't. the Tx is the the transmit pin for a module implementing the UART communication protocol.

The rest is sound... send two bytes to the microcontroller encoding the value 0-whatever the number was(4096?). The microcontroller will, upon receipt of the second byte, send the information over the SPI interface to the DAC...

 

But you did not tackle the problem that occurs when the bytes arrive out of sync.

 

But you did not tackle the problem that occurs when the bytes arrive out of sync.

What do you mean? Are you referring to a delay between sending the bytes over UART?

 

I mean suppose you are sending AB in a continuous string:

ABABABABABABABABABABABA...

and you receive BA.

You will obviously have erroneous data.

 

I mean suppose you are sending AB in a continuous string:

ABABABABABABABABABABABA...

and you receive BA.

You will obviously have erroneous data.

I didn't realize we were doing architecture too

Okay, so tack on a bit sequence in the extra bits in the word and use that to denote first/last byte or whatever...

You could also delay the computer until the microcontroller is ready and hope that they will stay in sync...

You need to be sure to send the data in an agreed format(i.e. endianness, justification, baud rate, parity?, etc.)

The computer can pump this data much faster than the microcontroller can process it, so you'll need to delay that, or better, send an acknowledge byte to the computer to denote a ready state... This can get really complex, depending on your level of redundancy....

 

In this case the solution is easy.
You only need 12 bits in order to transmit 0-4095. That leaves four spare bits.
Use two bits of each byte to denote the byte order.
Actually, you only need one bit per byte hence you have a spare bit on every byte.

As for speed, it can be the other way around. The MCU can process the data faster than the PC can send it.

 

As for speed, it can be the other way around. The MCU can process the data faster than the PC can send it.

Can be, though, it seems more likely to be the other way around.

 

The maximum baud I have seen on a PC is 115,200 bps while I regularly transmit to an MCU at 500,000 bps which is 20μs per byte or 40μs per pair of bytes.

Must half-decent MCUs can process 16-bit data and send it to a DAC via SPI in less than 40μs.

But you can't run RS-232 at 500,000 bps.

 

The maximum baud I have seen on a PC is 115,200 bps while I regularly transmit to an MCU at 500,000 bps which is 20μs per byte or 40μs per pair of bytes.

Must half-decent MCUs can process 16-bit data and send it to a DAC via SPI in less than 40μs.

But you can't run RS-232 at 500,000 bps.

I suppose, considering all you are doing is writing to the DAC, this would be correct...

I usually have many more subroutines

 

The maximum baud I have seen on a PC is 115,200 bps while I regularly transmit to an MCU at 500,000 bps which is 20μs per byte or 40μs per pair of bytes.

Must half-decent MCUs can process 16-bit data and send it to a DAC via SPI in less than 40μs.

But you can't run RS-232 at 500,000 bps.

Many of those USB to serial converters allow for quite high bit rates

 

Right. I am using CP2102 USB to serial bridge at 500,000 bps and using TTL interface, not RS-232.

 

To get SPI working over RS232, you could use the control lines like RTS and DSR to set the clock and data.
But this is woefully slow over USB to serial converters, because one usb transaction takes 1ms.

 

In this case the solution is easy.
You only need 12 bits in order to transmit 0-4095. That leaves four spare bits.
Use two bits of each byte to denote the byte order.
Actually, you only need one bit per byte hence you have a spare bit on every byte.

As for speed, it can be the other way around. The MCU can process the data faster than the PC can send it.

I notices that there are start and stop bits attached to the byte when I send it through UART. when I set the computer to send two successive byte to represent any number in 0-4095, that two bytes separated by start and stop bits, also the output is 20 bits in total including 2 sets of start and stop bit. Is it possible that the microcontroller can ignore those start and stop bit or I need to do some data manipulation in the microcontroller to delete the start and stop bit, also the extra 4 bits in the second byte?

 

The microcontroller can do anything you want. You send a byte over the uart, the microcontroller reads it and lets your program read that byte. No need to worry about start and stop bits, almost all micros have this solved on hardware level. Then you assemble the whole 12bit number and send it over the spi.
It will be better to send the first 7 bits in the first byte like 1xxx xxxx and then the rest 5 bits in the second byte like 000x xxxx, so that you can be sure which byte is the first byte.