seconds
than
Very definitely. We did some tests (long time ago) that suggested that 0.1s was barely acceptable, and 50ms was a realistic maximum. In the end we went with 20ms.
500ms is an age ;).Steve
Yes, 500ms is forever to respond to a keypress. They'll assume the key is flakey and press it harder, multiple times and that sort of thing.
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Absolutely. Can it be "extracted" in such a way that it maintains a minimal footprint for the next project? Absolutelty. Does this is means that the next application that reuses the "scheduling code" will work correctly? Maybe.
A "scheduler" is tool. If the programmer does not following the "owners manual", i.e. the constraints and semantics of the scheduler, than the application is simply not going work as expected (if at all). Different types of schedulers have different types of constraints. For example cooperative schedulers burden the application with "knowing" what the limits are with respect to how much time each task can consume before yeilding control of the CPU. Pre-emptive schedulers burden the application with mutual exclusion requirements when accesing shared data across tasks.
Coming back to the 'what is an RTOS?' debate, I would agree that the 'OS' part of the definition implies you must be able to extract the scheduling code from the application such that it is reusable by another application. If the scheduler is too dependent or too interwined with a specific application - it (at least for me) looses any meaning as an 'OS' - I view it as simply the scheduling policy of that application.
Mostly, I agree. That's pretty much the way I see things, out there in the rest of the world.
However (and you knew there's be one of those ;)): the distinction between "code re-use" and "generality"/"commercial OS" intrigues me. I tend to write my code so that there is a distinct OS layer, if you like - a set of services that include: - task scheduling - hardware resource access & maintenance (comms, display, keypad, I/O etc) - file/stream I/O (where appropriate) - utilities to support the above (display formatting etc) - etc etc etc
At this stage it's entirely application-independent, and much of the core is standard "in-house" stuff, re-used over and over. Is it an OS? Kinda. I do think of it as such, and that's what we call it. Occasionally I've delivered hardware with this OS layer as part of the deliverables, along with documentation to enable my customer to use it - the OS does have to be there (i.e. it's not just a set of hardware drivers) since the maintenance of the hardware resources is time-dependent and is scheduled along with everything else.
I'm probably stretching the commonly-accepted definition - but as I say, the boundaries intrigue me.
Steve
I try to be sure that some kind of feedback response is under 80ms. I have debounced and recognized the keys by 24ms at the latest, though I try to shore that up to closer to 15ms, or so.
500ms would be death. I've used equipment where some programmer did that and I wanted their heads on a platter. No excuse for it.Jon
That makes sense to me.
You can, I've run into that problem in run-time diagnostic tests watching the closing of relay contacts. The first test we used had a fixed amount of delay between changing the tips and checking to see if they had opened or closed. Technicians of course wanted to keep that as short as possible. There is a significant variation from cycle to cycle and if it was cut too short they would periodically fail diagnostics. These were in a direction changing application and so you would get two delays which made the problem worse, however you could hear the relays change and
500mS was perceptibly sluggish. I expect if responses were consistently in the 500mS range the interface would feel laboured.Robert
"Spehro Pefhany" schreef in bericht news: snipped-for-privacy@4ax.com...
seconds
than
Indeed it is. When you use a serial terminal and loose 100ms or more by sending/handshaking the commands to another piece of equipment with the actual I/O you really need to add an audible beep or lamps locally, giving some feedback that the key was pressed and reduce the effect of such frustrating behaviour.
-- Thanks, Frank. (remove 'q' and 'invalid' when replying by email)
I think they can. When one is typing quickly 500 ms can be a loooong time. The feeling can be annoying to say the least.
Well!, that was an interesting selection of responses.
I guess that the time to response "feel" of a system may depend on the type of initiation device one is using. When the initiator is a mimic icon that you click on, or a single pushbutton you press, to initiate the action then seeing the change of colour of the mimic icon or illumination of the push button's light in less than 500ms might not seem so bad.
I would agree that having to type commands at a keyboard, that took that long to determine which key of each you just pressed, would seem very sluggish. However, even here, 500ms might seem inconsequential for a response time after you hit the enter key.
Incidently, I didn't write those specs I mentioned. I just implemented them using the most appropriate techniques I could use at the time.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
I read of a study that found that users will accept anything up to about 4 sec. as a tolerable delay in getting completion of some operation and anything beyond that is "forever" and unacceptable. The study also found that the delay was not the critical item, but the variation of the delay. That is,
3.5 seconds +/- 0.5 is OK, but 4 +/- 3.9 is not.I believe it was in the same study that it was stated that
1/4 sec. is about the minimum reaction time of people.
Only indirectly. Somewhat obviously, the "felt" response time only starts to count after the moment the human operator believes to have completed the input action, and stops after he observes the status change. I.e. a mechanically soft, high-force push button switch on a machine's operator panel doesn't pose the same requirements on feedback speed as a keyboard key, esp. if the latter is a "klick" keyboard.
As a good reference of what kinds of speeds you may need, take a look at the hands of a professional musician, or a *very* fast touch typist at work. I consider myself fast, while not spectacular, yet even I can easily type in short bursts faster than around 5 letters a second. That's 200 ms per keypress, and I still usually manage to get them in the correct sequence, which means there's at least some tactile or visual feedback involved.
I've heard that some experiments regarding tactile feedback done with highly specialized personnel (fighter pilots) indicated that you may have to get the lag down to something like 1 ms before the last of them stop complaining about sluggish reponse.
-- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
I think the government put something in the water.
That may be the minimum loop time, but it's not the minimum perception time.
I suggest you imagine playing a keyboard and hearing the music that results. When playing music .25s slop would be considered more than disastrous (I play keyboard.) It would be fatal. Think about writing the software to handle an electronic piano keyboard. I don't think you'd never sell any with a .25s delay in the responses.
When I use front panel keys on an instrument (and yes, I also write the software for such instruments), 1/4 second delay between hitting a digit, let's say, and seeing that digit appear on the display is often unacceptable to me as an operator. I've test this kind of delay on myself, and it was not pleasant.
Yes, I could live with it. But I might not buy that instrument, again.
Jon
... snip ...
Some years ago I built a machine on which the keystroke was applied on the release. This had several advantages for me - I could positively identify the key in the midst of multiple keypushes, and the operator could change his mind by holding the key, pushing the correct one, releasing the key, releasing the correct one. I was expecting to get some harassment over the 'execute on release', but never did.
The machine was the firstPC - see separate thread.
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
I've done that, as well. Though one needs to think about it (or test it) before fielding the result. There are times when it is reasonable for the operator to expect some kind of change on press, not release. (Some people do kind of hold their finger on a button for a long moment -- whether or not that is common will depend on circumstances and people.)
Jon
delay
software
The cited number was for a typical case. Yours is for a particular case.
I don't consider 500ms good for _typical_ cases, ever. You would usually find me on the opposite side of the table in any discussion about a specific instrument, if you took that point of view for it. I've not yet met a front panel on an instrument where I'd tolerate a 500ms delay from key hit to digit displayed, for example.
Nor would I buy one.
But that is indeed just me.
Jon
Ever fire a flintlock rifle? :)
I just thought of a system where 500ms is too short; hand grenade.
No. Sounds interesting, though. Are they likely to use microcontrollers? ;)
I have a hunch that if they did, and if a particular one added a .5s delay to the triggering, and if I had a need for a flintlock for some reason and had a choice from among some that had much shorter delays, I'd probably not select the one with the micro offering a .5s delay.
:)
Jon
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.