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:[email protected]] Sent: Thursday, March 22, 2012 9:22 PM To: Dennis Ruffer Cc: [email protected] 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.
