Need something better than sleep()

I've been using sleep(1) after requesting data via a serial port because of the slight delay time in receiveing the data. However, now those 1 second delays have accumulated to too much wasted time since I really only need to wait a fraction of a second. If I was only doing one data request it wouldn't bee too bad... but I'm requesting over 5000 data chunks... 5000 seconds is a lot of time...

is there a similar function that takes values less than one second? I know of Sleep() in windows.h, but I'm running the program on a computer with only DOS 6.2. What are my options?

Thanks in advance

nanosleep(); you will probably want to build a function that uses the nanosleep/time structs internally so you can just do something like "mysleep(0,10)" where the first arg is seconds and the second one hundredths thereof, because nanosleep itself is not that simple or user friendly.

Here's the one I've been using, there are some includes that go with it that will be particular to your system, that is a mystery to me:

Code:

---

void gap (int secs, int hundredths) {
        struct timespec interval;
        interval.tv_sec=secs;
        interval.tv_nsec=hundredths*10000;
        nanosleep(&interval,NULL);
}

so, eg,
gap(0,25);

---

...actually it looks like nanosleep is POSIX, sorry.

That's similar to what I'm looking for, just I need it for dos...

Check your dos.h header file, and see if there are any sleep functions that have the resolution you are looking for.

DOS, or Windows? Most people tend to say DOS when they mean Windows Console apps, but the Native API is quite different.

--
Mats

No I actually mean DOS. Windows is not installed.

And what compiler are you using?

--
Mats

Turbo C++ 3.0

what compiler and libraries you use?

there is delay() which causes delay in milliseconds

search turboc++ help for "delay"

Just saw that is dos.h... I swear I looked through that before :/

Thanks

The answer is to use the delay() function.

#include <dos.h>


and then set your delay for what you want, in milliseconds:

delay(500); //delay will be 1/2 second.

This also works in WIndows console code, but I don't know why.

This is from Turbo C/C++ 1.01 btw, so it's 100% DOS, not windows.

how about this custom made function

Code:

---

#include <time.h>
#define MILLISEC 1000
void timewaste(clock_t lMillisec)
{
clock_t finish;
finish = clock() + (lMillisec / MILLISEC * CLOCKS_PER_SEC);
while (finish > clock())
;
}

---

you could easily extend that to any other time interval

Quote:

---

Originally Posted by creeping death

how about this custom made function

Code:

---

#include <time.h>
#define MILLISEC 1000
void timewaste(clock_t lMillisec)
{
clock_t finish;
finish = clock() + (lMillisec / MILLISEC * CLOCKS_PER_SEC);
while (finish > clock())
;
}

---

---

That is no better than the delay function that is already available in TurboC. Both have the drawback that it uses 100% of the CPU time in the machine, which is not ideal (but there's little else that can be done in DOS).

In a non-DOS environment, you should be using the OS supplied functions, as that will let the CPU do something else useful or go to sleep if there is nothing useful to do.

--
Mats

Well, I would have liked to not be using the CPU during the delay, but since I don't need the CPU to really be doing anything else during this time, then it's not that big a deal... out of curiosity, does the sleep function is dos.h use the CPU as well?

Quote:

---

Originally Posted by Bladactania

Well, I would have liked to not be using the CPU during the delay, but since I don't need the CPU to really be doing anything else during this time, then it's not that big a deal... out of curiosity, does the sleep function is dos.h use the CPU as well?

---

If it's a DOS function, there is no multitasking, so there is nothing that would happen instead, so yes.

--
Mats

That is unfortunate. But I guess there's no way around it.

Thanks.

Quote:

---

Originally Posted by Bladactania

That is unfortunate. But I guess there's no way around it.

Thanks.

---

Well, I guess you could rewrite the code to be Windows-compatible instead of using very ancient DOS... ;)

--
Mats

I'm limited by the computer the code will be running on. I'm writing code to run on a Single Board Computer running a 133Mhz Processor with about 32MB of memory...

Quote:

---

Originally Posted by Bladactania

I'm limited by the computer the code will be running on. I'm writing code to run on a Single Board Computer running a 133Mhz Processor with about 32MB of memory...

---

Right. So if you are going to use more than about 2% of the 32MB, you will need a different OS than DOS.

--
Mats

Wait... What?

DOS is limited to 640KB (well, ok the first 1MB, but the last 384KB of "DOS" memory is occupied by the BIOS, Video Memory and such things, so the application has a bit less than 640 KB to play with, since the first little bit of memory is occupied by vector table and the actual DOS kernel).

There are ways around it, but it gets messy very quickly.

--
Mats

Quote:

---

DOS is limited to 640KB (well, ok the first 1MB, but the last 384KB of "DOS" memory is occupied by the BIOS, Video Memory and such things, so the application has a bit less than 640 KB to play with, since the first little bit of memory is occupied by vector table and the actual DOS kernel).

---

Obviously that can't be true considering my first computer ran DOS with 4MB of RAM :)

Read more about this here. There are several ways to overcome the 640K barrier (back in the day, I used XMS). Chances are that whatever DOS version you are using supports a DOS extender of some kind. If you are using a version of DOS prior to 3.0, then things might get kind of tricky though.

Quote:

---

Originally Posted by bithub

Obviously that can't be true considering my first computer ran DOS with 4MB of RAM :)

Read more about this here. There are several ways to overcome the 640K barrier (back in the day, I used XMS). Chances are that whatever DOS version you are using supports a DOS extender of some kind. If you are using a version of DOS prior to 3.0, then things might get kind of tricky though.

---

DOS memory extenders require cooperation from the application. You don't just plug it in and magically get access to more memory.

If DOS is a requirement, I'd calibrate a busy-loop to do subsecond waiting.

Quote:

---

DOS memory extenders require cooperation from the application. You don't just plug it in and magically get access to more memory.

---

Nowhere did I imply there was magic involved, I just stated that is was possible (and relatively common to do).

Quote:

---

If DOS is a requirement, I'd calibrate a busy-loop to do subsecond waiting.

---

How is that an improvement over calling the delay() function?

Quote:

---

Originally Posted by bithub

Nowhere did I imply there was magic involved, I just stated that is was possible (and relatively common to do).

How is that an improvement over calling the delay() function?

---

How do you know you will have this function? The OP indicated targetting some custom environment.

Where would you even acquire a DOS memory extender? None of those companies are still in business.

Quote:

---

Originally Posted by brewbuck

Where would you even acquire a DOS memory extender? None of those companies are still in business.

---

Kids these days! Back in my day we had himem.sys and emm386.sys ... both of which came with DOS.


Quzah.

Quote:

---

Originally Posted by quzah

Kids these days! Back in my day we had himem.sys and emm386.sys ... both of which came with DOS.


Quzah.

---

Yes, but beyond that, you need the compiler to produce code that uses the extended memory. Most DOS applications didn't actually USE memory above 1MB, it was mainly used as disk-cache.

Note that to use memory above 1MB, the application code needs to run in protected mode, and to get above 16MB, it is necessary to have 32-bit protected mode. Neither of the protected modes are compatible with real-mode that DOS runs in, so basically, any interrupts have to be turned off whilst in protected mode. This also means no calls to BIOS, no reading/writing from/to hard-disk, etc, etc. It is non-trivial to run in protected mode and DOS at the same time.

--
Mats

I'm pretty sure DOOM used more than 1 MB of memory, and that it read from files, and could read key interrupts. Pardon me while I disagree with you.

Speak of the devil, here it is now: DOS extender - Wikipedia, the free encyclopedia

Perhaps I'm misunderstanding your statement, but again, I'm pretty sure DOOM handled keyboard interrupts just fine, and that it read from disk...


Quzah.

Quote:

---

Originally Posted by quzah

I'm pretty sure DOOM used more than 1 MB of memory, and that it read from files, and could read key interrupts. Pardon me while I disagree with you.

Speak of the devil, here it is now: DOS extender - Wikipedia, the free encyclopedia

Perhaps I'm misunderstanding your statement, but again, I'm pretty sure DOOM handled keyboard interrupts just fine, and that it read from disk...


Quzah.

---

DOOM was loading it own memory manager if I remember correctly. I do not know was it was doing, but it was one of the first programs doing it...

Yes, DOOM is mentioned in the Wikipedia article.

And if you have access to a Watcom compiler, then you can probably do mos things you could expect to do in DOS, but also have access to 4GB of address space. But we are no longer REALLY running DOS.

And with modern OS's, there is really no reason to try to make DOS run in 32-bit mode and still do 16-bit DOS.

Either find a RTOS that suits the task, or use Linux in some "embedded" variant.

--
Mats