Click here to Skip to main content
15,890,438 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hello,

I have been working on a multi-threaded MFC application that needs to send information via the serial port. Everything seems to work fine apart from the fact that I need to send the information every 100ms. I have been trying to send the information based on the tick counts to know when exactly to send the information as given below but no luck so far. Any suggestions on where I am going wrong? Any help would be really appreciated.

Code:

C++
Thread(...)
{
CDlg* appPtr = (CDlg*)lpVoid;

while(true)
{
	if(appPtr->m_StartSending == true)
      	{        
         dInitialCount = GetTickCount();

         if(dPRCount == 0)
            dPRCount = GetTickCount();

         dCurrentCount = GetTickCount();
         Difference = (dCurrentCount - dPRCount);
         if(Difference >= 100)
         {
            appPtr->SendPR(i);   
             //Send message via serial port every 100ms using WriteFile()
            // Sleep of 1 sec after writefile to ensure data is received
            dPRCount = 0;
            dCurrentCount = 0;
         }
}
}


C++
SendPR(i)
{
// transmitting my information
Write(...);
// Delay of 1 millisec to ensure data is received
Sleep(1);
}
Posted
Updated 2-May-13 22:58pm
v3
Comments
Sergey Alexandrovich Kryukov 2-May-13 11:16am    
How can you ever guarantee that the other side, on the other end of your RS-232 cable, can read the data in time? I guess the whole approach is wrong, even before reading the code...
—SA
Mobile.Instinct 2-May-13 11:24am    
Yes the data can be read in time and there is a sleep after my write command... of about 1 second to ensure the data is received...
Sergey Alexandrovich Kryukov 2-May-13 11:57am    
Where?
—SA
Mobile.Instinct 3-May-13 4:58am    
hello sergey, sorry for the delay. Just updated the question with the declaration of SendPR(i).
Sergey Alexandrovich Kryukov 3-May-13 10:36am    
No, I don't see any sleep...
—SA

Please see my comment to the question. The whole idea is wrong: you never wait for anything in your code. Are you trying to do a spin wait? This is always an evil. Either use a timer events or a separate thread (better); sleep between sending cycles. But even this could be wrong, due to the problem I mentioned in my comment to the question. You can get a chance for a better advice only if you provide complete information on why are you doing all that.

—SA
 
Share this answer
 
Comments
CPallini 3-May-13 5:03am    
5.
Sergey Alexandrovich Kryukov 3-May-13 10:31am    
Thank you, Carlo.
—SA
Mobile.Instinct 3-May-13 5:41am    
Can I try to the same using two threads? Do you suggest it being a good idea?
Sergey Alexandrovich Kryukov 3-May-13 10:31am    
Yes, but it depends on what are you going to do in these threads. I just say, all kind of communications should better be done in a separate thread. For example, if you read data, you can read unconditionally; if there is no data, it will be a blocking call, so a thread will go into the wait state, giving all time to other threads. The nature of communication is sequential, so a thread is the best.
—SA
What are trying to do?
If your communuication really needs an accurate synchronization (how accurate must be the 100 milliseconds period), you are going to fail (Windows OS cannot provide it).
 
Share this answer
 
Comments
Mobile.Instinct 3-May-13 5:15am    
Yeah, basically I have total 12 Write commands .. of which 4 of them need to be sent at 100 ms whilst others can go at any other rate.. Even using tick counts won't help?
Sergey Alexandrovich Kryukov 3-May-13 10:35am    
The time of execution of a timer tick handler cannot be guaranteed. Besides, as I say, who knows how slow is the device on the other end of a RS-232 cable? As to the timer: did you have had to deal with the situation when a new timer event is invoked when the handler did not yet complete processing of the previous event? Handling timer events is not so simple...
—SA
Sergey Alexandrovich Kryukov 3-May-13 10:32am    
Good point; that said Windows is not a real-time OS. My 5.
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900