[fpc-pascal]Serial Port Programming under LINUX...

[Rainer Hantsch]

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

On Fri, 26 Apr 2002, Stefan Becker wrote:
> 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!

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

-- 
      \\|//           Ing. Rainer HANTSCH  -  Hardware + Software
      (o o)           Forget Windoze! -- We focus on L-I-N-U-X...
--oOOo-(_)-oOOo--------------------------------------------------
Ing. Rainer HANTSCH  |  e-Mail: office at hantsch.co.at
Khunngasse 21/20     |  www   : http://www.hantsch.co.at
A-1030 Vienna        |  Tel.  : ++43 - 1 - 7988538 0 
---------------------|  Fax   : ++43 - 1 - 7988538 18
** AUSTRIA **        |  Mobile: ++43 - 664 - 9194382
-----------------------------------------------------------------