Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #34159 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2014-10-26 12:02 -0400 |
| Last post | 2014-10-28 14:06 -0500 |
| Articles | 20 on this page of 130 — 29 participants |
Back to article view | Back to comp.lang.forth
Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 12:02 -0400
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-26 16:11 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 12:20 -0400
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 12:44 -0400
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-26 17:09 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 14:45 -0400
Re: Installing gForth on the Raspberry Pi andrew@cucumber.demon.co.uk (Andrew Gabriel) - 2014-10-26 18:57 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 15:14 -0400
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-26 19:47 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 16:10 -0400
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-27 08:43 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 17:31 -0400
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-28 14:18 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 17:15 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 13:24 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 16:48 -0400
Re: Installing gForth on the Raspberry Pi Raymond Wiker <rwiker@gmail.com> - 2014-10-26 22:12 +0100
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 17:20 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 14:39 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 17:46 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 15:11 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 18:25 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 15:58 -0700
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-27 09:20 +0000
Re: Installing gForth on the Raspberry Pi josv@planet.nl - 2014-10-29 07:02 -0700
Re: Installing gForth on the Raspberry Pi Coos Haak <chforth@hccnet.nl> - 2014-10-30 11:20 +0100
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-27 08:56 +0000
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-27 10:14 +0000
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-27 08:48 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 17:35 -0400
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-28 14:24 +0000
Re: Installing gForth on the Raspberry Pi Alan Adams <alan@adamshome.org.uk> - 2014-10-28 15:52 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 12:49 -0400
Re: Installing gForth on the Raspberry Pi Ray <ray@invalid.com> - 2014-10-28 17:22 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 17:02 -0400
Re: Installing gForth on the Raspberry Pi Lars Brinkhoff <lars.spam@nocrew.org> - 2014-10-27 10:07 +0100
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-27 09:22 +0000
Re: Installing gForth on the Raspberry Pi stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-27 11:30 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 17:37 -0400
Re: Installing gForth on the Raspberry Pi stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-28 12:41 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 12:51 -0400
Re: Installing gForth on the Raspberry Pi stephenXXX@mpeforth.com (Stephen Pelc) - 2014-10-28 18:44 +0000
Re: Installing gForth on the Raspberry Pi anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-27 11:49 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 17:51 -0400
Re: Installing gForth on the Raspberry Pi "Elizabeth D. Rather" <erather@forth.com> - 2014-10-27 20:31 -1000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 03:01 -0400
Re: Installing gForth on the Raspberry Pi "Elizabeth D. Rather" <erather@forth.com> - 2014-10-27 21:14 -1000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 03:45 -0400
Re: Installing gForth on the Raspberry Pi "Elizabeth D. Rather" <erather@forth.com> - 2014-10-27 22:14 -1000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 14:09 -0400
Re: Installing gForth on the Raspberry Pi Mel Wilson <mwilson@the-wire.com> - 2014-10-28 21:50 +0000
Re: Installing gForth on the Raspberry Pi "Ivan D. Reid" <Ivan.Reid@ivan.fsnet.co.uk> - 2014-10-29 00:01 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 20:50 -0400
Re: Installing gForth on the Raspberry Pi "Ivan D. Reid" <Ivan.Reid@ivan.fsnet.co.uk> - 2014-10-29 01:20 +0000
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 00:58 +0000
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-28 18:04 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-29 01:40 -0400
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-29 12:41 +0000
Re: Installing gForth on the Raspberry Pi Theo Markettos <theom+news@chiark.greenend.org.uk> - 2014-11-16 15:34 +0000
Re: Installing gForth on the Raspberry Pi "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-11-16 12:01 -0500
Re: Installing gForth on the Raspberry Pi The Natural Philosopher <tnp@invalid.invalid> - 2014-11-16 17:22 +0000
Re: Installing gForth on the Raspberry Pi Rob Morley <nospam@ntlworld.com> - 2014-11-16 17:06 +0000
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-16 18:27 +0000
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-11-16 19:19 +0000
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-16 20:11 +0000
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-17 11:56 +0000
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-17 13:42 +0000
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-11-17 10:14 -0800
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-11-16 17:25 +0000
Re: Installing gForth on the Raspberry Pi Rob Morley <nospam@ntlworld.com> - 2014-11-16 17:40 +0000
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-11-16 19:12 +0000
Re: Installing gForth on the Raspberry Pi Alan Adams <alan@adamshome.org.uk> - 2014-11-16 19:50 +0000
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-11-16 21:22 +0000
Re: Installing gForth on the Raspberry Pi Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-11-16 17:38 -0500
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-17 00:12 +0000
Re: Installing gForth on the Raspberry Pi Michael J. Mahon <mjmahon@aol.com> - 2014-11-16 19:53 -0600
Re: Installing gForth on the Raspberry Pi Coos Haak <chforth@hccnet.nl> - 2014-11-17 01:00 +0100
Re: Installing gForth on the Raspberry Pi Alan Adams <alan@adamshome.org.uk> - 2014-11-17 12:03 +0000
Re: Installing gForth on the Raspberry Pi druck <news@druck.org.uk> - 2014-11-18 20:03 +0000
Re: Installing gForth on the Raspberry Pi druck <news@druck.org.uk> - 2014-11-16 18:20 +0000
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-29 11:53 +0000
Re: Installing gForth on the Raspberry Pi humptydumpty <ouatubi@gmail.com> - 2014-10-27 06:52 -0700
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 12:02 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 15:18 -0400
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-26 20:24 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 17:09 -0400
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-26 22:05 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 20:27 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 17:45 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 21:09 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 18:22 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 23:20 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-26 20:53 -0700
Re: Installing gForth on the Raspberry Pi andrew@cucumber.demon.co.uk (Andrew Gabriel) - 2014-10-27 10:23 +0000
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-27 13:36 -0700
Re: Installing gForth on the Raspberry Pi andrew@cucumber.demon.co.uk (Andrew Gabriel) - 2014-10-27 22:23 +0000
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-27 09:43 +0000
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-27 10:26 +0000
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-27 13:15 +0000
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-27 14:12 +0000
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-10-27 15:34 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 18:31 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-27 15:50 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 19:26 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-27 16:37 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 20:17 -0400
Re: Installing gForth on the Raspberry Pi Paul Rubin <no.email@nospam.invalid> - 2014-10-27 17:24 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 03:10 -0400
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-28 08:11 +0000
Re: Installing gForth on the Raspberry Pi Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-28 09:13 -0400
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-28 08:11 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 04:14 -0400
Re: Installing gForth on the Raspberry Pi Gordon Henderson <gordon+usenet@drogon.net> - 2014-10-28 08:15 +0000
Re: Installing gForth on the Raspberry Pi "A. Dumas" <alexandre@dumas.fr.invalid> - 2014-10-28 10:22 +0100
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 15:53 -0400
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 17:10 -0400
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-27 18:23 -0400
Re: Installing gForth on the Raspberry Pi Nomen Nescio <nobody@dizum.com> - 2014-11-15 23:09 +0100
Re: Installing gForth on the Raspberry Pi Martin Gregorie <martin@address-in-sig.invalid> - 2014-11-16 00:35 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-11-16 00:06 -0500
Re: Installing gForth on the Raspberry Pi albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-26 19:36 +0000
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-26 16:24 -0400
Re: Installing gForth on the Raspberry Pi Hannu Vuolasaho <vuokkosetae@gmail.com> - 2014-10-27 23:48 +0200
Re: Installing gForth on the Raspberry Pi josv@planet.nl - 2014-10-28 05:27 -0700
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 16:02 -0400
Re: Installing gForth on the Raspberry Pi Coos Haak <chforth@hccnet.nl> - 2014-10-28 22:57 +0100
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 19:54 -0400
Re: Installing gForth on the Raspberry Pi rickman <gnuarm@gmail.com> - 2014-10-28 20:01 -0400
Re: Installing gForth on the Raspberry Pi "A. Dumas" <alexandre@dumas.fr.invalid> - 2014-10-27 04:10 +0100
QUESTIONS and ANSWERS pass in the dark ;< - was [ Re: Installing gForth on the Raspberry Pi ] Richard Owlett <rowlett@cloud85.net> - 2014-10-28 14:06 -0500
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-29 11:53 +0000 |
| Message-ID | <5450d52a$0$6891$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #34270 |
In article <m2pe38$5v9$2@dont-email.me>, Martin Gregorie <martin@address-in-sig.invalid> wrote: >On Tue, 28 Oct 2014 14:09:25 -0400, rickman wrote: > >> Now I need to figure out how to edit code on the rPi and I >> should be ready to proceed. >> >As you are thinking of changing editors, it would be useful to know if >you prefer programming from the command line or using a GUI before >recommending editors. > >I'll make just one observation here: its worth looking at Vi or its >improved Vim clone. You may hate it but its still useful to know because >it is capable of running from a really minimal keyboard and screen. It >can be used if the screen is so old or broken that it only has a glass >teletype level of screen painting ability and a keyboard without cursor >or function keys. If you manage the bork the RPi really badly, knowing vi >may help you recover because its often usable when the system is degraded >to the point where emacs and other editors can't be used. Sure. It helps to learn one sequence by heart: <esc>:q! This is a sure way to leave vi whatever state it is in. Start with the habit to move around by hjkl. vi was never my first choice but it is an unfailing backup. > >> I might work from my PC and control the rPi remotely. >> >I think thats a good idea anyway. Connect the RPi to your LAN and run >PuTTY, a well regarded SSH implementation for Windows, on your PC and >you've immediately got command-line access to the RPi via an SSH session >as well as file transfers via the scp utility. This is known as running >the RPi in headless mode and means you don't need a screen/keyboard/mouse >for it. There may be an other reason, at least for early rPi, like I have one. Some keyboards may have intermittent failures because the current available is really low. (So much for: "I've usb keyboards lying around") And the usb driver sucks, such that it misses characters, especially annoying while typing passwords. (It has been mentioned, the blackbeards feel more solid.) <SNIP> >martin@ | Martin Gregorie Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2014-10-27 06:52 -0700 |
| Message-ID | <0020e5c4-194f-42d9-b36f-4cd0f0b40a38@googlegroups.com> |
| In reply to | #34169 |
On Sunday, October 26, 2014 9:15:27 PM UTC+2, rickman wrote: > On 10/26/2014 2:57 PM, Andrew Gabriel wrote: > > In article <>, > > rickman <> writes: > >> On 10/26/2014 1:09 PM, Gordon Henderson wrote: > >>> > >>>> Now I need to learn how to use gforth to open a serial port and open a > >>>> window from and send text to it to be displayed. > >>> > >>> Other languages are avalable ... :-) > >> > >> Meaning what? Is using OS functions somehow easier in other languages? > > > > Always easiest in C because that's what the OS functions are written in, > > but many other languages (which might be easier for some people to use) > > can come close enough that other things can sway it in their favor. > > I'm still not following. How does the language the OS was written in > have any impact on the interfaces the OS provides? This is an OS > interface issue that does not require any recoding of the OS. So why > would I care what language the OS was written in? > > > > You could do what you suggest by using tip or cu in a terminal window > > (such as xterm) - no programming required other than typing the commands > > into a shell, because the OS already contains the programs (originally > > written in C). > > I don't think you have grasped what I am trying to do. I have a program > that controls a device over a serial port. It was written in Forth > using OS specific calls (Windows). It also opens a socket to > communicate with a Telnet client to display bi-directional serial port > data for debugging. Again, this uses OS specific calls. > > Now I wish to port this program to the rPi. Rather than mess with > sockets and a separate program as a terminal emulator, I am thinking it > might be cleaner to keep it self contained and display the message > traffic in a separate window opened by the Forth program. > > Or maybe I am not following what you are saying. How does tip or cu get > what I want with no programming? It sounds like they are terminal > emulators. I still have to code an interface to them. > > > > OTOH, if your objective is to learn forth, that won't help one bit. > > No, Forth is already one of my tools. Now I'm trying to learn the rPi > environment from the viewpoint of Forth. > > -- > > Rick Hi! The cleanest way is what Anton Ertl described. For a better help go http://www.complang.tuwien.ac.at/cvsweb/cgi-bin/cvsweb/gforth/status.fs and download last version. To better understand use gforth manual: from command line 'info gforth' and search for 'open-pipe'. Yet another way (ugly) is something like (copied from command line): $ cat xtermid.fs : xterm-id ( -- fid ;return fileid of a new Xterm ) s\" xterm -e 'tty>.tmp' && xterm &" system s\" .tmp" slurp-file 1- \ no line-terminator BEGIN 2dup w/o open-file 0 <> IF ( ca u wfileid|garbage ) drop 59 ms ELSE nip nip EXIT THEN AGAIN ; $ gforth xtermid.fs -e 'xterm-id :NONAME 256 0 DO dup i s>d <# 10 HOLD #S #> rot write-file throw LOOP ; execute close-file throw bye' Should start an xterm and type 0 .. 255 on each line. It start an 'xterm' and execute a 'tty' command redirected to '.tmp' file. Immediately it close and if ok, start a new 'xterm' that has the same terminal file-name. Read temporary file that contains terminal file-name, and try to open until success. Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-26 12:02 -0700 |
| Message-ID | <7xbnoyk62t.fsf@ruckus.brouhaha.com> |
| In reply to | #34164 |
rickman <gnuarm@gmail.com> writes: >>> Now I need to learn how to use gforth to open a serial port and open a >>> window from and send text to it to be displayed. >> Other languages are avalable ... :-) > Meaning what? Is using OS functions somehow easier in other languages? Pyserial (3rd party library) is pretty easy to work with if you want to mess with serial ports from Python. In either Forth or Python, you should be able to just launch a terminal and run your program from inside it, so your program can write to the terminal, rather than opening a window from within your program.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-26 15:18 -0400 |
| Message-ID | <m2jhev$69c$2@dont-email.me> |
| In reply to | #34168 |
On 10/26/2014 3:02 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>>> Now I need to learn how to use gforth to open a serial port and open a >>>> window from and send text to it to be displayed. >>> Other languages are avalable ... :-) >> Meaning what? Is using OS functions somehow easier in other languages? > > Pyserial (3rd party library) is pretty easy to work with if you want to > mess with serial ports from Python. > > In either Forth or Python, you should be able to just launch a terminal > and run your program from inside it, so your program can write to the > terminal, rather than opening a window from within your program. I'm not sure what you mean by launching a terminal and running my program inside it. Please remember I am not conversant with Linux. The Forth I use under Windows has a command line interface which I use as the user console. So I don't want to display the message traffic there as well. I believe that is what you are suggesting, no? Or would gforth provide its own window for interaction with the user and the "terminal" window would be separate? If so, how do I display data in it? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Gordon Henderson <gordon+usenet@drogon.net> |
|---|---|
| Date | 2014-10-26 20:24 +0000 |
| Message-ID | <m2jl9c$jf7$1@dont-email.me> |
| In reply to | #34164 |
In article <m2jfg5$ulh$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 10/26/2014 1:09 PM, Gordon Henderson wrote: >> >>> Now I need to learn how to use gforth to open a serial port and open a >>> window from and send text to it to be displayed. >> >> Other languages are avalable ... :-) > >Meaning what? Is using OS functions somehow easier in other languages? My remark was intended to be somewhat tongue-in-cheeck - hence the :-) in it. The Pi world seems to be full of Python-heads, so a lot of the Pi users will be using Python and there's a lot of support for that. Linux (and Unix in-general) probably has more C support than anything else though. But I see you're a Forth programmer and have an existing Forth program to port, so that's great - read the fine manual for GNU Forth about how it interfaces with things like the serial port, and X windows. Gordon
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-26 17:09 -0400 |
| Message-ID | <m2jnvm$ji$1@dont-email.me> |
| In reply to | #34177 |
On 10/26/2014 4:24 PM, Gordon Henderson wrote: > In article <m2jfg5$ulh$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 10/26/2014 1:09 PM, Gordon Henderson wrote: >>> >>>> Now I need to learn how to use gforth to open a serial port and open a >>>> window from and send text to it to be displayed. >>> >>> Other languages are avalable ... :-) >> >> Meaning what? Is using OS functions somehow easier in other languages? > > My remark was intended to be somewhat tongue-in-cheeck - hence the :-) in it. > > The Pi world seems to be full of Python-heads, so a lot of the Pi users > will be using Python and there's a lot of support for that. Linux (and > Unix in-general) probably has more C support than anything else though. > > But I see you're a Forth programmer and have an existing Forth program > to port, so that's great - read the fine manual for GNU Forth about how > it interfaces with things like the serial port, and X windows. 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, http://www.forth.org/svfig/kk/TestSerial.f.txt I'm also finding info saying I need to set group membership to allow access to the serial port. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Gordon Henderson <gordon+usenet@drogon.net> |
|---|---|
| Date | 2014-10-26 22:05 +0000 |
| Message-ID | <m2jr6j$cfs$1@dont-email.me> |
| In reply to | #34181 |
In article <m2jnvm$ji$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 10/26/2014 4:24 PM, Gordon Henderson wrote: >> In article <m2jfg5$ulh$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>> On 10/26/2014 1:09 PM, Gordon Henderson wrote: >>>> >>>>> Now I need to learn how to use gforth to open a serial port and open a >>>>> window from and send text to it to be displayed. >>>> >>>> Other languages are avalable ... :-) >>> >>> Meaning what? Is using OS functions somehow easier in other languages? >> >> My remark was intended to be somewhat tongue-in-cheeck - hence the :-) in it. >> >> The Pi world seems to be full of Python-heads, so a lot of the Pi users >> will be using Python and there's a lot of support for that. Linux (and >> Unix in-general) probably has more C support than anything else though. >> >> But I see you're a Forth programmer and have an existing Forth program >> to port, so that's great - read the fine manual for GNU Forth about how >> it interfaces with things like the serial port, and X windows. > >Manual? Manual!!??? There's an F'ing MANUAL??? This one? https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/ >The manual is mute on serial port usage. I have found some references, >but they mostly are Greek to me like, > >http://www.forth.org/svfig/kk/TestSerial.f.txt 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. >I'm also finding info saying I need to set group membership to allow >access to the serial port. 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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-26 20:27 -0400 |
| Message-ID | <m2k3hn$5lv$1@dont-email.me> |
| In reply to | #34187 |
On 10/26/2014 6:05 PM, Gordon Henderson wrote: > In article <m2jnvm$ji$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 10/26/2014 4:24 PM, Gordon Henderson wrote: >>> In article <m2jfg5$ulh$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>>> On 10/26/2014 1:09 PM, Gordon Henderson wrote: >>>>> >>>>>> Now I need to learn how to use gforth to open a serial port and open a >>>>>> window from and send text to it to be displayed. >>>>> >>>>> Other languages are avalable ... :-) >>>> >>>> Meaning what? Is using OS functions somehow easier in other languages? >>> >>> My remark was intended to be somewhat tongue-in-cheeck - hence the :-) in it. >>> >>> The Pi world seems to be full of Python-heads, so a lot of the Pi users >>> will be using Python and there's a lot of support for that. Linux (and >>> Unix in-general) probably has more C support than anything else though. >>> >>> But I see you're a Forth programmer and have an existing Forth program >>> to port, so that's great - read the fine manual for GNU Forth about how >>> it interfaces with things like the serial port, and X windows. >> >> Manual? Manual!!??? There's an F'ing MANUAL??? > > This one? > > https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/ Sorry, should have used a smiley. >> The manual is mute on serial port usage. I have found some references, >> but they mostly are Greek to me like, >> >> http://www.forth.org/svfig/kk/TestSerial.f.txt > > 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?) 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. > 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. 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. >> I'm also finding info saying I need to set group membership to allow >> access to the serial port. > > If you're running Raspbian then you ought to be OK. > > Type > > id > > if in the output it says (dialout) then you're fine. Yep, it says dialout, so that part is covered. > 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. I'll give that a try. I need to get used to a text editor first. > 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 Certainly I do need console I/O, but I also need a second screen. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-26 17:45 -0700 |
| Message-ID | <7x38aagx1c.fsf@ruckus.brouhaha.com> |
| In reply to | #34195 |
rickman <gnuarm@gmail.com> writes: >> However it looks way overly complicated to me - using threads (for why?) > Yeah, I didn't get it either. 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. > The windows I/O is just read-file, but it returns a length which can > be zero. 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: 5a. Run a program that opens /tmp/bob and writes stuff to it. This is probably the simplest way to deal with your unidirectional output problem.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-26 21:09 -0400 |
| Message-ID | <m2k61a$cck$1@dont-email.me> |
| In reply to | #34196 |
On 10/26/2014 8:45 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> However it looks way overly complicated to me - using threads (for why?) >> Yeah, I didn't get it either. > > 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. > >> The windows I/O is just read-file, but it returns a length which can >> be zero. > > 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: > > 5a. Run a program that opens /tmp/bob and writes stuff to it. > > 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? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-26 18:22 -0700 |
| Message-ID | <7xr3xutifo.fsf@ruckus.brouhaha.com> |
| In reply to | #34197 |
rickman <gnuarm@gmail.com> writes: > 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? 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. > Is there a way to have the first terminal window interpret ANSI > commands, or is that automatic? Automatic.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-26 23:20 -0400 |
| Message-ID | <m2kdmc$33h$1@dont-email.me> |
| In reply to | #34198 |
On 10/26/2014 9:22 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> 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? > > 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. > >> Is there a way to have the first terminal window interpret ANSI >> commands, or is that automatic? > > Automatic. Awesome. Thanks a lot. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-26 20:53 -0700 |
| Message-ID | <7x8uk2tbgg.fsf@ruckus.brouhaha.com> |
| In reply to | #34200 |
rickman <gnuarm@gmail.com> writes: >> Automatic. > 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.
[toc] | [prev] | [next] | [standalone]
| From | andrew@cucumber.demon.co.uk (Andrew Gabriel) |
|---|---|
| Date | 2014-10-27 10:23 +0000 |
| Message-ID | <m2l6fg$r1g$1@dont-email.me> |
| In reply to | #34196 |
In article <7x38aagx1c.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> writes: > rickman <gnuarm@gmail.com> writes: >>> However it looks way overly complicated to me - using threads (for why?) >> Yeah, I didn't get it either. > > 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. > >> The windows I/O is just read-file, but it returns a length which can >> be zero. > > 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: > > 5a. Run a program that opens /tmp/bob and writes stuff to it. > > This is probably the simplest way to deal with your unidirectional > output problem. 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]
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-27 13:36 -0700 |
| Message-ID | <7xsii9cks7.fsf@ruckus.brouhaha.com> |
| In reply to | #34211 |
andrew@cucumber.demon.co.uk (Andrew Gabriel) writes: > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | andrew@cucumber.demon.co.uk (Andrew Gabriel) |
|---|---|
| Date | 2014-10-27 22:23 +0000 |
| Message-ID | <m2mgkf$1ah$1@dont-email.me> |
| In reply to | #34222 |
In article <7xsii9cks7.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> writes: > andrew@cucumber.demon.co.uk (Andrew Gabriel) writes: >> 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. > > 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. 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]
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-10-27 09:43 +0000 |
| Message-ID | <544e13b6$0$6883$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #34195 |
In article <m2k3hn$5lv$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 10/26/2014 6:05 PM, Gordon Henderson wrote: >> In article <m2jnvm$ji$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>> On 10/26/2014 4:24 PM, Gordon Henderson wrote: >>>> In article <m2jfg5$ulh$1@dont-email.me>, rickman ><gnuarm@gmail.com> wrote: >>>>> On 10/26/2014 1:09 PM, Gordon Henderson wrote: >>>>>> >>>>>>> Now I need to learn how to use gforth to open a serial port and open a >>>>>>> window from and send text to it to be displayed. >>>>>> >>>>>> Other languages are avalable ... :-) >>>>> >>>>> Meaning what? Is using OS functions somehow easier in other languages? >>>> >>>> My remark was intended to be somewhat tongue-in-cheeck - hence >the :-) in it. >>>> >>>> The Pi world seems to be full of Python-heads, so a lot of the Pi users >>>> will be using Python and there's a lot of support for that. Linux (and >>>> Unix in-general) probably has more C support than anything else though. >>>> >>>> But I see you're a Forth programmer and have an existing Forth program >>>> to port, so that's great - read the fine manual for GNU Forth about how >>>> it interfaces with things like the serial port, and X windows. >>> >>> Manual? Manual!!??? There's an F'ing MANUAL??? >> >> This one? >> >> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/ > >Sorry, should have used a smiley. > > >>> The manual is mute on serial port usage. I have found some references, >>> but they mostly are Greek to me like, >>> >>> http://www.forth.org/svfig/kk/TestSerial.f.txt >> >> 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?) > >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. > > >> 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. > >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. (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. > > >>> I'm also finding info saying I need to set group membership to allow >>> access to the serial port. 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. >-- > >Rick Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Gordon Henderson <gordon+usenet@drogon.net> |
|---|---|
| Date | 2014-10-27 10:26 +0000 |
| Message-ID | <m2l6k3$rgb$1@dont-email.me> |
| In reply to | #34209 |
In article <544e13b6$0$6883$e4fe514c@dreader36.news.xs4all.nl>, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >(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. 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. >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? 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. >This also answers the question, why threads in Linux? >You really need them for time outs alone. 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
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-10-27 13:15 +0000 |
| Message-ID | <m2lgi5$l6s$2@dont-email.me> |
| In reply to | #34212 |
On Mon, 27 Oct 2014 10:26:11 +0000, Gordon Henderson wrote: > 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. > 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 org |
[toc] | [prev] | [next] | [standalone]
| From | Gordon Henderson <gordon+usenet@drogon.net> |
|---|---|
| Date | 2014-10-27 14:12 +0000 |
| Message-ID | <m2ljs9$bbe$1@dont-email.me> |
| In reply to | #34216 |
In article <m2lgi5$l6s$2@dont-email.me>, Martin Gregorie <martin@address-in-sig.invalid> wrote: >On Mon, 27 Oct 2014 10:26:11 +0000, Gordon Henderson wrote: > >> 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. >> >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. 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
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web