Revision: 14461
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14461&view=rev
Author: druzus
Date: 2010-05-12 00:27:04 +0000 (Wed, 12 May 2010)
Log Message:
-----------
2010-05-12 02:26 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/external/minizip/ioapi.h
! fixed FreeBSD and HAIKU builds
* harbour/src/rtl/fserr.c
* added translation for EPERM
* harbour/include/Makefile
+ harbour/include/hbapicom.h
* harbour/src/rtl/Makefile
+ harbour/src/rtl/hbcom.c
+ added Harbour multiplatform serial port C API (hb_com*() functions).
implemented code for *nixes, MS-Windows and OS2. DOS is not supported
yet. Please make test on different platforms.
; few notes about this code:
termios (*nix) based builds:
- reading LSR is not supported
- duration in break signal is fixed (at least 0.25 seconds, and not
more that 0.5 seconds)
- DTR/DSR hardware flow control is not supported
- setting error character is not supported
- discard card is supported only on few platforms
- checking input/output flow state is not supported
- if some platforms do not support some termio extensions then
compile time warnings TODO_* should be generated.
MS-Windows builds:
- discard card is not supported
OS2 builds:
- checking for input flow state is not supported
- discard card is not supported
In all builds not all RS-232 hardware flags/state are available.
OS2 build supports most of them,
This code needs to be extensively tested. I wrote it without any
serious tests. Especially OS2 builds should be verified by OS2
users. I wrote this port using only documentation which OS2 API
available in the Internet.
DOS is not supported yet though it's possible to compile termio code
for *nixes with DJGPP. Anyhow it would be very nice if we can add
our own DOS serial port code. I would like to ask if any of you
has low level serial port code in C for DOS (i.e. used with Clipper)
and can send it to us so we can use it with Harbour. I have my
own serial port library for Clipper but it's written in assembler
and it's much wider then sth what we need so it cannot be easy
adopted for Harbour.
* harbour/contrib/hbct/Makefile
+ harbour/contrib/hbct/ctcom1.c
+ harbour/contrib/hbct/ctcom.ch
+ harbour/contrib/hbct/ctcom2.c
+ added CT3 compatible COM_*() functions.
+ added CT3 compatible XMOBLOCK(), XMOCHECK(), ZEROINSERT() and
ZEROREMOVE() functions.
+ added new CT COM function:
COM_DEVNAME( <nComPort> [, <cNewName> ] ) -> <cPrevName>
which can be used to specify device name for given port in modern
systems which do not give direct hardware access for the process.
; few notes about CT3 COM_*() functions in Harbour.
In COM_OPEN() only 1-st parameter is significant, input/output buffer
sizes and trap mode parameters are ignored. In modern OS-es such
functionality is controlled by OS and usually buffered read/write
is always enabled. The sizes of IO buffers can be used only as
suggested IO buffer size for OS in some systems. It's possible that
these additional parameters will be used in DOS builds in the future.
COM_READ() does not support 2-nd parameter <lNoDelete>. It can be
implemented but because we do not have direct access to OS buffers
then we will have to emulate it ourselves what is rather inefficient.
Anyhow I can implement it if users think it's critical.
In COM_CRC() I fixed few CT3 bugs so it's not bug compatible with CT3,
i.e. it works correctly for 8 bit and smaller polynomials instead of
returning 0 or supports much larger polynomials up to 64bits.
For 16/17 bit polynomials it gives the same results as CT3 so for most
common usage it should be binary compatible with CT3.
In ZEROREMOVE() I fixed decoding some wrong CCITT strings which does
not have trailing 0 so it returns empty string "" for such corrupted
data. If someone needs original CT3 behavior for some broken code then
is can be enabled by HB_CT3_ZEROREMOVE_BUG macro.
I haven't implemented few functions.
COM_GETIO(), COM_SETIO(), COM_GETIRQ(), COM_SETIRQ() are not portable
and can be implemented only for really few platforms, i.e. for DOS
when/if we add support for serial ports to Harbour DOS builds.
Similar functionality for all other platforms gives our new function
COM_DEVNAME().
COM_KEY(), COM_SKEY() and COM_EVENT() are also not implemented.
To make them well we should add support for asynchronous events to HVM
and such extension is still unavailable. Some simulation can be
implemented using idle tasks but this can be done also by final
Harbour users so I decided to not make it.
Please test it - I've never used CT3 COM_*() API with Clipper.
* harbour/contrib/hbct/dummy.c
* removed dummy CT3 serial communication functions
; such files with dummy functions introduces very serious problems for
user code because they do not respect original module granularity
effectively breaking overloading only chosen functions so it breaks
also some real Clipper code.
Modified Paths:
--------------
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbct/Makefile
trunk/harbour/contrib/hbct/dummy.c
trunk/harbour/contrib/hbnetio/netiosrv.c
trunk/harbour/external/minizip/ioapi.h
trunk/harbour/include/Makefile
trunk/harbour/src/rtl/Makefile
trunk/harbour/src/rtl/fserr.c
Added Paths:
-----------
trunk/harbour/contrib/hbct/ctcom.ch
trunk/harbour/contrib/hbct/ctcom1.c
trunk/harbour/contrib/hbct/ctcom2.c
trunk/harbour/include/hbapicom.h
trunk/harbour/src/rtl/hbcom.c
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
