Re: cross-platform serial api for gforth

On Jan 3, 10:25 am, stephen...@xxxxxxxxxxxx (Stephen Pelc) wrote:
On Fri, 2 Jan 2009 16:14:04 -0800 (PST), rickman <gnu...@xxxxxxxxx>
wrote:

I don't see any reason why
his code and my code can't have different low level forth words to
implement serial port I/O and the top level code be the same.

Under nearly all operating systems, serial ports are second-class
citizens coerced into a byte-stream model or a terminal model by
layers and layers of crud.

If you start from what Windows and Unices offer at the raw API
level, they are very different. For people who want to use details
that are not important to terminal users, the raw API is often
the simplest approach, e.g. to cope with USB serial ports that
can disappear at any time. Once you have defined what higher
level wordset you need, a harness layer is not a difficult job.
We did this for a building management system and the Linux and
Windows versions are built from the same code base with only a
few conditional compilations.

Just in case I have not made this clear, Joel and I are working
together on a project. This application is not for a general
commercial market. This is for a controlled environment (relatively)
talking to a test fixture which I am building. My thoughts are that
the serial port stream is just that, a byte-stream with no handshaking
except for the higher level protocol (send command, get response). It
would be useful to be able to completely reset the port if something
gets mucked up, otherwise it is just init stream, send a byte and get
a byte. The reason I am working on this is to semi-automate and
improve throughput of manual testing and balky software will work
against that purpose.

I see the display portion of the software working in a similar
manner. The app will output a byte stream to an ANSI terminal
emulation for display of the data that is updated in real time. In
this case real time is either when the user presses a button to update
registers in the target and the display shows the responses, or the
software cycles in a loop to repeatedly update the display from
queries.

The reason that we are using different OS is because I am pretty much
locked into Windows on my laptop (the machine the code has to run on)
and Joel does not have a Windows machine and *much* prefers to work on
his Mac. The way I think of this, there would be different versions
of the file for the code supporting the serial port, com.f, that would
provide the basic functions of com_key?, com_key, com_emit and what
ever init/close functions are needed. This file would be different
for the various OS that are needed. I don't see this as a major
stumbling block myself. Joel is thinking that all of the interface
code needs to be in one file and be smart enough to figure out how to
talk serial using the OS it is running under. That's ok with me as
long as it works.

Rick
.

Loading