Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #30977 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2014-05-29 21:35 -0400 |
| Last post | 2014-07-17 16:09 -0400 |
| Articles | 20 on this page of 190 — 24 participants |
Back to article view | Back to comp.lang.forth
MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 21:35 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 19:09 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 19:13 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 23:00 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 20:25 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 20:23 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 22:15 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 15:13 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 13:51 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 21:08 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 12:22 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 21:41 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 13:28 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 17:55 -0400
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 16:29 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 14:18 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 18:07 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 17:24 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 11:10 +0200
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-02 10:57 +0000
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 13:34 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 20:10 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 20:29 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 21:02 -0700
Re: MSP430-Stamp "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-30 04:05 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 15:13 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 19:57 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 23:32 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 21:07 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 02:39 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-07-17 12:40 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-17 16:08 -0400
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-18 00:06 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-07-18 08:22 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-18 23:42 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-18 18:28 -0400
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 01:41 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-18 19:48 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-07-18 16:59 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 14:30 +0200
Re: MSP430-Stamp Gary Bergstrom <forthprgrmr@gmail.com> - 2014-07-19 08:23 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-07-21 10:42 +0200
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 03:03 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 07:47 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-31 11:36 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-31 09:34 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 10:09 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-31 10:52 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 01:28 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 22:41 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 02:00 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 23:07 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 03:13 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 07:15 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 12:33 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 09:45 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 13:10 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 18:38 +0200
Re: MSP430-Stamp babruehl@gmail.com - 2014-06-01 11:40 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 11:13 +0200
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-01 09:50 +0000
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 12:47 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 04:05 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 12:39 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 10:00 -0700
Re: MSP430-Stamp babruehl@gmail.com - 2014-06-01 11:45 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 14:57 -0400
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-01 12:01 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 15:12 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 03:12 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 14:02 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-31 03:33 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 07:19 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-31 12:01 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 09:15 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 13:51 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-31 14:20 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 14:51 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-05-31 16:22 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-01 01:33 +0200
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-05-31 17:31 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 21:48 -0700
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-05-31 19:12 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 22:25 -0700
Re: MSP430-Stamp stephenXXX@mpeforth.com (Stephen Pelc) - 2014-06-01 09:45 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 04:16 -0700
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-01 08:51 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 21:03 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-01 21:17 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-04 22:46 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 13:27 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 08:39 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 16:10 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:10 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 19:52 +0000
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 23:25 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 15:02 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 10:56 +0000
Correct Software and Specifications (was Re: MSP430-Stamp) Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-09 09:59 +0100
Re: MSP430-Stamp mhx@iae.nl - 2014-06-05 14:30 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 10:59 +0000
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 15:57 +0200
Formal specifications etc. (was: MSP430-Stamp) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-05 15:34 +0000
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:48 -0700
Re: Formal specifications etc. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-05 19:46 +0000
Re: Formal specifications etc. (was: MSP430-Stamp) Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 23:02 +0200
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 14:15 -0700
Re: Formal specifications etc. rickman <gnuarm@gmail.com> - 2014-06-05 17:33 -0400
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 15:32 -0700
Re: Formal specifications etc. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-06 04:00 -0500
Re: Formal specifications etc. (was: MSP430-Stamp) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 11:05 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:01 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-06 01:09 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-05 22:01 -0400
Re: MSP430-Stamp stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-31 16:47 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 12:11 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-06 12:54 +0200
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 11:39 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-02 12:15 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-03 10:26 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 12:18 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-02 10:04 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-03 11:51 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 13:33 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-06 13:02 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 17:31 -0400
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-06 16:30 -1000
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 22:52 -0400
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-07 11:58 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-07 11:40 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-07 20:01 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 16:05 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-08 22:28 -0400
Re: MSP430-Stamp Gary Bergstrom <forthprgrmr@gmail.com> - 2014-06-08 20:36 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 21:38 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 14:36 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 02:45 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:18 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 15:57 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 16:20 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 20:42 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 21:05 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-04 10:43 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 21:28 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-03 22:43 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 23:31 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-04 04:13 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 01:41 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 01:51 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-03 16:19 +0100
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 09:14 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 13:19 -0400
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-03 07:43 -1000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 20:56 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-04 10:51 +0000
Re: MSP430-Stamp VisualForth <babruehl@gmail.com> - 2014-06-04 04:06 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 21:26 -0400
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-06 20:40 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-07 03:18 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-07 04:35 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-07 12:01 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:47 -0700
Re: MSP430-Stamp Mikael Nordman <oh2aun@gmail.com> - 2014-06-09 09:28 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:35 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-11 10:43 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 15:52 -0700
Re: MSP430-Stamp Coos Haak <chforth@hccnet.nl> - 2014-06-12 02:06 +0200
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 15:13 -1000
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-12 02:16 -0700
Re: MSP430-Stamp Mikael Nordman <oh2aun@gmail.com> - 2014-06-11 12:56 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 16:46 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:49 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-09 09:47 -0700
Re: MSP430-Stamp Rikard Lang <rikard.lang@gmail.com> - 2014-06-09 23:16 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-10 07:48 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:23 -0700
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-11 18:00 -0500
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 02:14 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-12 02:13 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 13:04 -0400
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-12 18:06 -0500
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 19:29 -0400
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-13 18:48 -0500
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:26 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-11 10:45 -0700
Re: MSP430-Stamp JUERGEN <epldfpga@aol.com> - 2014-06-13 00:03 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-18 11:11 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-18 05:27 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-18 12:29 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-17 16:09 -0400
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-01 09:50 +0000 |
| Message-ID | <538af774$0$4954$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #31120 |
In article <20140601111333.4f824781@42d75>,
HaveANiceDay <HaveANiceDay@NoSpam.invalid> wrote:
>rickman <gnuarm@gmail.com> wrote:
>
>> On 5/31/2014 12:34 PM, visualforth@rocketmail.com wrote:
>> > On Saturday, May 31, 2014 11:36:51 AM UTC-4, rickman wrote:
>> >
>> >> At this point I have lost the train of thought for this stamp project.
>> >> I would like to see a clear explanation of the goals and
>purpose of the
>> >> effort. Just what would this effort do that other efforts
>have not. So
>> >> far I have seen no reason not to use the Launchpad from TI rather than
>> >> rolling yet another MCU project.
>> >
>> > It's all about raising awareness for Forth.
>> > There are a lot of opportunities.
>> > One of them is promoting Forth - eForth, 4e4th, VFX, mecrisp
>for TI's LaunchPad. Several people are working on that. A real good
>comprehensible tutorial for newbees still is missing, for VFX a
>tutorial is in the making, I have read.
>> >
>
>
>
>>
>> Ok, I think I understand now. But I don't agree that you need to roll
>> new hardware to achieve this goal. Rather what would be infinitely more
>> useful to the beginners and the ones who tried using a Launchpad and ran
>> into the same troubles is to use the LaunchPad hardware and provide a
>> software upgrade to Forth.
>
>
>
>
>> The LaunchPad is not much different from the "stamp" hardware proposed.
>> It is a single MCU chip with a couple of switches and LEDs along with
>> the emulation section of the board which provides power, reset and
>> communications.
>
>The LP with his emulation/communication section as whole is much
>more complicated than the proposed stamp or breadboard, and so
>doesn't show to beginners how little is needed.
The LP has all this stuff on board, because your beginner has no
serial port, just usb. Moreover it allows even a beginner to
reflash the board herself pretty easily.
This is the command to put a fresh noforth on a board, once
mspdebug is installed. It could even be made into a button icon:
"
(echo erase all; echo prog noforth.a43) | mspdebug rf2500
"
(followed by the ceremonial reboot, all Windows users expect
to be done anyway.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | HaveANiceDay <HaveANiceDay@NoSpam.invalid> |
|---|---|
| Date | 2014-06-01 12:47 +0200 |
| Message-ID | <20140601124751.222cf4b4@42d75> |
| In reply to | #31123 |
albert@spenarnc.xs4all.nl (Albert van der Horst) wrote: > In article <20140601111333.4f824781@42d75>, > HaveANiceDay <HaveANiceDay@NoSpam.invalid> wrote: > >rickman <gnuarm@gmail.com> wrote: > > > >> On 5/31/2014 12:34 PM, visualforth@rocketmail.com wrote: > >> > On Saturday, May 31, 2014 11:36:51 AM UTC-4, rickman wrote: > >> > > >> >> At this point I have lost the train of thought for this stamp project. > >> >> I would like to see a clear explanation of the goals and > >purpose of the > >> >> effort. Just what would this effort do that other efforts > >have not. So > >> >> far I have seen no reason not to use the Launchpad from TI rather than > >> >> rolling yet another MCU project. > >> > > >> > It's all about raising awareness for Forth. > >> > There are a lot of opportunities. > >> > One of them is promoting Forth - eForth, 4e4th, VFX, mecrisp > >for TI's LaunchPad. Several people are working on that. A real good > >comprehensible tutorial for newbees still is missing, for VFX a > >tutorial is in the making, I have read. > >> > > > > > > > > >> > >> Ok, I think I understand now. But I don't agree that you need to roll > >> new hardware to achieve this goal. Rather what would be infinitely more > >> useful to the beginners and the ones who tried using a Launchpad and ran > >> into the same troubles is to use the LaunchPad hardware and provide a > >> software upgrade to Forth. > > > > > > > > > >> The LaunchPad is not much different from the "stamp" hardware proposed. > >> It is a single MCU chip with a couple of switches and LEDs along with > >> the emulation section of the board which provides power, reset and > >> communications. > > > >The LP with his emulation/communication section as whole is much > >more complicated than the proposed stamp or breadboard, and so > >doesn't show to beginners how little is needed. > > The LP has all this stuff on board, because your beginner has no > serial port, just usb. Moreover it allows even a beginner to > reflash the board herself pretty easily. excuse me, but I think you didn't understand: No serial port and nothing else is needed! The AVR you can easily and completely reflash just with a cable to the printer-port! (and if you want to protect your port you add 4 resistors) And I hope even nowadays PCs still have Printerports? > This is the command to put a fresh noforth on a board, once > mspdebug is installed. It could even be made into a button icon: > > " > (echo erase all; echo prog noforth.a43) | mspdebug rf2500 > " the same for AVR, the command-line to erase and reflash it via printerport is: avrdude -q -c stk200 -P /dev/parport0 -p atmega32 -e -U \ flash:w:amforth.hex:i -U eeprom:w:amforth.eep.hex:i (and averdude is multi-platform, but you have to adapt the "/dev/parport0" and the "atmega32", of course) > > (followed by the ceremonial reboot, all Windows users expect > to be done anyway. > > Groetjes Albert
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-01 04:05 -0700 |
| Message-ID | <7xfvjoubxq.fsf@ruckus.brouhaha.com> |
| In reply to | #31126 |
HaveANiceDay <HaveANiceDay@NoSpam.invalid> writes: > And I hope even nowadays PCs still have Printerports? No. Just USB. I haven't seen a parallel printer port in years.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 12:39 -0400 |
| Message-ID | <lmfkvl$s82$1@dont-email.me> |
| In reply to | #31120 |
On 6/1/2014 5:13 AM, HaveANiceDay wrote: > rickman <gnuarm@gmail.com> wrote: >> >> Ok, I think I understand now. But I don't agree that you need to roll >> new hardware to achieve this goal. Rather what would be infinitely more >> useful to the beginners and the ones who tried using a Launchpad and ran >> into the same troubles is to use the LaunchPad hardware and provide a >> software upgrade to Forth. > >> The LaunchPad is not much different from the "stamp" hardware proposed. >> It is a single MCU chip with a couple of switches and LEDs along with >> the emulation section of the board which provides power, reset and >> communications. > > The LP with his emulation/communication section as whole is much > more complicated than the proposed stamp or breadboard, and so > doesn't show to beginners how little is needed. I think it does. They even include a dotted line separating the MCU from the emulation circuit. > I personally like the Breadboard approach very much and although > I like the '430 and dislike the AVR, I think the second ones are > better suited for such an Project. > > Reasons: > -for programming you can connect them directly to the > printer-port You can't connect what to a printer port? Who has printer ports anyway? They went away about the same time as direct serial port. > -a lot of devices in DIL-Package are available > -for making them unbrickable you only have to call averdude with > a script that doesn't provide access to the (or some) "fuses" > -if already connected to the printer-port also communications > could be done by bit-banging > -I suppose the PP could also provide enough power to blink a few > LEDs > > so you would only need a breadboard, the chip, eventually a few > resistors, LEDs and switches and a simple cable to the PP! So what is stopping you? Go for it! Not many others have printer ports though. I am hanging onto a 10 year old desktop just to operate my HP 1100 printer. > and on the software side its nearly all already there (amforth, > avrdude) you only would have to change forth-communications to > printer-port instead of RS232 > > Of course unfortunately it would not promote the MSP430 or > 4e4th.... I don't think 4e4th would be excluded. Can't it be ported to the AVR? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-01 10:00 -0700 |
| Message-ID | <7xa99wbm4h.fsf@ruckus.brouhaha.com> |
| In reply to | #31132 |
rickman <gnuarm@gmail.com> writes: >> Of course unfortunately it would not promote the MSP430 or 4e4th.... > I don't think 4e4th would be excluded. Can't it be ported to the AVR? 4e4th based on Camelforth which runs on several processors but uses a fair amount of assembly code, at least in the MSP430 version. Btw I didn't realize "promote the MSP430" was part of the goal here: the MSP430 seems like a convenient and low cost chip to use, but "promoting" it is TI's job, not ours.
[toc] | [prev] | [next] | [standalone]
| From | babruehl@gmail.com |
|---|---|
| Date | 2014-06-01 11:45 -0700 |
| Message-ID | <a40da62f-6c88-4481-888e-2ae7060f3da3@googlegroups.com> |
| In reply to | #31134 |
On Sunday, June 1, 2014 1:00:46 PM UTC-4, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > >> Of course unfortunately it would not promote the MSP430 or 4e4th.... > > > I don't think 4e4th would be excluded. Can't it be ported to the AVR? > > > > 4e4th based on Camelforth which runs on several processors but uses a > > fair amount of assembly code, at least in the MSP430 version. Btw I > > didn't realize "promote the MSP430" was part of the goal here: the > > MSP430 seems like a convenient and low cost chip to use, but "promoting" > > it is TI's job, not ours. The TOPIC still is "MSP430-Stamp", was forked from "Go Forth and Prosper" But that doesn't mean anything, I guess.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 14:57 -0400 |
| Message-ID | <lmft2i$ntf$1@dont-email.me> |
| In reply to | #31137 |
On 6/1/2014 2:45 PM, babruehl@gmail.com wrote: > On Sunday, June 1, 2014 1:00:46 PM UTC-4, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >> >>>> Of course unfortunately it would not promote the MSP430 or 4e4th.... >> >>> I don't think 4e4th would be excluded. Can't it be ported to the AVR? >> >> >> >> 4e4th based on Camelforth which runs on several processors but uses a >> >> fair amount of assembly code, at least in the MSP430 version. Btw I >> >> didn't realize "promote the MSP430" was part of the goal here: the >> >> MSP430 seems like a convenient and low cost chip to use, but "promoting" >> >> it is TI's job, not ours. > > The TOPIC still is "MSP430-Stamp", was forked from "Go Forth and Prosper" > But that doesn't mean anything, I guess. The subject line is just that, some text. I thought to goal here was to discuss ideas on how to promote a forth target board. Lord knows the rest of the discussion has been all over the map. I don't have a problem with someone suggesting that limiting the idea to the TI devices is not the best idea even if I don't agree. I am quite happy with using the TI device. Much of the problem with this discussion is that we all seem to have different goals in mind. I am happy with limiting this discussion to an educational solution rather than a practical or commercial solution. That seems more in line with the original goals of 4e4th. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "VisualForth.com" <babruehl@gmail.com> |
|---|---|
| Date | 2014-06-01 12:01 -0700 |
| Message-ID | <5214d86e-42df-4693-85a7-171cf1763dc8@googlegroups.com> |
| In reply to | #31113 |
On Sunday, June 1, 2014 1:28:39 AM UTC-4, rickman wrote: > If the user wants the hardware with Forth together, then the Launchpad > could be programmed for them and sold with the Forth. Of course this > would increase the price significantly due to the handling and manual > work involved... best left to the user in my opinion. Then there is the > bricking issue. The problem with bricking for a new user is not the > cost, it is the discouragement. If they can easily recover by reloading > from the PC then it is not a real problem. So I think the best approach > is to let them buy the Launchpad themselves and provide them with the > software to make it a useful Forth development system. This is already done: Look at the 4E4th-IDE and MPE's MSP430 Forth Lite - both for free! There is nearly no difference to a preprogrammed Forth, at least with the 4Eth-IDE.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 15:12 -0400 |
| Message-ID | <lmftvq$tf4$2@dont-email.me> |
| In reply to | #31140 |
On 6/1/2014 3:01 PM, VisualForth.com wrote: > On Sunday, June 1, 2014 1:28:39 AM UTC-4, rickman wrote: > >> If the user wants the hardware with Forth together, then the Launchpad >> could be programmed for them and sold with the Forth. Of course this >> would increase the price significantly due to the handling and manual >> work involved... best left to the user in my opinion. Then there is the >> bricking issue. The problem with bricking for a new user is not the >> cost, it is the discouragement. If they can easily recover by reloading >> from the PC then it is not a real problem. So I think the best approach >> is to let them buy the Launchpad themselves and provide them with the >> software to make it a useful Forth development system. > > This is already done: > Look at the 4E4th-IDE and MPE's MSP430 Forth Lite - both for free! > There is nearly no difference to a preprogrammed Forth, at least with the 4Eth-IDE. Ok, I'm glad we knocked out that problem! I guess we can end this thread then. :) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-30 03:12 -0700 |
| Message-ID | <4e3ff942-2500-4874-9130-616b0e878f59@googlegroups.com> |
| In reply to | #30977 |
What I want to see is a small Forth board (MSP430 is fine) with a range of add-on boards that can be used for real world stuff. I want relay boards (one board, to drive 8 relays) I want analogue boards: 4-20mA current loop type (source or sink selectable) I want PWM boards I want I2C boards I want a LCD display add-on I want a 16-key keypad add-on I want a SD card reader add-on You know, like Microrobotics, from Cambridge do for their Venom boards: http://microrobotics.co.uk/vm2/interface.html http://microrobotics.co.uk/vm2/display.html http://microrobotics.co.uk/vm2/starterkit.html They make an awesome product. If something like that could be done, but with a Forth environment on it, I'm in.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-05-30 14:02 -0400 |
| Message-ID | <lmah44$75m$1@dont-email.me> |
| In reply to | #31019 |
On 5/30/2014 6:12 AM, Mark Wills wrote: > What I want to see is a small Forth board (MSP430 is > fine) with a range of add-on boards that can be > used for real world stuff. > > I want relay boards (one board, to drive 8 relays) > I want analogue boards: 4-20mA current loop type > (source or sink selectable) > I want PWM boards > I want I2C boards > I want a LCD display add-on > I want a 16-key keypad add-on > I want a SD card reader add-on > > You know, like Microrobotics, from Cambridge do for > their Venom boards: > > http://microrobotics.co.uk/vm2/interface.html > http://microrobotics.co.uk/vm2/display.html > http://microrobotics.co.uk/vm2/starterkit.html > > They make an awesome product. If something like that could be done, but with a Forth environment on it, I'm in. Do you have multiple personalities or something? You made three totally different posts in response to the same message in half an hour. So what do you want that you can't already get? Sounds like Microrobotics has what you want, you just don't like Venom. You can add Forth to *any* MCU can't you? What does the VM2 do that a bazillion other SBCs can't do? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-31 03:33 -0700 |
| Message-ID | <878620c5-46af-4827-81c4-d45bf9862709@googlegroups.com> |
| In reply to | #31037 |
On Friday, 30 May 2014 19:02:40 UTC+1, rickman wrote: > Do you have multiple personalities or something? You made three totally > different posts in response to the same message in half an hour. I wasn't aware that posting frequency was metered. Apologies. I'll try to post less if it annoys you. > > So what do you want that you can't already get? Sounds like > Microrobotics has what you want, you just don't like Venom. You can add > Forth to *any* MCU can't you? What does the VM2 do that a bazillion > other SBCs can't do? > Correct on all fronts. The VM2 hardware and software is really good. The issue for me is that the software has reached a level of complexity that I am uncomfortable with. The type of applications I want a board for are mission critical (SIL-1 or SIL-2). It comes down to being able prove to an external auditor that your code, or the OS underneath it isn't going to go off into the weeds. That's difficult to do with a closed OS. It's quite easy to do with an OS-less Forth system.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 07:19 -0700 |
| Message-ID | <7xwqd2f2te.fsf@ruckus.brouhaha.com> |
| In reply to | #31070 |
Mark Wills <markwills1970@gmail.com> writes: > Correct on all fronts. The VM2 hardware and software is really good. Don't know about the software but the hardware is an order of magnitude more expensive than the MSP430 stamp we were supposedly discussing. I'm sure it's well made and it may be fine for some industrial markets, but seems unaffordable for educational and consumer applications.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-05-31 12:01 -0400 |
| Message-ID | <lmcudd$ni6$1@dont-email.me> |
| In reply to | #31070 |
On 5/31/2014 6:33 AM, Mark Wills wrote: > On Friday, 30 May 2014 19:02:40 UTC+1, rickman wrote: >> Do you have multiple personalities or something? You made three totally >> different posts in response to the same message in half an hour. > > I wasn't aware that posting frequency was metered. Apologies. I'll try to post less if it annoys you. I just found it a bit confusing. Three posts with totally different spins. I wasn't sure which one to respond to. >> So what do you want that you can't already get? Sounds like >> Microrobotics has what you want, you just don't like Venom. You can add >> Forth to *any* MCU can't you? What does the VM2 do that a bazillion >> other SBCs can't do? >> > > Correct on all fronts. The VM2 hardware and software is really good. The issue for me is that the software has reached a level of complexity that I am uncomfortable with. The type of applications I want a board for are mission critical (SIL-1 or SIL-2). It comes down to being able prove to an external auditor that your code, or the OS underneath it isn't going to go off into the weeds. That's difficult to do with a closed OS. It's quite easy to do with an OS-less Forth system. So why not run Forth on their hardware then? I don't mind designing new hardware, but I'd like to understand what the purpose is. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 09:15 -0700 |
| Message-ID | <7xbnudsz5m.fsf@ruckus.brouhaha.com> |
| In reply to | #31070 |
Mark Wills <markwills1970@gmail.com> writes: > The VM2 hardware and software is really good... The type of > applications I want a board for are mission critical (SIL-1 or > SIL-2). It comes down to being able prove to an external auditor that > your code, or the OS underneath it isn't going to go off into the > weeds. Do you not need auditibility of the hardware for that as well? Is the VM2 auditible, including the chips? Do the boards use safety certified chips (I didn't see a mention of that)? I notice one of the TI Launchpads uses a chip specifically designated as being made for safety applications (I doubt the Launchpad board itself is certified for that though). The chip has something like dual ARM cores operating in lockstep with ECC on all data paths, and differential fault detection in the hardware. > That's difficult to do with a closed OS. It's quite easy to do with an > OS-less Forth system. I'm not convinced that it's easy to do in Forth either, if the software has much complexity. Look at the OpenSSL Heartbleed bug, for example. Do you think that would have been more easily detected in Forth? It wasn't a terribly deep or devious bug, but a good programmer made it and another good programmer familiar with the codebase missed it on review. The strength of Forth seems rest to partly in a philosophy of keeping the code very simple. There are some applications that can't help being complex, and Forth tends to not be used in them.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 13:51 -0700 |
| Message-ID | <7xy4xh8yfe.fsf@ruckus.brouhaha.com> |
| In reply to | #31077 |
Paul Rubin <no.email@nospam.invalid> writes: >> The type of applications I want a board for are mission critical >> (SIL-1 or SIL-2). > ... one of the TI Launchpads uses a chip specifically designated as > being made for safety applications... The chip has something like > dual ARM cores operating in lockstep with ECC on all data paths, and > differential fault detection in the hardware. OK, maybe this is overkill for SIL-1 or -2 (I read up a little and there are 4 levels). Still though, I think the hardware appropriate for critical applications is different (much more expensive) than what makes sense for educational or consumer applications. I do seem to remember that Forth Inc. and MPE both offer hardware (some of it seemingly comparable to the Viper stuff) with Forth integrated. Maybe that's what you want.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-31 14:20 -0700 |
| Message-ID | <75a28dfe-8b35-4b81-90f2-925cdc40ca23@googlegroups.com> |
| In reply to | #31090 |
On Saturday, 31 May 2014 21:51:01 UTC+1, Paul Rubin wrote: > Paul Rubin <no.email@nospam.invalid> writes: > > >> The type of applications I want a board for are mission critical > > >> (SIL-1 or SIL-2). > > > ... one of the TI Launchpads uses a chip specifically designated as > > > being made for safety applications... The chip has something like > > > dual ARM cores operating in lockstep with ECC on all data paths, and > > > differential fault detection in the hardware. > > > > OK, maybe this is overkill for SIL-1 or -2 (I read up a little and there > > are 4 levels). Still though, I think the hardware appropriate for > > critical applications is different (much more expensive) than what makes > > sense for educational or consumer applications. > > > > I do seem to remember that Forth Inc. and MPE both offer hardware (some > > of it seemingly comparable to the Viper stuff) with Forth integrated. > > Maybe that's what you want. Yes I like that board on the MPE site. The only issue is that minimum orders are 25 off. You're quite right that this is quite some way off from educational Forth programming. I would have thought the FIGnition was pretty much perfect though. I must admit though, that I like the idea of a bread-board Forth system. If the manual had a few different "recipes" (think of the old electronics kits for kids that had 10 or so different circuits that one could build) then that would be great. I'd be willing to contribute to getting something put together, and help with documentation. I have more than 50% of a book on Forth programming already written. It's written for total newcomers to Forth programming. It wouldn't take much to change it to suit a system other than my own (it's written for my retro hobby system on the very retro TI-99/4A) and might give me an incentive to finish it!
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 14:51 -0700 |
| Message-ID | <7xtx858vmk.fsf@ruckus.brouhaha.com> |
| In reply to | #31094 |
Mark Wills <markwills1970@gmail.com> writes:
> You're quite right that this is quite some way off from educational
> Forth programming. I would have thought the FIGnition was pretty much
> perfect though. I must admit though, that I like the idea of a
> bread-board Forth system.
Yes. I've never been convinced of the Fignition or 4e4th concept of an
MCU board as a tool for educational Forth programming. Gforth on a PC
seems better for that. Dirk gave the real insight, which is that the
end goal isn't Forth programming but rather it's embedded programming,
so Forth is an intermediate step. And that means the educational value
can come least partly from actual mucking with hardware at the level of
chips and wires, thus a breadboard instead of a PCB.
> If the manual had a few different "recipes" (think of the old
> electronics kits for kids that had 10 or so different circuits that
> one could build) then that would be great.
Yes, I like that idea a lot, especially since the later projects can
involve ripping up and re-using the parts of earlier ones, which is
difficult with PCB's.
- Project 1: blinking LED (mostly about wiring up the chip and LED)
- Project 2: Morse code (about software: program a text-to-morse
converter running the led from project 1)
- Project 3: Music synthesis (replace the led with a speaker and
change the morse code software to make waveforms or PWM on the GPIO
pin that was running the led)
- Project 4: Rocket launcher (about analog electronics) - use the
gpio pin to toggle a pulldown transistor, that energizes a
hand-wound coil that triggers a rubber band launcher that you
made out of paper clips
You get the idea.
> I'd be willing to contribute to getting something put together, and
> help with documentation. I have more than 50% of a book on Forth
> programming already written...
That would be really neat.
[toc] | [prev] | [next] | [standalone]
| From | "VisualForth.com" <babruehl@gmail.com> |
|---|---|
| Date | 2014-05-31 16:22 -0700 |
| Message-ID | <6da4e2f6-fa2b-4acb-8293-2aa4567debcb@googlegroups.com> |
| In reply to | #31094 |
On Saturday, May 31, 2014 5:20:32 PM UTC-4, Mark Wills wrote: > On Saturday, 31 May 2014 21:51:01 UTC+1, Paul Rubin wrote: > > > Paul Rubin <no.email@nospam.invalid> writes: > > > > > > >> The type of applications I want a board for are mission critical > > > > > > >> (SIL-1 or SIL-2). > > > > > > > ... one of the TI Launchpads uses a chip specifically designated as > > > > > > > being made for safety applications... The chip has something like > > > > > > > dual ARM cores operating in lockstep with ECC on all data paths, and > > > > > > > differential fault detection in the hardware. > > > > > > > > > > > > OK, maybe this is overkill for SIL-1 or -2 (I read up a little and there > > > > > > are 4 levels). Still though, I think the hardware appropriate for > > > > > > critical applications is different (much more expensive) than what makes > > > > > > sense for educational or consumer applications. > > > > > > > > > > > > I do seem to remember that Forth Inc. and MPE both offer hardware (some > > > > > > of it seemingly comparable to the Viper stuff) with Forth integrated. > > > > > > Maybe that's what you want. > > > > Yes I like that board on the MPE site. The only issue is that minimum orders are 25 off. > > > > You're quite right that this is quite some way off from > > educational Forth programming. I would have thought the > > FIGnition was pretty much perfect though. I must admit though, > > that I like the idea of a bread-board Forth system. If the > > manual had a few different "recipes" (think of the old > > electronics kits for kids that had 10 or so different circuits > > that one could build) then that would be great. I'd be willing > > to contribute to getting something put together, and help with > > documentation. I have more than 50% of a book on Forth > > programming already written. It's written for total newcomers > > to Forth programming. It wouldn't take much to change it to > > suit a system other than my own (it's written for my retro hobby > > system on the very retro TI-99/4A) and might give me an > > incentive to finish it! That's awesome! Great to know that 50% are already done!
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-06-01 01:33 +0200 |
| Message-ID | <lmdos0$gl9$1@online.de> |
| In reply to | #31077 |
Paul Rubin wrote: > I'm not convinced that it's easy to do in Forth either, if the software > has much complexity. Look at the OpenSSL Heartbleed bug, for example. > Do you think that would have been more easily detected in Forth? It > wasn't a terribly deep or devious bug, but a good programmer made it and > another good programmer familiar with the codebase missed it on review. The amount of bugs in a reviewed and "debugged" code-base is roughly the same per kLoC; the difference between a good one (like the Linux kernel) and a bad one isn't that high. OpenSSL is a big heap of code. It's simply too large to be trustworthy. The LibreSSL is going to throw out vast amounts of stuff that is unnecessary, like portability to OpenVMS and things like that. That alone will remove quite a number of bugs. However, if you do such things in Forth, and you do them right, you'll end up with much smaller code, and therefore, there will be an awful lot less bugs in the debugged product. This is just because Forth is way more expressive, as you write DSLs as you go. You can still write bad and bloated Forth programs, of course. But > The strength of Forth seems rest to partly in a philosophy of keeping > the code very simple. There are some applications that can't help being > complex, and Forth tends to not be used in them. The inherent complexity of a cryptographic protocol is much, much lower than SSL - the inherent complexity are in the order of a kLoC at most (I exclude the actual crypto primitives, as I simply use performant and well-debugged libraries, which are small enough to be ok even though they are written in C - if you convert that to compact Forth, stuff like Keccak is trivial; the ed25519 stuff was originally written in Python, and it is trivial there, too - good crypto is very simple stuff). The inherent complexity in SSL (which is horrible and therefore not even an option to considder if you think about why crypto is circumvented so often) is much, much lower than OpenSSL, I would guess at a few kLoCs. OpenSSL is a few hundred kLoCs, and I expect the LibreSSL people to strip it down below 100kLoCs. This is then still two orders of magnitude more than net2o. And net2o doesn't just replace OpenSSL, it also replaces DNSSEC, and is going to replace PGP as well. If a Forth programmer gets into a field where people think there is inherent complexity, they usually don't take much existing stuff, and start with the biggest source of bugs and bloatware: the specification (this needs to be burned and the ashes blown into the wind). If you have a big clusterfuck like Internet crypto, which was being subverted by NSA and other agencies (the BND e.g. is a very close cooperation partner, as well as the GCHQ) from day one, you not only have to throw the baby out with the bathwater (it has been conceived by the devil himself), you also have to demolish the entire building around the bath, and the stinking sewerage under the city. It's really *that* bad. The heartbleed bug is possible with Forth, too. The question is: Would a Forth programmer write such a protocol extension that only makes sense in an UDP-based protocol while SSL is TCP-based? Quite likely not. The other question is: How much would a Forth programmer have tested? When Heardbleed was discovered, I wrote a small Forth program to check servers for it; I did so because all the programs on the Internet checking for Heartbleed are big bloatware. All you need to check for Heartbleed is to send two fixed SSL protocol packets via TCP, you don't need a full SSL stack or anything remotely like that. And the first thing I found was that Heartbleed was limiting the output to 16k, at a time where everybody else said, Heartbleed could leak up to 64k of memory. They had read the source code, but they haven't even tested their assumptions! That sort of stuff happens all the time with programming languages where tinkiering with things isn't easy. You make an unfounded assumption and you don't find the time to prove it. You don't really debug for anything more than mere functionality, and that's certainly *not* enough for security relevant stuff. You must try everything to break your code, and if that fails, it's good. This is the reason why that sort of stuff happens so often with other programming languages. In Forth, debugging is fun, and quick. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web