Installing gForth on the Raspberry Pi

Manual? Manual!!??? There's an F'ing MANUAL???

The manual is mute on serial port usage. I have found some references, but they mostly are Greek to me like,

I'm also finding info saying I need to set group membership to allow access to the serial port.

Googling for "raspberry pi forth", I came across

Thanks for the link. Right now I'd like to pursue gForth because if I get my code working with that, it is likely I can use the code with minimal modifications under Windows gForth as well. Also, pijFORTHos is actually a bare metal forth not running under Linux at all. I want to keep this under an OS for now as there will be files written from the program and networking will be used to move the data. Not to mention I may want to add special capabilities to the rPi such as an oscilloscope.

It's not worth bothering. Just use a terminal.

Pty is probably simpler than sockets, it's just different and doesn't come up as often. I.e. most internet programmers are already used to sockets, while pty might require some head scratching.

Actually there's an even simpler approach now that I think of it. Just launch "xterm somescript" where somescript is a script that you write, and xterm will run the script instead of a shell. The script would just telnet to the socket listener in your program. Telnet in "line mode" will send a line at a time, doing stuff like erase processing, so your program won't have to deal with that.

I'm unclear where the rpi comes into the production system, if it does at all.

Not sure if you mean a terminal or a terminal emulator. I still have to figure out how to talk to a terminal emulator.

I already have a sockets implementation working for Windows. I would need to port that to Linux which may not be so fun.

I don't follow. Why would the terminal emulator be sending anything? I guess I wasn't clear. The terminal emulator is just being used to display the message traffic from the serial port.

It doesn't. As I said I would use the rPi for the same program for other purposes in the lab.

Maybe you can help me with the terminalogy of the sockets interface. I thought my program was a socket server. You seem to call it a "listener". Is that the same thing?

This one?

OK - So it's some 20 years since I got paid to write some Forth..

That looks like a more or less complete implementation of a library to access a generic serial port.

However it looks way overly complicated to me - using threads (for why?)

Stuff you might need to know:

The Pi's serial port is /dev/ttyAMA0

Hardware under Linux more or less works like a file - so open the file, read and write to the file using a file handle or descriptor (often refered to as 'fd' on other peoples code)

The down-side of just open/read/write is that it will usually block and yo won't be able to set the baud rate. termios is the mechanism to fiddle with that and things like partiy, etc.

If you're running Raspbian then you ought to be OK.

Type

id

if in the output it says (dialout) then you're fine.

You'll need to stop the kernel using the serial port - edit /boot/cmdline.txt and also need to stop Raspbian using it too - edit /etc/inittab. In both cases look for the /dev/ttyAMA0 information and remove it. Note that /boot/cmdline.txt must be one unbroken line.

Hope that helps to get you going.

If your output is just to the screen without any formatting, etc. you can simply run the program from an xterm (or whatever terminal is standard with lxde)

gordon@cmpi0:$ gforth Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit : hw ." Hello world" cr ; ok hw Hello world ok

Gordon

Terminal emulator.

Just have the emulator run a telnet script as described.

Ok, in that case the terminal emulator is only receiving and not sending, no big deal. The socket is bidirectional and you're only using one direction, which is fine. Maybe at some point you might like to type something on the terminal. You can always add the capability later.

Yeah pretty much.

Ok, I have windows code to do this already and I'd like to get rid of it. Even if I use the terminal emulator, I still need to figure out how to open a socket from inside gForth. Just saying "run a telnet script" doesn't tell me much.

The linux and windows socket api's are pretty similar. I have no idea what the gforth wrapper looks like.

There might be a hacky way to do this with shell redirection of the stderr file descriptor. Basically you'd pipe stderr into netcat, and launch an xterm with a netcat listener ("netcat -l") so that stuff written to the stderr from your program would then appear in the xterm.

Hmm, linux also has "named pipes" (fifos) where you create a filename representing the named pipe, write to it from your forth program and read from it in your terminal window. Getting this to work smoothly can take some messing around. Maybe this is the easiest approach. On your application side you'd just open the fifo filename and write to it. In the terminal you'd just "cat" the fifo.

Sorry, should have used a smiley.

Yeah, I didn't get it either. Under Win32Forth it was just a couple of windows commands to open and control the serial port. Actually I think the open was just file I/O but more complicated because they do some really goofy stuff with the file name when you get to double digit COM port numbers. After that the I/O is just file I/O.

The windows I/O is just read-file, but it returns a length which can be zero. Comkey? asks for 1 byte so the char is saved and the routine returns if it was found or not. When Comkey is called it calls Comkey? to make sure a char is in the buffer than returns the char from the buffer. Sounds like I can do the same thing. I just need to find the file I/O calls. But the serial port needs to be set up. One reference said to do that outside of the app.

Yep, it says dialout, so that part is covered.

I'll give that a try. I need to get used to a text editor first.

Certainly I do need console I/O, but I also need a second screen.

Obvious reason for threads is for bidirectional i/o, and being able to dump out a bufferload of text to the terminal without making your program wait.

Yeah you can do that with Linux too, you set a flag for asynchronous operation and then you can query whether the device is ready.

I'd say try the following:

1. Open terminal window
2. run "mkfifo /tmp/bob"
3. run "cat < /tmp/bob" (this will just sit and wait, so keep going)
4. Open another terminal window
5. In new window, run "cat > /tmp/bob" and start typing stuff

You should see the stuff you type in step 5 appear on the console from step 3.

It should be obvious from this, replace step 5 with:

This is probably the simplest way to deal with your unidirectional output problem.

Thanks, that sounds useful. I assume steps 1, 2 and 3 can be combined into a script which when run opens the window and runs the two commands? Is there a way to have the first terminal window interpret ANSI commands, or is that automatic?

Yes, or you can just do step 1 once with the fifo staying someplace persistent. You can then launch the terminal from gforth like this:

s" xterm -e cat /tmp/bob &" system

See "Passing Commands to the Operating System" in the gforth manual for the "system" command.

Automatic.

dist-upgrade doesn't mean something like "os system distribution upgrade." You don't get more, or different, packages. According to the man page for apt-get, it's a more intelligent version of upgrade:

Maybe the name means distinction in the sense of (mathematical set) difference, although if so, diff-upgrade would have been clearer.

Awesome. Thanks a lot.

Actually there are a ton of options to xterm to control the fonts, colors, sizes, etc. You could spend a few hours reading the manual page. There might be some alternate terminal programs on the rpi as well, like maybe gnome-terminal? I don't use an rpi so I don't know what's there.

The difference between upgrade and dist-upgrade is that upgrade will only install newer versions of packages already installed on your system if it can do so without removing any existing packages or installing additional ones.

So if you had knife(1.0), fork(1.2) and spoon(1.2) installed, and then knife(1.3) was released which depended on spork(1.3) which replaced fork(1.2) and spoon(1.2), an upgrade would do nothing, but a dist-upgrade would remove fork and spoon and install spork.

So in a way it is a distribution upgrade as you are changing which packages are installed rather than just upgrading existing ones.

This situation is also a lot more common when moving to a new release than during routine upgrades of the Stable system (Wheezy at the moment). Testing (Jessie) is more likely to need dist-upgrade.

The only thing you're saying is that those are c-based Forth's or someone did the hard work for you. Neither detracts from the fact that it is easier to do with c as a starting point. (You know, I'm the author of an assembler based Forth.)

Groetjes Albert

That is half the story. The truth behind is that UNIX + C is the only portable operating system in town. If you don't believe me, fill in the blanks .... + Ada ...+Forth ...+Haskell ...+algol68

Then we need millions+ customers to gain a critical mass.

Groetjes Albert