Groups > comp.lang.forth > #30977 > unrolled thread

MSP430-Stamp

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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →

#31279

From	visualforth@rocketmail.com
Date	2014-06-07 12:01 -0700
Message-ID	<42e6f17a-b440-4330-90ac-309376f432d1@googlegroups.com>
In reply to	#31265

On Saturday, June 7, 2014 7:35:11 AM UTC-4, Mark Wills wrote:
> After spinning this around in my head for a few days, I'm going 
> 
> to go ahead and post my thoughts re the feature set of the board.
> 
> 
> 
> The principle I have in my head is of a "main-board" that can
> 
> support a number of daughter-boards. The type of the daughter
> 
> boards (their function etc) is not of importance right now.
> 
> They can be determined much later (if at all/ever).
> 
> 
> 
> For the main board, I envisage the following:
> 
> 
> 
> Main Board Specification
> 
> ========================
> 
> * MSP430 based CPU (I like the part with 16K ram*)
> 
> * 1 off Serial port (RS232) for connection to PC/terminal
> 
> * 1 off Serial port (RS232) for connection to other devices
> 
> * 1 off connector for connection to a 16-key hex key-pad
> 
> * 1 off connector for connection to a LCD display 
> 
>   (e.g. 20x2, 20x4 Hitachi type)
> 
> * 1 off I2C connector for daisy-chaining daughter boards
> 
> * 1 off red LED
> 
> * 1 off green LED (the colours aren't important, I'm just
> 
>   specifying two LEDs of different colours)
> 
> * 1 off 2 position switch
> 
> * 1 off power connector/battery connector
> 
> 
> 
> Rationale
> 
> =========
> 
> I'll describe where I'm coming from with the above specification.
> 
> 
> 
> MSP430 CPU: The central tenet of all discussions so far. Low 
> 
> cost, good instruction set. One aspect of the discussion I would
> 
> to instroduce here is the FRAM part. Could we please have a 
> 
> discussion about using the FRAM version of the MSP430. I know
> 
> they are available in a number of specifications, but I don't
> 
> recall specifics any more. I was on top of this a couple of years
> 
> back when I was in regular contact with a TI sales rep, but
> 
> not anyore, and the MSP430 product line is developing very fast.
> 
> 
> 
> The FRAM version of the part offers a number of advantages, 
> 
> particularly in a educational type environment. Specifically,
> 
> one may write to FRAM with complete impunity, and not worry 
> 
> about the complications of wearing out flash. And of course, it
> 
> retains it's state after power off. All of the conveniences of
> 
> flash, and none of the complications. This is very handy for us
> 
> in an educational environment. It means that:
> 
> 
> 
> * We don't have to have complex solutions for things like 
> 
>   CREATE/DOES> (for example, in a Flash environment you might 
> 
>   want the PFA (or whatever you want to call it - the thing that
> 
>   children of CREATE returns to the stack) in RAM, whilst the
> 
>   compiled code goes in flash. This is because one may want to
> 
>   write to the PFA (consider the classical implementation of 
> 
>   CONSTANT). With FRAM, we simply don't need to go there.
> 
> * We wouldn't need special words for ! where ! needs to write to
> 
>   flash. For example, if ! is writing to an area of "true" RAM
> 
>   then no special action is required. If ! needs to write to 
> 
>   Flash, then the appropriate block/page needs to be unlocked, 
> 
>   the value written, and locked again etc. With FRAM, we just 
> 
>   don't need to go there.
> 
> * FRAM, as shown in the above two point, simplifies the Forth
> 
>   system running on the chip, but, crucially, simplifies the life
> 
>   of the student, meaning we can avoid having to describe to the
> 
>   student the architectural constraints of a Flash based system.
> 
>   
> 
> Serial Port - for connection to host
> 
> ------------------------------------
> 
> This would be for general communication with the board. The 
> 
> student would upload source code (a simple text file) to the 
> 
> board via an RS232 connection. The code would be compiled on
> 
> the board, not on the host PC. We want real-time, interactive
> 
> Forth. Not a host-based cross-compiler (IMO). The student should
> 
> be encouraged to (and the accompanying tutorial documentation
> 
> will) type stuff right at the keyboard of the PC, and see results
> 
> instantly, as has been the Forth way for decades.
> 
> 
> 
> Serial Port - for connection to other devices
> 
> ---------------------------------------------
> 
> Part of the tutorial syllabus shall include connecting the board
> 
> to other devices (or, perhaps another main board) and exchanging
> 
> data using a very simple protocol. Of course, it's possible to 
> 
> do this using the first serial port, but students may want to see
> 
> what their code is doing by sending output to the "PC" serial 
> 
> port, so they can see their program communicating in real-time.
> 
> 
> 
> 16-key Hex Keypad Port
> 
> ----------------------
> 
> The Hex keypad will form part of the ability (along with an LCD)
> 
> to allow the board to be used by a student for stand-alone 
> 
> projects, away from a PC. For example, the syllabus can include
> 
> a clock project that displays the time on the LCD, and allows
> 
> the setting of the time via the keypad. The Forth system will 
> 
> include words for scanning the keypad.
> 
> 
> 
> LCD Display Port
> 
> ----------------
> 
> For displaying output in a stand-alone configuration. Eg time in
> 
> a clock project.
> 
> 
> 
> I2C Port
> 
> --------
> 
> This will allow multiple daughter-boards to be connected to the
> 
> main board. For example, in the future, an SD card reader/writer
> 
> board could be developed for saving code/data. 
> 
> Ideas for daughter boards:
> 
>  * Analogue input boards (simple voltage reading, not current 
> 
>    loop);
> 
>  * Analogue output boards;
> 
>  * Digital input/output boards;
> 
>  * SD card reader writer.
> 
>  
> 
> LEDs
> 
> ----
> 
> For general use. For example, in a clock project, they could be
> 
> the alarm, in the absence of a buzzer.
> 
> 
> 
> Two Position Switch
> 
> -------------------
> 
> The two position switch shall determine what action the board
> 
> takes upon power-up. In one position, the board shall simply 
> 
> initialise itself and send its welcome message to the terminal
> 
> via the host serial port.
> 
> In the second position, the board shall begin executing a users
> 
> program upon power-up. This would be implemented using simple
> 
> vectored execution. E.g.
> 
> 
> 
> ' my_prog on_power_up !
> 
> 
> 
> 
> 
> 
> 
> Other things to consider:
> 
> =========================
> 
> * Including digital input/output (buffered) on the board, for 
> 
>   reading switches etc. Depends on how much I/O is available;
> 
> * A pezio buzzer.
> 
> 
> 
> My Contribution:
> 
> ================
> 
> I would be willing to commit to the following:
> 
> 
> 
> * Financial input (e.g. procurement of MSP430's or contribution
> 
>   towards same if (for example) they can be obtained cheaper in 
> 
>   the USA rather than the UK;
> 
>   
> 
> * Financial input towards board prototyping.
> 
>   
> 
> * Documentation development:
> 
>   * User reference manual;
> 
>   * Tutorial syllabus - a complete Forth course, starting from
> 
>     first principles and taking the student right through Forth,
> 
>     using Forth best-practices. Targeted specifically to the 
> 
>     board. 
> 
> 
> 
> Comments?
> 
> =========
> 
> Your comments are welcome. Upon initial reading, this probably 
> 
> comes over as being way over-the-top. However, I would encourage
> 
> some thought, rather than (respectfully) knee-jerk reaction.
> 
> The system I have described above is, in my opinion, a very good
> 
> compromise between a purely education board for Forth students 
> 
> and a board that could be put into general use (perhaps along
> 
> with a daughter-board or two).
> 
> 
> 
> For example, I could envisage using such a board to teach Forth
> 
> to students. However, I could equally envisage using the same
> 
> board, un-modified, along with, say, one digital input board and
> 
> one analog input board as a home burgler alarm system. Or perhaps
> 
> as an RTU in the field somewhere, maybe monitoring a block-valve
> 
> on a pipeline block-valve station.

Mark, 
I like your suggestion. It's at an higher end than our MSP430-Stamp, but it gives a lot more possibilities for use.

Especially I like your request to use an FRAM part.
The FRAM micro is ideally suited for Forth, no hassle with segmented Flash.
Michael ported CamelForth onto TI's first FRAM-MSP, the MSP430FR5739. This Forth may even run on other TI FRAM MSPs, too.
 
I did some research, and the MSP430F5529 with 128kB FRAM and a great lot of features will do it. I ordered some free TI samples. The only problem is that this part is 7mm x 7mm only with 48 pins (0.5 mm pitch) and has to be soldered. My research for socket showed that these are expensive.

Since a while I am thinking of the UEXT serial bus which is an open-project that is royalty-free, and some hardware to connect is already available.
Source: http://en.wikipedia.org/wiki/UEXT 
What about that?

Thanks for offering financial support for the prototyping!

[toc] | [prev] | [next] | [standalone]

#31322

From	Mark Wills <markwills1970@gmail.com>
Date	2014-06-09 03:47 -0700
Message-ID	<fe803f34-a59c-4c0c-865f-b8958dd5ecfb@googlegroups.com>
In reply to	#31279

On Saturday, 7 June 2014 20:01:29 UTC+1, visua...@rocketmail.com  wrote:
> Mark, 
> 
> I like your suggestion. It's at an higher end than our 
> MSP430-Stamp, but it gives a lot more possibilities for use.
> 
It probably is somewhat higher end, but it solves some potential 
nasty issues with Flash that I'd rather not get into in a learning
environment. It's one hurdle that the student does not need to 
jump over :-)

> 
> Michael ported CamelForth onto TI's first FRAM-MSP, the 
> MSP430FR5739. This Forth may even run on other TI FRAM MSPs, too.
Can you provide a link to this? Is this the 4e4th system?
(Sorry if I'm getting confused).

> I did some research, and the MSP430F5529 with 128kB FRAM and a 
> great lot of features will do it. I ordered some free TI 
> samples.
> The only problem is that this part is 7mm x 7mm only with 48 
> pins (0.5 mm pitch) and has to be soldered. My research for 
> socket showed that these are expensive.

I'm actually thinking that the 5739 would be perfect. The 5529
is cool with its 128KB of FRAM, but then we start getting into
very awkward memory paging issues in order to access it. That's
something that I would rather stay away from in a learning 
environment. It would also (I think - maybe Michael, your
colleague can comment on this?) considerably complicate the Forth
syetem on the chip. For example: How do you handle the paging
of memory in and out to execute things like colon definitions?

It gets complex real fast. My reccomendation would be to use then
64K part.

Of course, using FRAM adds some risks. It becomes quite easy for
bugged code to write all over the Forth system on the chip.
This is something that we would need to think carefully about.
I'm thinking that the following words:

* !
* C!
* ,
* C,

should have "safe" equivalents:

* S!
* SC!
* S,
* SC,

These words will check the address being written to, and if the
address is in an illegal area (anywhere in the Forth system, or
in the Forth system variables area) then it should abort with a
helpful error message.

The user should use these safe words while developing his 
application. When he is sure that it works (i.e. no exceptions
are triggered :-) then he could re-define them to use the un-safe
(and faster) versions, like this:

: S! ( val addr -- ) postpone ! ; immediate

That way, he doesn't have to edit the source code for his 
application.

There may be other words (MOVE CMOVE CMOVE> FILL etc) that will
need similar safe-guards. I'm open to suggestions. It's all about
minimising the chances of a user crashing the system and wiping
Forth off the chip and having to have it re-loaded.

Something for further discussion.

> 
> Since a while I am thinking of the UEXT serial bus which is an
> open-project that is royalty-free, and some hardware to connect
> is already available.
> 
> Source: http://en.wikipedia.org/wiki/UEXT 
> 
> What about that?
>
I've not heard of this. I'll have a look at it. "Standard" 
serial protocols are useful, because one can communicate with
other machines via the on-board UARTs very easily. But I'll
take a look.

> 
> 
> Thanks for offering financial support for the prototyping!

No problem. It's something that could have use for me in other
areas.

[toc] | [prev] | [next] | [standalone]

#31334

From	Mikael Nordman <oh2aun@gmail.com>
Date	2014-06-09 09:28 -0700
Message-ID	<4e13b1cd-942c-4008-abfc-fa1537455c72@googlegroups.com>
In reply to	#31322

On Monday, June 9, 2014 1:47:51 PM UTC+3, Mark Wills wrote:
> Of course, using FRAM adds some risks. It becomes quite easy for
> bugged code to write all over the Forth system on the chip.
> This is something that we would need to think carefully about.
> 

The MSP430 FRAM variants have a Memory Protection Unit 
that can protect the Forth Kernel. 
The kernel can be safe all the time from 
writes with standard ! C! and so on.

I have (re)started to write FlashForth for the MSP430 FRAM parts.
I will use the MPU for protecting the Kernel. 
The other versions of FF have the kernel protected in software.

Flashforth goes to CPU idle mode between system ticks to save power.
This is done in PAUSE. Usually the system cannot go to sleep fully
since the peripherals need to be clocked in order to wake up the CPU.

Deep sleep modes are usually very application dependent.
I don't know exactly how much can be achieved in this area with the MSP430
while still retaining a Forth Stamp feel that responds to serial activity.

Mike
http://flashforth.sourceforge.net

[toc] | [prev] | [next] | [standalone]

#31408

From	Mark Wills <markwills1970@gmail.com>
Date	2014-06-11 07:35 -0700
Message-ID	<282c1bb8-840d-4f8b-992d-654c7db17dcf@googlegroups.com>
In reply to	#31334

Mike,

Just wanted to bring your attention to a software package called 
Grace for the MSP430 parts:

Grace is a tool that allows you as an MSP430 developer to generate 
the peripheral's set up code within minutes. This will save you 
much of the work of poring through user guides and copying code 
examples and allow you to focus on the more important aspects of 
your application. Grace was released several years ago and has 
provided an invaluable tool to scores of MSP430 developers in 
helping them accelerate software their development.

I got the information from the MSP430 forum on the TI E2E web
site:

http://e2e.ti.com/support/microcontrollers/msp430/default.aspx

(Note: a myTI website account is required to access it).

Just wanted to let you know, as it could come in very handy for
getting the chip up and sane quickly. Seems the hardest part of
this particular family of MCU is configuring its multiple
peripherals in the correct modes, etc.

I've checked, and the latest version of Grace does support the 
MSP430FR59xx (FRAM) parts.

Hope this information is useful.

Regards

Mark

[toc] | [prev] | [next] | [standalone]

#31411

From	visualforth@rocketmail.com
Date	2014-06-11 10:43 -0700
Message-ID	<f21bc297-039f-4160-8958-833c23b4e81b@googlegroups.com>
In reply to	#31408

On Wednesday, June 11, 2014 10:35:02 AM UTC-4, Mark Wills wrote:
 
> Grace is a tool that allows you as an MSP430 developer to generate 
> the peripheral's set up code within minutes. 

Mark,
is Grace or it's output suitable to work with Forth?

[toc] | [prev] | [next] | [standalone]

#31423

From	Mark Wills <markwills1970@gmail.com>
Date	2014-06-11 15:52 -0700
Message-ID	<71391c71-622f-44f5-bf18-aa64d3451844@googlegroups.com>
In reply to	#31411

I don't think so. But it's output would be very useful as one of the very first parts of a forth system. The part executes the moment the power is turned on. If it can produce assembler output rather than C then that is probably even better. 

What are folks using for an assembler? Mike could you explain how your coding environment is set up for porting the Camel Forth version? 

Thanks

Mark

[toc] | [prev] | [next] | [standalone]

#31426

From	Coos Haak <chforth@hccnet.nl>
Date	2014-06-12 02:06 +0200
Message-ID	<1k2ohp5m90g9b$.118gaq46ycza6.dlg@40tude.net>
In reply to	#31423

Op Wed, 11 Jun 2014 10:43:11 -0700 (PDT) schreef
visualforth@rocketmail.com:

> is Grace or it's output suitable to work with Forth?

Op Wed, 11 Jun 2014 15:52:53 -0700 (PDT) schreef Mark Wills:

> I don't think so. But it's output would be very useful as one of the very first parts of a forth system. The part executes the moment the power is turned on. If it can produce assembler output rather than C then that is probably even better. 

You both seem not to know the difference between "it's output" and "its
output". It's likely you have problems with "you're" and "your" too.

I'm defina^Hitely not a native English speaker.
-- 
Coos

[toc] | [prev] | [next] | [standalone]

#31428

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2014-06-11 15:13 -1000
Message-ID	<bLKdnTGWzLZUYwXOnZ2dnUVZ_uGdnZ2d@supernews.com>
In reply to	#31426

On 6/11/14 2:06 PM, Coos Haak wrote:
> Op Wed, 11 Jun 2014 10:43:11 -0700 (PDT) schreef
> visualforth@rocketmail.com:
>
>> is Grace or it's output suitable to work with Forth?
>
> Op Wed, 11 Jun 2014 15:52:53 -0700 (PDT) schreef Mark Wills:
>
>> I don't think so. But it's output would be very useful as one of the very first parts of a forth system. The part executes the moment the power is turned on. If it can produce assembler output rather than C then that is probably even better.
>
> You both seem not to know the difference between "it's output" and "its
> output". It's likely you have problems with "you're" and "your" too.
>
> I'm defina^Hitely not a native English speaker.

"It's" is a contraction for "it is". "Its" is a possessive pronoun 
("belonging to it").

The easy way to remember is to think of other possessive pronouns: mine, 
yours, his, hers, its, theirs, ours. No apostrophes.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#31443

From	Mark Wills <markwills1970@gmail.com>
Date	2014-06-12 02:16 -0700
Message-ID	<a47385ca-c52d-40b6-83d8-711d84f4f415@googlegroups.com>
In reply to	#31426

Apologies, Coos.

a) It was very late and I was already in bed - I was tired but wanted to respond before going to sleep!

b) I was responding via my "Smart" phone, which is anything but smart.

Here's a cleaned up version, just to prove that I have a reasonable command of the Queen's English :-)

I don't think so. However its output would be very useful as one of the very first parts of a Forth system. The part that executes the moment the power is turned on. If it can produce assembler output rather than C output then that is probably even better.

[toc] | [prev] | [next] | [standalone]

#31418

From	Mikael Nordman <oh2aun@gmail.com>
Date	2014-06-11 12:56 -0700
Message-ID	<71a87945-9ad3-4f4c-99e2-dd1ba28c7148@googlegroups.com>
In reply to	#31408

On Wednesday, June 11, 2014 5:35:02 PM UTC+3, Mark Wills wrote:
> Mike,
> Just wanted to bring your attention to a software package called 
> Grace for the MSP430 parts:
> 
> Grace is a tool that allows you as an MSP430 developer to generate 
> the peripheral's set up code within minutes. 

Thanks Mark,
I will take a look.

Mike

[toc] | [prev] | [next] | [standalone]

#31347

From	rickman <gnuarm@gmail.com>
Date	2014-06-09 16:46 -0400
Message-ID	<ln56ff$e7p$1@dont-email.me>
In reply to	#31322

On 6/9/2014 6:47 AM, Mark Wills wrote:
> On Saturday, 7 June 2014 20:01:29 UTC+1, visua...@rocketmail.com  wrote:
>>
>> Michael ported CamelForth onto TI's first FRAM-MSP, the
>> MSP430FR5739. This Forth may even run on other TI FRAM MSPs, too.
> Can you provide a link to this? Is this the 4e4th system?
> (Sorry if I'm getting confused).
>
>> I did some research, and the MSP430F5529 with 128kB FRAM and a
>> great lot of features will do it. I ordered some free TI
>> samples.
>> The only problem is that this part is 7mm x 7mm only with 48
>> pins (0.5 mm pitch) and has to be soldered. My research for
>> socket showed that these are expensive.

There is a mistake somewhere.  The 5529 is not a FRAM part, it is Flash 
based.


> I'm actually thinking that the 5739 would be perfect. The 5529
> is cool with its 128KB of FRAM, but then we start getting into
> very awkward memory paging issues in order to access it. That's
> something that I would rather stay away from in a learning
> environment. It would also (I think - maybe Michael, your
> colleague can comment on this?) considerably complicate the Forth
> syetem on the chip. For example: How do you handle the paging
> of memory in and out to execute things like colon definitions?
>
> It gets complex real fast. My reccomendation would be to use then
> 64K part.

The 5739 is FRAM, but 16 kB, not 64.  It also has 1 kB of RAM.

My main issue I see is that people are picking processors and saying 
they would be "perfect" without having a set of requirements.


-- 

Rick

[toc] | [prev] | [next] | [standalone]

#31323

From	Mark Wills <markwills1970@gmail.com>
Date	2014-06-09 03:49 -0700
Message-ID	<521f8ea1-605d-4d86-810c-4e843acd0e88@googlegroups.com>
In reply to	#31279

I forgot to ask: Could you send me some information on getting samples. I can maybe get some from TI UK but we don't deal much with them anymore.

Mark

[toc] | [prev] | [next] | [standalone]

#31335

From	visualforth@rocketmail.com
Date	2014-06-09 09:47 -0700
Message-ID	<3aa0c860-f0f3-4cb3-a13c-0158bc6dc99c@googlegroups.com>
In reply to	#31323

On Monday, June 9, 2014 6:49:03 AM UTC-4, Mark Wills wrote:
> I forgot to ask: Could you send me some information on getting samples. I can maybe get some from TI UK but we don't deal much with them anymore.
> Mark

http://www.ti.com/general/docs/buy.tsp

You will be asked to setup an account, most samples are for free.

[toc] | [prev] | [next] | [standalone]

#31349

From	Rikard Lang <rikard.lang@gmail.com>
Date	2014-06-09 23:16 +0200
Message-ID	<2014060923162520151-rikardlang@gmailcom>
In reply to	#31265

On 2014-06-07 11:35:11 +0000, Mark Wills said:

> 
> For the main board, I envisage the following:
> 
> Main Board Specification
> ========================
> * MSP430 based CPU (I like the part with 16K ram*)
> * 1 off Serial port (RS232) for connection to PC/terminal
> * 1 off Serial port (RS232) for connection to other devices
> * 1 off connector for connection to a 16-key hex key-pad
> * 1 off connector for connection to a LCD display
>   (e.g. 20x2, 20x4 Hitachi type)
> * 1 off I2C connector for daisy-chaining daughter boards
> * 1 off red LED
> * 1 off green LED (the colours aren't important, I'm just
>   specifying two LEDs of different colours)
> * 1 off 2 position switch
> * 1 off power connector/battery connector
> 
> 
> 
> Comments?
> =========
> Your comments are welcome. Upon initial reading, this probably
> comes over as being way over-the-top. However, I would encourage
> some thought, rather than (respectfully) knee-jerk reaction.
> The system I have described above is, in my opinion, a very good
> compromise between a purely education board for Forth students
> and a board that could be put into general use (perhaps along
> with a daughter-board or two).
> 
> For example, I could envisage using such a board to teach Forth
> to students. However, I could equally envisage using the same
> board, un-modified, along with, say, one digital input board and
> one analog input board as a home burgler alarm system. Or perhaps
> as an RTU in the field somewhere, maybe monitoring a block-valve
> on a pipeline block-valve station.


Mark,

I really like your idea and I think it would be very suitable for 
people like myself who want to tinker with MCUs. I already tinker with 
Forth, but the board as described above would be a portal into dealing 
with sensors etc. The MSP430 looks really interesting too. I want that 
board ... soon.


--
-- 
FORTH LOVE IF HONK THEN

Rikard Lang

[toc] | [prev] | [next] | [standalone]

#31371

From	visualforth@rocketmail.com
Date	2014-06-10 07:48 -0700
Message-ID	<720c6c08-e8d8-4595-8a34-7d3b3b52c226@googlegroups.com>
In reply to	#31349

On Monday, June 9, 2014 5:16:25 PM UTC-4, Rikard Lang wrote:

> The MSP430 looks really interesting too. I want that 
> board ... soon.

Thanks for your order, Rikard!

How much do you like to pay for this board?
Your answer is important, because the price is a design constraint.
How much time do we have to get the first sample out of the door?
What format - size of the board - do you like to have?

When I have your answers, I will make a preliminary layout floorplan.
Cheers,
Dirk.

[toc] | [prev] | [next] | [standalone]

#31405

From	Mark Wills <markwills1970@gmail.com>
Date	2014-06-11 07:23 -0700
Message-ID	<3506769c-823d-4228-9ff5-8a06017e437d@googlegroups.com>
In reply to	#31371

I have (awaiting delivery) a sample of the MSP430FR5949IDAR on 
it's way. It's a 64K FRAM part with plenty of I/O, ADCs, RTC, you
name it. It doesn't have a kitchen sink. Apparently.

I chose this one due to it's packaging. It should be easy to make
a small PCB that converts the chip into something with DIL-style
pins for easy insertion into a project board.

I'm thinking that no specific PCB needs to be designed at all. 
Just supply a chip on a tiny PCB such that it can be easily 
dropped into a bread-board or project board. Then, supply 
instructions on how to hook components to the chip for each 
experiment, just like the electronics labs we used as children 
from Tandy (Radio Shack) and the like.

PDF showing the packaging type is here:

http://www.ti.com/lit/ml/mpds502/mpds502.pdf

Let the good times roll...

[toc] | [prev] | [next] | [standalone]

#31424

From	David Schultz <abuse@127.0.0.1>
Date	2014-06-11 18:00 -0500
Message-ID	<cc5mv.1551515$Oa6.1351495@fx14.iad>
In reply to	#31405

On 06/11/2014 09:23 AM, Mark Wills wrote:
> I have (awaiting delivery) a sample of the MSP430FR5949IDAR on 
> it's way. It's a 64K FRAM part with plenty of I/O, ADCs, RTC, you
> name it. It doesn't have a kitchen sink. Apparently.
> 
> I chose this one due to it's packaging. It should be easy to make
> a small PCB that converts the chip into something with DIL-style
> pins for easy insertion into a project board.
> 
> I'm thinking that no specific PCB needs to be designed at all. 
> Just supply a chip on a tiny PCB such that it can be easily 
> dropped into a bread-board or project board. Then, supply 
> instructions on how to hook components to the chip for each 
> experiment, just like the electronics labs we used as children 
> from Tandy (Radio Shack) and the like.
> 
> PDF showing the packaging type is here:
> 
> http://www.ti.com/lit/ml/mpds502/mpds502.pdf
> 
> Let the good times roll...
> 

I have a MSP430G2955 installed on a header breakout board. I looked at
the FR594x parts hoping that since they were available in the same
package I could use the same PCB. No luck as the pinouts are different.
Not too different but enough so that the power supply decoupling caps
connect to the wrong pins and the crystal is different too.

I hadn't bothered to share this because it was so simple.

http://home.earthlink.net/~schultdw/msp430/index.html


-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
Returned for Regrooving

[toc] | [prev] | [next] | [standalone]

#31438

From	rickman <gnuarm@gmail.com>
Date	2014-06-12 02:14 -0400
Message-ID	<lnbgf9$c4j$1@dont-email.me>
In reply to	#31424

On 6/11/2014 7:00 PM, David Schultz wrote:
> On 06/11/2014 09:23 AM, Mark Wills wrote:
>> I have (awaiting delivery) a sample of the MSP430FR5949IDAR on
>> it's way. It's a 64K FRAM part with plenty of I/O, ADCs, RTC, you
>> name it. It doesn't have a kitchen sink. Apparently.
>>
>> I chose this one due to it's packaging. It should be easy to make
>> a small PCB that converts the chip into something with DIL-style
>> pins for easy insertion into a project board.
>>
>> I'm thinking that no specific PCB needs to be designed at all.
>> Just supply a chip on a tiny PCB such that it can be easily
>> dropped into a bread-board or project board. Then, supply
>> instructions on how to hook components to the chip for each
>> experiment, just like the electronics labs we used as children
>> from Tandy (Radio Shack) and the like.
>>
>> PDF showing the packaging type is here:
>>
>> http://www.ti.com/lit/ml/mpds502/mpds502.pdf
>>
>> Let the good times roll...
>>
>
> I have a MSP430G2955 installed on a header breakout board. I looked at
> the FR594x parts hoping that since they were available in the same
> package I could use the same PCB. No luck as the pinouts are different.
> Not too different but enough so that the power supply decoupling caps
> connect to the wrong pins and the crystal is different too.
>
> I hadn't bothered to share this because it was so simple.
>
> http://home.earthlink.net/~schultdw/msp430/index.html

This board is for parts in a 38 pin TSSOP package.  This includes a 
number of FRAM parts including most of the MSP430FR594x (not the 
MSP430FR59471) and all of the MSP430FR595x devices.  However... the 
pinout of the 2955 (and this board) does not match any of these FRAM 
devices.  :(

So this board sounds pretty good in that you can get three of them for 
only $8.10, but you can't use them with FRAM devices.  If anyone wants a 
similar board for one of the FRAM devices (my preference would be a 
MSP430FR596x part in the QFN package, I would be willing to dust off the 
layout software and produce this.  I had forgotten how inexpensive 
oshpark can be for small boards.  Maybe this would be an excuse to try 
Kicad instead of FreePCB.  FreePCB is a great tool, but no one is 
continuing development.  Kicad on the other hand seems to have legs.

So if we drop all I/O "features" and only put the MCU and minimum 
support circuitry on the board, who would be interested in getting one 
of these?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#31442

From	Mark Wills <markwills1970@gmail.com>
Date	2014-06-12 02:13 -0700
Message-ID	<d32173a9-8a03-46f5-8c80-1beb1f2020a0@googlegroups.com>
In reply to	#31438

I already sent an email to David, but if you're willing to do the design then please go for it!

Please consider the MSP430FR5949. The reason I chose that part, (apart from amount of memory, etc) is that it lends itself to hand-soldering directly onto the PCB. Other packages will require a socket and that adds expense.

If you produce the board files (schematic, net list etc for a PCB manufacturer) then I'll get 50 or 100 boards made up by the supplier that I use in China. They are a British company, but thier PCB manufacturing operation is in China. They're very competitive, and when I used them for the TurboForth cartridge PCB the product was excellent, and met all the appropriate ROHS standards etc.

Mark

[toc] | [prev] | [next] | [standalone]

#31453

From	rickman <gnuarm@gmail.com>
Date	2014-06-12 13:04 -0400
Message-ID	<lncmii$7pm$1@dont-email.me>
In reply to	#31442

On 6/12/2014 5:13 AM, Mark Wills wrote:
> I already sent an email to David, but if you're willing to do the design then please go for it!
>
> Please consider the MSP430FR5949. The reason I chose that part, (apart from amount of memory, etc) is that it lends itself to hand-soldering directly onto the PCB. Other packages will require a socket and that adds expense.

There is no need for a socket.  Hand soldering is entirely feasible for 
the QFN package (not that I have done it but I have other issues).  I 
have read many reports of successful assembly of these parts by hand.

The 594x parts only support a low frequency crystal and the 595x parts 
only support a high frequency crystal.  The 596x parts support both 
types of crystals.

> If you produce the board files (schematic, net list etc for a PCB manufacturer) then I'll get 50 or 100 boards made up by the supplier that I use in China. They are a British company, but thier PCB manufacturing operation is in China. They're very competitive, and when I used them for the TurboForth cartridge PCB the product was excellent, and met all the appropriate ROHS standards etc.

There is likely no need unless you are going to have the boards 
populated.  Oshpark will sell the boards in multiples of 3 and handles 
all of the shipping.  Their only drawback is that they only do a run 
once or twice a month and you have to wait for the next run.  But you 
can't get any more convenient than that.  How will you distribute 100 
boards?  Mailing them out to people will be a PITA.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →

csiph-web

MSP430-Stamp

Contents

#31279

#31322

#31334

#31408

#31411

#31423

#31426

#31428

#31443

#31418

#31347

#31323

#31335

#31349

#31371

#31405

#31424

#31438

#31442

#31453