|
Hi,
I'm facing a problem reading data from Serial Port using VC++. I have to read data every 12 msec from the serial port. I'm using Overlapped method and ReadFile() function to read data. The time gap between two data stream is 12.5 msec. At one streatch I'm able to read only 8 bytes. Anyone knows what could be the problem?
Please help..
|
|
|
|
|
Forget about the "real-time" aspect of it. Windows is not a real-time operating system so you'll never be able to read data every 12 msec precisely. And you don't need to. The only thing you need to do is read data when data is available. So, what you could do is read data and if you read only 8 bytes, then continue reading until you received 12 bytes.
Once this is donc, you process your data and read the next data.
|
|
|
|
|
Cedric Moonen wrote: then continue reading until you received 12 bytes
Is it a magic number or have you the CPMRU (Code Project Mind Reader Unit) turned on?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Ouch, yes I misread his message. I thought I needed to read 12 bytes. But you get the idea 
|
|
|
|
|
|
 It seems like a hard day for me today. I should really read 7 times my post before pressing the post message button.
|
|
|
|
|
I have no clue how many bytes I should read. Every 12 msec data is coming to serial port, but ReadFile() function reads only 8 bytes at one instance. Why is it so? Any idea what the EV_BREAK in WaitCommEvent() does? Please help, very urgent.
|
|
|
|
|
Susanmat wrote: I have no clue how many bytes I should read.
That's already a big problem. You should be able to know how many bytes you need to read. Where is this data coming from and what is contained in it ? Can't you send first a byte that contains the size of the 'packet' ?
Susanmat wrote: Every 12 msec data is coming to serial port, but ReadFile() function reads only 8 bytes at one instance. Why is it so?
Please post some relevant code because I don't have eyes sitting in front of your computer. Probably it is just because there is only 8 bytes in the buffer.
Susanmat wrote: Any idea what the EV_BREAK in WaitCommEvent() does?
I think it is when a break character is sent on the serial port (if it is enabled).
Susanmat wrote: Please help, very urgent
This is a forum were people help for free on their spare time. If you cannot wait and need *urgent* help, then go on rentacoder and pay for somebody.
|
|
|
|
|
Hello everyone,
I have tested try-catch works with structured exception, to my surprise. Previously I think we have to use __try and __except.
Any comments? Here is my test code and I am using Visual Studio 2008.
#include <iostream>
using namespace std;
int main()
{
int* address = NULL;
try{
(*address) = 1024;
} catch (...)
{
cout << "access violation caught" << endl;
}
return 0;
}
thanks in advance,
George
|
|
|
|
|
George_George wrote: Any comments?
Yes, you're a bit late indeed, such code works as well with VS6 compiler.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
This behaviour is not standard compliant, but then again neither is MSVC6 in many other areas in addition to this issue. See here[^].
Steve
|
|
|
|
|
Thanks CPallini,
1. You mean catch(...) is not the standard way to catch structured exception and we should use __except instead?
2. How about try? The same as catch(...) for backward compatibility? And we should use __try instead?
regards,
George
|
|
|
|
|
In section 15.1 of the C++ standard you'll find the following:
"A handler will be invoked only by a throw-expression invoked in code executed in the handler's try block or in functions called from the handler's try block."
The fact that MSVC6 catches SEH exceptions means that it's not standard compliant - this will come as no surprise to anyone who's used it for awhile and tried to get standard compliant code to work.
Later versions introduced the /EH[^] switch to switch between the old "buggy" behaviour and standard compliant behaviour.
Steve
|
|
|
|
|
Thanks Steve,
1. You mean catch(...) is not the standard way to catch structured exception and we should use __except instead?
2. How about try? The same as catch(...) for backward compatibility? And we should use __try instead?
regards,
George
|
|
|
|
|
These are difficult questions. As I pointed out earlier, the C++ keyword catch should only catch exceptions explicitly thrown by a C++ throw statement, according to the C++ standard. The ability to catch SEH exception using the C++ catch statement is switchable in later versions of MSVC, although you’re stuck with the non-standard behaviour using MSVC6. Microsoft’s SEH mechanism, accessed in C++ (on Microsoft and compatible compilers) via the __try and __except[^] keywords, is Microsoft specific but then again so is the ability to catch these exceptions using the C++ catch statement. Also note that __try and __except[^] does not result in destructors being called as the stack is unwound, so it doesn’t place nice with C++ in many cases.
Steve
|
|
|
|
|
Hi Steve,
From the link, I have not found the statement you mentioned "__try and __except[^] does not result in destructors being called as the stack is unwound".
So, RAII model can not work with structured exception?
regards,
George
|
|
|
|
|
George_George wrote: So, RAII model can not work with structured exception?
Exactly.
Steve
|
|
|
|
|
Hi Steve,
Sorry for asking this question again.
I re-read your statement below agian,
--------------------
Also note that __try and __except[^] does not result in destructors being called as the stack is unwound, so it doesn’t place nice with C++ in many cases.
--------------------
Should it be __try and __except which block us from stack unwinding or more exactly should say structured exception blocks us from stack unwinding?
(I have this confusion because in Visual Studio we still can use catch to catch structured exception.)
regards,
George
|
|
|
|
|
Hi Steve,
Sorry for interrupting you again. I have tested that structured exception could also trigger stack unwinding, looks like either you are wrong or my understanding is not correct?
Here is my code,
#include <iostream>
using namespace std;
class Foo
{
public:
Foo()
{
cout << "constructing Foo" << endl;
}
virtual ~Foo()
{
cout << "destrucing Foo" << endl;
}
};
int main()
{
int* address = NULL;
try{
Foo foo1;
(*address) = 1024;
} catch (...)
{
cout << "access violation caught" << endl;
}
return 0;
}
</iostream>
Output:
constructing Foo
destructing Foo
access violation caught
regards,
George
|
|
|
|
|
Hi everybody,
in my MDI Project i create a Dialog-Window and open it with DoModal
The user hit's a key, the Dialog closes (via OnOK())
And if the stroken key isn't the correct one, i reuse the instance of the dialog
and call DoModal() a second time...
So far so good
Between OnOK() and the DoModal() the Dialog closes and disappears from the screen and reappears,
which is normal
But i like to freeze the display during this traitement, so that the user don't sees the Close-ReOpen
Any ideas?
Big thanks for help!
|
|
|
|
|
baerten wrote: Any ideas?
Check the key pressed *before* you close the dialog, and keep it open if it is wrong?
Iain.
|
|
|
|
|
Yes, normally it's the correct way to do this
But i need to step out the DoModal() (return to the function which calls the DoModal())
I created a Wrapper-Control which is called as the same way in windows-logic as in DOS-Console-logic
and in dos i have the following:
while(stop != 1) {
Grid.Execute();
switch(Grid.PressedKey) {
case KEY_ESC: stop = 1; break;
case KEY_ENTER: stop = 1; break;
};
}
I need to do this, because i reconstruct a DOS-Console Project into MFC
And both source-codes still exists (the DOS-Application should still exist after the MFC Application is ready)
So i need a source-code which can be traited in each logics
Because to adapt some 100000 lines of code isn't so cool 
This "amphibian" source-code works, but i try to get it more beautiful
Thanks anyway for your answer
|
|
|
|
|
baerten wrote: switch(Grid.PressedKey) {
case KEY_ESC: stop = 1; break;
case KEY_ENTER: /*traitement*/ stop = 1; break;
}
Coding horror candidate? 
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Unfortunately yes 
See my explain deeper
|
|
|
|
|
baerten wrote: But i need to step out the DoModal() (return to the function which calls the DoModal())
You can't do this AND have the dialog remain open. Pick one or the other.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
