|
Quote: This package allows twentysomething web developers to write a newer, worse version of JavaScript that no one else on their team knows.
LOL.
Never mind pictures of Guy - the "Express" / "Hot Pockets" link up is enough ... 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It's at least made with real cheese. 
|
|
|
|
|
Then source code would be littered with porn. No thanks. You have no idea where the last coder had been. 
|
|
|
|
|
|
Could have Clippy resurrected. It looks like you are trying to write a program...
|
|
|
|
|
|
just put a link to the image
|
|
|
|
|
I'm waiting for Visual Cortana (should find an "i" word so I can call her Vickie...), where you will tell VS what you want to build and it will find all the NuGet and GIT crap and build the application for you.
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
I am using something like
std::this_thread::sleep_for(std::chrono::microseconds(toWait));
where toWait is dynamic, depending on frequency and desired time minus the used time for the data processing.
I am aware of:
Blocks the execution of the current thread for at least the specified sleep_duration.
This function may block for longer than sleep_duration due to scheduling or resource contention delays.
but I would at least have expected that the scheduling or resource contention is something that can come but that goes again as fast as it gets solved but...
NO, it isn't.
Example:
1 minute à 250 Hz (4 ms period) --> 15000 expected ticks.
toWait = [3700, 3980] us depending on what it is done in each tick
30% of the tests working fine, sleeping the correct toWait --> 60.000xxx execution time, 15001 ticks 
70% of the tests going wrong, because it adds 6 ms to the wait time (toWait [9700, 9950] us) and the elephanting offset remains for the whole execution --> 60.000xxx execution time, 6001 ticks
Sorry... but I had to "shout"
Thanks for "listening"
EDIT (New day, new perspective):
I have just dumped the sleep_for(toWait);.
I am now using my own check using the QueryPerformanceCounter and comparing it to the period I want to use.
So far... performing good.
If my long time performance tests are successful and I get the time to do it right... I might put a bit order, create a helper class and write an article / tip about it.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 25-Apr-19 3:30am.
|
|
|
|
|
Clearly you had the ticks handled but you forget about the tocks!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I'm not sure about what you're trying to do, nor to have understood everything in the post, but it does seem a strange way to manage timing.
I don't know what sleep_for uses as sleeping mechanism nor the plaform you are using, but if it uses the equivalent of Windows' Sleep() then I can guarantee you 250Hz are way above the system capabilities in standard configuration (you can bypass it but it is Windows' specific and I don't know the platform you're using nor what you are trying to do).
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: I'm not sure about what you're trying to do, nor to have understood everything in the post
Trying to do a dynamic polling of values from external signals.
den2k88 wrote: but if it uses the equivalent of Windows' Sleep() then I can guarantee you 250Hz are way above the system capabilities in standard configuration (you can bypass it but it is Windows' specific
I am trying to bypass it with new possibilities from c++ 11 and above
I know it probably is not the best option, but it is one I am playing with right now.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
If you want a real time operating system, you will probably have to write your own. 
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
You can be fairly precise with Windows, XP to 10, but you have to know how to do it.
Mostly you can set the global scheduling timer (not the best choice but workable on embedded systems) down to 1ms. Under 1ms forget thread sleeping and go for a busy form of waiting.
It is a soft real time but it is cost effective.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Yeah, NT had a 9.8 something ms granularity, that was the smallest wait.
You can as you say change this on later OSs, but it isnt recommended.
What I have done is to use a loop count in code (the code can work out the number to count up to to for a given time period at start up).
It is interruptible, you can set the code priority (critical section etc), and it gave quite accurate timing in the end. Of course it does depend on how much hardware activity there is that really will steal the CPU from you. But in general it was pretty good.
|
|
|
|
|
Munchies_Matt wrote: What I have done is to use a loop count in code (the code can work out the number to count up to to for a given time period at start up).
That's a powerful solution. Mine was simpler for simpler needs, it broke down the wait time in time slices and used the usual SleepEx to save CPU time, in the remainder it used a stupid loop that checked the high precision timer - after all this time slice has been assigned to my thread, might as well use it.
But the problem was simpler, I just had to prevent two data packets being sent back-to-back forcing a delay, because the target device would get FUBAR if a request would arrive while it was still processing the previous one.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: I just had to prevent two data packets being sent back-to-back forcing a delay, because the target device would get FUBAR if a request would arrive while it was still processing the previous one
Yeah, hardware can be like that! 
|
|
|
|
|
Quote: fairly precise
OK for Horseshoes and hand grenades.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
And cheap industrial systems with real time constraints but still in the "mechanical actuation" range of values  Basically horseshoes and handgrenades.
A 155mm Howitzer *is* fairly precise, after all.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
As you have discovered, this is not very accurate. A better approach is to have a recurring timer that calls your callback every TBD.
If important, you would still need to call a clock API in your callback in order to determine when it was actually called, as opposed to when it was scheduled.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Do you mean a WM_TIMER? I thought they were even less accurate.
Care to elaborate a bit?
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Thanks
I think I have found another possible alternative, see OP
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Sounds like it's really ticking you off...
|
|
|
|
|
Sander Rossel wrote: Sounds like it's really ticking you off...
more pissing me off
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
