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) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour