Can I send data on two or more serial ports at the same time? RS485

[GaryZ21]

Is it possible to send seperate or same data out on two serial ports at the same time using CVI (Labwindows)?  Below is a section of my code

    bytes_sent = ComWrt (ComPort3, "123456", 6);
    bytes_sent = ComWrt (ComPort4, "abcdefg", 7);

When I look at the com ports using the oscilloscope, one of the port lags behind the first one by 60us or more.  Is there a fix to this, or is it possible to send both data out simultaneously?

[LuI]

Gary,

if 60 µs is not good enough for you than I fear there's no solution for your problem using standard OSs. And finally even real-time OSs can not really do several things simultanerously, but react within a specified time frame. If you got just one CPU, this can do just one task at any given moment. Having multicore-CPUs or multi-CPUed workstation may improve this, but than your OS and your code must support  real parallel tasking.
Your code fragment does call ComWrt first for Com3 and afterwards for Com4. So the 2nd call will be performed after the 1st returned.  If you need them to be performed in parallel than you need to start two tasks and have each one call ComWrt separately. But, as I said, finally a single-core CPU can handle just one task at any given time. So using two tasks might minimize the lag between both calls to ComWrt, but will not bring it o 0.

HTH   and
Greetings from Germany!<br>-- <br>Uwe

[GaryZ21]

Hello Lul,

Thanks for your response.   I'm not looking for a parallel task down to the nanosecond resolution. However, is it possible to have both of the task to come up within 1uS(microsecond) of one another?   Is there a function I can call in cvi or C, that enables two port to transmit simultaneously (uS resolution)? 

Second question -
Windows XP have a timing resolution of miliseconds, is it possible to use assembly code to get uS resolution or better?  If it is, how do I code in assembly using CVI?

[LuI]

Gary,

AFAIK you would need some kind of system driver to achieve what you stated. But I might have a misunderstanding here.
You know, this 1ms timing resolution you mentioned is the smallest timeslice the task scheduler can assign. Every task switch requires a context switch, wich unloads the complete context of the old task and loads the one of the next to the CPU. This requires at least som 10th of µs, depending on the actual system and memory load and the CPU speed.  If you need a higher (e.g. better) timing resolution you either need both serial port accesses within one single task (which implies the serialised acces, where the call to the 2nd process can start when the call to the 1st port has finished) or you need a system driver which does not rely on the task scheduler and usually runs with higher priority. Writing such drivers is a really complicated process - specialists charge some 10th of thousends of $$$. A third alternative is using a real time OS.

You know, serial port access is typically used asynchrounuosly. Your application sends some kind of data to a system buffer and calls the systems serial driver. This one takes a part of your data, copies it to the UART chip and starts its sending process. The UART sets an interrupt when its buffer is allmost empty, which makes the system serial driver to refill the UART buffer. When all data is sent, this UART interupt is changed to a notification, which can be read on the application level and used as a notification that all data has been send. You can of course start two of those processes, but the second can just be started when the first call had been returned. And AFAIK it returns when the first data is in the UART. So thats the delay you measured. I am not aware of any means to delay the first system serial driver or the UART until all others have been prepared and to start all drivers instances in parallel.
Greetings from Germany!<br>-- <br>Uwe