Not at all. If WriteFile blocks, then its thread is suspended by Windows and stops taking up CPU cycles until the write is completed by the device drivers, at which time your thread is scheduled for execution again. Blocking like this is fine, especially if it is in a worker thread, as you have done.
-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
snipped-for-privacy@visi.com (Grant Edwards) wrote in news:3f032d83$0$645$ snipped-for-privacy@newsreader.visi.com:
Yes, I believe that is why my code will eat a bit of CPU time. It isn't much, though. Only at the tail end of the transmission. I can handle that tiny burst, since I am not anywhere close to "real time" (as if that term made sense in Windows). Other applications, however, may not be able to tolerate it.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
I'm doing exactly the same. It has another advantage. You can discover collisions in certain situations.
Gerard
This can work in DOS because the application can respond to rx'ed chars in a timely manner and turn off the transmitter quickly. But in Windows, the variable delays in applications means that an application cannot be sure of responding the rx'ed characters in a timely manner. If a device on the RS-485 bus chooses to respond to your transmission fairly quickly, there is a good chance that it will begin its transmission while your transmitter is still on, resulting in a collision and lost data.
-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)
Have something to add? Share your thoughts — no account required.
Ask the community — no account required