Serial programming on OS9000

[pgr]

Hi, I am trying to port an existing Linux program to OS9000 (PPC) by
using Microware's Ultra Compiler Version 2.9. The original Linux code
uses "termios.h" which uses the function "open" to open the port. I
guess I have to replace "/dev/ttyS<x>" with "/t<x>" here.

What do I have to use instead of the "termios.h" functions like
"tcgetattr" and "tcflush"? My MWOS directory does not offer these but
does contain headers for "old style" function "ioctl". There is no
standard API for this function, so there are quite a lot of variants
out there [1]. I have problems identifying the acutal API contained in
MWOS and finding the needed constants and structures to use with this
variant of "ioctl", e. g. TIOCFLUSH and sgttyb.

Can somebody help me?

[1] http://en.wikibooks.org/wiki/Serial_Programming:Unix/V7

[Martin Gregorie]

I run OS-9 V2.4 on a 68020: OS9000 belongs in the V3.x revision of OS-9
so I can't provide direct help, but the following may get you started.

OS-9 is entirely nonstandard when it comes to low level manipulation of
serial ports: you really need access to the compiler manual to do this
translation properly. Don't forget that OS-9 isn't really anything to do
with the *nix world. OS-9 was released before MSDOS but, because it's
process model is a simplified work-alike for UNIX processes, it seems a
lot more modern and is certainly much better designed.

The 'old' K&R C compiler that came with OS-9 V2.4 handles serial port
setup via _gs_opt() and _ss_opt(), which allow you to get and set the
sgbuf struct which contains all the port settings. There are a few more
interesting functions: _gs_devn() [get the device name], _gs_eof() [test
for EOF] and _gs_rdy() [see if data is waiting to be read] that you might
need.

IIRC the Ultra-C compiler uses an equivalent set of library functions
with os_ prefixes in place of the _gs_ prefixes used by the K&R compiler.

If there's a port of the GNU C compiler for your PPC and OS9000 you might
find using that is the easiest approach unless you have a specific reason
for using the Ultra-C compiler. The GNU C port comes with the standard C
libraries. Add gmake to the mix and your original makefiles may also work
without any changes apart from, possibly, 'install'.

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[pgr]

Thanks for your reply.

So I have to forget about using anything near a standard API. Now I
switched to _os_open/close/write. This works on "/t1" as I am actually
sending data through my serial cable. You suggested setting baudrate
and so on via "_ss_opt". This function is conditioned by "ifdef
_OPT_PROTOS", so I can not use it.

There are function like

error_code _os_ss_dopt _OP((path_id, u_int32, void *));
error_code _os_ss_luopt _OP((path_id, u_int32, void *));
error_code _os_ss_popt _OP((path_id, u_int32, void *));

available for my program, but I do not know how to use them. The
documentation is too brief. The header offers a lot of defined values
like

#define SS_FLUSHBUF 0x9a

which seems to be a flushing command (that I also need for my
program). I found some chunk of code [1] on the internet opening a "/
t0" and setting options via "_os_gs_popt". I will try that now.

[1] http://www.mombu.com/programming/os9/t-silly-request-617090.html

[pgr]

I was successful on setting the baudrate to the higher value
BAUD19200. The workflow is:

1. _os_open("/t1", FAM_WRITE, &id);
2. _os_gs_luopt(id, &size, &opts); // (using the structure
scf_lu_opts)
3. _os_ss_luopt(id, size, &opts);
4. _os_close(id);

Now I still need to flushing...

[Martin Gregorie]

On Mon, 18 Aug 2008 05:18:38 -0700, pgr wrote:

> available for my program, but I do not know how to use them. The
> documentation is too brief.
>

If you were using V2.4 I'd say look at the Kernel API definitions, since
the C library functions we're talking about map 1:1 to the kernel API,
and that, like the V2.4 kernel, was written in MC68000 assembler.
However, OS9000 was written entirely in C, if there is an analogous set
of API definitions in the system manual (rather than the compiler manual)
I'd suggest you look there.

> like
>
> #define SS_FLUSHBUF 0x9a
>
> which seems to be a flushing command (that I also need for my program).
> I found some chunk of code [1] on the internet opening a "/ t0" and
> setting options via "_os_gs_popt". I will try that now.
>

OS-9's handling of this is different. The general approach is to use
buffered or unbuffered i/o on a per-file basis. This differs from the
*NIX way of buffering everything and providing a flush() operation.
The lower level operations (open/read/write) are usually unbuffered
(though there are some ugly tricks that can make them use buffers IIRC)
while the 'f' series functions (fopen/fread/fwrite) are buffered and do
support the fflush() function.

This is design philosophy: in general OS-9 buffers as little as possible
on the grounds that if nothing is buffered then a failure will do less
damage than if there are buffers full of stuff that hasn't been written
yet. It also reflects the hardware it was initially designed for - OS-9
was originally written for the 6809 and was a usable multi-user,
multitasking OS on a 6809 with only 64K of RAM(!). My system has a whole
8MB of RAM and has never come close to running out of memory in the 20
years I've had it.

Buffering also ties in with system modularity. For example, default disk
access operates directly at the block level, but higher level buffering
modules are available: if you load and initialise a disk buffering module
it will insert itself between the disk driver and the IOmanager and
suddenly you're using, say, a track-level disk buffer. I've seen one that
was shared by disk and tape: backups were blindingly fast.

[Martin Gregorie]

See my most recent comment. It should give you some idea of where to look
for more information.