|
Hi!
I've declared a a global structure and a static variable in a file called Common.h like this:
<pre lang="c++">
struct MenuSettings
{
int ScreenWidth;
int ScreenHeight;
}
static MenuSettings mSettings;
</pre>
I'm assigning values to ScreenWidth and ScreenHeight by reading a text file. This code is inside a file called Menu.cpp. While debugging the values of ScreenWidth and ScreenHeight inside Menu.cpp, the values are assigned correctly. I'm checking the following condition inside another file called Scroll.cpp:
<pre lang="c++">
if(mSettings.ScreenHeight >= 340)
{
}
</pre>
Here the value of "ScreenHeight" fetched from file is not coming. Instead it's coming as 0 and the if statement is bypassed. I need the correct value of ScreenHeight at Scroll.cpp. How to get it?
|
|
|
|
|
You should define the variable in just one source file, for instance:
(1) remove
pix_programmer wrote: static MenuSettings mSettings;
from the header file.
(2) Put, in the Menu.cpp file the variable definition:
MenuSettings mSettings;
(3) Put in Scroll.cpp file the variable declaration as extern:
extern MenuSettings mSettings;
That's all.
Veni, vidi, vici.
|
|
|
|
|
'static', when applied to a variable definition, means you can't see the variable outside the scope of the file in which it's declared.
if you want to share a variable across CPP files, define the variable, in Menu.cpp, like this:
MenuSettings mSettings;
and then in Scroll.cpp, add the following declaration:
extern MenuSettings mSettings;
that tells the compiler to look in other files for the variable.
better yet, put extern MenuSettings mSettings; in a common header file. that way you can use the variable by simply #including the header.
also: global variables are generally not a good idea.
modified 17-Feb-12 8:35am.
|
|
|
|
|
class Base
{
public:
Base() { }
virtual void foo1() { }
virtual void foo2() { }
} ;
class Derived : public Base
{
public:
Derived() { }
void foo1() { }
void foo3() { }
} ;
int _tmain(int argc, _TCHAR* argv[])
{
Derived * d = (Derived*)new Base() ;
d->foo3() ;
return 0;
}
In above code,
1) How it is possible to call foo3() of derived class.
2) If I call d->foo1(), Base class foo1() is getting called.
I am not able to understand this. Please explain.
Regards
msr
|
|
|
|
|
d is initialized with the vtable of Base, that's the reason why Base::foo1 is called.
On the other hand it is declared as a pointer to a Derived object, hence the compiler (you fooled) calls the foo3 method.
Try
class Derived : public Base
{
int data;
public:
Derived() { data = 100;}
void foo1() { }
void foo3() { cout << data << endl;}
} ;
Too see why fooling the compiler is not a good idea.
Veni, vidi, vici.
|
|
|
|
|
Hi, I have tried this. I am getting some junk value.
Why is this happened? 
Regards
msr
|
|
|
|
|
Because there is no instance of Derived, the method reads garbage.
Veni, vidi, vici.
|
|
|
|
|
msr_codeproject wrote: 1) How it is possible to call foo3() of derived class.
Just like you have it. What's the problem? 
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
OK, this is real simple.
You instantiate an instance of the "Base" class and then you fool the compiler into thinking it's a "Derived" class object.
Then you called a function that only exists in a "real" instantiation of a "Derived" class object.
What you did was fool yourself into expecting something reasonable to happen and you're surprised when it doesn't.
|
|
|
|
|
msr_codeproject wrote: I am not able to understand this. Please explain.
In addition to the other replies...
Don't write code like that. It is bad code.
|
|
|
|
|
Bad line here below. Don't do that.
Derived * d = (Derived*)new Base() ;
Try
Derived * d = new Derived;
|
|
|
|
|
Quick Q. Trying to set mark parity, write some data, set space parity, write out some more data. Doing this to emulate a wakeup bit for an older serial protocol. Now I am not convinced that I can do it reliably.
Initially I tried using SetCommsMask followed by WriteFile. When this failed, I also tried DeviceIOControl using IOCTL_SERIAL_SET_LINE_CONTROL, but alas, same result (SetCommsMask uses this anyway). The parity bit is not always set. I am not using overlapped comms.
When I look at the standard serial port driver supplied with the WDK, I see that IOCTL_SERIAL_SET_LINE_CONTROL uses WdfInterruptSynchronize to set the Line Control Register, and from what I read this is not synchronous (ie waits for an interrupt), so possible means that the parity bit might not always be set in the UART before I write out the data. Is this correct, or am I barking up the wrong tree?
|
|
|
|
|
Andrew Pearson wrote: the parity bit might not always be set in the UART before I write out the data.
Very likely. The timing of access to UART control registers has ALWAYS been a horror.* Remember that there's a FIFO buffering your tx data.
Suggestion: Unless you're using 8 data bits + parity, you can do it yourself. Just use 'n+1' data length and set/unset an appropriate high order bit.
* Since the original WD1402 in 1972 or thereabouts. The 8250 and its 16xxx successors (as used in PCs) are not much better. You might get the wrong effect, but at least they don't hang if you write to them at the "wrong" time.  
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Peter_in_2780 wrote: Very likely. The timing of access to UART control registers has ALWAYS been a horror.* Remember that there's a FIFO buffering your tx data.
Suggestion: Unless you're using 8 data bits + parity, you can do it yourself. Just use 'n+1' data length and set/unset an appropriate high order bit.
I figured as much.
It is 8bits + parity, shame. Wonder if its worth trying at the driver level? Might go look at some datasheets, although it has been a long while since I have had to go that far!
|
|
|
|
|
Andrew Pearson wrote: Might go look at some datasheets
I wish you lots of luck - you'll need it, seeing these days the UART functionality is typically embedded in an "all-in-one". Probably a microcontroller emulation...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Its very annoying actually, as I can step over WriteFile() and it all works perfectly. Run it and it fails. I have checked registers to make sure there is nothing in transmit holding register, i have turned off the FIFO's. Now I just set the Parity Bit, then Send out a byte using IOCTL_SERIAL_IMMEDIATE_CHAR and it still fails. Not sure there is much left that I can do.
I notice that WDK makes mention of an internal call, IOCTL_SERIAL_INTERNAL_BASIC_SETTINGS. I am not right up there with drivers, but I need to port one to 64bit soon so might be good practice!
Edit.
Put a Sleep(10) after writing out first byte, but before setting parity back to space and guess what, it works. So Problem is not the fact the parity is not getting set fast enough, its because I am changing back parity bit BEFORE the first byte is being transmitted.
Tried a few more IOCTL's to try and read Line Status Register but they all show it as clear. Will keep trawling through driver code and see if I can turn something up.
modified 17-Feb-12 0:06am.
|
|
|
|
|
Andrew Pearson wrote: I can step over WriteFile() and it all works perfectly. Run it and it fails
You know what this means dont you?
In step through the code is taking a lot longer to run than in 'run' mode, so this gives you a clue that it is timing related. ie, you need to make sure the data is completely sentf before changing the UART settings and sending more data. SO look at doing a TX FIFO flush or some such.
Andrew Pearson wrote: I need to port one to 64bit soon
*Should* be OK, just use the size_t type pretty much everywhere. 
Andrew Pearson wrote: Put a Sleep(10)
Yeah, timing. Flush, reset, disable/enable, 1 byte FIFO... All these can force the chip into the exact state you want.
==============================
Nothing to say.
|
|
|
|
|
You may change your code to use overlapped IO. Then you can wait until the transmission has been finished before changing the parity setting.
|
|
|
|
|
This is why I dont like overlapped IO.
A lot of coders think it must be somehow more 'cool', but end up with code that calls an IO, does a wait, and processes the response. Why not just leave it non overlapped?
==============================
Nothing to say.
|
|
|
|
|
Tried overlapped, same behaviour.
|
|
|
|
|
One last idea, if this does not help I will give up:
You can try to use SetCommMask() with EV_TXEMPTY and call WaitCommEvent() after writing data. When WaitCommeEvent returns false and GetLastError is ERROR_IO_PENDING, use WaitForSingleObject and call GetOverlappedResult when the event is signaled.
|
|
|
|
|
Nope, that does not work either.
Once again, I looked at the Driver Code for serial port, and the method for setting the EV_TXEMPTY flag is passed into the WdfInterruptSynchronize method, so it get called once the ISR is completed. It does not reflect the UARTS Line status register from what I can tell.
I think the only way to do it reliably is to write a driver that does not use ISR's.
|
|
|
|
|
You are right. The event is signaled when the last data byte has been copied from the TX buffer (transmitter holding register) to the transmit line register. What you need is the transmitter holding register and transmitter line register empty status. This is indicated by bit 6 of the line status register. Unfortunately, this event is not supported by the Windows SDK.
If you can live with a wait function, you may use the EV_TXEMPTY event and wait until the data byte has been trasnmitted (start + parity + data + stop) / baud. Because transmission is done by the UART hardware, the time is constant .
|
|
|
|
|
Had another idea. The Line Status Register is sent when IOCTL_SERIAL_LSRMST_INSERT is used, and this IS the actual UART Line Status Register. Bit 6 of the LSR, THR is empty, and line is idle, looks like it may be interesting. Will try this out today.
|
|
|
|
|
Andrew Pearson wrote: When I look at the standard serial port driver supplied with the WDK, I see that IOCTL_SERIAL_SET_LINE_CONTROL uses WdfInterruptSynchronize to set the Line Control Register,
Hmm, not sure if Microsoft actualy rewrote serial.sys to use WDF or not, so it cold just be a sample driver.
The older DDK with WDM source code actually IS serial.sys on those older machines (XP and older) so it might be a more informative source since WDF can hide stuff.
As the other poster says, watch out for the FIFO. I would make it 1 byte, that way you know that after any change you make to the parity bit settings will take effect immediately, and you might also like to have a slight delay, and possibly prod the UART before sending data. (You cold prod it by doing a disable/enable for example, or a flush, or toggling DTR...).
A UART programming sheet could be useful, it will tell you exactly what is going on at the chip when you run the various IOCTL calls.
How are you determining the value of the parity bit? DO you have a line sniffer? If not you might need to wire up the chip to a logic analyser to see what is actually on the wire. They are very useful, as well as scopes, in really getting HW to work as you want.
==============================
Nothing to say.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
