H
Hendrik van Rooyen
Absolutely false.
No its true, if you open the serial port with the standard open() instead of
os.open(). And it is also true that I was not contradicted in the past.
I know this, and I started the thread because they would not work full duplexAll standard PC serial ports are full-duplex devices.
for me.
8< -------------------- pyserial baudot program link -----------------------
Actually, no. Dynamixel servos as used on the latest Bioloid robots
are multidrop serial RS-485. But outside the embedded world, nobody uses
that stuff any more. (Embedded is going Ethernet; it's overkill but
works fine and is now cheap.)
Exactly - it is no longer part of mainstream fashion. We also still use RS-485
because it is cheaper, and we have better control over timing.
I enclose two naive test implementations.
To run them you will need a loopback connector.
One can be made by shorting pin 2 and 3 together on the standard DB9.
The results are illuminating - on my development machine, (dual 64 bit, some
gigs), the last lines look like this:
test.py:
The quick brown fox jumps over the lazy dog 1023
That took 3.91238284111 seconds - 3.82068636827 Millisecs per record,
261.733077152 recs per sec
hvr@Linuxbox:~/dos/JOBS/sms/lib>
test1.py:
The quick brown fox jumps over the lazy dog 1023
That took 3.90402388573 seconds - 3.81252332591 Millisecs per record,
262.293477185 recs per sec
hvr@Linuxbox:~/dos/JOBS/sms/lib>
Almost no difference between the two implementations.
This is basically because there is enough processing power to keep the link
running at full speed in both instances.
On the eBox, (486, 400MHz, 128Mb, no FP), the difference is startling:
test.py:
The quick brown fox jumps over the lazy dog 1023
That took 69.2863521576 seconds - 67.6624532789 Millisecs per record,
14.7792453797 recs per sec
root@ebox:/home/user/sms/lib#
About eighteen times slower than the development machine.
test1.py:
The quick brown fox jumps over the lazy dog 1023
That took 10.391780138 seconds - 10.148222791 Millisecs per record,
98.5394211964 recs per sec
root@ebox:/home/user/sms/lib#
Less than three times slower than the development machine.
The little processor + Slackware + python cannot keep the link busy.
Python, as a character handler, well let us say that it is suboptimal,
because saying that something sucks, sucks.
An almost seven times ratio between the implementations is not to be sneezed
at.
So the conclusions I have come to are the following:
1) Thou shalt not use ordinary python files for serial ports, on pain of
death.
2) Thou shalt strive mightily to minimize python calls, doing all in thy
power to move away from character input to string input.
3) Thou shalt expend real treasure for real processing power as there is no
such thing as a free lunch.
I would like to thank everybody who took the trouble to respond to teach me
the error of my ways.
- Hendrik