Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41632 > unrolled thread
| Started by | Mark Wills <markwills1970@gmail.com> |
|---|---|
| First post | 2015-09-01 00:49 -0700 |
| Last post | 2015-10-06 01:37 -0400 |
| Articles | 20 on this page of 132 — 35 participants |
Back to article view | Back to comp.lang.forth
Could Forth be getting a bit of traction? Mark Wills <markwills1970@gmail.com> - 2015-09-01 00:49 -0700
Re: Could Forth be getting a bit of traction? mentificium@gmail.com - 2015-09-01 04:18 -0700
Re: Could Forth be getting a bit of traction? Steve Graham <jsgrahamus@yahoo.com> - 2015-09-01 09:51 -0700
Re: Could Forth be getting a bit of traction? Andreas Wagner <andreas.wagner@lowfatcomputing.org> - 2015-09-01 10:23 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-02 13:53 -0700
Re: Could Forth be getting a bit of traction? Greg <borota@gmail.com> - 2015-09-04 17:35 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-04 18:27 -0700
Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-04 21:04 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 00:27 -0400
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-04 21:48 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 01:10 -0400
Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-04 22:19 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-04 23:31 -0700
Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-05 07:28 -0700
Re: Could Forth be getting a bit of traction? Alfred Singlestone <vitonis@gmail.com> - 2015-09-05 08:10 -0700
Re: Could Forth be getting a bit of traction? foxaudioresearch@gmail.com - 2015-09-05 09:05 -0700
Re: Could Forth be getting a bit of traction? visualforth@rocketmail.com - 2015-09-05 09:07 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 13:08 -0400
Re: Could Forth be getting a bit of traction? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 16:32 +0000
Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:19 +0200
Re: Could Forth be getting a bit of traction? Jason Damisch <jasondamisch@yahoo.com> - 2015-09-05 13:28 -0700
Re: Could Forth be getting a bit of traction? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 12:09 +0000
Re: Could Forth be getting a bit of traction? Richard Owlett <rowlett@cloud85.net> - 2015-09-06 13:27 -0500
Re: Could Forth be getting a bit of traction? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-07 15:36 +0000
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-07 09:46 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-05 14:20 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-06 20:52 -0700
Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-05 12:11 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-05 19:56 -0700
Re: Could Forth be getting a bit of traction? Greg <borota@gmail.com> - 2015-09-06 09:39 -0700
Re: Could Forth be getting a bit of traction? mhx@iae.nl - 2015-09-06 13:01 -0700
Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-06 18:48 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-06 19:43 -0700
Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-06 20:59 -0700
Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-08 19:46 +0000
Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-08 13:28 -0700
Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-08 17:27 -0700
Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-09 03:35 +0200
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-09-08 19:48 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 20:28 -0700
Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-08 20:48 -0700
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-09-08 21:00 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 21:35 -0700
Re: Could Forth be getting a bit of traction? mhx@iae.nl - 2015-09-10 15:20 -0700
Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-10 17:26 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-10 14:57 -1000
Re: Could Forth be getting a bit of traction? julian.fondren@endurance.com - 2015-09-10 20:47 -0700
Re: Could Forth be getting a bit of traction? mhx@iae.nl (Marcel Hendrix) - 2015-09-11 10:49 +0200
Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-11 10:16 -0700
Re: Could Forth be getting a bit of traction? Ron Aaron <rambamist@gmail.com> - 2015-09-09 07:42 +0300
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-08 18:41 -0400
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 19:24 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-08 20:59 -1000
Re: Could Forth be getting a bit of traction? Greg <borota@gmail.com> - 2015-09-09 15:47 -0700
Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-11 08:15 -0700
Re: Could Forth be getting a bit of traction? visualforth@rocketmail.com - 2015-10-04 19:59 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-04 17:48 -1000
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-04 21:10 -0700
Re: Could Forth be getting a bit of traction? Roberto Waltman <usenet@rwaltman.com> - 2015-10-05 00:53 -0400
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-05 03:51 -0400
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-04 18:58 -1000
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-04 23:35 -0700
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-04 23:44 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-05 08:54 -1000
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-05 12:58 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-06 01:35 -0400
Re: Could Forth be getting a bit of traction? JUERGEN <epldfpga@aol.com> - 2015-10-06 02:58 -0700
Re: Could Forth be getting a bit of traction? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-06 04:05 -0700
Re: Could Forth be getting a bit of traction? Mark Wills <markwills1970@gmail.com> - 2015-10-06 04:22 -0700
Re: Could Forth be getting a bit of traction? JUERGEN <epldfpga@aol.com> - 2015-10-06 15:00 -0700
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-06 16:02 -0700
Re: Could Forth be getting a bit of traction? Ron Aaron <rambamist@gmail.com> - 2015-10-07 07:49 +0300
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-06 15:04 -0700
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-09 14:16 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-06 09:34 -0400
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-06 09:08 -1000
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-06 20:49 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-07 00:56 -0400
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-06 21:11 -1000
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-09 21:07 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-10 19:38 -0400
Re: Could Forth be getting a bit of traction? Paul Rubin <no.email@nospam.invalid> - 2015-10-10 20:46 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-11 01:16 -0400
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-10-10 22:50 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-04 21:21 -1000
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-10-05 08:26 -0700
Re: Could Forth be getting a bit of traction? Alfred Singlestone <vitonis@gmail.com> - 2015-10-06 07:13 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-10 00:12 -0700
Re: Could Forth be getting a bit of traction? humptydumpty <ouatubi@gmail.com> - 2015-09-08 11:48 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-08 20:55 -1000
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-09 02:28 -0700
Re: Could Forth be getting a bit of traction? november.nihal@gmail.com - 2015-09-09 03:36 -0700
Re: Could Forth be getting a bit of traction? Marek Brunda <marekb@phoenics.org> - 2015-09-09 03:59 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-09 07:34 -1000
Re: Could Forth be getting a bit of traction? jim.brakefield@ieee.org - 2015-09-09 12:32 -0700
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-10 17:10 -0700
Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-09 18:59 +0000
Re: Could Forth be getting a bit of traction? Whammo <sidciavic@gmail.com> - 2015-09-09 12:28 -0700
structs/unions/records (was: Could Forth be getting a bit of traction?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-09 07:10 +0000
Re: structs/unions/records (was: Could Forth be getting a bit of traction?) hughaguilar96@gmail.com - 2015-09-09 02:18 -0700
Re: structs/unions/records rickman <gnuarm@gmail.com> - 2015-09-09 23:27 -0400
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-06 23:18 -0700
Re: Could Forth be getting a bit of traction? awegel@arcor.de (Alexander Wegel) - 2015-09-07 12:57 +0200
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-07 09:55 -0700
Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-07 18:45 +0000
Re: Could Forth be getting a bit of traction? awegel@arcor.de (Alexander Wegel) - 2015-09-08 00:13 +0200
Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-08 01:51 +0200
Re: Could Forth be getting a bit of traction? awegel@arcor.de (Alexander Wegel) - 2015-09-08 00:13 +0200
Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-07 18:27 +0000
Re: Could Forth be getting a bit of traction? borota@gmail.com - 2015-09-07 12:23 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-07 16:14 -0400
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-07 17:39 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-08 01:39 -0400
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-05 03:12 -0400
Re: Could Forth be getting a bit of traction? foxaudioresearch@gmail.com - 2015-09-05 09:02 -0700
Re: Could Forth be getting a bit of traction? "WJ" <w_a_x_man@yahoo.com> - 2015-09-05 16:47 +0000
Re: Could Forth be getting a bit of traction? Alfred Singlestone <vitonis@gmail.com> - 2015-09-05 11:13 -0700
Re: Could Forth be getting a bit of traction? josv@planet.nl - 2015-09-01 12:37 -0700
Re: Could Forth be getting a bit of traction? Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-01 22:02 +0200
Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-08 03:45 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-09-08 07:54 -1000
Re: Could Forth be getting a bit of traction? hughaguilar96@gmail.com - 2015-09-08 19:08 -0700
Re: Could Forth be getting a bit of traction? Mux <Yvo.Zoer@gmail.com> - 2015-09-09 15:00 -0700
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-09-09 23:18 -0400
Re: Could Forth be getting a bit of traction? p.lad.work@gmail.com - 2015-10-05 05:04 -0700
Re: Could Forth be getting a bit of traction? foxaudioresearch@gmail.com - 2015-10-05 06:39 -0700
Re: Could Forth be getting a bit of traction? Chris Curl <ccurl609@gmail.com> - 2015-10-05 18:44 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-05 17:47 -1000
Re: Could Forth be getting a bit of traction? Chris Curl <ccurl609@gmail.com> - 2015-10-05 21:58 -0700
Re: Could Forth be getting a bit of traction? Jason Damisch <jasondamisch@yahoo.com> - 2015-10-06 10:55 -0700
Re: Could Forth be getting a bit of traction? "Elizabeth D. Rather" <erather@forth.com> - 2015-10-06 09:13 -1000
Re: Could Forth be getting a bit of traction? rickman <gnuarm@gmail.com> - 2015-10-06 01:37 -0400
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-04 18:58 -1000 |
| Message-ID | <fN2dnTvbh47lno_LnZ2dnUU7-Yf46u6z@supernews.com> |
| In reply to | #42365 |
On 10/4/15 6:10 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>> For a newcomer nowadays it is not that easy to decide which Forth to >>> start with, especially with microcontrollers. >> For private exploration or hobby programming, the evaluation versions >> of the commercial packages are a great choice. > > Are any of them available for microcontrollers? I thought they were > just for Windows/Linux/Mac. SwiftX is an interactive cross-development system. The host runs on Windows/Linux/Mac, and there are target for most popular microcontrollers. It's really a far more convenient and satisfactory development environment than running a limited compiler entirely on the target. > Hmm actually there's MPE Lite: > > http://mpeforth.com/xc7lite.htm > > There are some code size limitations but it sounds usable, at least on > certain devices. > > I don't see a comparable version of Swift? Maybe I'm not looking in the > right place. Here: http://www.forth.com/embedded/index.html > > Meanwhile, I see Forth Application Techniques is $500 a copy on Amazon! > > http://www.amazon.com/dp/0966215613 > > Might be time for a new edition or printing ;-) That's actually the 2006 spiral-bound edition (historical artifact?). The current updated version is $18.99 :-) 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-04 23:35 -0700 |
| Message-ID | <87bncd960s.fsf@jester.gateway.sonic.net> |
| In reply to | #42367 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Here: http://www.forth.com/embedded/index.html Nice! Somehow I missed that there was an evaluation version, and I thought that I had checked. >> http://www.amazon.com/dp/0966215613 >> Might be time for a new edition or printing ;-) > That's actually the 2006 spiral-bound edition (historical > artifact?). The current updated version is $18.99 :-) I see a 2008 paperback edition for $248.26: http://www.amazon.com/dp/B00JYHV1XA I also see a paperback course notebook for $18.99: http://www.amazon.com/dp/1419685767 Is that the actual book? I saw it earlier but thought "course notebook" meant it was some kind of supplemental material that accompanied the main book. You might want to clarify that on the Amazon page.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-04 23:44 -0700 |
| Message-ID | <877fn195mg.fsf@jester.gateway.sonic.net> |
| In reply to | #42368 |
Paul Rubin <no.email@nospam.invalid> writes: >> Here: http://www.forth.com/embedded/index.html > Nice! Somehow I missed that there was an evaluation version Unfortunately it looks like they're all Windows .exe's. I might be able to try one out sometime but Linux would be much easier. It would be extra interesting to have an ARM Linux version that could be hosted on a Raspberry Pi or Beaglebone. I'm not really the target audience for this sort of thing though.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-05 08:54 -1000 |
| Message-ID | <rsydnQ0k5rbjWo_LnZ2dnUU7-S2dnZ2d@supernews.com> |
| In reply to | #42369 |
On 10/4/15 8:44 PM, Paul Rubin wrote: > Paul Rubin <no.email@nospam.invalid> writes: >>> Here: http://www.forth.com/embedded/index.html >> Nice! Somehow I missed that there was an evaluation version > > Unfortunately it looks like they're all Windows .exe's. I might be able > to try one out sometime but Linux would be much easier. It would be > extra interesting to have an ARM Linux version that could be hosted on a > Raspberry Pi or Beaglebone. I'm not really the target audience for this > sort of thing though. SwiftX only runs on Windows because most of the vendors' debug interfaces (which we use on the host side) are Windows only. There has been little interested in Linux hosts and none on OSX. As for the Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a host, it's a target. We prefer a PC host because it's capable of supporting a powerful optimizing compiler for the target as well as the most convenient editing and debugging tools. Target platforms may have an optional, limited compiling capability, but our assumption is that the major application development should be supported by the most powerful tools available. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-05 12:58 -0700 |
| Message-ID | <87vbal6qad.fsf@jester.gateway.sonic.net> |
| In reply to | #42378 |
"Elizabeth D. Rather" <erather@forth.com> writes: > As for the Raspberry Pi, it's not an i386 -- it's an ARM, so it would > not be a host, it's a target. We prefer a PC host because it's capable > of supporting a powerful optimizing compiler for the target as well as > the most convenient editing and debugging tools. The current Raspberry Pi is equivalent to a fairly powerful PC of maybe 10 years ago, with four 700 mhz cores and 1GB of ram if I remember right, plus an SD card for mass storage. It can run Windows 10 these days (ARM version of course). So it should be able to run all the SwiftX tools, though I take your point about vendor debug tools requiring x86 Windows. That hadn't occurred to me since most developers I know use Linux (primarily on servers), but I get that the embedded sector is different.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-06 01:35 -0400 |
| Message-ID | <muvmg9$bce$1@dont-email.me> |
| In reply to | #42378 |
On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote: > On 10/4/15 8:44 PM, Paul Rubin wrote: >> Paul Rubin <no.email@nospam.invalid> writes: >>>> Here: http://www.forth.com/embedded/index.html >>> Nice! Somehow I missed that there was an evaluation version >> >> Unfortunately it looks like they're all Windows .exe's. I might be able >> to try one out sometime but Linux would be much easier. It would be >> extra interesting to have an ARM Linux version that could be hosted on a >> Raspberry Pi or Beaglebone. I'm not really the target audience for this >> sort of thing though. > > SwiftX only runs on Windows because most of the vendors' debug > interfaces (which we use on the host side) are Windows only. There has > been little interested in Linux hosts and none on OSX. As for the > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a > host, it's a target. We prefer a PC host because it's capable of > supporting a powerful optimizing compiler for the target as well as the > most convenient editing and debugging tools. > > Target platforms may have an optional, limited compiling capability, but > our assumption is that the major application development should be > supported by the most powerful tools available. I think 10 years ago that may have been a valid perspective. But these days you don't need an i7 with 16 GB of memory to compile programs to run on *any* processor, much less a Cortex M3 or an MSP430. I think the mobile market has so promoted lightweight computing that it is a bit silly to think you need the power of a workstation to develop code when practical experience is telling us that many much simpler platforms are proving to be very productive. The rPi is just the tip of the ice burg. I know my preference is to move to lighter weight platforms for *all* my computing needs. I expect that will prove to be true for many in the near future. My last embedded application was done using Mecrisp on the target while using the rPi as a host, because of the poor support for Windows by the chip vendor. I only used the PC to provide a keyboard and screen to the rPi. I have put off buying one of the new rPi 2 with the quad core processor. When I get it I may leave the laptop out of it entirely and work directly on the rPi. The laptop is a *crappy* keyboard. BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next target. I am thinking of porting Mecrisp to it. I don't think that will be any harder than getting one of the commercial Forths to work with it. I could be wrong. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2015-10-06 02:58 -0700 |
| Message-ID | <a76cd6ba-7522-419f-a506-49e1630296a9@googlegroups.com> |
| In reply to | #42386 |
On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote: > On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote: > > On 10/4/15 8:44 PM, Paul Rubin wrote: > >> Paul Rubin <no.email@nospam.invalid> writes: > >>>> Here: http://www.forth.com/embedded/index.html > >>> Nice! Somehow I missed that there was an evaluation version > >> > >> Unfortunately it looks like they're all Windows .exe's. I might be able > >> to try one out sometime but Linux would be much easier. It would be > >> extra interesting to have an ARM Linux version that could be hosted on a > >> Raspberry Pi or Beaglebone. I'm not really the target audience for this > >> sort of thing though. > > > > SwiftX only runs on Windows because most of the vendors' debug > > interfaces (which we use on the host side) are Windows only. There has > > been little interested in Linux hosts and none on OSX. As for the > > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a > > host, it's a target. We prefer a PC host because it's capable of > > supporting a powerful optimizing compiler for the target as well as the > > most convenient editing and debugging tools. > > > > Target platforms may have an optional, limited compiling capability, but > > our assumption is that the major application development should be > > supported by the most powerful tools available. > > I think 10 years ago that may have been a valid perspective. But these > days you don't need an i7 with 16 GB of memory to compile programs to > run on *any* processor, much less a Cortex M3 or an MSP430. > > I think the mobile market has so promoted lightweight computing that it > is a bit silly to think you need the power of a workstation to develop > code when practical experience is telling us that many much simpler > platforms are proving to be very productive. > > The rPi is just the tip of the ice burg. I know my preference is to > move to lighter weight platforms for *all* my computing needs. I expect > that will prove to be true for many in the near future. My last > embedded application was done using Mecrisp on the target while using > the rPi as a host, because of the poor support for Windows by the chip > vendor. I only used the PC to provide a keyboard and screen to the rPi. > I have put off buying one of the new rPi 2 with the quad core > processor. When I get it I may leave the laptop out of it entirely and > work directly on the rPi. The laptop is a *crappy* keyboard. > > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next > target. I am thinking of porting Mecrisp to it. I don't think that > will be any harder than getting one of the commercial Forths to work > with it. I could be wrong. > > -- > > Rick Elizabeth explained what the product offer is - what their customers want. We are talking commercial product You say the product is not what you want. So you will not buy it - fine You have other options: try if MPE can deliver what you want - the only other commercial alternative to my knowledge, or write your own compiler optimized for what you want and additionally there are sufficient free solutions out there. Not very helpful comment of your's I think.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-10-06 04:05 -0700 |
| Message-ID | <8613719b-4a5a-40e7-b058-796e619d7f35@googlegroups.com> |
| In reply to | #42389 |
marți, 6 octombrie 2015, 12:58:16 UTC+3, JUERGEN a scris: > On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote: > > On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote: > > > On 10/4/15 8:44 PM, Paul Rubin wrote: > > >> Paul Rubin <no.email@nospam.invalid> writes: > > >>>> Here: http://www.forth.com/embedded/index.html > > >>> Nice! Somehow I missed that there was an evaluation version > > >> > > >> Unfortunately it looks like they're all Windows .exe's. I might be able > > >> to try one out sometime but Linux would be much easier. It would be > > >> extra interesting to have an ARM Linux version that could be hosted on a > > >> Raspberry Pi or Beaglebone. I'm not really the target audience for this > > >> sort of thing though. > > > > > > SwiftX only runs on Windows because most of the vendors' debug > > > interfaces (which we use on the host side) are Windows only. There has > > > been little interested in Linux hosts and none on OSX. As for the > > > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a > > > host, it's a target. We prefer a PC host because it's capable of > > > supporting a powerful optimizing compiler for the target as well as the > > > most convenient editing and debugging tools. > > > > > > Target platforms may have an optional, limited compiling capability, but > > > our assumption is that the major application development should be > > > supported by the most powerful tools available. > > > > I think 10 years ago that may have been a valid perspective. But these > > days you don't need an i7 with 16 GB of memory to compile programs to > > run on *any* processor, much less a Cortex M3 or an MSP430. > > > > I think the mobile market has so promoted lightweight computing that it > > is a bit silly to think you need the power of a workstation to develop > > code when practical experience is telling us that many much simpler > > platforms are proving to be very productive. > > > > The rPi is just the tip of the ice burg. I know my preference is to > > move to lighter weight platforms for *all* my computing needs. I expect > > that will prove to be true for many in the near future. My last > > embedded application was done using Mecrisp on the target while using > > the rPi as a host, because of the poor support for Windows by the chip > > vendor. I only used the PC to provide a keyboard and screen to the rPi. > > I have put off buying one of the new rPi 2 with the quad core > > processor. When I get it I may leave the laptop out of it entirely and > > work directly on the rPi. The laptop is a *crappy* keyboard. > > > > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next > > target. I am thinking of porting Mecrisp to it. I don't think that > > will be any harder than getting one of the commercial Forths to work > > with it. I could be wrong. > > > > -- > > > > Rick > > Elizabeth explained what the product offer is - what their customers want. > We are talking commercial product > You say the product is not what you want. So you will not buy it - fine > You have other options: > try if MPE can deliver what you want - the only other commercial alternative to my knowledge, > or write your own compiler optimized for what you want > and additionally there are sufficient free solutions out there. > Not very helpful comment of your's I think. You always seem to be very upset when free forth implementations come to disscussion. The subject is "Could Forth be getting a bit of traction?" and not "Could Commercial Forths be getting a bit of traction?". I also feel free to post anything about free/open source forths here, but I don't, because all I would say is "no, it doesn't". Anyway, do you think that commercial forth vendors can do anything to help the "traction?" When there are only two of them as you said? My strong feeling is that the open source community is the only one that can really help. But this open source community is very thin... For example, I have a big application pending, for a Cortex-M4 with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I have a hard time deciding where to choose Lua/elua or Micropython for it. "Standard" forth is lower level than C, so no way (I would consider at most oforth or Factor, but I can't do that as long as they are not open source...)
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-10-06 04:22 -0700 |
| Message-ID | <f1d545f6-2026-4cbd-8251-2d4a5b2f7013@googlegroups.com> |
| In reply to | #42390 |
On Tuesday, 6 October 2015 12:06:01 UTC+1, Raimond Dragomir wrote: > marți, 6 octombrie 2015, 12:58:16 UTC+3, JUERGEN a scris: > > On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote: > > > On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote: > > > > On 10/4/15 8:44 PM, Paul Rubin wrote: > > > >> Paul Rubin <no.email@nospam.invalid> writes: > > > >>>> Here: http://www.forth.com/embedded/index.html > > > >>> Nice! Somehow I missed that there was an evaluation version > > > >> > > > >> Unfortunately it looks like they're all Windows .exe's. I might be able > > > >> to try one out sometime but Linux would be much easier. It would be > > > >> extra interesting to have an ARM Linux version that could be hosted on a > > > >> Raspberry Pi or Beaglebone. I'm not really the target audience for this > > > >> sort of thing though. > > > > > > > > SwiftX only runs on Windows because most of the vendors' debug > > > > interfaces (which we use on the host side) are Windows only. There has > > > > been little interested in Linux hosts and none on OSX. As for the > > > > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a > > > > host, it's a target. We prefer a PC host because it's capable of > > > > supporting a powerful optimizing compiler for the target as well as the > > > > most convenient editing and debugging tools. > > > > > > > > Target platforms may have an optional, limited compiling capability, but > > > > our assumption is that the major application development should be > > > > supported by the most powerful tools available. > > > > > > I think 10 years ago that may have been a valid perspective. But these > > > days you don't need an i7 with 16 GB of memory to compile programs to > > > run on *any* processor, much less a Cortex M3 or an MSP430. > > > > > > I think the mobile market has so promoted lightweight computing that it > > > is a bit silly to think you need the power of a workstation to develop > > > code when practical experience is telling us that many much simpler > > > platforms are proving to be very productive. > > > > > > The rPi is just the tip of the ice burg. I know my preference is to > > > move to lighter weight platforms for *all* my computing needs. I expect > > > that will prove to be true for many in the near future. My last > > > embedded application was done using Mecrisp on the target while using > > > the rPi as a host, because of the poor support for Windows by the chip > > > vendor. I only used the PC to provide a keyboard and screen to the rPi. > > > I have put off buying one of the new rPi 2 with the quad core > > > processor. When I get it I may leave the laptop out of it entirely and > > > work directly on the rPi. The laptop is a *crappy* keyboard. > > > > > > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next > > > target. I am thinking of porting Mecrisp to it. I don't think that > > > will be any harder than getting one of the commercial Forths to work > > > with it. I could be wrong. > > > > > > -- > > > > > > Rick > > > > Elizabeth explained what the product offer is - what their customers want. > > We are talking commercial product > > You say the product is not what you want. So you will not buy it - fine > > You have other options: > > try if MPE can deliver what you want - the only other commercial alternative to my knowledge, > > or write your own compiler optimized for what you want > > and additionally there are sufficient free solutions out there. > > Not very helpful comment of your's I think. > > You always seem to be very upset when free forth implementations come to disscussion. The subject is "Could Forth be getting a bit of traction?" and not "Could Commercial Forths be getting a bit of traction?". > I also feel free to post anything about free/open source forths here, but I don't, because all I would say is "no, it doesn't". > Anyway, do you think that commercial forth vendors can do anything to help the "traction?" When there are only two of them as you said? > My strong feeling is that the open source community is the only one that can really help. But this open source community is very thin... For example, I have a big application pending, for a Cortex-M4 with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I have a hard time deciding where to choose Lua/elua or Micropython for it. "Standard" forth is lower level than C, so no way (I would consider at most oforth or Factor, but I can't do that as long as they are not open source...) Lack of libraries is the issue IMO.
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2015-10-06 15:00 -0700 |
| Message-ID | <cff6cdde-f215-486c-8b6c-e0cc2326e158@googlegroups.com> |
| In reply to | #42390 |
On Tuesday, October 6, 2015 at 12:06:01 PM UTC+1, Raimond Dragomir wrote: > marți, 6 octombrie 2015, 12:58:16 UTC+3, JUERGEN a scris: > > On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote: > > > On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote: > > > > On 10/4/15 8:44 PM, Paul Rubin wrote: > > > >> Paul Rubin <no.email@nospam.invalid> writes: > > > >>>> Here: http://www.forth.com/embedded/index.html > > > >>> Nice! Somehow I missed that there was an evaluation version > > > >> > > > >> Unfortunately it looks like they're all Windows .exe's. I might be able > > > >> to try one out sometime but Linux would be much easier. It would be > > > >> extra interesting to have an ARM Linux version that could be hosted on a > > > >> Raspberry Pi or Beaglebone. I'm not really the target audience for this > > > >> sort of thing though. > > > > > > > > SwiftX only runs on Windows because most of the vendors' debug > > > > interfaces (which we use on the host side) are Windows only. There has > > > > been little interested in Linux hosts and none on OSX. As for the > > > > Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a > > > > host, it's a target. We prefer a PC host because it's capable of > > > > supporting a powerful optimizing compiler for the target as well as the > > > > most convenient editing and debugging tools. > > > > > > > > Target platforms may have an optional, limited compiling capability, but > > > > our assumption is that the major application development should be > > > > supported by the most powerful tools available. > > > > > > I think 10 years ago that may have been a valid perspective. But these > > > days you don't need an i7 with 16 GB of memory to compile programs to > > > run on *any* processor, much less a Cortex M3 or an MSP430. > > > > > > I think the mobile market has so promoted lightweight computing that it > > > is a bit silly to think you need the power of a workstation to develop > > > code when practical experience is telling us that many much simpler > > > platforms are proving to be very productive. > > > > > > The rPi is just the tip of the ice burg. I know my preference is to > > > move to lighter weight platforms for *all* my computing needs. I expect > > > that will prove to be true for many in the near future. My last > > > embedded application was done using Mecrisp on the target while using > > > the rPi as a host, because of the poor support for Windows by the chip > > > vendor. I only used the PC to provide a keyboard and screen to the rPi. > > > I have put off buying one of the new rPi 2 with the quad core > > > processor. When I get it I may leave the laptop out of it entirely and > > > work directly on the rPi. The laptop is a *crappy* keyboard. > > > > > > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next > > > target. I am thinking of porting Mecrisp to it. I don't think that > > > will be any harder than getting one of the commercial Forths to work > > > with it. I could be wrong. > > > > > > -- > > > > > > Rick > > > > Elizabeth explained what the product offer is - what their customers want. > > We are talking commercial product > > You say the product is not what you want. So you will not buy it - fine > > You have other options: > > try if MPE can deliver what you want - the only other commercial alternative to my knowledge, > > or write your own compiler optimized for what you want > > and additionally there are sufficient free solutions out there. > > Not very helpful comment of your's I think. > > You always seem to be very upset when free forth implementations come to disscussion. The subject is "Could Forth be getting a bit of traction?" and not "Could Commercial Forths be getting a bit of traction?". > I also feel free to post anything about free/open source forths here, but I don't, because all I would say is "no, it doesn't". > Anyway, do you think that commercial forth vendors can do anything to help the "traction?" When there are only two of them as you said? > My strong feeling is that the open source community is the only one that can really help. But this open source community is very thin... For example, I have a big application pending, for a Cortex-M4 with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I have a hard time deciding where to choose Lua/elua or Micropython for it. "Standard" forth is lower level than C, so no way (I would consider at most oforth or Factor, but I can't do that as long as they are not open source...) Not at all. I just think it is silly to complain about a commercial supplier who does it how their customers want it. I come from the commercial world and I sometimes doubt how many here are as well. Go to a dentist and tell him how she / he should do it - They probably will just drill a bit deeper or put the price up to indicate how they like your "better" knowledge. There is a difference funnyly enough - they get their living from it. I like the free versions as well, actually 4e4th is one I started with before I got involved with MPE and VFX. And if you have read the book Ting did recently it states that I got him back into reviving the MSP430 again by connecting him to Klaus and Dirk. But I assume you know this all. Open Forths definitely breed new ideas and they are then discussed for example at Euroforth - see my inputs I did in this thread and the ANS meeting I attended. ( thanks again for allowing this - looked under all of the tables but could not find any conspiracy ... ) The Forth community is so small now compared to the past that any good idea counts, but people often do not understand how a commercial product support over many years works - slightly different from: Oh I can change my compiler this afternoon as you can with any free system which is probably more fun. Portability and maintenance count in professional and commercial systems. Regarding your project Cortex M4: just send an email to both suppliers and see what the result is - you might be surprised or get the "positive" feedback that they cannot achieve what you want for whatever reason - which will make your decision easier as well. I do not know the FORTH INC products that well, but MPE offers some free ARM options which should give you an indication. If your hesitation/searching costs you 1 week of your life , that means 5 x 8 = 40 hours of project lost. At for example 50 dollars per hour this means $2000 lost in revenue ( and you would have the commercial compiler for free for your next project ). And by the way, who causes the traction - free or commercial - is irrelevant - the market is by definition 100%. If the market value increases for whatever reason, everybody wins - Forth suppliers and consultants - including an increased credibility of the market about Forth.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-06 16:02 -0700 |
| Message-ID | <87io6j7g8s.fsf@jester.gateway.sonic.net> |
| In reply to | #42405 |
JUERGEN <epldfpga@aol.com> writes: > I just think it is silly to complain about a commercial supplier who > does it how their customers want it. ... Regarding your project > Cortex M4: just send an email to both suppliers and see what the > result is ... If your hesitation/searching costs you 1 week of your > life , that means 5 x 8 = 40 hours of project lost. I think you're responding to both Rickman and Raimond Dragomir, who are dealing with separate sets of issues. Rickman is quite aware of the commercial Forth options but found that Mecrisp filled his requirements. I think he knows that the commercial Forths have features and support that Mecrisp doesn't, but he didn't need it. I don't think he complained about commercial vendors; but rather, he just said that he found something non-commercial that did what he wanted, and indicated that maybe they hadn't kept up with the changing state of the market. Raimond on the other hand is programming a bigger system (8MB ram) and isn't looking to use Forth at all. The alternatives he mentioned (oForth, Factor, Lua, MicroPython) are all more "automated" than Forth: they manage far more of of the program's details than Forth does, which has a cost in hardware resources and program determinism. But on bigger processors and in some apps, that is often perfectly fine. So I think he understands the trade-offs enough to make a good decision regarding his own constraints. (Factor is FOSS by the way. I don't know about oForth. For non-FOSS Forth-inspired systems in this class, I'd add Ron Aaron's 8th to the list). > And if you have read the book Ting did recently it states that I got > him back into reviving the MSP430 again by connecting him to Klaus and > Dirk. But I assume you know this all. Which book is that? I didn't realize Ting had a new book out. I've looked at some of his older ones and found them very interesting.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2015-10-07 07:49 +0300 |
| Message-ID | <mv285k$8it$2@dont-email.me> |
| In reply to | #42407 |
On 10/7/15 02:02, Paul Rubin wrote: > I don't know about > oForth. For non-FOSS Forth-inspired systems in this class, I'd add Ron > Aaron's 8th to the list). I'd agree :)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-06 15:04 -0700 |
| Message-ID | <87mvvv7iwt.fsf@jester.gateway.sonic.net> |
| In reply to | #42390 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes: > For example, I have a big application pending, for a Cortex-M4 > with at least 8MB sdram, and a serial flash of 4MB/8MB or a sd card. I > have a hard time deciding where to choose Lua/elua or Micropython for > it. "Standard" forth is lower level than C, so no way With that much memory you have more choices, including CPython and (not my favorite) Javascript. In fact there's a small Javascript that runs directly on a CM4: http://www.adafruit.com/products/2621
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-09 14:16 -0700 |
| Message-ID | <87k2qv4u9n.fsf@jester.gateway.sonic.net> |
| In reply to | #42390 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes: > "Standard" forth is lower level than C, so no way (I would > consider at most oforth or Factor, but I can't do that as long as they > are not open source...) Both are FOSS. Oforth is BSD3 licensed and Factor is BSD2.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-06 09:34 -0400 |
| Message-ID | <mv0igo$blt$1@dont-email.me> |
| In reply to | #42389 |
On 10/6/2015 5:58 AM, JUERGEN wrote: > On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote: >> On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote: >>> On 10/4/15 8:44 PM, Paul Rubin wrote: >>>> Paul Rubin <no.email@nospam.invalid> writes: >>>>>> Here: http://www.forth.com/embedded/index.html >>>>> Nice! Somehow I missed that there was an evaluation version >>>> >>>> Unfortunately it looks like they're all Windows .exe's. I might be able >>>> to try one out sometime but Linux would be much easier. It would be >>>> extra interesting to have an ARM Linux version that could be hosted on a >>>> Raspberry Pi or Beaglebone. I'm not really the target audience for this >>>> sort of thing though. >>> >>> SwiftX only runs on Windows because most of the vendors' debug >>> interfaces (which we use on the host side) are Windows only. There has >>> been little interested in Linux hosts and none on OSX. As for the >>> Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a >>> host, it's a target. We prefer a PC host because it's capable of >>> supporting a powerful optimizing compiler for the target as well as the >>> most convenient editing and debugging tools. >>> >>> Target platforms may have an optional, limited compiling capability, but >>> our assumption is that the major application development should be >>> supported by the most powerful tools available. >> >> I think 10 years ago that may have been a valid perspective. But these >> days you don't need an i7 with 16 GB of memory to compile programs to >> run on *any* processor, much less a Cortex M3 or an MSP430. >> >> I think the mobile market has so promoted lightweight computing that it >> is a bit silly to think you need the power of a workstation to develop >> code when practical experience is telling us that many much simpler >> platforms are proving to be very productive. >> >> The rPi is just the tip of the ice burg. I know my preference is to >> move to lighter weight platforms for *all* my computing needs. I expect >> that will prove to be true for many in the near future. My last >> embedded application was done using Mecrisp on the target while using >> the rPi as a host, because of the poor support for Windows by the chip >> vendor. I only used the PC to provide a keyboard and screen to the rPi. >> I have put off buying one of the new rPi 2 with the quad core >> processor. When I get it I may leave the laptop out of it entirely and >> work directly on the rPi. The laptop is a *crappy* keyboard. >> >> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next >> target. I am thinking of porting Mecrisp to it. I don't think that >> will be any harder than getting one of the commercial Forths to work >> with it. I could be wrong. >> >> -- >> >> Rick > > Elizabeth explained what the product offer is - what their customers want. > We are talking commercial product > You say the product is not what you want. So you will not buy it - fine > You have other options: > try if MPE can deliver what you want - the only other commercial alternative to my knowledge, > or write your own compiler optimized for what you want > and additionally there are sufficient free solutions out there. > Not very helpful comment of your's I think. Sorry you don't find my comments "helpful". But you seem to have misread the post. First, Elizabeth didn't say what her *customers* want, she said, "*We* prefer a PC host". She is speaking from the perspective of a vendor, not a user. There are many reasons to want to limit support to a single platform. It is a lot more work to support multiple operating systems and host CPUs. That is not at all the same thing as saying users don't want to use hosts other than Windows on big iron. The existence of the many alternative Forths shows clearly there is at least some market for that. The statement about vendor debug interfaces is a bit disingenuous. Nearly every MCU (certainly all the popular ones) has support under Linux using open source tools. Even if the vendor doesn't support these tools themselves it doesn't mean the tools don't exist and don't work well. The entire reason I used the rPi for my last project was because TI only offered a non-signed driver for their launchpad boards which I found very hard to install under Win 8. So I used a tool under Raspian that installed very easily and worked well. As to my preferences, I believe I was pretty clear about just that, they are my preferences, "I know my preference...". I also commented on the state of the software development market and I stand by those comments. Just as cell phones have largely replaced land lines and laptops/tablets have largely replaced desktops, software development is well on its way to leaving behind the big iron and Windows. I'm not sure exactly what your post is about. I am very aware of my options for development. I mentioned that in my post. It appears you were disturbed by my comments, "helpful" or not. Am I not supposed to talk about what I want and what I use??? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-06 09:08 -1000 |
| Message-ID | <_Zidnex3Vre0gYnLnZ2dnUU7-RGdnZ2d@supernews.com> |
| In reply to | #42392 |
On 10/6/15 3:34 AM, rickman wrote: > On 10/6/2015 5:58 AM, JUERGEN wrote: >> On Tuesday, October 6, 2015 at 6:36:04 AM UTC+1, rickman wrote: >>> On 10/5/2015 2:54 PM, Elizabeth D. Rather wrote: >>>> On 10/4/15 8:44 PM, Paul Rubin wrote: >>>>> Paul Rubin <no.email@nospam.invalid> writes: >>>>>>> Here: http://www.forth.com/embedded/index.html >>>>>> Nice! Somehow I missed that there was an evaluation version >>>>> >>>>> Unfortunately it looks like they're all Windows .exe's. I might be >>>>> able >>>>> to try one out sometime but Linux would be much easier. It would be >>>>> extra interesting to have an ARM Linux version that could be hosted >>>>> on a >>>>> Raspberry Pi or Beaglebone. I'm not really the target audience for >>>>> this >>>>> sort of thing though. >>>> >>>> SwiftX only runs on Windows because most of the vendors' debug >>>> interfaces (which we use on the host side) are Windows only. There has >>>> been little interested in Linux hosts and none on OSX. As for the >>>> Raspberry Pi, it's not an i386 -- it's an ARM, so it would not be a >>>> host, it's a target. We prefer a PC host because it's capable of >>>> supporting a powerful optimizing compiler for the target as well as the >>>> most convenient editing and debugging tools. >>>> >>>> Target platforms may have an optional, limited compiling capability, >>>> but >>>> our assumption is that the major application development should be >>>> supported by the most powerful tools available. >>> >>> I think 10 years ago that may have been a valid perspective. But these >>> days you don't need an i7 with 16 GB of memory to compile programs to >>> run on *any* processor, much less a Cortex M3 or an MSP430. >>> >>> I think the mobile market has so promoted lightweight computing that it >>> is a bit silly to think you need the power of a workstation to develop >>> code when practical experience is telling us that many much simpler >>> platforms are proving to be very productive. >>> >>> The rPi is just the tip of the ice burg. I know my preference is to >>> move to lighter weight platforms for *all* my computing needs. I expect >>> that will prove to be true for many in the near future. My last >>> embedded application was done using Mecrisp on the target while using >>> the rPi as a host, because of the poor support for Windows by the chip >>> vendor. I only used the PC to provide a keyboard and screen to the rPi. >>> I have put off buying one of the new rPi 2 with the quad core >>> processor. When I get it I may leave the laptop out of it entirely and >>> work directly on the rPi. The laptop is a *crappy* keyboard. >>> >>> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next >>> target. I am thinking of porting Mecrisp to it. I don't think that >>> will be any harder than getting one of the commercial Forths to work >>> with it. I could be wrong. >>> >>> -- >>> >>> Rick >> >> Elizabeth explained what the product offer is - what their customers >> want. >> We are talking commercial product >> You say the product is not what you want. So you will not buy it - fine >> You have other options: >> try if MPE can deliver what you want - the only other commercial >> alternative to my knowledge, >> or write your own compiler optimized for what you want >> and additionally there are sufficient free solutions out there. >> Not very helpful comment of your's I think. > > Sorry you don't find my comments "helpful". But you seem to have > misread the post. First, Elizabeth didn't say what her *customers* > want, she said, "*We* prefer a PC host". She is speaking from the > perspective of a vendor, not a user. There are many reasons to want to > limit support to a single platform. It is a lot more work to support > multiple operating systems and host CPUs. That is not at all the same > thing as saying users don't want to use hosts other than Windows on big > iron. The existence of the many alternative Forths shows clearly there > is at least some market for that. In fact, the approach we use in SwiftX is what our customers (who are mostly professional programmers developing complex microprocessor-based products) have demanded for years. In addition, a major part of our work is contract programming, so we are not only developing and maintaining software for other programmers to use, we are using it in challenging projects. The solutions our customers request as well as our own experience trying to do a better job for our contract programming customers are what drives the development of our products. > The statement about vendor debug interfaces is a bit disingenuous. > Nearly every MCU (certainly all the popular ones) has support under > Linux using open source tools. Even if the vendor doesn't support these > tools themselves it doesn't mean the tools don't exist and don't work > well. The entire reason I used the rPi for my last project was because > TI only offered a non-signed driver for their launchpad boards which I > found very hard to install under Win 8. So I used a tool under Raspian > that installed very easily and worked well. Depends on which tools you're talking about. We do not use any vendor compilers or debuggers. We get access to host-side drivers for flash burning and things like the TI BDM, JTAG, etc. via their developer programs. We don't always use them the way the developer intended. For example, we often run the debugging interface to the host as a separate task from the tasks involved in the application, so you can observe the running application without necessarily halting it. Many of our customers' projects are on custom hardware without any user interface or with otherwise very limited facilities for supporting a debugging environment other than what SwiftX provides via its connected host. > As to my preferences, I believe I was pretty clear about just that, they > are my preferences, "I know my preference...". I also commented on the > state of the software development market and I stand by those comments. > Just as cell phones have largely replaced land lines and > laptops/tablets have largely replaced desktops, software development is > well on its way to leaving behind the big iron and Windows. > > I'm not sure exactly what your post is about. I am very aware of my > options for development. I mentioned that in my post. It appears you > were disturbed by my comments, "helpful" or not. Am I not supposed to > talk about what I want and what I use??? Of course you are :-) 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-06 20:49 -0700 |
| Message-ID | <87y4ff5oee.fsf@jester.gateway.sonic.net> |
| In reply to | #42386 |
rickman <gnuarm@gmail.com> writes: > I think the mobile market has so promoted lightweight computing that > it is a bit silly to think you need the power of a workstation to > develop code when practical experience is telling us that many much > simpler platforms are proving to be very productive. The most demanding application these days is web browsers and it's getting worse all the time. They keep improving the performance of Javascript, and whenever that happens, web developers feel entitled to eat yet more CPU cycles. So the web will always be slow from here on out. > I have put off buying one of the new rPi 2 with the quad core > processor. When I get it I may leave the laptop out of it entirely > and work directly on the rPi. The laptop is a *crappy* keyboard. I like working on a small laptop (compact box with keyboard and screen in the same place, lets me sit anywhere and code) with heavy computing done on a remote server. For a small ARM box you might look at the Odroid XU4 which should be > 2x the speed of the rPi 2: http://www.hardkernel.com/main/products/prdt_info.php Hetzner (big German web host) has been renting them out as dedicated servers, though overpriced IMHO: https://www.hetzner.de/us/hosting/produktmatrix/rootserver-produktmatrix-ax I've been playing with Scaleway ARM servers (30 minute no-registration trial: http://instantcloud.io ) which are closer to the rPi 2 in performance but are amazingly cheap (3 euro per month with 50GB SSD, 200 megabit internet, hourly billing and a real cloud API). OVH is doing a small trial with 64-bit ARM servers that I didn't get to join before it filled, but hopefully they will widen it soon. x86, feel the heat ;-). > > BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next > target. I am thinking of porting Mecrisp to it. I don't think that > will be any harder than getting one of the commercial Forths to work > with it. I could be wrong. I wouldn't expect porting to be harder, but of course the commercial Forths have a lot more features and libraries.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-10-07 00:56 -0400 |
| Message-ID | <mv28hq$9m6$1@dont-email.me> |
| In reply to | #42409 |
On 10/6/2015 11:49 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > >> I think the mobile market has so promoted lightweight computing that >> it is a bit silly to think you need the power of a workstation to >> develop code when practical experience is telling us that many much >> simpler platforms are proving to be very productive. > > The most demanding application these days is web browsers and it's > getting worse all the time. They keep improving the performance of > Javascript, and whenever that happens, web developers feel entitled to > eat yet more CPU cycles. So the web will always be slow from here on > out. > >> I have put off buying one of the new rPi 2 with the quad core >> processor. When I get it I may leave the laptop out of it entirely >> and work directly on the rPi. The laptop is a *crappy* keyboard. > > I like working on a small laptop (compact box with keyboard and screen > in the same place, lets me sit anywhere and code) with heavy computing > done on a remote server. For a small ARM box you might look at the > Odroid XU4 which should be > 2x the speed of the rPi 2: > > http://www.hardkernel.com/main/products/prdt_info.php > > Hetzner (big German web host) has been renting them out as dedicated > servers, though overpriced IMHO: > > https://www.hetzner.de/us/hosting/produktmatrix/rootserver-produktmatrix-ax > > I've been playing with Scaleway ARM servers (30 minute no-registration > trial: http://instantcloud.io ) which are closer to the rPi 2 in > performance but are amazingly cheap (3 euro per month with 50GB SSD, 200 > megabit internet, hourly billing and a real cloud API). OVH is doing a > small trial with 64-bit ARM servers that I didn't get to join before it > filled, but hopefully they will widen it soon. x86, feel the heat ;-). >> >> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next >> target. I am thinking of porting Mecrisp to it. I don't think that >> will be any harder than getting one of the commercial Forths to work >> with it. I could be wrong. > > I wouldn't expect porting to be harder, but of course the commercial > Forths have a lot more features and libraries. I don't know what it would take to port a commercial Forth to a new target. Part of my concern with a commercial forth is the contractual issues that I don't even want to explore. I don't typically develop large or complex applications, so I can usually do my work with less capable tools. Mostly it is nice to not be restrained by the licensing of commercial Forths. If I were to work on a larger project demanding the best tools, then I might go for one of the commercial packages. Until then, I want to work openly and freely. Heck, I barely know Forth and still manage to develop applications. The really funny part is that my last serious Forth project was to control a test fixture via an RS-232 port to an FPGA. I had a major comms problem and I kept trying to nail it down thinking it was something goofy in the comms software. In the end it was in my FPGA, I had forgotten the durn synchronizing FF at the input to the UART!!! A rookie mistake! So much for code reuse. A bit like the Ariane rocket failure, lol. The UART worked great in the previous project, but when I ported it to the new project I forgot to adequately verify the I/O details (the sync FF was external to the UART code). However, while trying to find the bug, I had included some *really* fancy error checking code in Forth and learned about catch throw in the process. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-10-06 21:11 -1000 |
| Message-ID | <54qdnYCL1Z4NWInLnZ2dnUU7-a2dnZ2d@supernews.com> |
| In reply to | #42414 |
On 10/6/15 6:56 PM, rickman wrote: > On 10/6/2015 11:49 PM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >> >>> I think the mobile market has so promoted lightweight computing that >>> it is a bit silly to think you need the power of a workstation to >>> develop code when practical experience is telling us that many much >>> simpler platforms are proving to be very productive. >> >> The most demanding application these days is web browsers and it's >> getting worse all the time. They keep improving the performance of >> Javascript, and whenever that happens, web developers feel entitled to >> eat yet more CPU cycles. So the web will always be slow from here on >> out. >> >>> I have put off buying one of the new rPi 2 with the quad core >>> processor. When I get it I may leave the laptop out of it entirely >>> and work directly on the rPi. The laptop is a *crappy* keyboard. >> >> I like working on a small laptop (compact box with keyboard and screen >> in the same place, lets me sit anywhere and code) with heavy computing >> done on a remote server. For a small ARM box you might look at the >> Odroid XU4 which should be > 2x the speed of the rPi 2: >> >> http://www.hardkernel.com/main/products/prdt_info.php >> >> Hetzner (big German web host) has been renting them out as dedicated >> servers, though overpriced IMHO: >> >> >> https://www.hetzner.de/us/hosting/produktmatrix/rootserver-produktmatrix-ax >> >> >> I've been playing with Scaleway ARM servers (30 minute no-registration >> trial: http://instantcloud.io ) which are closer to the rPi 2 in >> performance but are amazingly cheap (3 euro per month with 50GB SSD, 200 >> megabit internet, hourly billing and a real cloud API). OVH is doing a >> small trial with 64-bit ARM servers that I didn't get to join before it >> filled, but hopefully they will widen it soon. x86, feel the heat ;-). >>> >>> BTW, I am looking at the SmartFusion2 ARM-CM3/FPGA SoC as my next >>> target. I am thinking of porting Mecrisp to it. I don't think that >>> will be any harder than getting one of the commercial Forths to work >>> with it. I could be wrong. >> >> I wouldn't expect porting to be harder, but of course the commercial >> Forths have a lot more features and libraries. > > I don't know what it would take to port a commercial Forth to a new > target. Part of my concern with a commercial forth is the contractual > issues that I don't even want to explore. Not really that complicated. We license the development system. A turnkey target that isn't itself programmable has no further obligations. > I don't typically develop > large or complex applications, so I can usually do my work with less > capable tools. Mostly it is nice to not be restrained by the licensing > of commercial Forths. If I were to work on a larger project demanding > the best tools, then I might go for one of the commercial packages. > Until then, I want to work openly and freely. Heck, I barely know Forth > and still manage to develop applications. > > The really funny part is that my last serious Forth project was to > control a test fixture via an RS-232 port to an FPGA. I had a major > comms problem and I kept trying to nail it down thinking it was > something goofy in the comms software. In the end it was in my FPGA, I > had forgotten the durn synchronizing FF at the input to the UART!!! A > rookie mistake! So much for code reuse. A bit like the Ariane rocket > failure, lol. The UART worked great in the previous project, but when I > ported it to the new project I forgot to adequately verify the I/O > details (the sync FF was external to the UART code). However, while > trying to find the bug, I had included some *really* fancy error > checking code in Forth and learned about catch throw in the process. Good. Catch/throw is really powerful, probably the best single innovation in Forth94 (Thank you, Mitch Bradley!) 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-10-09 21:07 -0700 |
| Message-ID | <877fmv4b9i.fsf@jester.gateway.sonic.net> |
| In reply to | #42414 |
rickman <gnuarm@gmail.com> writes: > Part of my concern with a commercial forth ... Mostly it is nice to > not be restrained by the licensing of commercial Forths. If I were to > work on a larger project demanding the best tools, then I might go for > one of the commercial packages. Don't forget, Mecrisp is GPL3, which constrains how you can ship it in products. Life might be easier with a commercial Forth where you can probably get whatever you need by writing enough checks.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web