Telepathy > 512 characters with latest changes
eager
I can't seem to get more then 512 characters out in 1 tp_send() call,
the rest gets dropped....
PROC MAIN()
local x := "" ,lop
? TP_OPEN( 3 ,,, 38400, 8, "n", 1)
? TP_CTRLCTS( 3, 1 )
for lop := 1 to 100
x += replicate(ltrim(str(lop)),42)
next
? tp_send(3,x)
Thanks,
Abe
Przemysław Czerpak
Hi,
TP_SEND() without timeout parameter in one call should send as much bytes
as possible without blocking the sending process:
http://www.ousob.com/ng/telepath/ng128a3.php
so you are describing correct and expected behavior.
You always have to check number of send bytes to repeat the operation
or report an error. You cannot consider that TP_SEND() will send 1 to
20 or 100000 bytes in one call. It depends on used hardware and hardware
buffers and also software/device driver/OS and the size of software
sending buffers. In your system the send buffer size is probably 512.
best regards,
Przemek
Abe Buchinger
Thanks for your reply, and for all of it!
It definitely used to work before the recent changes.
I need to recheck again but I tried using the input/output buffersize parameter in TP_OPEN( 3 ,1024,1024, 38400, 8, "n", 1)
And a timeout in tp_send but with the same results.
Thanks,
Przemysław Czerpak
Hi Przemek,
> Thanks for your reply, and for all of it!
> It definitely used to work before the recent changes.
It's highly possible that previous implementation was not
TelePathy compatible and was always using some timeouts
on some chosen platforms.
> I need to recheck again but I tried using the input/output
> buffersize parameter in TP_OPEN( 3 ,1024,1024, 38400, 8, "n", 1)
> And a timeout in tp_send but with the same results.
The buffer size is ignored.
Unfortunately it's not portable extension and in most of OS-es
it cannot be changed and on some others like MS-Windows the
exact behavior depends on used hardware and serial port driver
and the values set by user are not obligatory.
Anyhow setting buffer size is not correct solution to avoid
problems with such code. The write operation can be interrupted
for many different reasons, i.e. when modems are used then
sometimes the speed can be strongly reduced by line noise and
such programs suddenly stop to work correctly due to timeouts
or not transmitted after previous write data still located in
the output buffer.
Programmer should always check how many bytes was written by
WRITE/SEND functions.
best regards,
Przemek
Abe Buchinger
>It's highly possible that previous implementation was not
>TelePathy compatible and was always using some timeouts
>on some chosen platforms.
In Telepathy for Clipper it just worked.
Looks like it had its own buffer & background function to feed the port. Tp_send() returned instantly did not wait until buffer was sent out.
Tp_Send returned how much did make it into the buffer.
Tp_Outfree returned the (buffer size) - (still needs to printed).
In Harbour it worked too until recent changes. (I don’t Know how, though.)
I'm not asking, but I _wish_ it would be implemented.
All the best,
Abe
Maurilio Longo
The buffers on tp_open() call were internal buffers, not hardware ones, used
by low-level tp_xxx library internals.
You could set them up to 65kB and, when calling tp_send(), if your string was
smaller than the available space inside buffer, tp_send would copy it inside
its buffer and return immediately.
It is true that if you try to tp_send() a string longer than the available
space, tp_send() copies as much as it can and returns the number of copied
chars to the caller.
tp_open() - open serial port
nError := tp_open(nPort, [nIsize], [nOsize], [nBaud], [nData],
[cParity], [nStop])
nPort Serial port number.
nIsize Input buffer size, default 1536.
nOsize Output buffer size, default 1536.
nBaud Baud rate, default 1200.
nData Number of data bits, default 8.
cParity Parity setting, default "N".
nStop Number of stop bits, default 1.
Returns Error code.
Opens a serial port. Each port must be opened before it can be used
for I/O.
nPort is the port number, from 1 to 8. Ports 1 and 2 correspond to
DOS devices COM1 and COM2. Ports 3 and 4 correspond to COM3 and
COM4, which are not standard DOS devices on most systems. Ports 5
through 8 are initially unassigned, but can be set up for nonstandard
serial ports by the tp_setport() function.
nIsize and nOsize are the sizes of the input and output buffers.
They may range from 32 to 64999 bytes. The default is 1536 (1-1/2K)
bytes for each.
nBaud, nData, cParity, and nStop are the initial baud rate, number of
data bits, parity setting, and number of stop bits. The defaults are
1200 baud, 8 data bits, "N" (no parity), and 1 stop bit.
and here tp_send
tp_send() - send string
nSent := tp_send(nPort, cString, [nTimeout])
nPort Serial port number.
cString String to send.
nTimeout Maximum wait time, in seconds.
Returns Number of characters sent.
Sends a string to the serial port.
If nTimeout is specified, waits up to nTimeout seconds to send if the
output buffer becomes full. If nTimeout is omitted or zero, sends as
much as possible and returns immediately. -1 for nTimeout waits
forever (until the string is sent, tp_idle() returns TRUE, or an
error occurs).
Best regards.
Maurilio.
--
__________
| | | |__| Maurilio Longo
|_|_|_|____| farmaconsult s.r.l.
Przemysław Czerpak
Hi,
> >It's highly possible that previous implementation was not
> >TelePathy compatible and was always using some timeouts
> >on some chosen platforms.
>
> In Telepathy for Clipper it just worked.
If you haven't checked returned value then it only means that
it used to work until something else has not happened.
> Looks like it had its own buffer & background function to feed the port.
Yes it is. The TelePath NG for tp_open() sais:
nIsize Input buffer size, default 1536.
nOsize Output buffer size, default 1536.
In current Harbour HBTPATHY implementation (just like in the previous one)
This parameter is in practice ignored and the buffer size depends on used
OS.
> Tp_send() returned instantly did not wait until buffer was sent out.
It depends on the 3-rd optional <nTimeout> Tp_send() parameter.
If is omitted or zero then tp_sends() sends as much as possible
and returns immediately, -1 means wait utill whole string is not
send and positive value is timeout in seconds.
As I can see current HBTPATHY code has to be fixed because it uses
<nTimeout> as milliseconds not seconds.
Due to side effect in the previous HBTPATHY implementation the
0 timeout was random value between 0 and 1 millisecond.
Current implementation uses timeout precisely though current harbour
low level serial port in MS-Windows sets at least 1 millisecond as
maximal total write timeout what seems to be reasonable for most of
applications. Anyhow maybe I'll eliminate this "improvement" in
the future.
In summary it means that tp_send( port, buffer ) in current HBTPATHY
implementation should not send less bytes then previous one.
If it writes only 512 byte to the port in your system then it is
probably the default buffer size.
> Tp_Send returned how much did make it into the buffer.
Yes and as I can see in new HBTPATHY code it can return -1.
It can be fixed just like the problem with <nTimeout> above
by simple modification of:
RETURN hb_comSend( t_aPorts[ nPort, TPFP_HANDLE ], cString,, nTimeout )
to:
RETURN max( 0, hb_comSend( t_aPorts[ nPort, TPFP_HANDLE ], ;
cString,, nTimeout / 1000 ) )
> Tp_Outfree returned the (buffer size) - (still needs to printed).
In previous HBTPATHY code it was implemented only for MS-Windows and OS2.
In other systems it's hard to check the size of output buffer in portable
way so I haven't implemented it in HBCOM code.
In current HBTPATHY code after updating to use HBCOM this function always
returns -1.
I'll check how many platforms can support it and maybe I'll add some
functions to check the sizes of OS IO buffers to HBCOM so it will be
possible to implement Tp_Outfree() in new HBTPATHY version at least
for few platforms.
> In Harbour it worked too until recent changes. (I don’t Know how, though.)
I do not think so. I've just checked current and old code. See above.
Both versions uses the default OS buffer sizes so nothing has changed
here. There are only some minor differences in timeout calculation and
some race conditions in previous HBTPATHY code have been eliminated.
BTW what is your OS?
> I'm not asking, but I _wish_ it would be implemented.
Setting the size of output and input buffers cannot be implemented for
all platforms because most of systems does not give such possibilities
so for sure it will never be portable extension.
Anyhow for correct code which checks values returned by tp_send*() and
tp_recv*() this is unimportant so I strongly suggest you to update the
code and forget about such problems.
best regards,
Przemek
Przemysław Czerpak
Hi,
> The buffers on tp_open() call were internal buffers, not hardware ones, used
> by low-level tp_xxx library internals.
> You could set them up to 65kB and, when calling tp_send(), if your string was
> smaller than the available space inside buffer, tp_send would copy it inside
> its buffer and return immediately.
Exactly and the problem is that we cannot set the size of input and
output buffers on most of platforms so we are accepting what OS sets
by default and these values depends on OS and used hardware with low
level device driver code, i.e. some serial devices can write directly
to memory region which has some strictly defined size and alignment,
i.e. single memory page.
> It is true that if you try to tp_send() a string longer than the available
> space, tp_send() copies as much as it can and returns the number of copied
> chars to the caller.
And probably exactly this happens in code sent by Abe, f.e. 512 bytes
as default OS output buffer size.
best regards,
Przemek