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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-28 12:51 -0400 |
| Message-ID | <m2ohj5$5uu$2@dont-email.me> |
| In reply to | #34248 |
On 10/28/2014 8:41 AM, Stephen Pelc wrote: > On Mon, 27 Oct 2014 17:37:05 -0400, rickman <gnuarm@gmail.com> wrote: > >> On 10/27/2014 7:30 AM, Stephen Pelc wrote: >>> On Sun, 26 Oct 2014 15:14:56 -0400, rickman <gnuarm@gmail.com> wrote: >>> >>>> 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. >>> >>> 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. >> >> Great, how does that help me use gForth? > > It doesn't, but it may be a cheaper solution overall when your > time is paid for. Perhaps, but I don't have a good way of estimating that. To be honest, I find the MPE web site to be confusing and hard to find info on your products. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-10-28 18:44 +0000 |
| Message-ID | <544fe39b.505701795@news.demon.co.uk> |
| In reply to | #34254 |
On Tue, 28 Oct 2014 12:51:27 -0400, rickman <gnuarm@gmail.com> wrote: >Perhaps, but I don't have a good way of estimating that. To be honest, >I find the MPE web site to be confusing and hard to find info on your >products. Well, we answer our emails - try the obvious one with the xxx removed, or ring the US access number 901-313-4312 during UK office hours - it's got voicemail, so we'll call back if we miss you. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-27 11:49 +0000 |
| Message-ID | <2014Oct27.124917@mips.complang.tuwien.ac.at> |
| In reply to | #34169 |
rickman <gnuarm@gmail.com> writes:
>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.
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
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-27 17:51 -0400 |
| Message-ID | <m2mepv$qae$1@dont-email.me> |
| In reply to | #34215 |
On 10/27/2014 7:49 AM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> 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. > > 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. 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
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-27 20:31 -1000 |
| Message-ID | <2YCdnVNUS67HpdLJnZ2dnUU7-XednZ2d@supernews.com> |
| In reply to | #34227 |
On 10/27/14 11:51 AM, rickman wrote: ... > > 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. Baffled by your concern. Native Forths have been doing this since the 1970's, without OSs of any kind. Serial port drivers took (in the good old days) about one block/sceen of code. Multiple tasks could manage their own screens or ports. IMO introducing OSs into the picture is complicating the process, not simplifying it. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-28 03:01 -0400 |
| Message-ID | <m2nf16$9pi$1@dont-email.me> |
| In reply to | #34236 |
On 10/28/2014 2:31 AM, Elizabeth D. Rather wrote: > On 10/27/14 11:51 AM, rickman wrote: > .... >> >> 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. > > Baffled by your concern. Native Forths have been doing this since the > 1970's, without OSs of any kind. Serial port drivers took (in the good > old days) about one block/sceen of code. Multiple tasks could manage > their own screens or ports. > > IMO introducing OSs into the picture is complicating the process, not > simplifying it. I'm baffled by your response. I'm not writing this from scratch. I have a working program that runs under Windows using Win32Forth. I'm just trying to port that to the rPi. What native Forth should I use that would be more suitable than using the Raspian OS that comes with the board? I believe I have seen a native Forth for the rPi, but I don't see how that makes anything more simple. Funny, one response in this thread says I am silly for thinking about writing my own code for the data display in a separate window since the OS provides so many other ways to do that. Now I am being told I am silly for not wanting to write nearly all of the code myself for the windows management as well as the serial port driver.... I think. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-27 21:14 -1000 |
| Message-ID | <G4qdndjs6Yjc39LJnZ2dnUU7-SGdnZ2d@supernews.com> |
| In reply to | #34237 |
On 10/27/14 9:01 PM, rickman wrote: > On 10/28/2014 2:31 AM, Elizabeth D. Rather wrote: >> On 10/27/14 11:51 AM, rickman wrote: >> .... >>> >>> 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. >> >> Baffled by your concern. Native Forths have been doing this since the >> 1970's, without OSs of any kind. Serial port drivers took (in the good >> old days) about one block/sceen of code. Multiple tasks could manage >> their own screens or ports. >> >> IMO introducing OSs into the picture is complicating the process, not >> simplifying it. > > I'm baffled by your response. I'm not writing this from scratch. I > have a working program that runs under Windows using Win32Forth. I'm > just trying to port that to the rPi. What native Forth should I use > that would be more suitable than using the Raspian OS that comes with > the board? I believe I have seen a native Forth for the rPi, but I > don't see how that makes anything more simple. > > Funny, one response in this thread says I am silly for thinking about > writing my own code for the data display in a separate window since the > OS provides so many other ways to do that. Now I am being told I am > silly for not wanting to write nearly all of the code myself for the > windows management as well as the serial port driver.... I think. Ok, if the board comes with all the code you need, why is there a long thread about how to do serial I/O? I understand that you have a whole application. It should be straightforward to write the underlying TYPE/ACCEPT support, either natively (I don't know how permissive Raspian is of folks doing their own I/O) or with OS calls. I do know that whatever solution you find will almost certainly be simpler than what you're doing under Windows. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-28 03:45 -0400 |
| Message-ID | <m2nhj5$gra$1@dont-email.me> |
| In reply to | #34239 |
On 10/28/2014 3:14 AM, Elizabeth D. Rather wrote: > On 10/27/14 9:01 PM, rickman wrote: >> On 10/28/2014 2:31 AM, Elizabeth D. Rather wrote: >>> On 10/27/14 11:51 AM, rickman wrote: >>> .... >>>> >>>> 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. >>> >>> Baffled by your concern. Native Forths have been doing this since the >>> 1970's, without OSs of any kind. Serial port drivers took (in the good >>> old days) about one block/sceen of code. Multiple tasks could manage >>> their own screens or ports. >>> >>> IMO introducing OSs into the picture is complicating the process, not >>> simplifying it. >> >> I'm baffled by your response. I'm not writing this from scratch. I >> have a working program that runs under Windows using Win32Forth. I'm >> just trying to port that to the rPi. What native Forth should I use >> that would be more suitable than using the Raspian OS that comes with >> the board? I believe I have seen a native Forth for the rPi, but I >> don't see how that makes anything more simple. >> >> Funny, one response in this thread says I am silly for thinking about >> writing my own code for the data display in a separate window since the >> OS provides so many other ways to do that. Now I am being told I am >> silly for not wanting to write nearly all of the code myself for the >> windows management as well as the serial port driver.... I think. > > Ok, if the board comes with all the code you need, why is there a long > thread about how to do serial I/O? I understand that you have a whole > application. It should be straightforward to write the underlying > TYPE/ACCEPT support, either natively (I don't know how permissive > Raspian is of folks doing their own I/O) or with OS calls. I do know > that whatever solution you find will almost certainly be simpler than > what you're doing under Windows. I'm just not following what you are saying. I think when you say "native" you mean not using the OS rather than not *having* an OS. I have no interest in writing an interrupt driver for an OS when one already exists. Why should I reinvent the wheel? Or do I still not understand what you are suggesting? You also mention OS calls which is exactly what I am asking about. I find your comparison to Windows a bit silly. So far everything I have been told is virtually the same as under Windows. As much as anything I am asking about gForth really. gForth runs under Linux and Windows. I'm hoping I can find code that works transparently under both. My point in asking about this is that I am sure I'm not the first person to use a serial port in gForth. The one code example found so far was very complicated, much more so than what I need. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-27 22:14 -1000 |
| Message-ID | <eZOdnWQJlO79zdLJnZ2dnUU7-eudnZ2d@supernews.com> |
| In reply to | #34240 |
On 10/27/14 9:45 PM, rickman wrote: > On 10/28/2014 3:14 AM, Elizabeth D. Rather wrote: >> On 10/27/14 9:01 PM, rickman wrote: >>> On 10/28/2014 2:31 AM, Elizabeth D. Rather wrote: >>>> On 10/27/14 11:51 AM, rickman wrote: >>>> .... >>>>> >>>>> 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. >>>> >>>> Baffled by your concern. Native Forths have been doing this since the >>>> 1970's, without OSs of any kind. Serial port drivers took (in the good >>>> old days) about one block/sceen of code. Multiple tasks could manage >>>> their own screens or ports. >>>> >>>> IMO introducing OSs into the picture is complicating the process, not >>>> simplifying it. >>> >>> I'm baffled by your response. I'm not writing this from scratch. I >>> have a working program that runs under Windows using Win32Forth. I'm >>> just trying to port that to the rPi. What native Forth should I use >>> that would be more suitable than using the Raspian OS that comes with >>> the board? I believe I have seen a native Forth for the rPi, but I >>> don't see how that makes anything more simple. >>> >>> Funny, one response in this thread says I am silly for thinking about >>> writing my own code for the data display in a separate window since the >>> OS provides so many other ways to do that. Now I am being told I am >>> silly for not wanting to write nearly all of the code myself for the >>> windows management as well as the serial port driver.... I think. >> >> Ok, if the board comes with all the code you need, why is there a long >> thread about how to do serial I/O? I understand that you have a whole >> application. It should be straightforward to write the underlying >> TYPE/ACCEPT support, either natively (I don't know how permissive >> Raspian is of folks doing their own I/O) or with OS calls. I do know >> that whatever solution you find will almost certainly be simpler than >> what you're doing under Windows. > > I'm just not following what you are saying. I think when you say > "native" you mean not using the OS rather than not *having* an OS. I > have no interest in writing an interrupt driver for an OS when one > already exists. Why should I reinvent the wheel? > > Or do I still not understand what you are suggesting? It can be easier to write the driver (which, in my experience, takes about an hour with no OS) than to spend days finding out how to do it through an OS. Back in the day, we ignored DOS calls for that very reason (DOS was much slower, anyway). I am not familiar with Linux or gForth, but the very fact that there has been such discussion here I find baffling. > You also mention OS calls which is exactly what I am asking about. I > find your comparison to Windows a bit silly. So far everything I have > been told is virtually the same as under Windows. As much as anything I > am asking about gForth really. gForth runs under Linux and Windows. I'm > hoping I can find code that works transparently under both. If it's easy and just the same as Windows, why the long discussion? > My point in asking about this is that I am sure I'm not the first person > to use a serial port in gForth. The one code example found so far was > very complicated, much more so than what I need. I fervently hope you find a simpler solution. Serial drivers should be simple. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-28 14:09 -0400 |
| Message-ID | <m2om5b$pjm$1@dont-email.me> |
| In reply to | #34243 |
On 10/28/2014 4:14 AM, Elizabeth D. Rather wrote: > On 10/27/14 9:45 PM, rickman wrote: >> On 10/28/2014 3:14 AM, Elizabeth D. Rather wrote: >>> On 10/27/14 9:01 PM, rickman wrote: >>>> On 10/28/2014 2:31 AM, Elizabeth D. Rather wrote: >>>>> On 10/27/14 11:51 AM, rickman wrote: >>>>> .... >>>>>> >>>>>> 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. >>>>> >>>>> Baffled by your concern. Native Forths have been doing this since the >>>>> 1970's, without OSs of any kind. Serial port drivers took (in the good >>>>> old days) about one block/sceen of code. Multiple tasks could manage >>>>> their own screens or ports. >>>>> >>>>> IMO introducing OSs into the picture is complicating the process, not >>>>> simplifying it. >>>> >>>> I'm baffled by your response. I'm not writing this from scratch. I >>>> have a working program that runs under Windows using Win32Forth. I'm >>>> just trying to port that to the rPi. What native Forth should I use >>>> that would be more suitable than using the Raspian OS that comes with >>>> the board? I believe I have seen a native Forth for the rPi, but I >>>> don't see how that makes anything more simple. >>>> >>>> Funny, one response in this thread says I am silly for thinking about >>>> writing my own code for the data display in a separate window since the >>>> OS provides so many other ways to do that. Now I am being told I am >>>> silly for not wanting to write nearly all of the code myself for the >>>> windows management as well as the serial port driver.... I think. >>> >>> Ok, if the board comes with all the code you need, why is there a long >>> thread about how to do serial I/O? I understand that you have a whole >>> application. It should be straightforward to write the underlying >>> TYPE/ACCEPT support, either natively (I don't know how permissive >>> Raspian is of folks doing their own I/O) or with OS calls. I do know >>> that whatever solution you find will almost certainly be simpler than >>> what you're doing under Windows. >> >> I'm just not following what you are saying. I think when you say >> "native" you mean not using the OS rather than not *having* an OS. I >> have no interest in writing an interrupt driver for an OS when one >> already exists. Why should I reinvent the wheel? >> >> Or do I still not understand what you are suggesting? > > It can be easier to write the driver (which, in my experience, takes > about an hour with no OS) than to spend days finding out how to do it > through an OS. There are several things wrong with that idea. The first is that I *want* to have the OS so that I can use the many other tools available under it. One of my issues with Linux is the lack of support from a variety of vendors, but for the most part I can do anything under Linux I can do under Windows. I bet you aren't typing your posts on a bare metal Forth machine. Secondly I disagree it is an hour job to write and debug a serial port driver on the rPi hardware. I have looked at the hardware manual and I expect it would take much longer just to find the info needed and learning how the device works in enough detail to use interrupts with the UART. This is not an MSP430 or an AVR. One of the reasons I wish to work with the rPi is to put me in a better position to build an add on card for the Pi. This card would very likely include a very low power FPGA and a GA144. But I need to have some level of confidence that I can get a fast interface to the Pi. Right now the few parallel lines and an SPI won't cut it. The BBB looks much better in that regard with a parallel memory mapped interface I am told. But the BBB has much less of a support group. In reality I am learning about Linux as the moment so it doesn't matter as much which hardware I am on. I can change that later if I find it important. > Back in the day, we ignored DOS calls for that very > reason (DOS was much slower, anyway). I am not familiar with Linux or > gForth, but the very fact that there has been such discussion here I > find baffling. Most of the discussion has actually been off topic in the sense that it was not directly along the line of minimal effort to my end. I thought it might be a good idea crossposting to both the Forth group and to the rPi group. It seems many of the replies from the rPi group are about the many different ways the window interface can be done. Many of the replies from the Forth group seem to be suggesting a variety of things, but few of them on target. I expected someone familiar with gForth would point me to an example saying, Here is how so and so did it" as I found when doing this under Win32Forth. The only example I found in gForth was very complex clearly due to needs that are not at all like mine. But I have most of the info I need and might be able to work out the rest. Now I need to figure out how to edit code on the rPi and I should be ready to proceed. I might work from my PC and control the rPi remotely. Or I have been thinking of changing editors on the PC anyway. Maybe this would be a good time to learn Emacs. >> You also mention OS calls which is exactly what I am asking about. I >> find your comparison to Windows a bit silly. So far everything I have >> been told is virtually the same as under Windows. As much as anything I >> am asking about gForth really. gForth runs under Linux and Windows. I'm >> hoping I can find code that works transparently under both. > > If it's easy and just the same as Windows, why the long discussion? I would ask you that question. If you aren't interested in helping, why are you in this discussion making it longer? >> My point in asking about this is that I am sure I'm not the first person >> to use a serial port in gForth. The one code example found so far was >> very complicated, much more so than what I need. > > I fervently hope you find a simpler solution. Serial drivers should be > simple. I think that is true, it is often the OS that is not so simple. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mel Wilson <mwilson@the-wire.com> |
|---|---|
| Date | 2014-10-28 21:50 +0000 |
| Message-ID | <m2p32s$d3p$1@dont-email.me> |
| In reply to | #34256 |
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. I might work from my PC and control the rPi > remotely. Or I have been thinking of changing editors on the PC anyway. > Maybe this would be a good time to learn Emacs. ISTR the nano editor is not bad. I hope I'm right in remembering that it's available on the Pi. Mel.
[toc] | [prev] | [next] | [standalone]
| From | "Ivan D. Reid" <Ivan.Reid@ivan.fsnet.co.uk> |
|---|---|
| Date | 2014-10-29 00:01 +0000 |
| Message-ID | <slrnm50bj5.519.Ivan.Reid@smtp.orangehome.co.uk> |
| In reply to | #34264 |
On Tue, 28 Oct 2014 21:50:22 +0000 (UTC), Mel Wilson <mwilson@the-wire.com>
wrote in <m2p32s$d3p$1@dont-email.me>:
> 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. I might work from my PC and control the rPi
>> remotely. Or I have been thinking of changing editors on the PC anyway.
>> Maybe this would be a good time to learn Emacs.
> ISTR the nano editor is not bad. I hope I'm right in remembering that
> it's available on the Pi.
Yes, I was thinking of recommending that; it's been available on every
Linux distro I've used lately, including Ubuntu on the Tegra TK1 "Jetson"
development kit. For simple text/code editing it doesn't have all the
baggage of emacs (or vi). Worth checking out if you don't *need* multi-
windows, multi-buffers, X windows, etc.
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-28 20:50 -0400 |
| Message-ID | <m2pdlu$hgl$1@dont-email.me> |
| In reply to | #34268 |
On 10/28/2014 8:01 PM, Ivan D. Reid wrote: > On Tue, 28 Oct 2014 21:50:22 +0000 (UTC), Mel Wilson <mwilson@the-wire.com> > wrote in <m2p32s$d3p$1@dont-email.me>: >> 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. I might work from my PC and control the rPi >>> remotely. Or I have been thinking of changing editors on the PC anyway. >>> Maybe this would be a good time to learn Emacs. > >> ISTR the nano editor is not bad. I hope I'm right in remembering that >> it's available on the Pi. > > Yes, I was thinking of recommending that; it's been available on every > Linux distro I've used lately, including Ubuntu on the Tegra TK1 "Jetson" > development kit. For simple text/code editing it doesn't have all the > baggage of emacs (or vi). Worth checking out if you don't *need* multi- > windows, multi-buffers, X windows, etc. Yeah, I'm sure there is a lot in emacs I don't need, but I do work in multiple languages including Verilog and VHDL and like the syntax coloring. Also, I'd like to switch editors on the PC so I am using the same one on all platforms. Nano might do this, but it is not clear from searching for this info. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Ivan D. Reid" <Ivan.Reid@ivan.fsnet.co.uk> |
|---|---|
| Date | 2014-10-29 01:20 +0000 |
| Message-ID | <slrnm50g69.569.Ivan.Reid@smtp.orangehome.co.uk> |
| In reply to | #34269 |
On Tue, 28 Oct 2014 20:50:48 -0400, rickman <gnuarm@gmail.com>
wrote in <m2pdlu$hgl$1@dont-email.me>:
> On 10/28/2014 8:01 PM, Ivan D. Reid wrote:
>> Yes, I was thinking of recommending that; it's been available on every
>> Linux distro I've used lately, including Ubuntu on the Tegra TK1 "Jetson"
>> development kit. For simple text/code editing it doesn't have all the
>> baggage of emacs (or vi). Worth checking out if you don't *need* multi-
>> windows, multi-buffers, X windows, etc.
> Yeah, I'm sure there is a lot in emacs I don't need, but I do work in
> multiple languages including Verilog and VHDL and like the syntax
> coloring. Also, I'd like to switch editors on the PC so I am using the
> same one on all platforms. Nano might do this, but it is not clear from
> searching for this info.
OK, I'm not sure if there's a "native" Windows version of nano.
You might not want to go down this route, but I use cygwin on Windows and
it does have nano. If you just use terminal screens it's not too hard;
going the full X windows route is a whole other steep learning curve. (If
you do go the whole hog with cygwinX, then (X)emacs becomes available on
Windows too -- but I'm pretty sure there's a more-native version
somewhere.)
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-10-29 00:58 +0000 |
| Message-ID | <m2pe38$5v9$2@dont-email.me> |
| In reply to | #34256 |
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. > 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. If you want some GUI capability, use VNC: you run vncserver on the RPi and a Windows version of vncviewer on the PC, or there's a Java applet that lets your web browser act as the viewer. Either way, this lets you drive the RPi from your PC's keyboard and mouse and see what its doing on the PC screen. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-28 18:04 -0700 |
| Message-ID | <7xsii7wusn.fsf@ruckus.brouhaha.com> |
| In reply to | #34270 |
Martin Gregorie <martin@address-in-sig.invalid> writes: > 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 Note you can still use the named pipe approach to multiple Forth windows by just opening multiple putty windows as described above. Run gforth in one of them and cat the named pipe to another.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-29 01:40 -0400 |
| Message-ID | <m2puku$j8e$2@dont-email.me> |
| In reply to | #34270 |
On 10/28/2014 8:58 PM, Martin Gregorie 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. I was working with some folks who run Linux in their network boxes. I couldn't do anything without specific instructions because they are so used to the command line editor. They would do stuff and it would be in a "mode" where I couldn't type and didn't know to hit esc to get out. lol I think he said it was like vi. You point may be very valid. >> 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. > > If you want some GUI capability, use VNC: you run vncserver on the RPi > and a Windows version of vncviewer on the PC, or there's a Java applet > that lets your web browser act as the viewer. Either way, this lets you > drive the RPi from your PC's keyboard and mouse and see what its doing on > the PC screen. Thanks, I'll take a look at that. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-10-29 12:41 +0000 |
| Message-ID | <m2qn9n$d01$2@dont-email.me> |
| In reply to | #34273 |
On Wed, 29 Oct 2014 01:40:24 -0400, rickman wrote: > I was working with some folks who run Linux in their network boxes. I > couldn't do anything without specific instructions because they are so > used to the command line editor. They would do stuff and it would be in > a "mode" where I couldn't type and didn't know to hit esc to get out. > lol I think he said it was like vi. You point may be very valid. > > Raspbian installs vi as part of the standard installation and vim is also available. vim definitely offers syntax colouring regardless of whether its being run as in an xterm console or as a GUI application and later versions of vi do the same. Both leave it off by default but it can ve enabled globally by editing /etc/virc (for vi) or /etc/vimrc (for vim) or you can control it locally from within vi/vim by typing the colon command ":syntax on". -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Theo Markettos <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2014-11-16 15:34 +0000 |
| Message-ID | <mQx*-dJgv@news.chiark.greenend.org.uk> |
| In reply to | #34273 |
In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: > I was working with some folks who run Linux in their network boxes. I > couldn't do anything without specific instructions because they are so > used to the command line editor. They would do stuff and it would be in > a "mode" where I couldn't type and didn't know to hit esc to get out. > lol I think he said it was like vi. You point may be very valid. vi is horrible. It's like one of those early 20th century electric tools with no safety features whatsoever, so you couldn't just pick it up and use it, you had to learn how to not electrocute yourself first. There are some other command line editors about that aren't quite so bloody: 'nano' usually ships with most Linux distros. It actually has an on-screen prompt that tells you what the keypresses are. So you can edit a file without having to learn anything. nano is a bit limiting, but enough to get by. For more serious editing I prefer 'joe', which again has an on-screen help bar, but has lots more editing features than nano. joe usually has to be installed with the package manager. emacs might come in handy here too, except its keypresses are more arcane and it's harder to find them out in the program. (eg I start emacs, it tells me to press Ctrl-h for help, I do that, says press ? for more, then splits the screen and shows me a list of help topics including 'b' for key bindings, press that and a list of keystrokes come up in the bottom split of the screen. But the input focus is in the window in the top half of the screen, and the key bindings that I can see don't tell me how to switch focus to get to the key bindings list to scroll them. So the help isn't actually helpful at all) For some of these tools, discoverability is a complete disaster. Theo
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-11-16 12:01 -0500 |
| Message-ID | <op.xpff701zmk81un@localhost> |
| In reply to | #34434 |
On Sun, 16 Nov 2014 10:34:20 -0500, Theo Markettos <theom+news@chiark.greenend.org.uk> wrote: > In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: >> I was working with some folks who run Linux in their network boxes. I >> couldn't do anything without specific instructions because they are so >> used to the command line editor. They would do stuff and it would be in >> a "mode" where I couldn't type and didn't know to hit esc to get out. >> lol I think he said it was like vi. You point may be very valid. > > vi is horrible. It's like one of those early 20th century electric tools > with no safety features whatsoever, so you couldn't just pick it up and > use it, you had to learn how to not electrocute yourself first. > While I prefer EDIT, on MS-DOS, or a very similar editor, Leafpad, on Linux, you only need to know 6 VI commands and 3 EX/ED commands to use VI very effectively. If you use GREP, you probably already familiar the regular expressions that VI uses. One of the areas where VI excels, due to the EX/ED commands, is matching many lines on a line-by-line basis from a command instead of visually editing, although it has a visual editing mode too, at least on Linux nowadays. The line-by-line ability makes VI excellent for processing lists or word dictionaries or DNS names or Usenet groups list or C program output or system logs, etc. The other area where VI excels is that good ports of it are available on nearly every platform, even including DOS. It's probably worth learning just for that. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web