|
Member 3363498 wrote: Windows XP virual memory management would take care of data larger than RAM size
It will but if you're gong to be manipulating those huge chunks of memory at once - as in repeatedly allocating 4 GB then running through the entire 4G allocation - you're system is going to be constantly thrashing on the paging file. The additional time spent accessing the hard drive is probably going to be greater than whatever time you will gain be rewriting your logic to use the bigger chunks of memory. Processor speeds blow away disk access speeds.
Also, even if you put more than 4G of physical memory in your machine, XP cannot access it. It has a hard upper limit of 43G (32G using the default settings).
Judy
modified on Tuesday, April 15, 2008 8:38 AM
|
|
|
|
|
If you want to do this sort of thing you're probably best off using the Virtual Memory Win32 API, ::VirtualAlloc etc. Windows doesn't cope all that well if you try and grab all the RAM off it through the normal heap mechanism. You're also incurring CRT overhead and possibly tripping over inherent 2GB limits in the CRT malloc etc implementations when you use new. If you don't want to use Virtual memory you could use the Win32 Heap API e.g. ::HeapAlloc instead. Depending on how much RAM you've actually got you might get away with it. If you do my advice is make sure your allocation size are multiples of 64K and don't make them larger than about 4MB max at a time. That might help Windows to cope well enough. There's all sorts of wiredness going on underneath as ever with disk cache sizes and paging stuff in and out so you might want to target a specific and relatively recent Windows version aswell e.g. at least Server 2003 by defining _WIN32_WINNT 0x0502 and WINVER 0x0502. I'm not certain this will help but it's worth a try. 
"The secret of happiness is freedom, and the secret of freedom, courage."
Thucydides (B.C. 460-400)
|
|
|
|
|
I believe that applications need to be flagged to indicate that they are able to handle a memory address space larger than 2GB. In VC++6.0 there was the /LARGEADDRESSWARE linker switch.
Remember that allocation of memory requires two things: (1) you need available free memory that can be allocated, and (2) you need enough contiguous addresses in your application's address space to access that memory through.
When you start heading beyond 2GB, you may need to be starting the OS with special flags (/3GB in the boot.ini file) which forces it to only reserve 1GB of address space instead of 2GB.
You should Google for things like the switch I mentioned above "AWE", and the "/3GB" switch for more information. Also, look into the VirtualAlloc(...) and related functions for handling large amounts of memory.
Peace!
-=- James Please rate this message - let me know if I helped or not!<hr></hr>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
On 32-bit windows you can't dynamically allocate 3GB of memory.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
On 32 bit windows the whole user address space is only 2GB!
Steve
|
|
|
|
|
I configure a connection between my app and the COM1 port of a PC using the following piece of code:
hComm = CreateFile(("COM1"),
GENERIC_READ | GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
FILE_FLAG_OVERLAPPED,
0);
then using the GetCommState() function for reading the settings of the port and SetCommState() for setting the desired value's and trying to read the inputbuffer with ReadFile() I stumbled on a problem:
When starting my app this reports no error at all but it doesn't detect any input on the serial port (in my case a barcode scanner) and stops the reading function on a time_out and the handle is closed. If I start now (even when my app is still running) the Windows HyperTerminal with the appropriate settings for the scanner communication and quit the HyperTerminal again (even if I didn't scan any code, just establishing the connection and terminating it) and I start my app again the scanned codes are shown. If I check the settings of the DCB they are the same, when I run my app and then HyperTerminal.
Do I have to define something, somewhere regarding the "COM1" string used in the CreateFile section, and if so how is it done?
Frank Peeters
|
|
|
|
|
FPeeters wrote: then using the GetCommState() function for reading the settings of the port and SetCommState() for setting the desired value's
What are you setting with SetCommState ? The baudrate ?
Make sure that you specify the correct parity, stop bits and byte size. Does your barcode scanner use some kind of handshaking ? That might be the problem.
|
|
|
|
|
If I look in HyperTerminal the dataflow control is set to NONE and I will try to set the DCB also to NONE.
But, how is it possible that the same app runs well when het Hyperterminal is started and stopped before the app starts to communicate and doesn't communicate when I start after rebooting Windows and not opening the hyperterminal?
|
|
|
|
|
Did you check return values (you cannot have COM1 open for both Hyperterminal and your application)?
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
The Com1 port is closed in my app when I receive a Time_Out event (CloseHandle). So when opening the Hyperterminal after this event shouldn't generate a problem (otherwise HyperTerminal creates an error message). Also, as far as I know, if I try to create a handle to an open COM port, C++ generates an errorcode. But, please correct me if I am wrong.
|
|
|
|
|
FPeeters wrote: if I try to create a handle to an open COM port, C++ generates an errorcode
What do you mean with that ?
In fact, if you are trying to open a port which is already opened, the CreateFile function will return an invalid handle (check the documentation of this function). So, before trying to read on the port, you should verify that your handle is valid (handle != INVALID_HANDLE_VALUE).
|
|
|
|
|
Cedric Moonen wrote: In fact, if you are trying to open a port which is already opened, the CreateFile function will return an invalid handle (check the documentation of this function). So, before trying to read on the port, you should verify that your handle is valid (handle != INVALID_HANDLE_VALUE).
Sorry for the confusion, but this is what I was trying to say...
|
|
|
|
|
When I look at an article written by Konchat (Creating a Serial Communication on WIN32) he shows a screenshot (figure 2) where he sets portName as "COM1", but in the presented watch screen that portname has a value (0x00421a2c "COM1"). I assume that the hex code is in fact the real adress of the port. I haven't declared anything like this is my app, and I don't know what to declare and where.
|
|
|
|
|
Did you check all return values?
CreateFile returns a valid handle?
GetCommState and SetCommState return TRUE?
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
As far as I can tell CreateFile returns a valid Handle and GetCommState and SetCommState are true.
Here is in pseudo-code how I did it:
hComm=CreateFile(("COM1"), GENERIC_READ|GERERIC_WRITE,0,0,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,0);
if (hComm == INVALID_HANDLE_VALUE)
//ERROR MESSAGE TO LISTBOX
else
//OK MESSAGE TO LISTBOX
if (!GetCommState(hComm,&dcb))
//ERROR MESSAGE TO LISTBOX
else
//OK MESSAGE TO LISTBOX
if (!SetCommState(hComm, &dcb))
//ERROR MESSAGE TO LISTBOX
else
//OK MESSAGE TO LISTBOX
if(osReader.hEvent == NULL)
//ERROR MESSAGE TOLISTBOX
else
while (ReadActive)
if(!ReadFile(hComm,lpBuff,sizeof(lpBuff),&dwRead,&osReader))
//ERROR MESSAGE TO LISTBOX
else
dwResult = WaitForSingleObject(osReader.hEvent, READ_TIMEOUT);
switch(dwResult)
case WAIT_OBJECT_0
case WAIT_TIMEOUT
default
So if I get an INVALID_HANDLE_VALUE the rest of the code is skipped and an errormessage is written in a ListBox, also if either the GetCommState() and SetCommState() function restuns FALSE I should receive an error message in this ListBox. But I don't receive an error message and the app reports a Time-out on the Listbox.
|
|
|
|
|
Maybe the read operation was completed before the wait starts. Why don't you call GetOverlappedResult?
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
My question is:
Why is he opening a bar code scanner with FILE_FLAG_OVERLAPPED in the first place. I have never seen a bar code scanner which required overlapped I/O.
Best Wishes,
David Delaune
|
|
|
|
|
Maybe his application requires it.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
No the reason why I used this kind of IO is quit simple: I couldn't find any explanation on how to run the COM port otherwise... So if there is any suggestion on how to work with a barcode scanner I would like to know.
|
|
|
|
|
You can simply use COM synchronously.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
In all the articles I've found everyone says you can use com synchronously but no-one explains it.
I am a starter on C++ (formerly programming PLC's and slowly changing over to PC control for some machines).
|
|
|
|
|
If you configure a COM for synchronous operations (see for instance [^]) then each call to ReadFile becomes a blocking one (until timeout expires, see [^]).
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks for the info, but to go back to my original problem: Does this solve it, or is it a better way to communicate for me with the com port?
|
|
|
|
|
At least, you can try.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
OK I deserved that one, ofcourse I can try, and I will..
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
