Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
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:
 
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;
         }
}
}
 
SendPR(i)
{
// transmitting my information
Write(...);
// Delay of 1 millisec to ensure data is received
Sleep(1);
}
Posted 2-May-13 6:05am
Edited 2-May-13 23:58pm
v3
Comments
Sergey Alexandrovich Kryukov at 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 at 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 at 2-May-13 11:57am
   
Where?
—SA
Mobile.Instinct at 3-May-13 4:58am
   
hello sergey, sorry for the delay. Just updated the question with the declaration of SendPR(i).
Sergey Alexandrovich Kryukov at 3-May-13 10:36am
   
No, I don't see any sleep...
—SA
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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
  Permalink  
Comments
CPallini at 3-May-13 5:03am
   
5.
Sergey Alexandrovich Kryukov at 3-May-13 10:31am
   
Thank you, Carlo.
—SA
Mobile.Instinct at 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 at 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
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

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).
  Permalink  
Comments
Mobile.Instinct at 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 at 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 at 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)

  Print Answers RSS
0 OriginalGriff 6,769
1 Sergey Alexandrovich Kryukov 6,338
2 DamithSL 5,408
3 Manas Bhardwaj 4,816
4 Maciej Los 4,195


Advertise | Privacy | Mobile
Web04 | 2.8.1411023.1 | Last Updated 3 May 2013
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100