Hello,

I decided to port a DOS program (written in BP7) to Linux, because it becomes hard and harder to maintain it since I completely changed to Linux. Because this program actually controls my central heating, this is a good project for summer time, where I have no pressure to get it uninterrupted working.

To give some overview:
This program uses a TSR driver named "FOSSIL", driver name X00.SYS, which actually does the whole low-level stuff and has some very smart features built in, like:
- supporting up to 8 serial ports (in DOS !!!)
- having big buffers for sending and receiving
- allowing me to transfer particuar characters or a whole block of data into or from the buffer
- allowing me to test how many bytes are in every buffer and how much space is free (before doing a block transfer)
- allowing me to set easily communication parameters like baud-rate, parity, num of start-/stopbits, kind of handshaking, ...
- allowing me to flush buffers (erases all content of the Tx or Rx buffer)
- directly control and test control lines (rise/lower DTR, RING, ...)

Actually, this X00 driver was written for BBS systems with analog modems around 1970-1980, namely for MAXIMUS and OPUS. This BBS programs were the best ones at their time as far as I can remember, of course, at that time there was no real Internet available to the public. ;-)

So I took this driver, because it made my life easy: Actually I didn't have to do much more than loading the TSR (here I could pass some parameters to it, i.e. how many serial ports - and which ports - it should take over, then I simply loaded my program.
My program was talking through a SW-Interrupt with the X00 driver, tested its presence, and was then able to exchange data smoothly at any desired speed. Perfect for me.

Michael Van Kanneyt told me a few days ago that there is some sort of TSerial available, but he has no details at hands, because he didn't use it. But he mentioned that some people are using it.

Can somebody, please, give me more details on TSerial, what it can (not) do, maybe a little "hello world" using it, and so forth? I definitely need buffering and the possibility to empty a buffer, test if it is empty (=everything was/is sent), and to see its content (how much is currently inside, to see if dataflow is actually happening or not). Of course, everything must work non-blocking.

Please, be so kind and help. I have a book about FreePascal (from Michael), but this book is too old and does not cover all the new functions of FreePascal, so it is somewhat problematic to me, because I write programs without an IDE and/or Lazarus.

mfg

Ing. Rainer Hantsch

FOSSIL didn't appear on the scene until 1986-87. :)

I'm not sure how you'd go about performing interrupt driven serial I/O under Linux, but I can't imagine it's that difficult.

There is a BBS program called EleBBS that is written with FPC and works under Linux. You might want to dig up a copy and see how he did the serial I/O routines for the BBS.

g.

There is also an actively developed BBS package called mbse that includes all source code that includes interfacing to modems after mgetty receives the call (also with source code). Note that these are written in C.

V.

On Mon, 25 Feb 2008, Gene Buckle wrote:

| > Actually, this X00 driver was written for BBS systems with analog modems | > around 1970-1980, namely for MAXIMUS and OPUS. This BBS programs were the | > best
| > ones at their time as far as I can remember, of course, at that time there | > was
| > no real Internet available to the public. ;-)
| >
| FOSSIL didn't appear on the scene until 1986-87. :)

Oh! I thought this was longer ago ... Though, it is still long ago. :-D

| I'm not sure how you'd go about performing interrupt driven serial I/O under | Linux, but I can't imagine it's that difficult.
|
| There is a BBS program called EleBBS that is written with FPC and works under | Linux. You might want to dig up a copy and see how he did the serial I/O | routines for the BBS.

I guess you totally mis-understood my question, or I explained wrongly what I want.

1. I do NOT want to run a BBS. I want to port the control software of my central heating (I developed, programmed and built the whole control- and regulation system (hardware and software) by myself in 1998. I use microcontrollers in my house (in room sensors, at the heater, ...) and they get their commands from a central software, currently running on DOS and using the FOSSIL-driver for serial I/O.
That is, what I wanted to explain to show a little bit of the back- ground.

2. I want to port the central software to Linux because this allows me to easily control it from my office then, while this is problematic with DOS, because it does not really talk TCP/IP, is not multitasking, and also doesn't support telnet, so I would have much more work when I want to proceed with DOS. No, such things should be done by the opera- ting system, and here is Linux really perfect.

3. I will prefer to simply open a /dev/ttyXX from my central software and talk to my controllers then. If this is interrupt driven or not, I do not really (want to) care about.
I expect that an Operating System like Linux will be able to give me that functionality and does all this low level stuff by itself?

I only want to use sme kind of API, Class, Object or set of procedures which allows me similar things as were possible with the FOSSIL driver:
- Buffered I/O
- Flow Control as I need (RTS/CTS, XON/XOFF, Both, None)
- Direct Control of control lines like DTR, ...
- Possibilities for monitoring fill level of buffers, to force them to be erased (made empty), ...

Actually, I only asked for point 3, nothing else, and if tSerial of FreePascal is able to give me that on LINUX. I never will touch Windows (because I want to make my life easier, not harder), nor do I want to continue with DOS (see points 1+2 of above). ;-)

Hope this clears a bit what I actually want.

mfg

Ing. Rainer Hantsch

| There is also an actively developed BBS package called mbse that includes all | source code that includes interfacing to modems after mgetty receives the | call (also with source code). Note that these are written in C.

Well, I assumed that FreePascal will have some sort of unit with such functionality, so all I have to do is adding something to the "uses" part and then call some procedures/functions?

Actually, I must say that I do not really want to "reinvent the wheel" if something is already existing, therefore I ask first.

mfg

Ing. Rainer Hantsch

You could take a look to Synaser ... find it on google!

Horacio

On Mon, 25 Feb 2008 17:30:52 +0100 (CET), Rainer Hantsch wrote

Have a look at unit serial. The interface can be seen here:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/unix/serial.pp?view=markup

this is an older utility unit that isn't used much, and there is no docs. Maybe there are examples somewhere, but I don't know much about it yet.

Please let me know your results. I want to play with a serial link to a microchip embedded board in the (hopefully near) future myself.

The idea was that you grab a copy of EleBBS and strip the serial code out for your own uses, NOT run a BBS on it. It is an example of serial port access in Linux that may or may not work for you, simple as that.

g.

Hi!

In Linux you simply open() the /dev/ttySxx device and then read() and write() to it. This is for data, for other stuff (e.g. flow control, ...) can be done via ioctl() (please excuse the C syntax). But as Horacio already said you probably go better with a wrapper, e.g. Synaser or TSerial (but I didn't use either).

Your second problem could be to find suitable Linux drivers for your special multiport-RS232 hardware. But I assume you already got it working.

Bye
Hansi

On Mon, 25 Feb 2008, Johann Glaser wrote:

| > I only want to use sme kind of API, Class, Object or set of procedures | > which allows me similar things as were possible with the FOSSIL | > driver:
| > - Buffered I/O
| > - Flow Control as I need (RTS/CTS, XON/XOFF, Both, None) | > - Direct Control of control lines like DTR, ... | > - Possibilities for monitoring fill level of buffers, to force | > them to be erased (made empty), ...
|
| In Linux you simply open() the /dev/ttySxx device and then read() and | write() to it. This is for data, for other stuff (e.g. flow | control, ...) can be done via ioctl() (please excuse the C syntax). But | as Horacio already said you probably go better with a wrapper, e.g. | Synaser or TSerial (but I didn't use either).

As far as I could find out some years ago, the /dev/ttySxx are having no buffer. I did first steps with writing a unit which gives me some interface similar to that what I used for FOSSIL, but I always had blocking writes. I had to loop and wait, until the last char was sent. Well this is not such problematic in Unix because I can run that part as daemon and de-couple things a bit this way, but it is still unnecessarily complicated.

I cannot build a text string (as an example), write it to the buffer with an immediate return, and do other things while data are sent/received. -- At least I didn't get that working 10 years ago, so I gave finally up and took DOS, because I had to get my heating running, because winter was close, and FOSSIL allowed that. So this temporary solution is meanwhile running 10 years.

Some wrapper will surely be still required, because not very much will have changed at ttyS's. Is there some documentation about tSerial available?

"Luca Olivetti" mentioned SynaSer. I had a short look on the web site he pointed me to, but the first thing I read is: "This is library for blocking communication on serial ports. It is non-visual class as in Synapse, and programmer interface is very similar to Synapse..." --> "BLOCKING" is the magic word which is the problem. :-(

I see, I will have to do it by hands, writing a daemon by myself. I thought that FreePascal will possibly have such features built in meanwhile.

| Your second problem could be to find suitable Linux drivers for your | special multiport-RS232 hardware. But I assume you already got it | working.

Well, I run my self-invented bus protocol on one serial port. All microcontrollers (Microchip PIC) are sitting on a serial bus with opto-isolators, spread across my house, and each one has an address and can therefore be addressed precisely. So I can read the room temperatures and adjust the temperature of the central heating, position of mixers,... And I only need one (serial) bus/port with 5 wires for that. :-D

But you are right, this part is no problem and approved since meanwhile 10 years. (I wonder how quick time is running...)

mfg

Ing. Rainer Hantsch

Hi, Gene,

this unit is really old, but good. I used it first time on SuSE 5.1 on a really ancient FreePascal version. But I must say, it simply worked. =D

The only problem is that it is running without buffers and all this fancy stuff which FOSSIL had, and at that time I was a novice on Linux. But if you are interested in, I can search for my wrapper I wrote at that time, It made life a little bit easier to me.

Yes, Microchip is a good choice. I love this PICs. And if you wish, buy MikroPascal (http://www.mikroe.com), this is a fully featured PASCAL COMPILER (!!!) which creates code for PICs! -- Really excellent.

have a look on my web site, you can see there a prototype of a handheld data recorder I built. It consumes - including the SD-CARD - 2-3mA only, so you can imagine how long it runs with one battery. (http://www.hantsch.co.at then choose -> Entwicklungen on the left. But everything is in German language...)

mfg

Ing. Rainer Hantsch

Actually, I must say that I do not really want to "reinvent the wheel" if something is already existing, therefore I ask first.

Take a look at synaser (available at the
synapse page http://www.ararat.cz/synapse/).
I'm succesfully using it in a program that works unattended 24 hours a day so I can say it's quite reliable.

Bye

Yes, I usually put the communication in its own thread.

Bye

[...]

As far as I could find out some years ago, the /dev/ttySxx are having no buffer.

I think that is a matter of your OS and maybe a question of port settings, but I'm not really sure. ;)

--> "BLOCKING" is the magic word which is the problem. :-(

That problem is easily solved. I'm only using serial.pp for reading a dumb and slow dmm, but in principle (on FreeBSD):

fCom := fpOpen('/dev/cuaa0', O_RDWR OR O_NOCTTY );//OR O_NONBLOCK);

See the commented tail of that line? Linux must have something similar (IMHO). That way you can switch to the expected behaviour.

After opening some settings need to be done:

	tios: termios;
begin
	fillchar(tios, sizeof(tios), #0);
	tios.c_ispeed := B1200;
	tios.c_ospeed := B1200;
	tios.c_cflag := CREAD or CLOCAL or CS7 or CSTOPB;
	tios.c_oflag := 0;
	tios.c_iflag := IGNBRK OR IGNPAR;
	tios.c_lflag := 0;
	r := tcsetattr(fCom, TCSANOW, tios);

All of that could be done using:

	SerSetParams(fCom, 1200, 7, NoneParity, 2, []);

but for me that did not set all I needed, though I don't remember what was missing.

And for controlling the lines you can do sth. lke:

	SerSetRTS(fCom, FALSE);

and the same for other lines. Look into the serial unit and also the tios unit. On FreeBSD termios(4) has a lot of information (and it states every line has an input queue aka buffer).

HTH,
Marc