'real time' issues

[Leisha Wharfield]

So your advice is to stick with the serial port? Thanks for the 
wikipedia link.

Leisha

Paul Gr wrote:

>
> hello Leisha,
>
> A small note on ‘real time’ issues:
>
> Since marketing people like to use ‘sexy’ words to promote additional 
> functionality or suggest superior specifications, we have to be a bit 
> careful how to interpret the words ‘real time’ correctly. The actual 
> meaning depends on the context: Most hardware and software engineers 
> use the words ‘real time’ to indicate that the time allowed to execute 
> some kind of operation is limited to a known maximum. Some engineers 
> also differentiate between so called hard and soft real time. In hard 
> real time systems it is an absolute system failure if the real time 
> criteria are not met. (Ie. the air bag in a car is definitely a hard 
> real time system.) In soft real time systems the real time criteria 
> are less strict. This is the case with EPrime where it is sufficient 
> to keep track of such timing failures. (See also 
> http://en.wikipedia.org/wiki/Real_time) Anyway, this kind of real time 
> is about the response time limits of a system, not its execution speed 
> or bandwidth.
>
> Real time streaming media protocols on the other hand, are said to 
> play media in ‘real time’ when it is possible to play the media stream 
> at the correct speed (ie. not in slow motion.) So, in this case 
> marketing people and engineers refer to the large bandwidth or 
> execution speed of the system, not maximum response latency. In other 
> words: even though Firewire and USB standards support large 
> bandwidths, this does not mean that they support short (<1ms) 
> transmission delays. Furthermore, the complex protocol stacks that are 
> used to implement those communication systems make it almost 
> impossible to realize short latencies. But even if you are willing to 
> accept timing errors, it is not very trivial to develop hardware that 
> connects through USB or Firewire. RS232 and parallel ports are much 
> easier to use in both hard- and software.
>
> There are some real time systems that use another common connection 
> between de external hardware and the computer: Ethernet. A (dedicated) 
> Ethernet connection supports high bandwidth and short transmission 
> latencies. However, as with USB and Firewire, it is not very easy to 
> develop hard- and software for such a connection. (Note that PST 
> writes it will support some kind of Network Socket Device in version 2.)
>
> Paul Groot
>
>
>
>> From: Leisha Wharfield <leisha at decisionresearch.org>
>> To: Alison Wright <alison.wright at kcl.ac.uk>, 'E-Prime' 
>> <eprime at mail.talkbank.org>
>> Subject: Laptop replies + new issue #5
>> Date: Thu, 05 Jan 2006 10:33:00 -0800
>>
> ...
>
>>
>> 5. A final issue to add: We use input devices that were made for our 
>> RT experiments. They are large switches or buttons, one for each 
>> hand, that can be pushed easily and give a solid clicking sound. They 
>> are wired into a serial device because when we began this series of 
>> RT computer experiments, we were told that the serial port was the 
>> cleanest, quickest way to get to the processor and we are measuring 
>> very fine time differences. Now serial ports are hard to come by on 
>> laptops, and when I read about new laptop connectors I find that the 
>> now-standard FireWire IEEE 1394 is a port that was designed for using 
>> a computer in "real time," that is, to play 3D games or to interact 
>> with streaming video. Wouldn't this now be the best port for 
>> measuring very fine time differences? Or is serial still the best way 
>> to go?
>>
>> I'll post another synopsis of replies received.
>>
>> Thanks for all your help.
>>
>> Leisha
>>
>
>
>

-- 
"Billions and billions."

   And it wasn't written, it appeared spontaneously with a big bang.
   And God said, "Let them eat archaic."
   And God looked on it, and said, "MMMmmmmmm... /sprinkles/!" 

   Dennis M. Hammes