* Ada way to read/write to character file @ 2002-01-05 12:01 Michael Bode 2002-01-07 15:13 ` Alfred Hilscher 0 siblings, 1 reply; 14+ messages in thread From: Michael Bode @ 2002-01-05 12:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-05 12:01 Ada way to read/write to character file Michael Bode @ 2002-01-07 15:13 ` Alfred Hilscher 2002-01-09 0:04 ` Nick Roberts 0 siblings, 1 reply; 14+ messages in thread From: Alfred Hilscher @ 2002-01-07 15:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-07 15:13 ` Alfred Hilscher @ 2002-01-09 0:04 ` Nick Roberts 2002-01-09 2:12 ` tmoran 0 siblings, 1 reply; 14+ messages in thread From: Nick Roberts @ 2002-01-09 0:04 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 0:04 ` Nick Roberts @ 2002-01-09 2:12 ` tmoran 2002-01-09 6:25 ` Michael Bode 2002-01-09 12:11 ` Nick Roberts 0 siblings, 2 replies; 14+ messages in thread From: tmoran @ 2002-01-09 2:12 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 2:12 ` tmoran @ 2002-01-09 6:25 ` Michael Bode 2002-01-09 16:12 ` Georg Bauhaus 2002-01-09 12:11 ` Nick Roberts 1 sibling, 1 reply; 14+ messages in thread From: Michael Bode @ 2002-01-09 6:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 6:25 ` Michael Bode @ 2002-01-09 16:12 ` Georg Bauhaus 2002-01-09 20:38 ` Michael Bode 0 siblings, 1 reply; 14+ messages in thread From: Georg Bauhaus @ 2002-01-09 16:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 16:12 ` Georg Bauhaus @ 2002-01-09 20:38 ` Michael Bode 2002-01-09 23:57 ` James Rogers 2002-01-10 23:13 ` Georg Bauhaus 0 siblings, 2 replies; 14+ messages in thread From: Michael Bode @ 2002-01-09 20:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 20:38 ` Michael Bode @ 2002-01-09 23:57 ` James Rogers 2002-01-10 6:17 ` Michael Bode 2002-01-10 23:13 ` Georg Bauhaus 1 sibling, 1 reply; 14+ messages in thread From: James Rogers @ 2002-01-09 23:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 23:57 ` James Rogers @ 2002-01-10 6:17 ` Michael Bode 0 siblings, 0 replies; 14+ messages in thread From: Michael Bode @ 2002-01-10 6:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 20:38 ` Michael Bode 2002-01-09 23:57 ` James Rogers @ 2002-01-10 23:13 ` Georg Bauhaus 1 sibling, 0 replies; 14+ messages in thread From: Georg Bauhaus @ 2002-01-10 23:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 2:12 ` tmoran 2002-01-09 6:25 ` Michael Bode @ 2002-01-09 12:11 ` Nick Roberts 2002-01-09 14:17 ` Ted Dennison 1 sibling, 1 reply; 14+ messages in thread From: Nick Roberts @ 2002-01-09 12:11 UTC (permalink / raw) <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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 12:11 ` Nick Roberts @ 2002-01-09 14:17 ` Ted Dennison 2002-01-11 0:19 ` Nick Roberts 0 siblings, 1 reply; 14+ messages in thread From: Ted Dennison @ 2002-01-09 14:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-09 14:17 ` Ted Dennison @ 2002-01-11 0:19 ` Nick Roberts 2002-01-12 16:01 ` Michael Bode 0 siblings, 1 reply; 14+ messages in thread From: Nick Roberts @ 2002-01-11 0:19 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada way to read/write to character file 2002-01-11 0:19 ` Nick Roberts @ 2002-01-12 16:01 ` Michael Bode 0 siblings, 0 replies; 14+ messages in thread From: Michael Bode @ 2002-01-12 16:01 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2002-01-12 16:01 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-05 12:01 Ada way to read/write to character file Michael Bode 2002-01-07 15:13 ` Alfred Hilscher 2002-01-09 0:04 ` Nick Roberts 2002-01-09 2:12 ` tmoran 2002-01-09 6:25 ` Michael Bode 2002-01-09 16:12 ` Georg Bauhaus 2002-01-09 20:38 ` Michael Bode 2002-01-09 23:57 ` James Rogers 2002-01-10 6:17 ` Michael Bode 2002-01-10 23:13 ` Georg Bauhaus 2002-01-09 12:11 ` Nick Roberts 2002-01-09 14:17 ` Ted Dennison 2002-01-11 0:19 ` Nick Roberts 2002-01-12 16:01 ` Michael Bode
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox