Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #46626 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2016-04-11 15:32 -0400 |
| Last post | 2016-05-21 22:32 -0400 |
| Articles | 20 on this page of 146 — 19 participants |
Back to article view | Back to comp.lang.forth
Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-11 15:32 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-14 08:10 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-14 12:43 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-14 17:33 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-14 21:09 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 04:38 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 11:55 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 10:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 14:07 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 mhx@iae.nl - 2016-04-15 10:56 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-15 14:33 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-18 17:59 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-19 03:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-22 00:33 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 04:27 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-15 06:30 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-18 21:47 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "HAA" <someone@microsoft.com> - 2016-04-21 01:27 +1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-20 21:12 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-20 15:54 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-20 19:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-21 17:13 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-21 22:26 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-22 11:35 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-22 14:47 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-22 12:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 01:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 15:11 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 18:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 16:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 22:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-23 21:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 01:58 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-24 00:53 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 12:08 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "Elizabeth D. Rather" <erather@forth.com> - 2016-04-24 14:59 -1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 22:15 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-24 20:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-24 20:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-25 18:41 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-30 08:39 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 13:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-02 11:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-02 16:31 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-02 16:50 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-02 16:49 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 09:06 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 10:20 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 14:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 14:44 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-03 16:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-03 16:28 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-03 13:37 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-05 02:56 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-05 23:56 +0100
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-06 08:42 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 13:00 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Mike Mellen <mmellen@intellikey.com> - 2016-05-06 13:56 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-07 03:48 -0500
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-07 14:05 +0100
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-07 08:34 -0500
Re: RTX20xx, was Ting: SVFIG FPGA Design Workshop Featuring eP8080 pahihu <pahihu@gmail.com> - 2016-05-08 12:22 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-04 00:10 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-04 00:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 12:20 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 13:03 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 11:30 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 15:23 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 12:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 12:56 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 17:04 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 17:38 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 15:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 18:58 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 19:09 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:14 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-06 19:17 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:24 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-05-06 16:20 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Walter Banks <walter@bytecraft.com> - 2016-05-06 17:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-07 13:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-07 14:57 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "Elizabeth D. Rather" <erather@forth.com> - 2016-05-03 10:58 -1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-05-03 21:35 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 23:04 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 22:41 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 01:55 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 23:21 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:21 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-24 08:40 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-24 08:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 12:16 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 22:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-24 03:29 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 visualforth@rocketmail.com - 2016-04-25 19:03 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 05:04 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-26 10:42 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 15:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-26 16:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 21:10 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-27 01:18 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 09:44 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-27 09:48 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-28 23:23 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 05:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 stephen@mpeforth.com (Stephen Pelc) - 2016-04-23 12:10 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-23 08:05 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-23 13:01 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 18:36 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "HAA" <someone@microsoft.com> - 2016-04-23 21:33 +1000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 hughaguilar96@gmail.com - 2016-04-22 09:47 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 "WJ" <w_a_x_man@yahoo.com> - 2016-04-25 07:24 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-23 16:16 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-26 03:15 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-26 11:22 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-27 07:48 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 12:05 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-27 10:34 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 10:51 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 14:27 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 11:38 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 16:04 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 16:52 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 17:25 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 10:06 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-01 14:07 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 11:14 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-27 17:17 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 02:06 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-28 00:43 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 11:53 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-04-28 18:39 +0000
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-28 17:02 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-30 13:32 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 16:49 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Paul Rubin <no.email@nospam.invalid> - 2016-04-30 18:55 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-30 22:08 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-05-01 09:32 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-01 14:10 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-04-27 14:12 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Coos Haak <chforth@hccnet.nl> - 2016-04-27 23:45 +0200
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 JUERGEN <epldfpga@aol.com> - 2016-04-29 07:17 -0700
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-16 18:48 -0400
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 Cecil Bayona <cbayona@cbayona.com> - 2016-05-17 14:28 -0500
Re: Ting: SVFIG FPGA Design Workshop Featuring eP8080 rickman <gnuarm@gmail.com> - 2016-05-21 22:32 -0400
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-27 14:27 -0400 |
| Message-ID | <nfr03o$cp6$1@dont-email.me> |
| In reply to | #46806 |
On 4/27/2016 1:51 PM, Paul Rubin wrote: > JUERGEN <epldfpga@aol.com> writes: >> Thanks Rick, I have asked if there is an easy way to just cut out 8 of >> the 16 16bit registers for now to fit into the IceStick1k - this would >> be a nice solution. My so called 901 - 1/2 of the 1802 in registers. >> Fig Forth 1802 found. A lot of fun and history brought back to life. > > I wonder what you guys get out of implementing this stuff in FPGA's > instead of software. I understand the enjoyment of emulating old > processors, but unless you need exact timing etc., why not just save a > lot of effort by just writing code? Why is it more effort to write HDL than to write Forth or some other software only language? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-27 11:38 -0700 |
| Message-ID | <8760v2j3s0.fsf@nightsong.com> |
| In reply to | #46810 |
rickman <gnuarm@gmail.com> writes: > Why is it more effort to write HDL than to write Forth or some other > software only language? I don't know, I've never written HDL. But one obvious issue is the hassle of compiling it and loading it into the target FPGA. Where if I just wanted to play with RTX or 1802 programming or whatever, I could run an emulator on my laptop or on a razzleberry pi etc., surely more convenient.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-27 16:04 -0400 |
| Message-ID | <nfr5q3$3m6$1@dont-email.me> |
| In reply to | #46811 |
On 4/27/2016 2:38 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Why is it more effort to write HDL than to write Forth or some other >> software only language? > > I don't know, I've never written HDL. But one obvious issue is the > hassle of compiling it and loading it into the target FPGA. Where if I > just wanted to play with RTX or 1802 programming or whatever, I could > run an emulator on my laptop or on a razzleberry pi etc., surely more > convenient. Don't you still have to compile it and run it? I believe you feel there is something especially hard about loading a file into an FPGA. Actually, the FPGA would be programmed once (the configuration is usually saved in Flash) and the board boots up on power up just like any target board. You then load your application and you are off! I've never found an emulator that was any easier to use than an FPGA board. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-27 16:52 -0400 |
| Message-ID | <nfr8ji$fbp$1@dont-email.me> |
| In reply to | #46813 |
On 4/27/2016 4:04 PM, rickman wrote: > On 4/27/2016 2:38 PM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> Why is it more effort to write HDL than to write Forth or some other >>> software only language? >> >> I don't know, I've never written HDL. But one obvious issue is the >> hassle of compiling it and loading it into the target FPGA. Where if I >> just wanted to play with RTX or 1802 programming or whatever, I could >> run an emulator on my laptop or on a razzleberry pi etc., surely more >> convenient. > > Don't you still have to compile it and run it? I believe you feel there > is something especially hard about loading a file into an FPGA. > Actually, the FPGA would be programmed once (the configuration is > usually saved in Flash) and the board boots up on power up just like any > target board. You then load your application and you are off! > > I've never found an emulator that was any easier to use than an FPGA board. I just realized, you likely meant to say "simulator" rather than "emulator". I assume that was a typo. I doubt you will be running RTX code on an emulator unless you have an RTX in an FPGA which is the thing you are saying is harder to use. My point still stands. The user interface for an emulator and a simulator are largely the same. In the end you have a bunch of "stuff" you have to do to get a design tested. The "stuff" you do for an FPGA design may be different, but it is *very* comparable in terms of "hassle factor". Once you've loaded a CPU emulation into an FPGA it is largely the same as using the real device. When interfacing a peripheral in HDL, the simulation is so much easier to debug than the real world. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-27 17:25 -0700 |
| Message-ID | <87shy6h94b.fsf@nightsong.com> |
| In reply to | #46814 |
rickman <gnuarm@gmail.com> writes: > I just realized, you likely meant to say "simulator" rather than > "emulator". I assume that was a typo. I doubt you will be running > RTX code on an emulator unless you have an RTX in an FPGA which is the > thing you are saying is harder to use. Oh I suppose there's a distinction but I wasn't worrying about it. I just meant a software program that runs the RTX instruction set but doesn't try to get the timing exact, as Juergen mentioned. I could probably write that in an afternoon or two in Python or somewhat longer in Forth. As said I've never used HDL. I could believe that it's as quick as Forth but I'd be surprised if it's quicker. > Once you've loaded a CPU emulation into an FPGA it is largely the same > as using the real device. When interfacing a peripheral in HDL, the > simulation is so much easier to debug than the real world. I know there are FPGA implementations of the PDP-10 which have sputtered around for many years without ever really getting anywhere, but there are many software simulations out there, some of which ran actual PDP-10 production applications commercially. There are also software simulations of most old microcomputers, there's DOSEMU that lets you run DOS stuff under Linux, etc. These things could also be done with FPGA's but most people don't bother, presumably for a reason.
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-05-01 10:06 -0700 |
| Message-ID | <fe8ba5b9-cfb9-41dc-b4e7-7cc15039662d@googlegroups.com> |
| In reply to | #46820 |
On Thursday, April 28, 2016 at 1:25:58 AM UTC+1, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > > I just realized, you likely meant to say "simulator" rather than > > "emulator". I assume that was a typo. I doubt you will be running > > RTX code on an emulator unless you have an RTX in an FPGA which is the > > thing you are saying is harder to use. > > Oh I suppose there's a distinction but I wasn't worrying about it. I > just meant a software program that runs the RTX instruction set but > doesn't try to get the timing exact, as Juergen mentioned. I could > probably write that in an afternoon or two in Python or somewhat longer > in Forth. As said I've never used HDL. I could believe that it's as > quick as Forth but I'd be surprised if it's quicker. > > > Once you've loaded a CPU emulation into an FPGA it is largely the same > > as using the real device. When interfacing a peripheral in HDL, the > > simulation is so much easier to debug than the real world. > > I know there are FPGA implementations of the PDP-10 which have sputtered > around for many years without ever really getting anywhere, but there > are many software simulations out there, some of which ran actual PDP-10 > production applications commercially. There are also software > simulations of most old microcomputers, there's DOSEMU that lets you run > DOS stuff under Linux, etc. These things could also be done with FPGA's > but most people don't bother, presumably for a reason. Paul, write the software simulator for the RTX in an afternoon or so - well, you have to do it to prove it so we believe it. And for me it is the same situation for Novix and GA144 or even a G1 , G16, ... - if it is so simple - why is there no Forth Software Emulator - probably people have tried and gave up. Just a software simulator - timing is secondary. If the emulators exist - people can decide what to run it on if they want to.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-01 14:07 -0400 |
| Message-ID | <ng5gep$i8s$2@dont-email.me> |
| In reply to | #46856 |
On 5/1/2016 1:06 PM, JUERGEN wrote: > On Thursday, April 28, 2016 at 1:25:58 AM UTC+1, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> I just realized, you likely meant to say "simulator" rather than >>> "emulator". I assume that was a typo. I doubt you will be >>> running RTX code on an emulator unless you have an RTX in an FPGA >>> which is the thing you are saying is harder to use. >> >> Oh I suppose there's a distinction but I wasn't worrying about it. >> I just meant a software program that runs the RTX instruction set >> but doesn't try to get the timing exact, as Juergen mentioned. I >> could probably write that in an afternoon or two in Python or >> somewhat longer in Forth. As said I've never used HDL. I could >> believe that it's as quick as Forth but I'd be surprised if it's >> quicker. >> >>> Once you've loaded a CPU emulation into an FPGA it is largely the >>> same as using the real device. When interfacing a peripheral in >>> HDL, the simulation is so much easier to debug than the real >>> world. >> >> I know there are FPGA implementations of the PDP-10 which have >> sputtered around for many years without ever really getting >> anywhere, but there are many software simulations out there, some >> of which ran actual PDP-10 production applications commercially. >> There are also software simulations of most old microcomputers, >> there's DOSEMU that lets you run DOS stuff under Linux, etc. These >> things could also be done with FPGA's but most people don't bother, >> presumably for a reason. > > Paul, write the software simulator for the RTX in an afternoon or so > - well, you have to do it to prove it so we believe it. And for me it > is the same situation for Novix and GA144 or even a G1 , G16, ... - > if it is so simple - why is there no Forth Software Emulator - > probably people have tried and gave up. Just a software simulator - > timing is secondary. If the emulators exist - people can decide what > to run it on if they want to. Writing a simulator for any CPU is a lot harder than it might sound. Just the GUI is much more than a day's work. Then there is the digging through the docs to get the instructions right. Testing could easily take weeks. I don't get the purpose of an RTX emulator on a modern chip. Why not just run on the modern chip directly? Is it a WOW factor of saying you are programming the chip that few on the Philae? If you are coding in Forth just target the chip you are using. No? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-05-01 11:14 -0700 |
| Message-ID | <7c04772a-7b6e-45a1-bb60-f3164e95d2a1@googlegroups.com> |
| In reply to | #46857 |
On Sunday, May 1, 2016 at 7:07:39 PM UTC+1, rickman wrote: > On 5/1/2016 1:06 PM, JUERGEN wrote: > > On Thursday, April 28, 2016 at 1:25:58 AM UTC+1, Paul Rubin wrote: > >> rickman <gnuarm@gmail.com> writes: > >>> I just realized, you likely meant to say "simulator" rather than > >>> "emulator". I assume that was a typo. I doubt you will be > >>> running RTX code on an emulator unless you have an RTX in an FPGA > >>> which is the thing you are saying is harder to use. > >> > >> Oh I suppose there's a distinction but I wasn't worrying about it. > >> I just meant a software program that runs the RTX instruction set > >> but doesn't try to get the timing exact, as Juergen mentioned. I > >> could probably write that in an afternoon or two in Python or > >> somewhat longer in Forth. As said I've never used HDL. I could > >> believe that it's as quick as Forth but I'd be surprised if it's > >> quicker. > >> > >>> Once you've loaded a CPU emulation into an FPGA it is largely the > >>> same as using the real device. When interfacing a peripheral in > >>> HDL, the simulation is so much easier to debug than the real > >>> world. > >> > >> I know there are FPGA implementations of the PDP-10 which have > >> sputtered around for many years without ever really getting > >> anywhere, but there are many software simulations out there, some > >> of which ran actual PDP-10 production applications commercially. > >> There are also software simulations of most old microcomputers, > >> there's DOSEMU that lets you run DOS stuff under Linux, etc. These > >> things could also be done with FPGA's but most people don't bother, > >> presumably for a reason. > > > > Paul, write the software simulator for the RTX in an afternoon or so > > - well, you have to do it to prove it so we believe it. And for me it > > is the same situation for Novix and GA144 or even a G1 , G16, ... - > > if it is so simple - why is there no Forth Software Emulator - > > probably people have tried and gave up. Just a software simulator - > > timing is secondary. If the emulators exist - people can decide what > > to run it on if they want to. > > Writing a simulator for any CPU is a lot harder than it might sound. > Just the GUI is much more than a day's work. Then there is the digging > through the docs to get the instructions right. Testing could easily > take weeks. > > I don't get the purpose of an RTX emulator on a modern chip. Why not > just run on the modern chip directly? Is it a WOW factor of saying you > are programming the chip that flew on the Philae? If you are coding in > Forth just target the chip you are using. No? > > -- > > Rick C I think the 8080 workshop answers the question - or you will find answers there and then. For me it is understanding how it works and seeing how the data is handled. Interesting for me yes - for many others I do not know but this is beside the point for me.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-27 17:17 -0700 |
| Message-ID | <87wpnih9hz.fsf@nightsong.com> |
| In reply to | #46813 |
rickman <gnuarm@gmail.com> writes: >> run an emulator on my laptop or on a razzleberry pi > Don't you still have to compile it and run it? I believe you feel > there is something especially hard about loading a file into an > FPGA. Actually, the FPGA would be programmed once (the configuration > is usually saved in Flash) and the board boots up on power up just > like any target board. You then load your application and you are > off! Wouldn't I have to 1) order the FPGA board from somewhere; 2) figure out how to connect it up and configure it; 3) make room for it on my overcrowded computer table; 4) get hold of a Windows machine and install and configure and run closed-source Windows tools to load stuff into the FPGA? By comparison I can run a software emulation on > I've never found an emulator that was any easier to use than an FPGA > board. Mecrisp comes with an ARM emulator that you can compile and run on an existing computer. In fact I run Mecrisp on a computer that I've never seen or touched. It's a scaleway.com C1 board in Paris, France that I connect to by internet. How can that be harder than actually mucking with an FPGA with physical cables and all that grody stuff?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-28 02:06 -0400 |
| Message-ID | <nfs938$dd3$1@dont-email.me> |
| In reply to | #46819 |
On 4/27/2016 8:17 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> run an emulator on my laptop or on a razzleberry pi >> Don't you still have to compile it and run it? I believe you feel >> there is something especially hard about loading a file into an >> FPGA. Actually, the FPGA would be programmed once (the configuration >> is usually saved in Flash) and the board boots up on power up just >> like any target board. You then load your application and you are >> off! > > Wouldn't I have to 1) order the FPGA board from somewhere; 2) figure out > how to connect it up and configure it; 3) make room for it on my > overcrowded computer table; 4) get hold of a Windows machine and install > and configure and run closed-source Windows tools to load stuff into the > FPGA? By comparison I can run a software emulation on > >> I've never found an emulator that was any easier to use than an FPGA >> board. > > Mecrisp comes with an ARM emulator that you can compile and run on an > existing computer. In fact I run Mecrisp on a computer that I've never > seen or touched. It's a scaleway.com C1 board in Paris, France that I > connect to by internet. How can that be harder than actually mucking > with an FPGA with physical cables and all that grody stuff? I bet you had a harder time getting your cable modem running than it would be to get an FPGA board up and running. Plug in both ends of the USB cable... done. Was that so hard? I can see there is no point to discussing this further. You have it in your mind that there is something intrinsically difficult about working with FPGAs. That is likely based on your lack of knowledge in the area. I can assure you that I had *much* more trouble trying to get the bloody Stellaris board to run Mecrisp than I did getting *any* of the FPGA boards up and running including the one I designed myself! The TI driver wasn't signed so I eventually gave up trying to install it under Windows 8. I had an rPi that I had never used before which could serve as the platform to host the flash tool for the Stellaris board... once I learned a enough about Linux. Then it came time to talk to the Stellaris board. I've never had so much trouble finding a compatible terminal program in my life! Seems every command window under Linux is a terminal window, except it isn't connected to a serial port and it doesn't have any idea how to be a *useful* terminal. I don't remember how many programs I went through to find one that was actually compatible with Mecrisp. It was all finally worth the effort to use the rPi as a remote interface from the other room from my laptop although I still had to go in when the Stellaris got hung. By comparison, I've never had any real issue with any connection to an FPGA board. The one I designed is programmed using a programming cable from the Lattice Diamond tools. No problem there. This same programmer is used to program hundreds and thousands of boards in production. I think programming and test takes about two minutes per board which includes plugging and unplugging the board from the test fixture and attaching the serial number label. The eval/kickstart boards typically use a single USB cable for power *and* control and even include a UART interface if you wish to use that to talk to your design. I suppose you can find simulators to run on your PC. I don't recall there being one for Mecrisp. I wouldn't mind a link. That might be useful if you don't want to use hardware. All of my HDL designs are wrung out thoroughly in simulation before they ever touch the hardware. It is infinitely easier to access internal signals in simulation than in hardware. But that's the hardware design, not the software. Any project that uses hardware will need to reach the metal at some point. Then you just plain need hardware. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-28 00:43 -0700 |
| Message-ID | <87k2jigovb.fsf@nightsong.com> |
| In reply to | #46823 |
rickman <gnuarm@gmail.com> writes: > I bet you had a harder time getting your cable modem running than it > would be to get an FPGA board up and running. Plug in both ends of > the USB cable... done. Was that so hard? No host-side software? > I can assure you that I had *much* more trouble trying to > get the bloody Stellaris board to run Mecrisp than I did getting *any* > of the FPGA boards up and running including the one I designed myself! Yeah, I find the idea of bringing up Mecrisp on the Stellaris somewhat off-putting too. I got two Stellaris boards when they were on promotion for $5 each but they're sitting on their boxes years later. I like to think I could deal with getting Mecrisp up on the Stellaris if I had a reason to do so, but again, I see multiple hours or days of futzing around as par for the course with this kind of thing. By comparison, compiling Mecrisp under Linux took just a few seconds and I could run it immediately, though not really usefully due to mysterious bugs it has on the Scaleway platform. I do get the impression that the Arduino and maybe current ARM Mbed environments are much easier to deal with than the Stellaris software that TI shipped. > The TI driver wasn't signed so I eventually gave up trying to install > it under Windows 8. I wouldn't have even tried that as I almost never use Windows for anything. > Seems every command window under Linux is a terminal window, except it > isn't connected to a serial port Hmm, ok, yeah I can see how that might have been an obstacle to a Linux newcomer. As a Linux developer I know how to deal with issues like that, but it takes a while to know where to find the knowledge. > I suppose you can find simulators to run on your PC. I don't recall > there being one for Mecrisp. I wouldn't mind a link. It's included with Mecrisp-stellaris-- look for files called "thumbulator*.c" The .c file cites: https://github.com/dwelch67/thumbulator but Matthias modified it some for Mecrisp and specific cpus. I haven't tried to use it. > That might be useful if you don't want to use hardware. All of my HDL > designs are wrung out thoroughly in simulation before they ever touch > the hardware. OK, so you also see the value of avoiding touching hardware for as long as possible. But with FPGAs (or with a Stellaris) you eventually do need to touch the hardware. With a Linux box you might never need to. > Any project that uses hardware will need to reach the metal at some > point. Then you just plain need hardware. Yes, definitely so. However, many many things don't need hardware. I've never really understood some posters' desire to build microprocessor boards to help people learn Forth. It's far easier to learn Forth using something like Gforth on a Linux box. I follow the hardware projects and am interested in them from my desire to learn something about hardware, not for learning Forth. That said, Mecrisp-ICE, targeted to a modified J1 running on an FPGA with a completely FOSS toolchain, looks really interesting.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-28 11:53 -0400 |
| Message-ID | <nftbg0$8s1$1@dont-email.me> |
| In reply to | #46824 |
On 4/28/2016 3:43 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I bet you had a harder time getting your cable modem running than it >> would be to get an FPGA board up and running. Plug in both ends of >> the USB cable... done. Was that so hard? > > No host-side software? > >> I can assure you that I had *much* more trouble trying to >> get the bloody Stellaris board to run Mecrisp than I did getting *any* >> of the FPGA boards up and running including the one I designed myself! > > Yeah, I find the idea of bringing up Mecrisp on the Stellaris somewhat > off-putting too. I got two Stellaris boards when they were on promotion > for $5 each but they're sitting on their boxes years later. I like to > think I could deal with getting Mecrisp up on the Stellaris if I had a > reason to do so, but again, I see multiple hours or days of futzing > around as par for the course with this kind of thing. By comparison, > compiling Mecrisp under Linux took just a few seconds and I could run it > immediately, though not really usefully due to mysterious bugs it has on > the Scaleway platform. > > I do get the impression that the Arduino and maybe current ARM Mbed > environments are much easier to deal with than the Stellaris software > that TI shipped. > >> The TI driver wasn't signed so I eventually gave up trying to install >> it under Windows 8. > > I wouldn't have even tried that as I almost never use Windows for > anything. > >> Seems every command window under Linux is a terminal window, except it >> isn't connected to a serial port > > Hmm, ok, yeah I can see how that might have been an obstacle to a Linux > newcomer. As a Linux developer I know how to deal with issues like > that, but it takes a while to know where to find the knowledge. > >> I suppose you can find simulators to run on your PC. I don't recall >> there being one for Mecrisp. I wouldn't mind a link. > > It's included with Mecrisp-stellaris-- look for files called > "thumbulator*.c" The .c file cites: > > https://github.com/dwelch67/thumbulator > > but Matthias modified it some for Mecrisp and specific cpus. I haven't > tried to use it. So you don't know what it takes to run??? What do I do with a .c file? That's going to be a hundred times more painful than running the FPGA software. But then I know how to do that. Everything is easy if you know it, lol. I remember showing my customer the Lattice classic tools. The programmer has some goofy marketing name and my customer couldn't find it. Once I showed it to him it was easier. The factory programs and tests my boards. This is done by a 20-something tech, so how hard can it be? Of course once you've done a thousand of them I guess it gets easier... lol >> That might be useful if you don't want to use hardware. All of my HDL >> designs are wrung out thoroughly in simulation before they ever touch >> the hardware. > > OK, so you also see the value of avoiding touching hardware for as long > as possible. But with FPGAs (or with a Stellaris) you eventually do > need to touch the hardware. With a Linux box you might never need to. You miss the point. Running the simulation for debugging the hardware is invaluable because the hardware is hard to view. If I were debugging RTX code and had a good debugger I would likely prefer to run the code on the hardware. I don't recall seeing much software development done in simulation because of the practicalities of creating the environment. Embedded stuff is all about interacting with the environment and modern processors have debuggers (emulators). If you just want to run Aristophanes's Sieve then a simulator would do just fine. >> Any project that uses hardware will need to reach the metal at some >> point. Then you just plain need hardware. > > Yes, definitely so. However, many many things don't need hardware. > I've never really understood some posters' desire to build > microprocessor boards to help people learn Forth. It's far easier to > learn Forth using something like Gforth on a Linux box. I follow the > hardware projects and am interested in them from my desire to learn > something about hardware, not for learning Forth. Because an embedded board can do things that are hard to do from a PC (at least since they took away the parallel port). Those things can be much more interesting than seeing the OK prompt on a PC. > That said, Mecrisp-ICE, targeted to a modified J1 running on an FPGA > with a completely FOSS toolchain, looks really interesting. Not sure why. It is limited to a very small selection of chips. Ask Juergen about the size of the available devices. Maybe they are working to expand the range to more of the Lattice devices. It will be a long road to Xilinx or Altera devices. I'm also a bit leery of ever getting the tools up. It's been a while since I looked at this, but it seemed like it was not so easy to get a tool chain up and running. Looking for Mecrisp-ICE, I found a German message list post by Michael Kalus that seems to be talking about the iCEstick. I think he is asking if there is a larger chip that can be soldered on the iCEstick. There is. The 1K LUT device (1,280 actually) can be replaced with a 4K LUT device (3,520 actually). Seems he is rather limited by the capacity of the 1K LUT device. I see the iCE40-HX4K-TQ144 is supported by the IceStorm tools. I wonder if I can run these tools on the Raspberry Pi? Not sure I would ever get them up under Windows... lol -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-04-28 18:39 +0000 |
| Message-ID | <slrnni4po9.gk9.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #46830 |
On 2016-04-28, rickman <gnuarm@gmail.com> wrote: > On 4/28/2016 3:43 AM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>> I bet you had a harder time getting your cable modem running than it >>> would be to get an FPGA board up and running. Plug in both ends of >>> the USB cable... done. Was that so hard? >> >> No host-side software? >> >>> I can assure you that I had *much* more trouble trying to >>> get the bloody Stellaris board to run Mecrisp than I did getting *any* >>> of the FPGA boards up and running including the one I designed myself! >> >> Yeah, I find the idea of bringing up Mecrisp on the Stellaris somewhat >> off-putting too. I got two Stellaris boards when they were on promotion >> for $5 each but they're sitting on their boxes years later. I like to >> think I could deal with getting Mecrisp up on the Stellaris if I had a >> reason to do so, but again, I see multiple hours or days of futzing >> around as par for the course with this kind of thing. By comparison, >> compiling Mecrisp under Linux took just a few seconds and I could run it >> immediately, though not really usefully due to mysterious bugs it has on >> the Scaleway platform. >> >> I do get the impression that the Arduino and maybe current ARM Mbed >> environments are much easier to deal with than the Stellaris software >> that TI shipped. >> >>> The TI driver wasn't signed so I eventually gave up trying to install >>> it under Windows 8. >> >> I wouldn't have even tried that as I almost never use Windows for >> anything. >> >>> Seems every command window under Linux is a terminal window, except it >>> isn't connected to a serial port >> >> Hmm, ok, yeah I can see how that might have been an obstacle to a Linux >> newcomer. As a Linux developer I know how to deal with issues like >> that, but it takes a while to know where to find the knowledge. >> >>> I suppose you can find simulators to run on your PC. I don't recall >>> there being one for Mecrisp. I wouldn't mind a link. >> >> It's included with Mecrisp-stellaris-- look for files called >> "thumbulator*.c" The .c file cites: >> >> https://github.com/dwelch67/thumbulator >> >> but Matthias modified it some for Mecrisp and specific cpus. I haven't >> tried to use it. > > So you don't know what it takes to run??? What do I do with a .c file? > That's going to be a hundred times more painful than running the FPGA > software. But then I know how to do that. Everything is easy if you > know it, lol. > > I remember showing my customer the Lattice classic tools. The > programmer has some goofy marketing name and my customer couldn't find > it. Once I showed it to him it was easier. The factory programs and > tests my boards. This is done by a 20-something tech, so how hard can > it be? Of course once you've done a thousand of them I guess it gets > easier... lol > > >>> That might be useful if you don't want to use hardware. All of my HDL >>> designs are wrung out thoroughly in simulation before they ever touch >>> the hardware. >> >> OK, so you also see the value of avoiding touching hardware for as long >> as possible. But with FPGAs (or with a Stellaris) you eventually do >> need to touch the hardware. With a Linux box you might never need to. > > You miss the point. Running the simulation for debugging the hardware > is invaluable because the hardware is hard to view. If I were debugging > RTX code and had a good debugger I would likely prefer to run the code > on the hardware. I don't recall seeing much software development done > in simulation because of the practicalities of creating the environment. > Embedded stuff is all about interacting with the environment and > modern processors have debuggers (emulators). If you just want to run > Aristophanes's Sieve then a simulator would do just fine. > > >>> Any project that uses hardware will need to reach the metal at some >>> point. Then you just plain need hardware. >> >> Yes, definitely so. However, many many things don't need hardware. >> I've never really understood some posters' desire to build >> microprocessor boards to help people learn Forth. It's far easier to >> learn Forth using something like Gforth on a Linux box. I follow the >> hardware projects and am interested in them from my desire to learn >> something about hardware, not for learning Forth. > > Because an embedded board can do things that are hard to do from a PC > (at least since they took away the parallel port). Those things can be > much more interesting than seeing the OK prompt on a PC. > > >> That said, Mecrisp-ICE, targeted to a modified J1 running on an FPGA >> with a completely FOSS toolchain, looks really interesting. > > Not sure why. It is limited to a very small selection of chips. Ask > Juergen about the size of the available devices. Maybe they are working > to expand the range to more of the Lattice devices. It will be a long > road to Xilinx or Altera devices. I'm also a bit leery of ever getting > the tools up. It's been a while since I looked at this, but it seemed > like it was not so easy to get a tool chain up and running. > > Looking for Mecrisp-ICE, I found a German message list post by Michael > Kalus that seems to be talking about the iCEstick. I think he is asking > if there is a larger chip that can be soldered on the iCEstick. There > is. The 1K LUT device (1,280 actually) can be replaced with a 4K LUT > device (3,520 actually). Seems he is rather limited by the capacity of > the 1K LUT device. I see the iCE40-HX4K-TQ144 is supported by the > IceStorm tools. I wonder if I can run these tools on the Raspberry Pi? > Not sure I would ever get them up under Windows... lol > -- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-28 17:02 -0400 |
| Message-ID | <nfttjm$gg6$2@dont-email.me> |
| In reply to | #46831 |
On 4/28/2016 2:39 PM, Albert van der Horst wrote: > On 2016-04-28, rickman <gnuarm@gmail.com> wrote: >> On 4/28/2016 3:43 AM, Paul Rubin wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> I bet you had a harder time getting your cable modem running than it >>>> would be to get an FPGA board up and running. Plug in both ends of >>>> the USB cable... done. Was that so hard? >>> >>> No host-side software? >>> >>>> I can assure you that I had *much* more trouble trying to >>>> get the bloody Stellaris board to run Mecrisp than I did getting *any* >>>> of the FPGA boards up and running including the one I designed myself! >>> >>> Yeah, I find the idea of bringing up Mecrisp on the Stellaris somewhat >>> off-putting too. I got two Stellaris boards when they were on promotion >>> for $5 each but they're sitting on their boxes years later. I like to >>> think I could deal with getting Mecrisp up on the Stellaris if I had a >>> reason to do so, but again, I see multiple hours or days of futzing >>> around as par for the course with this kind of thing. By comparison, >>> compiling Mecrisp under Linux took just a few seconds and I could run it >>> immediately, though not really usefully due to mysterious bugs it has on >>> the Scaleway platform. >>> >>> I do get the impression that the Arduino and maybe current ARM Mbed >>> environments are much easier to deal with than the Stellaris software >>> that TI shipped. >>> >>>> The TI driver wasn't signed so I eventually gave up trying to install >>>> it under Windows 8. >>> >>> I wouldn't have even tried that as I almost never use Windows for >>> anything. >>> >>>> Seems every command window under Linux is a terminal window, except it >>>> isn't connected to a serial port >>> >>> Hmm, ok, yeah I can see how that might have been an obstacle to a Linux >>> newcomer. As a Linux developer I know how to deal with issues like >>> that, but it takes a while to know where to find the knowledge. >>> >>>> I suppose you can find simulators to run on your PC. I don't recall >>>> there being one for Mecrisp. I wouldn't mind a link. >>> >>> It's included with Mecrisp-stellaris-- look for files called >>> "thumbulator*.c" The .c file cites: >>> >>> https://github.com/dwelch67/thumbulator >>> >>> but Matthias modified it some for Mecrisp and specific cpus. I haven't >>> tried to use it. >> >> So you don't know what it takes to run??? What do I do with a .c file? >> That's going to be a hundred times more painful than running the FPGA >> software. But then I know how to do that. Everything is easy if you >> know it, lol. >> >> I remember showing my customer the Lattice classic tools. The >> programmer has some goofy marketing name and my customer couldn't find >> it. Once I showed it to him it was easier. The factory programs and >> tests my boards. This is done by a 20-something tech, so how hard can >> it be? Of course once you've done a thousand of them I guess it gets >> easier... lol >> >> >>>> That might be useful if you don't want to use hardware. All of my HDL >>>> designs are wrung out thoroughly in simulation before they ever touch >>>> the hardware. >>> >>> OK, so you also see the value of avoiding touching hardware for as long >>> as possible. But with FPGAs (or with a Stellaris) you eventually do >>> need to touch the hardware. With a Linux box you might never need to. >> >> You miss the point. Running the simulation for debugging the hardware >> is invaluable because the hardware is hard to view. If I were debugging >> RTX code and had a good debugger I would likely prefer to run the code >> on the hardware. I don't recall seeing much software development done >> in simulation because of the practicalities of creating the environment. >> Embedded stuff is all about interacting with the environment and >> modern processors have debuggers (emulators). If you just want to run >> Aristophanes's Sieve then a simulator would do just fine. >> >> >>>> Any project that uses hardware will need to reach the metal at some >>>> point. Then you just plain need hardware. >>> >>> Yes, definitely so. However, many many things don't need hardware. >>> I've never really understood some posters' desire to build >>> microprocessor boards to help people learn Forth. It's far easier to >>> learn Forth using something like Gforth on a Linux box. I follow the >>> hardware projects and am interested in them from my desire to learn >>> something about hardware, not for learning Forth. >> >> Because an embedded board can do things that are hard to do from a PC >> (at least since they took away the parallel port). Those things can be >> much more interesting than seeing the OK prompt on a PC. >> >> >>> That said, Mecrisp-ICE, targeted to a modified J1 running on an FPGA >>> with a completely FOSS toolchain, looks really interesting. >> >> Not sure why. It is limited to a very small selection of chips. Ask >> Juergen about the size of the available devices. Maybe they are working >> to expand the range to more of the Lattice devices. It will be a long >> road to Xilinx or Altera devices. I'm also a bit leery of ever getting >> the tools up. It's been a while since I looked at this, but it seemed >> like it was not so easy to get a tool chain up and running. >> >> Looking for Mecrisp-ICE, I found a German message list post by Michael >> Kalus that seems to be talking about the iCEstick. I think he is asking >> if there is a larger chip that can be soldered on the iCEstick. There >> is. The 1K LUT device (1,280 actually) can be replaced with a 4K LUT >> device (3,520 actually). Seems he is rather limited by the capacity of >> the 1K LUT device. I see the iCE40-HX4K-TQ144 is supported by the >> IceStorm tools. I wonder if I can run these tools on the Raspberry Pi? >> Not sure I would ever get them up under Windows... lol Did you forget to include a post??? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-30 13:32 -0700 |
| Message-ID | <87mvoag7n8.fsf@nightsong.com> |
| In reply to | #46830 |
rickman <gnuarm@gmail.com> writes:
>> https://github.com/dwelch67/thumbulator
>> I haven't tried to use it.
> So you don't know what it takes to run??? What do I do with a .c
> file?
Just type "make" and it compiles. Compilation took 3.5 seconds on the
Scaleway box which would correspond to under 0.5 sec on a fast x86.
Then run "./thumbulator filename.bin". I ran Mecrisp under it and it
worked fine:
$ ./thumbulator ../mecrisp-stellaris-lpc1114fn28.bin
Mecrisp-Stellaris 2.1.6 with M0 core for LPC1114FN28 by Matthias Koch
: foo 10 0 do i . loop ; ok.
foo 0 1 2 3 4 5 6 7 8 9 ok.
This took like no effort.
> Everything is easy if you know it, lol.
True-- I guess I knew what to look for and that helped.
> I don't recall seeing much software development done in simulation
> because of the practicalities of creating the environment. Embedded
> stuff is all about interacting with the environment and modern
> processors have debuggers (emulators).
I guess it depends what it is. If it's something like a motor
controller or SDR that has hard realtime deadlines, ok, you can't really
emulate it that usefully. If it's something less constrained (e.g. it
just talks to some HID gear or serial ports, so a millisecond here or
there doesn't matter) then I've generally found it a big win to simulate
the whole system. E.g. I programmed a box that ran a POS receipt
printer. By simulating the system (including the printer) during
testing, I'm sure I saved many miles of paper.
> If you just want to run Aristophanes's Sieve then a simulator would do
> just fine.
Another example: your embedded box runs some complicated DSP algorithm
that converts one waveform to another. You can debug the algorithm
without having to talk to real hardware, so you're probably better off
using your comfy workstation environment instead of a cross-debugger.
>> easier to learn Forth using something like Gforth on a Linux box.
> Because an embedded board can do things that are hard to do from a PC
> (at least since they took away the parallel port). Those things can
> be much more interesting than seeing the OK prompt on a PC.
Fine, but RPi-level Linux boards have real GPIO's, memory protection,
and tons more resources making breathing space for the software. What's
the value of starting on an MSP430? I've never understood that. I do
understand the MSP can be deployed in ways the RPi can't, but that's not
an issue for first-time learners.
I'd still consider that device control stuff to be outside the scope of
"learn to program". Like to program DSP's you have to understand the
Fourier transform, but that's a topic in math rather than programming.
For a first-time learner without much math background, whose interest
isn't specifically in DSP, this probably makes DSP programming a
not-so-good introductory topic in programming. The math you would also
have to teach makes the learning curve steeper.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-30 16:49 -0400 |
| Message-ID | <ng35j0$3er$1@dont-email.me> |
| In reply to | #46850 |
On 4/30/2016 4:32 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> https://github.com/dwelch67/thumbulator >>> I haven't tried to use it. >> So you don't know what it takes to run??? What do I do with a .c >> file? > > Just type "make" and it compiles. Compilation took 3.5 seconds on the > Scaleway box which would correspond to under 0.5 sec on a fast x86. > Then run "./thumbulator filename.bin". I ran Mecrisp under it and it > worked fine: > > $ ./thumbulator ../mecrisp-stellaris-lpc1114fn28.bin > Mecrisp-Stellaris 2.1.6 with M0 core for LPC1114FN28 by Matthias Koch > : foo 10 0 do i . loop ; ok. > foo 0 1 2 3 4 5 6 7 8 9 ok. > > This took like no effort. What do I type make into? I assume my laptop running Windows 8? Is the file listed above the modified version Matthias provided? >> Everything is easy if you know it, lol. > > True-- I guess I knew what to look for and that helped. > >> I don't recall seeing much software development done in simulation >> because of the practicalities of creating the environment. Embedded >> stuff is all about interacting with the environment and modern >> processors have debuggers (emulators). > > I guess it depends what it is. If it's something like a motor > controller or SDR that has hard realtime deadlines, ok, you can't really > emulate it that usefully. If it's something less constrained (e.g. it > just talks to some HID gear or serial ports, so a millisecond here or > there doesn't matter) then I've generally found it a big win to simulate > the whole system. E.g. I programmed a box that ran a POS receipt > printer. By simulating the system (including the printer) during > testing, I'm sure I saved many miles of paper. Great if your system is simple and you have *accurate* models for the devices you are interfacing too. I remember once in college a grad student in control theory had worked on a motor simulator that worked perfectly with his control software. Then he tried it on a real motor and it didn't work right. He blamed the real motor! lol >> If you just want to run Aristophanes's Sieve then a simulator would do >> just fine. > > Another example: your embedded box runs some complicated DSP algorithm > that converts one waveform to another. You can debug the algorithm > without having to talk to real hardware, so you're probably better off > using your comfy workstation environment instead of a cross-debugger. I thought we were talking about the RTX2000? This has gotten rather general. Of course there are plenty of situations where simulation is good. I've said exactly that. Not sure what your point is. >>> easier to learn Forth using something like Gforth on a Linux box. >> Because an embedded board can do things that are hard to do from a PC >> (at least since they took away the parallel port). Those things can >> be much more interesting than seeing the OK prompt on a PC. > > Fine, but RPi-level Linux boards have real GPIO's, memory protection, > and tons more resources making breathing space for the software. What's > the value of starting on an MSP430? I've never understood that. I do > understand the MSP can be deployed in ways the RPi can't, but that's not > an issue for first-time learners. > > I'd still consider that device control stuff to be outside the scope of > "learn to program". Like to program DSP's you have to understand the > Fourier transform, but that's a topic in math rather than programming. > For a first-time learner without much math background, whose interest > isn't specifically in DSP, this probably makes DSP programming a > not-so-good introductory topic in programming. The math you would also > have to teach makes the learning curve steeper. What processor you use depends on what your goals are. Several people here like the lower end MCUs for education because the hardware is available very inexpensively. I don't care. I just want hardware that does what I want. I used the rPi as a server to host the programming software for the Stellaris board I was using. I never got the Bluetooth module I bought working correctly so I've since switched to a Microsemi SmartFusion2 board with integrated Bluetooth. I hope that works better. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-04-30 18:55 -0700 |
| Message-ID | <87eg9mfsox.fsf@nightsong.com> |
| In reply to | #46851 |
rickman <gnuarm@gmail.com> writes: > What do I type make into? I assume my laptop running Windows 8? You'd have to install a bunch of other stuff to do that compilation under Windows. As mentioned I did it on a Scaleway Linux server. You can rent a server like that for 0.6 eurocents per hour (3 euro per month) or I can set up an account for you on mine if you want to mess with it. > Is the file listed above the modified version Matthias provided? Yes. > Great if your system is simple and you have *accurate* models for the > devices you are interfacing too. Obviously you have to test with the real hardware too, but it's usually a lot easier to simulate, especially if the hardware is unique or expensive. In the thing I mentioned, the hardware setup was down the hall and I was required to test my latest version on it once a day, but the rest of the time I almost always worked at my desk. > Then he tried it on a real motor and it didn't work right. He blamed > the real motor! lol Heh. No one told him the map is not the territory :) > I thought we were talking about the RTX2000? This has gotten rather > general. Of course there are plenty of situations where simulation is > good. I've said exactly that. Not sure what your point is. Well, Juergen asked for an RTX2000 simulation though I hope we talked him out of it. However, with the RTX2000 as with almost anything else, I'd do as much development as I could on a workstation rather than on the real hardware. > What processor you use depends on what your goals are. Several people > here like the lower end MCUs for education because the hardware is > available very inexpensively. Reasonable, if your goal is to use an MCU at all. > I don't care. I just want hardware that does what I want. I used the > rPi as a server to host the programming software for the Stellaris > board I was using. In principle the pi0 could work for that, but it would likely be much more pain than using a bigger model.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-04-30 22:08 -0400 |
| Message-ID | <ng3o8u$ulf$1@dont-email.me> |
| In reply to | #46852 |
On 4/30/2016 9:55 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> What do I type make into? I assume my laptop running Windows 8? > > You'd have to install a bunch of other stuff to do that compilation > under Windows. As mentioned I did it on a Scaleway Linux server. You > can rent a server like that for 0.6 eurocents per hour (3 euro per > month) or I can set up an account for you on mine if you want to mess > with it. Starting to look like a *lot* of hassle to me... >> Is the file listed above the modified version Matthias provided? > > Yes. > >> Great if your system is simple and you have *accurate* models for the >> devices you are interfacing too. > > Obviously you have to test with the real hardware too, but it's usually > a lot easier to simulate, especially if the hardware is unique or > expensive. In the thing I mentioned, the hardware setup was down the > hall and I was required to test my latest version on it once a day, but > the rest of the time I almost always worked at my desk. > >> Then he tried it on a real motor and it didn't work right. He blamed >> the real motor! lol > > Heh. No one told him the map is not the territory :) > >> I thought we were talking about the RTX2000? This has gotten rather >> general. Of course there are plenty of situations where simulation is >> good. I've said exactly that. Not sure what your point is. > > Well, Juergen asked for an RTX2000 simulation though I hope we talked > him out of it. However, with the RTX2000 as with almost anything else, > I'd do as much development as I could on a workstation rather than on > the real hardware. I believe Juergen asked for an RTX2000 emulation that would not be working with a virtual environment, but rather turn the target hardware into a machine that executes RTX2000 code. Or maybe he asked for an actual RTX2000 design in an FPGA. Not sure at this point. But the general world of simulation and emulation has drifted far off topic. >> What processor you use depends on what your goals are. Several people >> here like the lower end MCUs for education because the hardware is >> available very inexpensively. > > Reasonable, if your goal is to use an MCU at all. > >> I don't care. I just want hardware that does what I want. I used the >> rPi as a server to host the programming software for the Stellaris >> board I was using. > > In principle the pi0 could work for that, but it would likely be much > more pain than using a bigger model. Actually it can't without help. With a single USB port it would need a hub to control anything and still talk to a network. Mine was letting me talk to Mecrisp on a Stellaris target through the USB serial port while being connected to my network via Ethernet. The rPi zero would need both a hub and an Ethernet interface for that. Might as well use an rPi of nearly any other type. I read some page that the rPi zero is "getting" a new feature that has been asked for a lot. Can't find what that even means. I guess it is something they are adding to a new rev? Or maybe just software. Or maybe they are going with a full size HDMI connector instead of the mini that is virtually always used with a $3 adapter on a $5 board and is nearly as large as the board. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | JUERGEN <epldfpga@aol.com> |
|---|---|
| Date | 2016-05-01 09:32 -0700 |
| Message-ID | <a783531f-8189-45c6-beb4-679dc99b9c8e@googlegroups.com> |
| In reply to | #46850 |
On Saturday, April 30, 2016 at 9:32:16 PM UTC+1, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: > >> https://github.com/dwelch67/thumbulator > >> I haven't tried to use it. > > So you don't know what it takes to run??? What do I do with a .c > > file? > > Just type "make" and it compiles. Compilation took 3.5 seconds on the > Scaleway box which would correspond to under 0.5 sec on a fast x86. > Then run "./thumbulator filename.bin". I ran Mecrisp under it and it > worked fine: > > $ ./thumbulator ../mecrisp-stellaris-lpc1114fn28.bin > Mecrisp-Stellaris 2.1.6 with M0 core for LPC1114FN28 by Matthias Koch > : foo 10 0 do i . loop ; ok. > foo 0 1 2 3 4 5 6 7 8 9 ok. > > This took like no effort. > > > Everything is easy if you know it, lol. > > True-- I guess I knew what to look for and that helped. > > > I don't recall seeing much software development done in simulation > > because of the practicalities of creating the environment. Embedded > > stuff is all about interacting with the environment and modern > > processors have debuggers (emulators). > > I guess it depends what it is. If it's something like a motor > controller or SDR that has hard realtime deadlines, ok, you can't really > emulate it that usefully. If it's something less constrained (e.g. it > just talks to some HID gear or serial ports, so a millisecond here or > there doesn't matter) then I've generally found it a big win to simulate > the whole system. E.g. I programmed a box that ran a POS receipt > printer. By simulating the system (including the printer) during > testing, I'm sure I saved many miles of paper. > > > If you just want to run Aristophanes's Sieve then a simulator would do > > just fine. > > Another example: your embedded box runs some complicated DSP algorithm > that converts one waveform to another. You can debug the algorithm > without having to talk to real hardware, so you're probably better off > using your comfy workstation environment instead of a cross-debugger. > > >> easier to learn Forth using something like Gforth on a Linux box. > > Because an embedded board can do things that are hard to do from a PC > > (at least since they took away the parallel port). Those things can > > be much more interesting than seeing the OK prompt on a PC. > > Fine, but RPi-level Linux boards have real GPIO's, memory protection, > and tons more resources making breathing space for the software. What's > the value of starting on an MSP430? I've never understood that. I do > understand the MSP can be deployed in ways the RPi can't, but that's not > an issue for first-time learners. > > I'd still consider that device control stuff to be outside the scope of > "learn to program". Like to program DSP's you have to understand the > Fourier transform, but that's a topic in math rather than programming. > For a first-time learner without much math background, whose interest > isn't specifically in DSP, this probably makes DSP programming a > not-so-good introductory topic in programming. The math you would also > have to teach makes the learning curve steeper. Paul, the explanation why MSP430G2553 is very simple, and here the hardware aspects count - at least for my MicroBox Project - 20 pins, small, DIL and a few free and and as well commercial Forths are available. As minimum you can start with a Solderless breadboard, a chip, one resistor, some LEDs, a bit of wire and a USB to TTL cable, use a pre-programmed chip and it all runs on the Chip. TI supported our more complex MicroBox Project with 1000 chips and the scouts soldered / built 450 last year - 11 June Maker Fair Bristol is the next event - all of the components are free. I do not know many alternatives where they can learn to solder, understand all of the components ofthe project roughly, build their own board and start programming it in Forth. 1000 PCBs came for free. The scouts had no soldering experience and no programming experience. And got it all free of charge including our work.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-01 14:10 -0400 |
| Message-ID | <ng5gk2$i8s$3@dont-email.me> |
| In reply to | #46855 |
On 5/1/2016 12:32 PM, JUERGEN wrote: > On Saturday, April 30, 2016 at 9:32:16 PM UTC+1, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>>> https://github.com/dwelch67/thumbulator I haven't tried to use >>>> it. >>> So you don't know what it takes to run??? What do I do with a >>> .c file? >> >> Just type "make" and it compiles. Compilation took 3.5 seconds on >> the Scaleway box which would correspond to under 0.5 sec on a fast >> x86. Then run "./thumbulator filename.bin". I ran Mecrisp under it >> and it worked fine: >> >> $ ./thumbulator ../mecrisp-stellaris-lpc1114fn28.bin >> Mecrisp-Stellaris 2.1.6 with M0 core for LPC1114FN28 by Matthias >> Koch : foo 10 0 do i . loop ; ok. foo 0 1 2 3 4 5 6 7 8 9 ok. >> >> This took like no effort. >> >>> Everything is easy if you know it, lol. >> >> True-- I guess I knew what to look for and that helped. >> >>> I don't recall seeing much software development done in >>> simulation because of the practicalities of creating the >>> environment. Embedded stuff is all about interacting with the >>> environment and modern processors have debuggers (emulators). >> >> I guess it depends what it is. If it's something like a motor >> controller or SDR that has hard realtime deadlines, ok, you can't >> really emulate it that usefully. If it's something less >> constrained (e.g. it just talks to some HID gear or serial ports, >> so a millisecond here or there doesn't matter) then I've generally >> found it a big win to simulate the whole system. E.g. I programmed >> a box that ran a POS receipt printer. By simulating the system >> (including the printer) during testing, I'm sure I saved many miles >> of paper. >> >>> If you just want to run Aristophanes's Sieve then a simulator >>> would do just fine. >> >> Another example: your embedded box runs some complicated DSP >> algorithm that converts one waveform to another. You can debug the >> algorithm without having to talk to real hardware, so you're >> probably better off using your comfy workstation environment >> instead of a cross-debugger. >> >>>> easier to learn Forth using something like Gforth on a Linux >>>> box. >>> Because an embedded board can do things that are hard to do from >>> a PC (at least since they took away the parallel port). Those >>> things can be much more interesting than seeing the OK prompt on >>> a PC. >> >> Fine, but RPi-level Linux boards have real GPIO's, memory >> protection, and tons more resources making breathing space for the >> software. What's the value of starting on an MSP430? I've never >> understood that. I do understand the MSP can be deployed in ways >> the RPi can't, but that's not an issue for first-time learners. >> >> I'd still consider that device control stuff to be outside the >> scope of "learn to program". Like to program DSP's you have to >> understand the Fourier transform, but that's a topic in math rather >> than programming. For a first-time learner without much math >> background, whose interest isn't specifically in DSP, this probably >> makes DSP programming a not-so-good introductory topic in >> programming. The math you would also have to teach makes the >> learning curve steeper. > > Paul, the explanation why MSP430G2553 is very simple, and here the > hardware aspects count - at least for my MicroBox Project - 20 pins, > small, DIL and a few free and and as well commercial Forths are > available. As minimum you can start with a Solderless breadboard, a > chip, one resistor, some LEDs, a bit of wire and a USB to TTL cable, > use a pre-programmed chip and it all runs on the Chip. TI supported > our more complex MicroBox Project with 1000 chips and the scouts > soldered / built 450 last year - 11 June Maker Fair Bristol is the > next event - all of the components are free. I do not know many > alternatives where they can learn to solder, understand all of the > components ofthe project roughly, build their own board and start > programming it in Forth. 1000 PCBs came for free. The scouts had no > soldering experience and no programming experience. And got it all > free of charge including our work. I met a guy here in the US who was doing something similar but not as complex. I don't recall the details but he was putting together a kit for scouts. I never figured out what I could do to help him. I think he was in Richmond, VA. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web