Hello, all!

I do really hope that there is somebody here who has real EXPERIENCE with programming serial communications in FPC and for Linux. - I am totally unhappy because I find no WORKING solution for this. Please, if you can help, leave me a message. -- THANKS!

What I had in the past:
-----------------------
When I was programming in TP/BP for DOS, I used the FOSSIL/X00 TSR-driver to communicate with serial devices. This TSR driver did all low level stuff for me, including a ring buffer, handshaking (both, XON/XOFF and/or RTS/CTS), ..., so I only had to write a relatively simple unit, to make "Fossil" more user friendly.
With this simple task I had the possibility to send/receive _buffered_, flush/purge the buffer contents, rise/lower DTR, ask if chars were received _without_ actually reading them in,... -- EXCELLENT.

What I am looking for:
----------------------
Since my change to Linux and FreePascal, I am really unhappy because there seems to be nothing similar available here. Well, There are some units available for FPC, but most of them are for DOS or WIN32. The only one which appears to be very useful, is OBJCOM.
But this unit has an unacceptable BUG inside: It stops any further communication when the DCD is dropped by the modem when the connection breaks. It seems that this causes a total loss of the internal file handle! Sadly to say, but it appears as if nobody is working on this ObjCOM any longer, including M.Kiesel who contributed ObjCom, so this appears to be a dead end...

If somebody has a unit which works with FOSSIL (DOS), WIN32 *AND* LINUX and gives me an acceptable control to the data communication, I will be happy to know about that, even if this is a commercial unit.

Thanks in advance,

mfg

Ing. Rainer Hantsch

hello Rainer,

Well, There are some units available for FPC, but most of them are for DOS or WIN32. The only one

which

appears to be very useful, is OBJCOM. But this unit has an unacceptable BUG inside: It stops any further communication when the DCD is dropped by the modem when the connection breaks. It seems that this causes a total loss of the internal file

handle!

Sadly to say, but it appears as if nobody is working on this ObjCOM any longer, including M.Kiesel who contributed ObjCom, so this appears to be a dead end...

May i suggest using EleCOM? I am not aware of any of such bugs in EleCOM itself, unless i do not understand you correctly.
http://www.elebbs.com/

If somebody has a unit which works with FOSSIL (DOS), WIN32 *AND* LINUX

and

gives me an acceptable control to the data communication, I will be happy

to

know about that, even if this is a commercial unit.

EleCOM does not do Linux.

groeten, Maarten.

Hi,
I don't know if there is a fossile interface (unit) for linux but Brad Campbell's () unit helped me
alot.
I put it on http://home.t-online.de/home/yukonho/seriell.pp

Stefan

Thanks!

I had a look on this code right now, but I am afraid that this code will not supply me a buffered input. (I mean: If I currently do NOT read the arriving data, the data must be buffered in some kind of FIFO, and I must be able to check if there are characters available before(!) doing a read operation. (important, because otherwise my program will hang until something comes in!)

Is this done with this code?

mfg

Ing. Rainer Hantsch

Hi again,
what are you doing with the seriel port? If it's something like modem communications or Terminal then just let the operating system do the work and "talk" to the device through STD IN/OUT. I rewrote one program that was a terminal driver and now I just use /usr/sbin/mgetty to do the work!

Now a real question for the linux programmers:

I use and open the device using : "fdOpen('/dev/ttyS0'....);"

reading the device with: "FD_SET (PortHdl,FDS);"
and "Select(PortHdl+1,@FDS, nil, nil, 50);"
and "FD_ISSET(PortHdl,FDS) and
"fdRead(PortHdl,TermInStr[1],sizeof(TermInStr)-1); (see examples below)

I would say that the operating system would be doing all then I/O buffering? Is this correct? Or would I loss charater input from the device /dev/ttyS0 if
there would be more then 16 char (whatever the hardware UART holds) waiting?

I POLL my input procedure fairly infrequently and have never lost any seriell input that
I know of!

to you knowledgable linux Gurus...
my regards,

Stefan

EXAMPLES:

function StartInput:boolean;
const
 ScalePort = '/dev/ttyS0'; {S0 = com1 S1 = com2}
begin
StartInput:=false;
 PortHdl:=fdOpen(ScalePort,Open_RdWr or  Open_NonBlock or Open_Excl);
if PortHdl>0 then
begin
  {Attempt to Lock the port, I'm not sure this is strictly nessecary}
  FLock(PortHdl,LOCK_EX);
  IOCtl(PortHdl,TCGETS,@tios);
   tios.c_cflag := B2400 or CS8 Or CREAD Or CLOCAL;
   tios.c_lflag := 0;
   tios.c_oflag := 0;
   tios.c_iflag := IGNPAR;
   IOCtl(PortHdl,TCSETS,@tios);
   DtrOn;
   RS485RX;
  StartInput:=true;
end;
end;
procedure ScaleInput;
begin
  FD_Zero (FDS);                 {Clear File Descriptors Array}
  FD_SET (PortHdl,FDS);    {Input from Serial Port}
                          {index+1   Readfds,Writefds,exceptfds,TimeOut_ms}
                          {Will Wait 50ms or input from above}
 InAct:=Select(PortHdl+1,@FDS,   nil,     nil,      50);
 if InAct= -1 then
 begin
  WriteLn('Error in "Select"',LinuxError);
  TagQuit:=true;
 end else
 begin
 if InAct>0 then
 begin
   if FD_ISSET(PortHdl,FDS) then         {Have we data waiting in UART ? }
   begin
    InLen:=fdRead(PortHdl,TermInStr[1],sizeof(TermInStr)-1);
    if InLen>0 then
    begin
     for Loop:=1 to Inlen do
     begin
      poin:= (ord(TermInStr[Loop]) and $7F);
      case poin of
       10:begin
           do_StrIsIn;
           inScaleStr:="'';
           end;
       13:begin
            end;
      else
        InScaleStr:=InScaleStr+chr(poin);
      end;
      end; {case}
     end;
    end;
 end; {no input}
 end; {no error}
end;

Thanks! I had a look on this code right now, but I am afraid that this code will

not

supply me a buffered input. (I mean: If I currently do NOT read the

arriving

data, the data must be buffered in some kind of FIFO, and I must be able to check if there are characters available before(!) doing a read operation. (important, because otherwise my program will hang until something comes

in!)

with

> >programming serial communications in FPC and for Linux. - I am totally > unhappy > >because I find no WORKING solution for this. Please, if you can help,

leave

TSR-driver

more

> >user friendly. > >With this simple task I had the possibility to send/receive _buffered_, > >flush/purge the buffer contents, rise/lower DTR, ask if chars were

received

there

handle!

> >Sadly to say, but it appears as if nobody is working on this ObjCOM any > >longer, including M.Kiesel who contributed ObjCom, so this appears to be

a

> >dead end... > > > > > >If somebody has a unit which works with FOSSIL (DOS), WIN32 *AND* LINUX

and

> >gives me an acceptable control to the data communication, I will be

happy

Hello!
Here some more detailled information about what I want to do with serial communication...

Well, I am afraid that this is a completely different thing, because I am orginating the communications rather than being passive and being called from remote...
I want to communicate to/with Microcontrollers at a very low level. This means that I "mis-use" DTR as an "Attention" line.
This is an easy "Packet protocol": I lower DTR for some time (roughly 1/2 second now) to give all external PIC(s) enough time to complete their current task and enter a "communication mode", After rising DTR again, I send out the data (this are some bytes only, but full 8 Bit!) immediately and receive then the answer.
This happens at a relatively low data rate of 1200-2400 bps, but it is timing sensitive, because the PICs have absolutely no data buffering. So I must give them even between particular bytes enough time to process them!

Also, a friend of me wants to port his self developed Microcontroller Programming System (he developed a complete PIC programming tool with compiler, debugger,m programmer,...) from DOS to Windows and Linux. With ObjCOM this would be the best choice, because it is cross platform. But it is BUGGY. He has nearely the same problems because he did all that in DOS with direct UART access...

What I am looking for is:
-------------------------
FOSSIL (as an example) was surely developed primarily for running the OPUS and/or MAXIMUS BBS. But it had such a great design that it can be used for nearely EVERY purpose, because you have full control over the serial port, can choose mearely everything, and then simply read and write from/to this port with two simple procedures, but there is always FOSSIL invoked which does the basic things by itself, so you do not have to work at this low level at all...

ObjCOM appears to be a logical next step. It is, what FOSSIL was at DOS time: Some kind of "Super-FOSSIL"; it implements "low level drivers" for DOS (Fossil), Windoze, and LINUX. All this drivers are covered by a common object, so you do not have to change even one line inside your program when moving between Linux and DOS/Windows. - It was primarily written for EleBBS, if I understood right.
-> Sounds perfectly, but there is a bug inside which I cannot locate, so it is currently USELESS at all. :-/

If somebody is out who is able to locate the bug (I think I found the weak point, but I am not familiar enough with Linux internals to be sure...) I will be happy to get help.

mfg

Ing. Rainer Hantsch

The example code you looked at is used to do exactly that.. I use it to talk to pics at 38400 baud and I can recieve a message and turn it around in less than 10mSec (I modify the kernel HZ value to 400) If you open the port in non-blocking mode then you can simply do a recv on the port and if you get 0 bytes there is no data for you. OR, you can open in blocking mode and ask for x bytes and it will hang up waiting for that data to arrive.
I do a select() on the port and it sits there and waits for some data to arrive. I use multiple ports in the select to allow me to do many things while waiting for the data.. It's very easy if you think about it a little.

In fact, I used to poll my remotes. Now I have an RS232-RS485 interface that self times TX and also set's RTS to indicate bus busy, I now talk to many devices in a "collision bus" type of setup and can return messages in less than 10mSec. My Pics have a retry timer of 100mSec and I have never failed to turn around a message in this time. Even on a 386SX25.

For your application do this..
Set DTR
Delay 1/2 Sec
Unset DTR
Send Data
RXDataLength = 0
TimeOut = False
While (RXDataLength < Wanted) and (Not Timeout) do Data := Data + Recieve(Port,GotLength)
RXDataLength := RXDataLength + GotLength
Check For Timeout() <-- use system msec timer or something Done

Here you either have the data you want or it has timed out.. Clear as mud ?

If you have to pace the data going to the pics.. then send it a byte at a time with a delay in a loop.. Easy..

hi,

ObjCOM appears to be a logical next step. It is, what FOSSIL was at DOS time: Some kind of "Super-FOSSIL"; it implements "low level drivers"

for

DOS (Fossil), Windoze, and LINUX. All this drivers are covered by a common object, so you do not have to change even one line inside your program

when

moving between Linux and DOS/Windows. - It was primarily written for

EleBBS,

if I understood right. -> Sounds perfectly, but there is a bug inside which I cannot locate, so

it

is currently USELESS at all. :-/

ObjCom is not primarily written for EleBBS. ObjCom (originally) is based on EleCOM - EleCOM is written for EleBBS. ObjCom is done for OpenXP - a Fidonet mailer. I develop EleCOM - where parts - mainly the tcp/ip routines - are also based upon previous work by others.

You seem to describe this bug in an earlier message as:

But this unit has an unacceptable BUG inside: It stops any further communication when the DCD is dropped by the modem when the connection breaks. It seems that this causes a total loss of the internal file handle!

You also describe that you need both Win32, DOS and Linux communications in an earlier message, if i recall. You do not, however, specify under which platform this bug occurs.

The Win32 routines of EleCOM indeed will not talk to the comport if no carrier is detected, to prevent it from hanging on a dropped user. You can easily fix this by either changing com_SendBlock and com_ReadBlock which looks something like: