Installing gForth on the Raspberry Pi

Willem Ouwerkerk has his server for 8051 single board computers. It has drop down menus, all based on not much more than a few ansi codes and AT-XY. I have worked on the MANIP thermal simulation for spacecraft. It had a windows system that runs within a vt100, and portably at that.

If you're on some unix-like OS, remember infocom. You can look up escape codes for things like color, scrolling and whatnot. The character based windows on startup when installing linux in same mode uses that. You can get pretty far with half a dozen of those codes. And your program will work with a Hazeltine 1200 if ever one wants to hook that thing up. 1]

Groetjes Albert

1] Those were already pretty obscure in the 80's.
--
Albert van der Horst, UTRECHT,THE NETHERLANDS 
Economic growth -- being exponential -- ultimately falters. 
 Click to see the full signature
Reply to
Albert van der Horst
Loading thread data ...

Numbered pipes and files aren't too hard " albert@cherry:~$ lina 17> aapje

80386 ciforth 5.1 "we gaan naar rome " 3 WRITE-FILE THROW ? ciforth ERROR # -9 : Bad file descriptor

"we gaan naar rome " 17 WRITE-FILE OK BYE

albert@cherry:~$ cat aapje we gaan naar rome albert@cherry:~$more aapje

"

Groetjes Albert

--
Albert van der Horst, UTRECHT,THE NETHERLANDS 
Economic growth -- being exponential -- ultimately falters. 
 Click to see the full signature
Reply to
Albert van der Horst

(I've some recent experience, trying to write a terminal server for single board computers like the MPS430).

You didn't notice but returning with a count of zero is not smart but stupid. Suppose you have a 300 baud line and a 4 Ghz machine. Then you're effectively polling and hanging up the machine. It is stupid not to wait at least the time that is needed for a single character to arrive, 30 mS. So we have to play with time outs of the order of one character timing, which is milliseconds. Writing a serial line is full of those real time issues. Windows nt followed to an extent the VMS philosophy which is

  1. set out a read, return immediately
  2. If the read finishes *as configured* (this means x characters, or a time out, or a ^D, or a ^J or and ASCII null, or a combination of those) it sets and event flag.
  3. You can have your program wait, on any combination of event flags, so you can keep track of several simultaneous read and write operations.

This is generally considered superior to the Unix approach with the select mechanism, but ... (In the 80's I heard, Unix is good for development, VMS is good for real time. ) MSDOS documentation, implementation and integration with the rest of the OS is lacking in many respects. (Did I say MSDOS, I mean MS windows.)

There are no hard specifications, now how is one supposed to write a driver for USB serial with those specs?

This also answers the question, why threads in Linux? You really need them for time outs alone.

One must be aware of how groups work. Then you can forget them until such time that you're warned you've not enough privileges.

Groetjes Albert

--
Albert van der Horst, UTRECHT,THE NETHERLANDS 
Economic growth -- being exponential -- ultimately falters. 
 Click to see the full signature
Reply to
Albert van der Horst

There's also the ncurses library - if there's a gforth wrapper for it. That makes your terminal windows more or less implementation independant and allows for multiple windows, pop-ups and so on.

I've used curses a lot from C, but not from forth.

Gordon

Reply to
Gordon Henderson

xterm has a little known feature built-in to allow it to be used as a secondary (or multiple) terminal window under control of an application, without the need to run any command in it - the app simply reads and writes to specific filedescriptors setup for the purpose. This is the -S (capital- S for Slave Mode) option. A single process can open a number of xterms this way, and directly control them without running additional apps in them.

Unfortunately, -S is woefully inadequately described on the manpage, and its format very system-specific (again not covered on manpage).

(dtterm also supports -S, but gnome-terminal does not AFAIK.)

--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]
Reply to
Andrew Gabriel

Linux (and Unix in general) doesn't work like that. Regardless of the language you're writing your program in, Linux maintains the serial devices for you. You can write a block of data to a serial device and your program will not stall unless you fill up the output buffer in the Linux kernel.

There are system calls to let you force-flush the output buffer and foce-empty the output buffer as well as letting you know how much is in it.

So, depending on how your program is written, you never need to wory, and you can always increase the buffer size if you need to.

Similarly for reading, the kernel reads the characters and stores them in a buffer until your program is ready to read them - at which point, you can either use a non-blocking read which won't stall if there are no characters left, or use a system call to let you know how many characters are ready to be read.

Of-course if you don't read the input quick enough and are not using hardware or software handshaking (which the kernel does automatically if configured to do so), then you lose data, but this is not different to any other system.

Linux drives USB serial drives and presents an interface that's identical to an on-board hardware serial device. You can not normally tell if you're talking to a USB serial device or a hardware serial device unless you know it's path - typically /dev/ttyS0 for on-board serial (or /dev/ttyAMA0 for the Pi), and /dev/ttyUSB0 or /dev/ttyACM0 for USB serial devices.

Well you don't. There are ways to do without threads, and without using select() or poll() either. It's just a matter of knowing the system calls to use - and for a newbie to Linux, that's a fairly steep learning curve, and the termiios structure and ioctl() mechanism can appear somewhat daunting at first.

Gordon

Reply to
Gordon Henderson

VFX Forth for ARM Linux has a serial port driver, a socket layer and technical support. It works well on both the Raspberry Pi and the Beaglebone Black.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

Concerning the telnet client part: Gforth maps the Forth "user input device" to the standard input/output, and it expects a terminal there for the interactive mode (I think that's called a console application in Windows).

So if you have a telnetd on your rPi, you can telnet there, start Gforth from there, and then the Gforth output (TYPE, EMIT, etc.) will be displayed on your telnet client, and your input to the telnet client will be the input of Gforth (KEY, ACCEPT, QUIT input).

The more modern variant of this approach would be to use an ssh connection rather than a telnet connection; i.e., sshd on the rPi, an ssh client (ssh on Unix, putty on Windows) on the PC.

With this approach, you don't need to open a socket or anything, just all the usual words to talk with the user input device.

However, if you want to have a separate channel for diplaying the message traffic, one way to do that would be to start an xterm and talk to it through a pipe. An example of how to do that can be found in status.fs in the Gforth distribution (not sure if that's included in the Debian package), which does exactly that. To make use of that, you have to run an X server on the display end of the connection (so that xterm has an X server to display on).

Other approaches are also possible, but these two are the ones that should be easiest.

- anton

--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html 
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html 
 Click to see the full signature
Reply to
Anton Ertl

Sure, but IME using poll() makes the whole issue of handling more than one file/network connection.serial port within the same program without using threads or interprocess communication rather simple once you get your head around hoe poll() works.

Again, IME, a major issue is working out what C standard library calls to use. If you know the name of the function, the manpages usually tell you all you need to know about that function, and 'apropos' is good if you're not entirely sure about its name (apropos search manpage title lines and lists all the manpages with your search term in the title.

However, if you're doing more than trivial C programming on a Linux box, get a copy of "Unix SVR4 System Programming" from O'Reilly (aka The Lion Book). Its quite a chunk and, despite its name, is 100% relevant to writing C on Linux. Its groups functions logically, uses clear descriptions of what's going on and includes goor example code.

Last shot: If you're newish to C, but want to write it well, your personal library should include "The C Programming Language" by Kernighan and Richie (ed. 2 or later) "The Practise of Programming" by Kernighan and Pike

The first is a very readable introduction to writing C, written by the authors of the language while the second is applicable to almost any block structured language (C, Java, Python...) and gives good advice about variable and function names, program layout and how to write code thats easy to maintain and debug. Its a good book to read when you've learnt a programming language or two and before you tackle a significant programming task.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

Not sure why you're telling me this - I've been programming in C on Unix and like systems for nearly 35 years now and am quite happy stuck in my ways.

Gordon

Reply to
Gordon Henderson

Apologies, Gordon - I obviously misplaced my post within the thread. It was, of course, intended for Rickman, who seemed doubtful about writing Linux programs and/or C. Hopefully it will also be useful for anybody else in his position.

I would have found Kernighan&Pike very useful when I was in starting to write significant programs (or even simpler ones that weren't throwaways! ) but at that point even K&R hadn't been written, let alone UNIX. As it happens I'd already evolved a fairly similar style to that described in K&P, but even so I found it a useful read simply because it is extremely readable and offers a good description of how to write well-structured programs.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

Right! However, I'm fairly sure the new epiphany-browser wasn't (isn't) included in a dist-upgrade. My update script does dist-upgrade and I had run it a few times already between the release of Epiphany and manually installing it. (However again, Gordon said "additional stuff to support the new web browser" so that might indeed be covered:)

Reply to
A. Dumas

Yes I noticed that in the xterm man page, but does the app then have to deal with the pty interface? I remember wanting to use that for something once, and it looked kind of messy in the docs, and I ended up not pursuing it. I guess if the xterm can just inherit a file descriptor and not have to mess with pty devices, that can be simpler than the named pipe approach.

Reply to
Paul Rubin

I'm not sure what you mean by "hard work". If you mean the few constants, yes, there is a file with them declared in Forth. Otherwise is is just a windows system call with a data structure. All of that is already a part of any Forth that runs under an OS. How else could they get to the I/O? Serial ports just use a few different constants.

You make it sound like it takes enormous work to find those constants and use them.

--

Rick
Reply to
rickman

I don't get your point. There are a huge number of native Forth implementations, so if I understand your analogy it would be just Forth

  • Forth. No?
--

Rick
Reply to
rickman

Great, how does that help me use gForth?

--

Rick
Reply to
rickman

Obviously I am terrible at explaining things as I never seem to be able to get people to understand what I am trying to do with this app. I find it very simple, but I must be leaving out important info. Let me try drawing an ASCII art picture... Test Fixture Forth App Terminal Emulator +--------+ +--------+ +---------+ | | RS232 | Forth | ??? | RS232 | | UUT || User || Data | | | | I/O | | Display | +--------+ +--------+ +---------+

The middle box is the Forth app with its own console I/O. The left box is a test fixture connected to the computer by RS-232. The user controls the app through the console I/O and when actually production testing boards test results are copied into the paste buffer by the program to be pasted into a spread sheet.

The current iteration of the program uses a socket connection to display the RS232 message data in a terminal emulator as a second window separate from the console. This is useful as a debug tool but is not strictly required for production testing.

Just to be clear, the rPi will not be used for production testing. If possible I would like to have a single source file which will compile correctly on both Linux and Windows systems, but that is not essential and not even important at this stage. Right now I'd just like to get the serial port working and find a way to display the traffic data somewhere other than the console window. I think the pipes thing may work just fine, possibly under Windows as well.

--

Rick
Reply to
rickman

Yes, program creates a pty. Look at W.Richard Steven's excellent book, "Advanced Programming in the Unix Environment", chapter 19. (He shows ptys for Solaris and BSD, but unfortunately not Linux. You can find ptyopen.c Linux source code for doing it on the web.) You end up with two filedescriptors, one for the master side and one for the slave side of the pty.

Then you simply fork/exec xterm, giving it the master side fd, and you use the slave side fd to read and write to the xterm. The format of the -S option (on Solaris at least) is -Sxx%d where %d is the master side fd, and xterm ignores the first two characters (the "xx") for some historic reason (I vaguely recall they must not be slashes, which cause the field to be interpreted differently). The other undocumented feature here is that xterm sends back an initial line of text which was not typed in the xterm window - it is the X Window ID of the xterm window (which I just skip past, as I never need my app to ask the window manager to iconize or redisplay the xterm).

--
Andrew Gabriel 
[email address is not usable -- followup in the newsgroup]
Reply to
Andrew Gabriel

What is a terminal *server*?

I can't say I follow your reasoning. I don't see how bit rate has anything to do with the issue. If a read is requested and there is no data in the read buffer, the routine returns indicating it read no data. If there is data in the buffer it returns the data and the lesser count of data in the buffer and the amount requested. Actually, this is the same as the no data case where it returns the data in the buffer which is none and returns the size which is zero. In all cases it returns immediately. If the program wishes to wait for data it just sits in a loop checking for new data and hopefully wasting time by calling a wait routine rather than tying up CPU with a spin loop.

Where exactly is the problem?

--

Rick
Reply to
rickman

I'm not sure why you think I am "doubtful" about writing in C. I am.. er, was... fairly experienced in C, but I have not used it in a decade or more and don't intend to use it if I don't have to... and I *don't* have to. Don't get me wrong. There is not much bad about C. I just like the interactivity of Forth. I find it much easier to get stuff working in Forth than to use a debugger in C.

My copy of K&R is sitting in my bookcase along with a couple of other C books and a small collection of VHDL books. My two Forth books are laying on my desk next to my work area...

--

Rick
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.