Re: [gforth] problem with gforth7 and serial access

[kibler]

In response to the lack of support and some testing on my own,
it appears that serial and probably numerous other functions in
gforth 7 are broken and will remain broken forever. I come to that
conclusion for two reasons - one is that no one has responded
with any proof or code that uses the regular functions in gforth
to handle serial as it was done in gforth 6 - i.e. using existing
functions to access a serial tty port. From my testing it would appear
that the serial interface is now designed to support only console
access and not communications with an embedded product that
might be handling raw data. I see in the updated io.c, key_avail
function, code looking for EOF character, and if found returns "0", or
to say nothing is there. Clearly that breaks any form of raw serial transfers
where some binary data might be handled. I suspect there are other
offending code sections, as I saw clear examples of keyboard
handling when I had a print statement in the key_avail code. It showed
that characters were being seen and handled outside the actual
code intended for doing it and thus breaking any true serial I/O.

My second concern is based on the fact that all serial code and socket
code examples given in emails, clearly use their own system calls to replace
gforth internal system calls, as everyone has learned that they are
broken and just don't work. This is troubling as it means no one is
interested in fixing internal calls, or that they know they would break too
many other "tweaks" of gforth for some specific platform. It is nice
that gforth will run on so many hardware systems, but troubling that
so much hardware specific coding has been done. The more useful
programs across multiple hardware usually are successful because they
have removed all specific hardware coding and left many platform specific
tasks to the user and not hidden in functions no one would suspect of
doing more than they should (i.e. checking for EOF instead of only returning
a system calls status value).

In trying to figure out what to do, as gforth 7 clearly breaks our previously
working code, I looked at kforth since several code modules were imported
from it to gforth. The modules do work in kforth, but I was unable to make
them work in gforth. I did see several comments that basically said they
"should" work, but it appears no one has actually tried them. I did and they
did not work for me. I suspect my problem is again, unwanted low level
changes in gforth internal that breaks older code. I found kforth to be lots
cleaner, but has assembly code making it non-portable. The best part of
kforth however is that all the examples provided seem to work and have been
tested. gforth does not have an example directory and as such, especially
since you need to re-do all system calls on your own, it clearly needs an
example directory of how you expect others to code around the broken
internal functions. It would help as well if some of the functions were removed
from the documentation as they should not be used except by those who
know how they have been programmed recently. This could be covered
in the examples of successful code and would show what limits exist for
those functions.

Our group has several directions to go to work around these issues, but the main
thing we learned is that gforth works well for normal and simple forth coding.
It does not work well for serial and other functions closely aligned with a 
systems
hardware or OS features. For items like serial, a roll your own interface is
the normal and only option available.
Bill.


On 03/22/12 22:21, Dennis Ruffer wrote:
> Despite all the OSX specific stuff, it is basically a POSIX interface which
> should apply to Linux too, and I see that it even uses select.  You might
> look at SetupTermios, which I remember being quite tricky.  I don't know if
> that is where your problem is, but it sounds like the kind of problem that
> things like flow control could affect.
>
> DaR
>
> -----Original Message-----
> From: kibler [mailto:address@hidden
> Sent: Thursday, March 22, 2012 9:22 PM
> To: Dennis Ruffer
> Cc: address@hidden
> Subject: Re: [gforth] problem with gforth7 and serial access
>
> Thanks Dennis for the example code.
>
> All the system/c-interface calls are for BSD and thus not usable on linux.
> However the example is full of how-to's and as such might help.
>
> What I notice with the three examples of code so far is that all of the
> examples had to define their own system library calls.
> You used the c-function calls to create your library of system/stdC
> routines. That seems a bit strange, as in gforth 6, we can open and write to
> files, even those that are actually serial ports or USB to serial
> converters. In Unix, you are not really suppose to know whether a file is
> I/O or just a regular file - the system calls handle the actual work behind
> the calls as it were.
>
> So I guess it gets back to the original problem, which is why is select
> broken, or just broken for the serial I/O part of reading and writing to a
> file. It just doesn't make sense that we need to re-do all the system calls
> for something that did work.
> Bill.