Re: [gforth] problem with gforth7 and serial access

[Bernd Paysan]

Am Dienstag, 3. April 2012, 09:25:47 schrieb 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.

Maybe.  One thing why you should not boast so loudly about "no support" is 
that you did completely fail to show code examples that are broken.  You 
showed no code at all.  It is difficult for us to respond seriously to bug 
reports without having an easy way to reproduce the bug.  All we then could do 
is guess and point you to code that does work on Gforth 0.7.

> 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.

This is not the EOF character, this is the EOF return value of getc(), which 
is -1.  It will be returned when EOF is reached, and is not confused with ^D.

> 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.

What did you see?

> 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.

There are other issues.  First of all, Gforth's internal has no way to set 
baud rates and line discipline etc.  This you need to roll on your own, 
anyways.  So while you are at it, you can just do the rest yourself, too.  
Gforth's keyboard handling goes through C's stdio buffers, which is 
inappropriate for real serial line handling.

> 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).

Well, you misunderstood what this EOF is:  It is the indicaton that the file 
has ended, it is not ^D, it is -1.  If the file has ended, there is no further 
key available.  Thus the return value of 0 is correct.  The failure of 
select() on Linux for serial lines (returns "nothing availabe" when there is 
indeed something available) is IMHO a bug in Linux.  ioctl(FIONREAD) does not 
work on files, so that is not an option, either - the code in Gforth 0.6 was 
broken and had to be replaced.

> 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.

Well, for functions close to the system, use the C interface (libcc.fs).  
That's the way to go.  serial.fs is in contrib, it's third party stuff.  As 
such, the Gforth autors are not active maintainers of that stuff, and we don't 
check if it still works.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

signature.asc
Description: This is a digitally signed message part.