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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Gary Bergstrom <forthprgrmr@gmail.com> |
|---|---|
| Date | 2014-07-19 08:23 -0700 |
| Message-ID | <f6fff8dd-8c67-4eb0-b738-a6965bfa332c@googlegroups.com> |
| In reply to | #32488 |
On Saturday, July 19, 2014 8:30:26 AM UTC-4, Bernd Paysan wrote: > Yes, Cypress moves the Flash programming behind some system calls, instead > of giving direct access to the flash write instruction. Typically, you can > erase a block of flash (erase means all bits set to 1), and write words > (toggle bits from 1 to 0). For in-flash programming, this is very handy, > because you can treat flash as a write-once memory. With the write-a-block > at a time model from Cypress, you can't do that. You write into the shadow > memory, and you probably can't read from that memory, unless you make sure > it's flushed out. That's difficult, because in Forth, a word becomes > visible after it's defined, and words are typically smaller than 128 bytes. > > A possible way around is to look at the ROM which implements the flash > writing, and if possible use those instructions directly, instead of using > the syscall interface. I'm not sure I understand the problem with the flash on the PSOC4/5 parts. Each row of flash can be erased and written with a call to the internal flash programmer. So if you want to write to the flash, then copy the row, add the new data, and write the row. The part guarentees a minimum of 100k write cycles, so you can do this a lot. It would be better to buffer up a few words rather than doing this for every byte, but building a small queue for writing to flash shouldn't be too hard (vector "," and use it to buffer small blocks). Or am I missing something? I rewrite data in flash blocks on other processors this way without any problems. I have both the PSOC4 and 5 boards and so far don't have a Forth running. I'm currently lost at C. Unfortunately my client wants me to stay that way.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2014-07-21 10:42 +0200 |
| Message-ID | <lqijun$cim$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #32482 |
> Mathias talked all that really needs to be done is to modify the Flash > interface code for the unique size blocks. He seems to think they are > an odd size for compiling directly to flash. At least I think it was > Mathias... lol. I'm not good with names, especially when there are no > faces. Here's mine so you can remember me more easily... :) Hi Rick, yes, I wrote to you before. I would suggest loading the disassembler into RAM of Cypress chip after porting terminal code and doing some reverse-engineering research on Flash writes. For general Flash issue tackling I offered to Bernd Paysan to vectorize hflash! and include a vectorized flash-flush, too. So you could write Flash code in Forth, and compile it two times with compiletoram and then again with compiletoflash. For all others that might have interest a copy of my older mail: Matthias Dear Rick, nice that you want to tackle the issue ! The trick is to marry jump opcode backpatching with Flash page buffers without having too many erase cycles... Conditional jumps have 8 Bits signed offset giving a jump range of 512 Bytes in total. So with 4+1 row buffers of 128 Bytes each you can handle all conditional jumps without the need for an erase, and only a few longer unconditional jumps (11 bits signed range) in very long definitions may cause erase cycles. Flushing buffers on smudge, and perhaps you are in luck and you can arm-twist the Flash controller to write to a partially written row again as many Flash implementations can toggle singular bits from 1 --> 0. As only forward jumps are filled back into holes, maybe we need only 2+1 buffers, but I would rather go for more to have most typical unconditional jumps catched, too. This depends on total RAM available. Basically you will have to buffer the row you are going to write to, do writes in buffers, mark this as changed, and when all buffers are used, erase and write back the oldest buffer. This is very similiar to the classic "Forth blocks" implementation. But now, for a start: Get the current Mecrisp-Stellaris 1.1.7 package and have a look on the sources. Change memory map, chip init and terminal code. Mecrisp-Stellaris can boot and compile to ram without having proper Flash code. This is the first milestone. Contact me again when reaching this. Next is to write assembly code for write one Flash row, erase one Flash row and erase all Flash after the first 16 kb which are reserved for Forth core. Try this manually, make sure it works properly. Then do experimentation/datasheet research if you can write to a partially filled Flash row again. How many times ? Is it reliable ? You will end up having another target folder. Third step is to insert row buffering into the files in the mecrisp-stellaris-source/common folder. I am there to help you on implementing this, it should work with a variable row size and buffer count to have support for NXP chips later, too. Good luck ! Matthias PS: There is a "Thumb-2 Supplement Reference Manual". Go for that, it describes the instruction set available.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-05-30 03:03 -0700 |
| Message-ID | <0271503e-4830-4813-9a26-9801ea76ad10@googlegroups.com> |
| In reply to | #30977 |
I certainly don't want to piss on anyone's fire or anything, but, 'yall know this has already been done, right? https://sites.google.com/site/libby8dev/fignition The FIGnition board (a DIY Forth computer that plugs into a TV) has been around for around 5 years and is doing very very well. You can even buy them from RS Components. It is being actively developed by Julian and is now a really useable little computer - absolutely perfect for learning Forth on since it's a Forth machine from power-up, like the Jupiter Ace was. There's a PS2 interface available so you can use a "real" keyboard with it, too. The FIGNition has had quite a lot of publicity too: http://www.theregister.co.uk/2011/05/10/fignition_forth_pc/ The idea is that kids can solder it up themselves (with some supervision) and then get to programming it. It runs FIG Forth, so they can sit down with Starting Forth and have at it. With an adult supervising, they'll the penny soon drops. Get out of the CLF bubble - there's stuff happening :-)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 07:47 -0700 |
| Message-ID | <7xk392vwc5.fsf@ruckus.brouhaha.com> |
| In reply to | #31017 |
Mark Wills <markwills1970@gmail.com> writes: > I certainly don't want to piss on anyone's fire or anything, > but, 'yall know this has already been done, right? > https://sites.google.com/site/libby8dev/fignition That's a good point and a cool board, though fancier and more expensive than what we're discussing here. I'm more and more liking the solderless breadboard approach to showing how all the hardware is connected up. It means you can actually see all the wires and change the wiring for your own purposes, unlike a PCB (especially a multilayer one) where the wiring is mostly invisible or hard to follow, and mostly can't be changed.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-05-31 11:36 -0400 |
| Message-ID | <lmcsul$d0s$1@dont-email.me> |
| In reply to | #31073 |
On 5/31/2014 10:47 AM, Paul Rubin wrote: > Mark Wills <markwills1970@gmail.com> writes: >> I certainly don't want to piss on anyone's fire or anything, >> but, 'yall know this has already been done, right? >> https://sites.google.com/site/libby8dev/fignition > > That's a good point and a cool board, though fancier and more expensive > than what we're discussing here. I'm more and more liking the > solderless breadboard approach to showing how all the hardware is > connected up. It means you can actually see all the wires and change > the wiring for your own purposes, unlike a PCB (especially a multilayer > one) where the wiring is mostly invisible or hard to follow, and mostly > can't be changed. That is why PCBs come with schematics and artwork. There is not much about an MCU that you would want to change other than the IO. That is dealt with by providing a prototyping area on the PCB or IO connectors to add IO on daughtercards or externally. There are tons of MCU boards available from different sources at different levels of quality. 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. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-05-31 09:34 -0700 |
| Message-ID | <5bd1fc83-27f2-4920-9e8e-3dd6af1cc80a@googlegroups.com> |
| In reply to | #31075 |
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. One opportunity would be a MSP430-Stamp. Despite different other solutions, imagine a YouTube video showing a solderless breadboard, where somebody puts a preprogrammed MSP430 and some wires on it, connects it to a terminal, and voilá, typing in 'LED on', and the LED switches on. Just for fun. To show how easy it is to start a system from scratch within a few minutes. Last night I was working on a correction of my C program which I wrote for a MSP430F2012 three years ago. When upgrading from 4MB SPI-Flash (not available any more) to 8MB SPI-Flash an error occurred - the program didn't find the data, some kind of stupid overrun error. My fault. I discovered that there was no IAR Systems Embedded Workbench Kickstart on my new (refurbished) laptop, so I googled for it, downloaded slac050ax.zip - which needs nearly 30 minutes for 330MB, installed IAR Systems Embedded Workbench 11.3 Kickstart which needs 1.1GB HD, started Kickstart, and ended up having trouble with the license key which I couldn't resolve. So I looked through my USB sticks and I was glad to find slac050aj with only 180MB (unzipped), deinstalled IAR 11, and installed IAR Systems Embedded Workbench 6.4 Kickstart (only 603 MB), the system which I originally used for my development. After clicking some buttons and copying my source into the right folder, I got a first rebuild, and after some minutes the correction was done. I wrote this to show what a normal MSP430-LaunchPad user has to do before he can get anything done. With a preprogrammed MSP430 with Forth on it on a solderless breadboard, it's a matter of minutes, and with a MSP430G2553-LaunchPad and the 4E4th-IDE it's a matter of seconds. I am sure it is a good idea to show the world that there is a more efficient way to go to work! Thanks for reading! Forth be with you! Dirk.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 10:09 -0700 |
| Message-ID | <7xioolkh8y.fsf@ruckus.brouhaha.com> |
| In reply to | #31078 |
visualforth@rocketmail.com writes: > One opportunity would be a MSP430-Stamp. Despite different other > solutions, imagine a YouTube video showing a solderless breadboard, > where somebody puts a preprogrammed MSP430 and some wires on it, > connects it to a terminal, and voilá, typing in 'LED on', and the LED > switches on. Traditionally a "stamp" is a very small PCB, i.e. the size of a postage stamp, like 2x2 cm or so. So this circuit wouldn't be called a stamp. Another possibility is to put the circuit on a small PCB with DIP headers, like the PJRC Teensies (pjrc.com) or the Arduino Nano. That lets the user plug it directly into a breadboard. Can anyone tell exactly what this is: http://www.ebay.com/itm/191117208428 i.e. is it a complete Arduino clone of some sort, that could be a Forth target? The Atmega 328 has 32k flash, 1k eeprom, and 2k sram, which is a little more capacious than the G2553. On the other hand it's an 8-bit cpu with relatively verbose code.
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-05-31 10:52 -0700 |
| Message-ID | <2b9beee4-edd1-4fd5-b39a-f6b4928e0622@googlegroups.com> |
| In reply to | #31080 |
On Saturday, May 31, 2014 1:09:01 PM UTC-4, Paul Rubin wrote: > Can anyone tell exactly what this is: > http://www.ebay.com/itm/191117208428 > i.e. is it a complete Arduino clone of some sort, that could be a Forth > target? The Atmega 328 has 32k flash, 1k eeprom, and 2k sram, which is > a little more capacious than the G2553. On the other hand it's an 8-bit > cpu with relatively verbose code. The board printing says "Arduino Pro", already 2421 sold, and the price tells me that a 4$ Forth-Stamp will be feasible. Delivered from Shenzhen, China, with free shipping! May be we should find a Chinese supplier who puts Forth on the chip and does the marketing?
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 01:28 -0400 |
| Message-ID | <lmedm9$fef$1@dont-email.me> |
| In reply to | #31078 |
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. > > One opportunity would be a MSP430-Stamp. > Despite different other solutions, imagine a YouTube video showing a solderless breadboard, where somebody puts a preprogrammed MSP430 and some wires on it, connects it to a terminal, and voilá, typing in 'LED on', and the LED switches on. > > Just for fun. > To show how easy it is to start a system from scratch within a few minutes. > > Last night I was working on a correction of my C program which I wrote for a MSP430F2012 three years ago. When upgrading from 4MB SPI-Flash (not available any more) to 8MB SPI-Flash an error occurred - the program didn't find the data, some kind of stupid overrun error. My fault. > > I discovered that there was no IAR Systems Embedded Workbench Kickstart on my new (refurbished) laptop, so I googled for it, downloaded slac050ax.zip - which needs nearly 30 minutes for 330MB, installed IAR Systems Embedded Workbench 11.3 Kickstart which needs 1.1GB HD, started Kickstart, and ended up having trouble with the license key which I couldn't resolve. > > So I looked through my USB sticks and I was glad to find slac050aj with only 180MB (unzipped), deinstalled IAR 11, and installed IAR Systems Embedded Workbench 6.4 Kickstart (only 603 MB), the system which I originally used for my development. After clicking some buttons and copying my source into the right folder, I got a first rebuild, and after some minutes the correction was done. > > I wrote this to show what a normal MSP430-LaunchPad user has to do before he can get anything done. With a preprogrammed MSP430 with Forth on it on a solderless breadboard, it's a matter of minutes, and with a MSP430G2553-LaunchPad and the 4E4th-IDE it's a matter of seconds. > > I am sure it is a good idea to show the world that there is a more efficient way to go to work! 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. If the user already has the hardware, I'm not sure what would the best way to get them set up with Forth. That depends on whether we are looking at a resident Forth or a tethered Forth I suppose. I expect a tethered Forth would best be done by using the existing emulation section of the LaunchPad. A resident Forth would need to talk to the PC through a serial port, but there may be a way to do that through the emulation section of the LaunchPad. I see jumpers labeled "MSP430 Application UART" between the two sections. So the emulation section would be the UART interface so you don't need a special TTL UART cable. 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. 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. I think it would be hard to produce something and make it as popular as this hardware. Rather than rolling new hardware and promoting Forth with it (which is the basic mistake I think Simon is making) it would be better to use existing hardware and add Forth to it. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 22:41 -0700 |
| Message-ID | <7x4n05yyoa.fsf@ruckus.brouhaha.com> |
| In reply to | #31113 |
rickman <gnuarm@gmail.com> writes: > A resident Forth would need to talk to the PC through a serial port, PC's don't have serial ports any more, unless you buy a USB to serial adapter cable. > 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 comm section apparently has an MSP430 of its very own, that is more powerful than the G2553 that's supposedly the main cpu. > Rather than rolling new hardware and promoting Forth with it (which is > the basic mistake I think Simon is making) it would be better to use > existing hardware and add Forth to it. Yeah, there are trade-offs. Certainly I don't see any point to rolling new hw that does about the same stuff as the old hw. It's potentially interesting if it does something new or different.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 02:00 -0400 |
| Message-ID | <lmefie$njf$1@dont-email.me> |
| In reply to | #31114 |
On 6/1/2014 1:41 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> A resident Forth would need to talk to the PC through a serial port, > > PC's don't have serial ports any more, unless you buy a USB to serial > adapter cable. You trimmed the relevant portion of my post about this. Go back and read it again. >> 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 comm section apparently has an MSP430 of its very own, that is more > powerful than the G2553 that's supposedly the main cpu. ??? What is your point? >> Rather than rolling new hardware and promoting Forth with it (which is >> the basic mistake I think Simon is making) it would be better to use >> existing hardware and add Forth to it. > > Yeah, there are trade-offs. Certainly I don't see any point to rolling > new hw that does about the same stuff as the old hw. It's potentially > interesting if it does something new or different. More importantly, it would be "yet another MCU board". Just adding Forth to a piece of hardware isn't going to make anyone buy it over an existing board they can put Forth on. Why spend the time and energy rolling hardware that is me-too. As to "new or different"... that is getting pretty durn hard to do. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 23:07 -0700 |
| Message-ID | <7xzjhxgo32.fsf@ruckus.brouhaha.com> |
| In reply to | #31115 |
rickman <gnuarm@gmail.com> writes: >> PC's don't have serial ports any more > You trimmed the relevant portion of my post about this. I still don't see what you're getting at. Do you mean use the stuff on the Launchpad to communicate with the PC through USB? Yes that's what the comms side of the Launchpad is intended for, but then there was some discussion of it possibly needing special drivers. It sounded like you really meant use a PC serial port, and those have gotten hard to find. >> It's potentially interesting if it does something new or different. > More importantly, it would be "yet another MCU board". Just adding > Forth to a piece of hardware isn't going to make anyone buy it over an > existing board they can put Forth on. Right. Or even use Forth on a PC without any external hardware. > Why spend the time and energy rolling hardware that is me-too. As to > "new or different"... that is getting pretty durn hard to do. Thus the solderless breadboard suggestion. At least it's different.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 03:13 -0400 |
| Message-ID | <lmejqf$bf6$1@dont-email.me> |
| In reply to | #31116 |
On 6/1/2014 2:07 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> PC's don't have serial ports any more >> You trimmed the relevant portion of my post about this. > > I still don't see what you're getting at. Do you mean use the stuff on > the Launchpad to communicate with the PC through USB? Yes that's what > the comms side of the Launchpad is intended for, but then there was some > discussion of it possibly needing special drivers. It sounded like you > really meant use a PC serial port, and those have gotten hard to find. Everything on USB requires drivers. I'm sure they come with the LaunchPad if not with the OS. >>> It's potentially interesting if it does something new or different. >> More importantly, it would be "yet another MCU board". Just adding >> Forth to a piece of hardware isn't going to make anyone buy it over an >> existing board they can put Forth on. > > Right. Or even use Forth on a PC without any external hardware. > >> Why spend the time and energy rolling hardware that is me-too. As to >> "new or different"... that is getting pretty durn hard to do. > > Thus the solderless breadboard suggestion. At least it's different. I think that has always existed and is a *lot* more work. Have you done much with those things? It is very easy to mis-wire a circuit on those and very frustrating when a mistake is made. The sort of people I think are the target would have little debugging skills. The LaunchPad has holes for I/O pins which could be installed in a wireless breadboard for expanding I/O. If someone wants to go the wireless breadboard route, again, no need for a board design. Just write the needed software and document the wiring required. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-01 07:15 -0700 |
| Message-ID | <7x7g50ogwd.fsf@ruckus.brouhaha.com> |
| In reply to | #31118 |
rickman <gnuarm@gmail.com> writes: > Everything on USB requires drivers. I'm sure they come with the > LaunchPad if not with the OS. The Launchpad comes with a CD full of Windows code that is useless to me as a Linux user. There are some downloadable Linux programs for running the Launchpad and I should get around to figuring out how to use them. But the idea of a resident Forth is partly to get rid of the need for special software on the host side. I guess things were simpler in the serial port era. >> Thus the solderless breadboard suggestion. At least it's different. > I think that has always existed and is a *lot* more work. Have you > done much with those things? Just analog stuff and I didn't have much trouble, but I can understand how an MCU circuit would have more wires and more ways to make mistakes. Here's a completely insane hack: the guy took an MSP430 and chopped it down to 6 pins and it still worked. That could eliminate some wires. There's also an NXP ARM part in an 8-pin PDIP. > The LaunchPad has holes for I/O pins which could be installed in a > wireless breadboard for expanding I/O. I guess so. There are some Arduino shields like that. Getting rid of the PCB brings more simplicity out though. It screams hackability. > If someone wants to go the wireless breadboard route, again, no need > for a board design. Just write the needed software and document the > wiring required. Right, that's part of the attraction.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 12:33 -0400 |
| Message-ID | <lmfkkr$q1g$1@dont-email.me> |
| In reply to | #31129 |
On 6/1/2014 10:15 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Everything on USB requires drivers. I'm sure they come with the >> LaunchPad if not with the OS. > > The Launchpad comes with a CD full of Windows code that is useless to me > as a Linux user. There are some downloadable Linux programs for running > the Launchpad and I should get around to figuring out how to use them. > But the idea of a resident Forth is partly to get rid of the need for > special software on the host side. I guess things were simpler in the > serial port era. Serial ports are still simple unless you make them complicated. The chip used on the LaunchPad is a USB serial port. They claim no driver needs to be downloaded... " USB debugging and programming interface featuring a driverless installation and application UART serial communication with up to 9600 Baud". I would expect the same from Linux. Someone was bragging about how Linux seldom needs drivers to be downloaded compared to Windows. >>> Thus the solderless breadboard suggestion. At least it's different. >> I think that has always existed and is a *lot* more work. Have you >> done much with those things? > > Just analog stuff and I didn't have much trouble, but I can understand > how an MCU circuit would have more wires and more ways to make mistakes. > > Here's a completely insane hack: the guy took an MSP430 and chopped it > down to 6 pins and it still worked. That could eliminate some wires. > There's also an NXP ARM part in an 8-pin PDIP. > >> The LaunchPad has holes for I/O pins which could be installed in a >> wireless breadboard for expanding I/O. > > I guess so. There are some Arduino shields like that. Getting rid of > the PCB brings more simplicity out though. It screams hackability. I'm not sure why screaming is desirable. The point is that a lot more folks will play with a $10 PCB than will put together a solderless breadboard. >> If someone wants to go the wireless breadboard route, again, no need >> for a board design. Just write the needed software and document the >> wiring required. > > Right, that's part of the attraction. Then what is holding it up? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-01 09:45 -0700 |
| Message-ID | <7xha44bmu2.fsf@ruckus.brouhaha.com> |
| In reply to | #31130 |
rickman <gnuarm@gmail.com> writes: > Serial ports are still simple unless you make them complicated. The > chip used on the LaunchPad is a USB serial port. They claim no driver > needs to be downloaded... " Oh that's great, and makes sense. Dirk was saying it presented some special interface that needed its own drivers. > I'm not sure why screaming is desirable. The point is that a lot more > folks will play with a $10 PCB than will put together a solderless > breadboard. Well, the $10 PCB's are already out there, Forth already runs on them, etc. Once there's a PCB then I stop caring about the circuit complexity or wiring and it's just another black box like a laptop though. I really like the idea of having just one chip and a few passive parts with all connections completely visible and changeable. >>> If someone wants to go the wireless breadboard route, again, no need >>> for a board design. > Then what is holding it up? Shrug, Dirk seems interested in it. I could conceivably give it a try, but hardware isn't really my thing and I'm better off writing code.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-01 13:10 -0400 |
| Message-ID | <lmfmqb$9lm$1@dont-email.me> |
| In reply to | #31133 |
On 6/1/2014 12:45 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Serial ports are still simple unless you make them complicated. The >> chip used on the LaunchPad is a USB serial port. They claim no driver >> needs to be downloaded... " > > Oh that's great, and makes sense. Dirk was saying it presented some > special interface that needed its own drivers. > >> I'm not sure why screaming is desirable. The point is that a lot more >> folks will play with a $10 PCB than will put together a solderless >> breadboard. > > Well, the $10 PCB's are already out there, Forth already runs on them, > etc. Once there's a PCB then I stop caring about the circuit complexity > or wiring and it's just another black box like a laptop though. I > really like the idea of having just one chip and a few passive parts > with all connections completely visible and changeable. > >>>> If someone wants to go the wireless breadboard route, again, no need >>>> for a board design. >> Then what is holding it up? > > Shrug, Dirk seems interested in it. I could conceivably give it a try, > but hardware isn't really my thing and I'm better off writing code. The code is what I am talking about. I thought the solderless breadboard was about the simplicity of the hardware. I think you would need few wires actually... Power and ground 2 Serial port 2 LED 1 SW 1 Reset 1 Test 1 So 8 connections to the MCU should do the job once you have a programmed MCU. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | HaveANiceDay <HaveANiceDay@NoSpam.invalid> |
|---|---|
| Date | 2014-06-01 18:38 +0200 |
| Message-ID | <20140601183848.492e6c69@42d75> |
| In reply to | #31129 |
Paul Rubin <no.email@nospam.invalid> wrote: > rickman <gnuarm@gmail.com> writes: > > Everything on USB requires drivers. I'm sure they come with the > > LaunchPad if not with the OS. > > The Launchpad comes with a CD full of Windows code that is useless to me > as a Linux user. There are some downloadable Linux programs for running > the Launchpad and I should get around to figuring out how to use them. > But the idea of a resident Forth is partly to get rid of the need for > special software on the host side. I guess things were simpler in the > serial port era. > Or parallel-port era, as you pointed out, yes! But with the LP and Linux you _can_ get away without _any_ special download. The required firmware for the on-board TI USB-chip "ti_3410.fw.ihex" normally comes already with mspdebug (or even maybe already there due to some firmware package), and the "drivers for the Launchpad" are the "ti_usb_3410_5052" and "cdc_acm", which are already shipped in the kernel since quite a while ago. The only problem I know about is that, depending on your installation, maybe a modem-manager tries to initialise the "USB ACM device", blocking it for about 15-30 seconds after plug in, until giving up. And for communication with the Forth on the LP you can use "minicom" if the target-Forth uses appropriate flow-control. If not it gets overrun on downloads but works still fine typing at hand... You only apt-get/emerge/yum/pacman... mspdebug minicom, plug in the LP, and there you go. >ok For Windows user its clearly worse, but they are used to it- and maybe the LP-cd can help them.
[toc] | [prev] | [next] | [standalone]
| From | babruehl@gmail.com |
|---|---|
| Date | 2014-06-01 11:40 -0700 |
| Message-ID | <2a62774f-2149-4048-8b35-1c75ea68ff9c@googlegroups.com> |
| In reply to | #31131 |
On Sunday, June 1, 2014 12:38:48 PM UTC-4, HaveANiceDay wrote: > For Windows user its clearly worse, but they are used to it- and > maybe the LP-cd can help them. For Windows users it's much easier: Download the 4E4th-IDE at http://www.4e4th-ide.org/ - doesn't need installing, doesn't need any other package, ready to go with instructions showing up directly after start.
[toc] | [prev] | [next] | [standalone]
| From | HaveANiceDay <HaveANiceDay@NoSpam.invalid> |
|---|---|
| Date | 2014-06-01 11:13 +0200 |
| Message-ID | <20140601111333.4f824781@42d75> |
| In reply to | #31113 |
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. 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 -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! 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....
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web