Prev: Problem with UDP Send/Receive & xPC Target
Next: Reduce elements in a point cloud
From: Jan Houska on 21 Dec 2009 12:54
Hi John,

currently, the Real-Time Windows Target RS232 interface is unable to
accept new data in periods shorter than 2 ms. This is a known limitation
and there's work in progress to remove it. This does not directly relate
to the data throughput - if you are sending data in packets longer than
one byte, you can easily get to the full data capacity. But, if you are
sending just one byte in each sample, it is correct that you currently
cannot get higher than 500 bytes/s (not 100 bytes/s as you write).

The current solution to get faster than 2 ms sampling period has some
severe drawbacks on the overall system performance, and is not shipping
with the product yet. It is important to keep in mind that on that 486,
you had the whole CPU for your own use. On Windows, you need to let the
OS and other applications run while still maintaining real-time response
in Real-Time Windows Target. With devices where Windows strongly
interfere, like the RS232, this is not easy to do.

If you are interested in more detail and if you want to try some
preliminary versions of the higher-speed driver, please send me an e-mail.

Best Regards, Jan


John Woods wrote:
> I made a mistake in my previous post. 1/10 should be replaced by 1/100
> in my previous post. That is, we can not achieve 1/100 of the available
> capacity (11520 bytes/s).
>
> Sorry about this.
>
> John
>
>
> "John Woods" <akimgsoc(a)gmail.com> wrote in message
> <hgnk4b$s5u$1(a)fred.mathworks.com>...
>> Hi Frank,
>>
>> Thank you very much for your reply.
>> The bottleneck here is not really the hardware (the relatively slow
>> speed of rs232) but poor programming (on both Matlab and Windows
>> side). With 115200 baud (which is the standard maximum speed of the
>> com port), it is possible to achieve 11520 bytes/s "real-time"
>> transmission using 8 data + 1 start + 1 stop bit (without even using
>> the FIFOs). In fact, if I remember correctly, I was achieving this
>> data rate with an i486 running at 33 MHz. Now, I can not achieve a
>> rate faster than 100 bytes/s with a 3.2 GHz dual core i586.
>>
>> The potential "real-time" transmission rate of the serial port is not
>> really that bad at all (11520 bytes/s). However, thanks to the
>> excellent utilization of hardware resources in Matlab and Windows, we
>> can not even achieve 1/10 of that available capacity. Unfortunately,
>> buffering the data is not a solution as the communication is supposed
>> to be "real-time".
>>
>> Best regards,
>>
>> John
>>
>>
>>
>>
>> "Frank W." <yohansan(a)web.de> wrote in message
>> <hgnfnn$ml1$1(a)fred.mathworks.com>...
>> > > > I am trying to use real-time windows target to communicate with
>> another computer >through the serial port. The problem I have is that
>> the serial communication blocks of >real-time windows target do not
>> work in real-time. I am using Matlab 2007b but I have >also tried
>> Matlab 2009a and had exactly the same problem. Is there any way to fix
>> the >problem?
>> > > Hi,
>> > I would first (befoe setting up the project) calculate if the data
>> really can be transmitted in real time. Depending on the baud rate you
>> use you know the amount of bytes that can be transmitted. If this
>> value is too small either increase the baud rate and/or minimize
>> protocol data (if this is possible). If you use your own protocol
>> consider buffering data and processing unimportant tasks at a lower rate.
>> > If there is still too much data you'd have to use ethernet.
>> > Regards
>> > Frank


--

--
Jan Houska HUMUSOFT s.r.o.
houska(a)humusoft.com Pobrezni 20
http://www.humusoft.com 186 00 Praha 8
tel: ++ 420 284 011 730 Czech Republic
fax: ++ 420 284 011 740
 | 
Pages: 1
Prev: Problem with UDP Send/Receive & xPC Target
Next: Reduce elements in a point cloud