Ada way to read/write to character file

Ada way to read/write to character file

[Michael Bode]

Hi,

I'm wondering if there is an Ada way (i.e. standard package) to read
and write to a character mode (sequential) file like the COM?:
resp. /dev/ttyS? interface. Ada.Text_IO has no read/write file mode
and with GNAT I wasn't able to connect two File_Type variables to the
same physical file at the same time. 

I want to communicate with a device hanging on the RS232 port. I have
to write to the device and read the answers. I could of course do it
like open, write, close, open read, close, open,... But I think this
is not very elegant. I just finished doing it with the Win32
resp. POSIX API functions, but I'm still wondering if it could be done
with some standard Ada package.

Re: Ada way to read/write to character file

[Alfred Hilscher]

Hi Michael,

I think it's because Text_IO is designed for sequential files where it
does not make sense to switch between reading and writing. For what you
want do you should use "Direct_IO" which provides an open mode
"Inout_file". 

e.g. package Com_IO is new Direct_IO (Character); -- hope this works as
intended


Michael Bode wrote:
> 
> Hi,
> 
> I'm wondering if there is an Ada way (i.e. standard package) to read
> and write to a character mode (sequential) file like the COM?:
> resp. /dev/ttyS? interface. Ada.Text_IO has no read/write file mode
> and with GNAT I wasn't able to connect two File_Type variables to the
> same physical file at the same time.
> 
> I want to communicate with a device hanging on the RS232 port. I have
> to write to the device and read the answers. I could of course do it
> like open, write, close, open read, close, open,... But I think this
> is not very elegant. I just finished doing it with the Win32
> resp. POSIX API functions, but I'm still wondering if it could be done
> with some standard Ada package.

Re: Ada way to read/write to character file

[Nick Roberts]

"Alfred Hilscher" <Alfred.Hilscher@icn.siemens.de> wrote in message
news:3C39BB2B.57F2BB3D@icn.siemens.de...

> I think it's because Text_IO is designed for sequential files where it
> does not make sense to switch between reading and writing. For what you
> want do you should use "Direct_IO" which provides an open mode
> "Inout_file".
>
> e.g. package Com_IO is new Direct_IO (Character); -- hope this works as
> intended

No, no, no! This won't vaguely work. Michael wants to use a serial device
for (bidirectional) sequential text I/O. Ada.Direct_IO is for random binary
file access (totally different!).

> Michael Bode wrote:
> >
> > Hi,
> >
> > I'm wondering if there is an Ada way (i.e. standard package) to read
> > and write to a character mode (sequential) file like the COM?:
> > resp. /dev/ttyS? interface. Ada.Text_IO has no read/write file mode
> > and with GNAT I wasn't able to connect two File_Type variables to the
> > same physical file at the same time.
> >
> > I want to communicate with a device hanging on the RS232 port. I have
> > to write to the device and read the answers. I could of course do it
> > like open, write, close, open read, close, open,... But I think this
> > is not very elegant. I just finished doing it with the Win32
> > resp. POSIX API functions, but I'm still wondering if it could be done
> > with some standard Ada package.

I think the answer to this question is, unfortunately, "No".

Personally, if I were writing an Ada.Text_IO implementation for MS-DOS (or
Windows) or an *n[iu]x, I would have made damn sure it could be used
(bidirectionally) with the character devices, but there's nothing (and there
could not sensibly have been anything) in the RM95 compelling any
implementation to do so.

--
Best wishes,
Nick Roberts

Re: Ada way to read/write to character file

[tmoran]

>Michael wants to use a serial device for (bidirectional) sequential text I/O.
>...
>> > I want to communicate with a device hanging on the RS232 port. I have
>> > to write to the device and read the answers.
>made damn sure it could be used (bidirectionally) with the character devices,
  Given timing, error conditions, dropped lines, and the likelihood of
non-text data, I wonder how often you would actually want to do
"sequential text I/O" on an RS232 port.  There's also the question of
where do you specify parity & baud rate.  It's not hard to write a
package to do buffered input and output, though it varies quite a lot
across OSes.  It may also be that the compiler vendor has supplied one
solution.

Re: Ada way to read/write to character file

[Michael Bode]

tmoran@acm.org writes:

>   Given timing, error conditions, dropped lines, and the likelihood of
> non-text data, I wonder how often you would actually want to do
> "sequential text I/O" on an RS232 port. 

There are all kinds of devices that are controlled by text commands
over RS232. I currently have on my table (in the lab) a pyrometer, a
temperature controller (home made), drives for optical tables, a drive
for a linear axis, 2 CCTV cameras and a scope. So I guess I will have to
do that quite often :-).

> There's also the question of
> where do you specify parity & baud rate.

Since this has to be done only once at program start one could simply
execute something like "stty -F /dev/ttyS0 ..." or "mode com1
...". Using the proper API functions is a bit more work but
better. Esp. with Windows 2k I could not get the communication to work
when I set the COM1 parameters with mode and then started my
program. Windows 98 was fine, Linux too. Timeout values have to be set
from API functions anyway. That way I discoverd the Win32 bindings
that come with gnat 3.13p are a bit old, Microsoft has changed the
definiton of the COMM_DCB struct, but the old one still works too.

Re: Ada way to read/write to character file

[Nick Roberts]

<tmoran@acm.org> wrote in message news:IGN_7.9654$762.80315@rwcrnsc54...

> Given timing, error conditions, dropped lines, and the likelihood
> of non-text data, I wonder how often you would actually want to
> do "sequential text I/O" on an RS232 port.

Timing typically turns out not to be a major problem in most cases. In Ada
95, you can always use an ATC time-out to limit a wait. Typically, in the
case of a dropped line, the user resets (or re-runs) the program. Error
conditions simply cause dropped characters; dropped characters can happen
with files anyway (e.g. the typist mistypes something), and Ada programs can
and should deal with this situation in an appropriate way. In the case of
bidirectional I/O with a device, it will often be possible for the program
to detect a (syntax) error in received data, and remedy the problem by
requesting a resend.

Binary (non-text) data (popping up in amongst text data) is not very likely.
Usually, if you have a character device connected to your port, it will not
send or require binary data without being specifically told to do so. Most
(admittedly not all) character devices will never (need to) send or be sent
binary data. If the implementation (and the underlying OS) can deal with
character I/O of all the characters coded 0 to 255, it may be possible to do
binary I/O this way (albeit a nasty way). Since, in Ada 95, you can obtain
the underlying stream of an open text file, this -- or the direct use of
Ada.Streams.Stream_IO -- could be another (better) way to do serial binary
I/O.

Finally, both MS-DOS and the Unixen have all manner of sequential character
'devices' which are not actually serial communications devices (or devices
at all).

It is true that the Ada.Text_IO interface will sometimes be inadequate for
character device I/O, but only sometimes. Things like line and page numbers
might not work properly or meaningfully (but can generally be ignored
anyway). It might be necessary to do a lot of Flushing (but the equivalent
of this is generally necessary for device I/O anyway). (The lack of a
standard Flush was an annoying problem in Ada 83.)

> There's also the question of where do you specify parity & baud rate.

In the 'Form' parameter of the 'Open' procedure, if necessary. An
alternative can be an environment variable, or a system program/function
invoked before the Ada program.

> It's not hard to write a package to do buffered input and output,
> though it varies quite a lot across OSes.

Buffered input and output is usually required in the implementation of
Ada.Text_IO anyway, for ordinary files as well as devices. Thus it makes
sense for the device I/O to be implemented in the same place as the file
I/O, so that the buffering part (at the least) can be shared.

> It may also be that the compiler vendor has supplied one solution.

But this will be non-standard. The whole question was of having a standard
way of doing it.

--
Best wishes,
Nick Roberts

Re: Ada way to read/write to character file

[Ted Dennison]

In article <a1hc2t$qo9j3$2@ID-25716.news.dfncis.de>, Nick Roberts says...
>Timing typically turns out not to be a major problem in most cases. In Ada
>95, you can always use an ATC time-out to limit a wait. Typically, in the

Not when its an OS wait. Compiler writers *could* make that work, but they don't
have to.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Ada way to read/write to character file

[Georg Bauhaus]

Michael Bode <m.g.bode@web.de> wrote:
: tmoran@acm.org writes:
:>   Given timing, error conditions, dropped lines, and the likelihood of
:> non-text data, I wonder how often you would actually want to do
:> "sequential text I/O" on an RS232 port. 
: 
: ...
: for a linear axis, 2 CCTV cameras and a scope. So I guess I will have to
: do that quite often :-).

The point is, I think, that Text_I/O is for text, where text refers
to the Ada notion of text, which includes lines, columns, pages and
what not; all of these give special meaning to some Character values
that you might not want to be that special for your devices.

So, when 0S services are called for, call the OS. Some package
producers have sets of subprograms to make things easier. If you
dig the archives for RS232/COM and Ada...

Moreover, if you want to live on the paranoia side, you might want
to consider it an assumption to consider OS's character
handling to be 8 bits chunk handling in sequential no-endian order.

And might it not be adventurous in some circumstances, like a
multi-access situation, to think that you would have to put hardware
in a required state just once at the start of a program?


Georg

Re: Ada way to read/write to character file

[Michael Bode]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> The point is, I think, that Text_I/O is for text, where text refers
> to the Ada notion of text, which includes lines, columns, pages and
> what not; all of these give special meaning to some Character values
> that you might not want to be that special for your devices.

As far as I have seen all those devices use quite simple textual
structures i.e. normal ASCII printable characters, CR, LF and maybe
ESC. I'm not 100% sure as this is my first real Ada program, but I
would expect no problems with this and Ada.Text_IO.

For your other points: all that may be true in general and therefore
must be considered in a true standard package. But for my small world
of Windows and Linux PCs Ada.Text_IO with a r/w mode would work. But
it is not there and I wanted to make sure that I had not overlooked
something. It was not really a big deal to write my own package and I
had some practice in writing C bindings to OS functions too.

Re: Ada way to read/write to character file

[James Rogers]

Michael Bode wrote:
> 
> As far as I have seen all those devices use quite simple textual
> structures i.e. normal ASCII printable characters, CR, LF and maybe
> ESC. I'm not 100% sure as this is my first real Ada program, but I
> would expect no problems with this and Ada.Text_IO.
> 
> For your other points: all that may be true in general and therefore
> must be considered in a true standard package. But for my small world
> of Windows and Linux PCs Ada.Text_IO with a r/w mode would work. But
> it is not there and I wanted to make sure that I had not overlooked
> something. It was not really a big deal to write my own package and I
> had some practice in writing C bindings to OS functions too.

My experience with RS-232 serial I/O is that this has absolutely NO
relationship with file I/O. To make RS-232 I/O work you must implement
an RS-232 driver. That driver must set the appropriate bits in the
RS-232 control register on your hardware to either read or write
data. Those bit settings result in a corresponding set of bit
responses from the device, to indicate whether or not the device is
ready for the read or write. Finally, you must read or write the
byte(s), one bit at a time.

Communicating with the RS-232 driver can be abstracted to a set of
"put" and "get" procedures, but those procedures will be part of
your RS-232 driver definition, and not related to Ada.Text_IO.

Unix likes to pretend that all devices are programmatically 
equivalent to files. This is done through some conventions and
odd mappings between files and device drivers. Note that this is
operating system specific, not language specific. 

Jim Rogers
Colorado Springs, Colorado USA

Re: Ada way to read/write to character file

[Michael Bode]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> Unix likes to pretend that all devices are programmatically 
> equivalent to files. This is done through some conventions and
> odd mappings between files and device drivers. Note that this is
> operating system specific, not language specific. 

Windows does the same thing. You have to open("/dev/ttyS*") (Unix) or
CreateFile("COM*") (Windows), then you read() (Unix) or ReadFile()
(Windows) and write() / WriteFile() and then your close() (Unix) or
CloseHandle() (Windows). After the open() you can set the comm
parameters or you use the currently set parameters. In the latter case
it's exactly like a normal file and you could set the parameters by a
standard OS command before your program starts. The only difference is
how the parameter setting is done.

Maybe there are 300 other OSses where this is handled different, but
as far as PCs are concerned if you have Windows and Unix agree on
something there is not much left to differ. At least since Apple has
gone BSD it should be the same there, if the have RS232 at all.

Re: Ada way to read/write to character file

[Georg Bauhaus]

Michael Bode <m.g.bode@web.de> wrote:
: I'm not 100% sure as this is my first real Ada program, but I
: would expect no problems with this and Ada.Text_IO.

Nor am I but I would expect problems, e.g. with long lines.
If you consult the RM for this, A.10.2 ff, you will see that
you have to take care of automatically inserted characters,
and more.
(CR LF/CR/LF have proven to be a rich source of all sorts of
surprisingly obnoxious data driven trouble.)

:  But for my small world
: of Windows and Linux PCs Ada.Text_IO with a r/w mode would work.

I still think this might be true for the Unix or WinDOS/2 notion
of text (vs. raw/binary), but not for Ada's.


Georg

Re: Ada way to read/write to character file

[Nick Roberts]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:0gY_7.10115$cD4.20201@www.newsranger.com...

> In article <a1hc2t$qo9j3$2@ID-25716.news.dfncis.de>, Nick Roberts says...
> >Timing typically turns out not to be a major problem in most cases. In
> >Ada 95, you can always use an ATC time-out to limit a wait. Typically,
>
> Not when its an OS wait. Compiler writers *could* make that work, but they
> don't have to.

I'll take your word for it, but I can't actually find anything in the RM95
specifically to that effect. (Is that what you mean by "they don't have
to"?.)

One point I'd like to throw in 'from left field', as they say, seeing
certain comments in other posts in this thread: I don't see any sensible way
in which one file object (in the RM95 A.7 sense) can be used simultaneously
for input and output; what is possible (and sensible) is for two file
objects to provide input and output (respectively) for the same external
file (e.g. device). Typically, Standard_Input and Standard_Output work this
way.

--
Best wishes,
Nick Roberts

Re: Ada way to read/write to character file

[Michael Bode]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> for input and output; what is possible (and sensible) is for two file
> objects to provide input and output (respectively) for the same external
> file (e.g. device). Typically, Standard_Input and Standard_Output work this
> way.

It seemed sensible for me too, but it didn't work. I got an exception
when I opened the 2nd file.