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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-03 12:18 -0400 |
| Message-ID | <lmksg9$q6m$1@dont-email.me> |
| In reply to | #31168 |
On 6/3/2014 4:26 AM, Matthias Koch wrote: >>> * Launchpads are brickable if you have no 4 wire JTAG available. >> >> I'm unclear on this. How is the LaunchPad brickable when there are >> dedicated serial port and JTAG controller chips? Are you saying you >> can brick the JTAG controller MSP430? >> > > Exactly this. You can abuse the firmware upload mechanism... > > By the way, there are 5 test points next to the MSP430F1612 on the > Launchpad. How can you brick the JTAG chip? Is there a way to upload to the JTAG controller chip as well as the target MCU? That would not be too sharp. It reminds me of a board I designed which had an upload feature. I added a jumper which would prevent writing to the chip with the upload firmware. The software team overruled my decision and used a simple "key" mechanism that only had to write some value to a register to unlock the write protect. No, that is not likely to fail, but you can't say it was secure. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-02 10:04 -0700 |
| Message-ID | <7xzjhvfdkr.fsf@ruckus.brouhaha.com> |
| In reply to | #31147 |
Matthias Koch <matthias.koch@hot.uni-hannover.de> writes: > * Launchpads are brickable if you have no 4 wire JTAG available. > * Launchpads are rather big. > * Launchpads have no optical link on board. > My favourite for a MSP430-Stamp would be a mix of Goodfet ideas ... Thanks very much for the informative post, one of the best contributions to this thread so far. Can you say what the optical link is for? Also, can we get our bearings about what is so great about the MSP430 itself? I like it because it evokes the PDP-11 that I programmed in high school, and I feel vague unease towards the ARM (more lurking complexity) and slight distaste towards the AVR8 (uglier instruction set, 8-bit operations). Plus I like that the 430 Value Line is very cheap and that 16 bits is a natural cell size for a small Forth. But in rational terms the 430 is just another MCU, and lots more possibilities may be worth considering. > http://tinkerlog.com/2009/01/18/attiny-breadboard-headers/ Ohh, I like that. A 430 or ARM version would be really nice.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2014-06-03 11:51 +0200 |
| Message-ID | <lmk5tv$dnr$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #31152 |
> Can you say what the optical link is for? Together with a coil and a large capacitor you can seal your project for underwater usage and still have a communications channel even in heavy electrical noise. It can also serve as an ESD-proof debug terminal remaining in projects that have no electrical communication connector otherwise in their final form and use the LED for human signaling at the same time. It is time to introduce the uncommon feature that a LED connected with both anode and cathode to a microcontroller can serve for communication. It won't increase the board cost, but gives one interesting example to try out of the box. If not used for communication, a LED connected with both wires can serve as ambient light sensor. Mecrisp contains Ledcomm sources both in assembly and Forth, and there is the pioneering paper called "Very Low-Cost Sensing and Communication Using Bidirectional LEDs" describing the basic ideas: http://www.merl.com/publications/TR2003-35 > Also, can we get our bearings about what is so great about the MSP430 > itself? I like it because it evokes the PDP-11 that I programmed in > high school, and I feel vague unease towards the ARM (more lurking > complexity) and slight distaste towards the AVR8 (uglier instruction > set, 8-bit operations). Plus I like that the 430 Value Line is very > cheap and that 16 bits is a natural cell size for a small Forth. At the beginning, I have choosen MSP430 for their very nice instruction set. Additionally, they have very convenient clocking, atomic IO, run on unregulated power and have nice analog characteristics and forgiving electrical characteristics that make them suitable to conquer the rather uncharted lands of bit-banging mixed with analog effects by experiment - it is simple to write cycle accurate self-timing code. All this comes with readable datasheets and a manageable complexity to understand. We should go the rather uncommon road and supply examples on how to do small useful things just with a few standard discrete components. Most board vendors are trying to push the border with special parts, but I don't want to buy parts that are unused afterwards for every experiment to try out. As we focus on introducing Forth ideas, we should not try to push the border in a direction that others have gone (too?) many times before. Rather we should give an experimental section showing ideas with common discrete components and clever software including some that result in nice give-away or useful-in-the-kitchen type. This includes doing analogs in the Forth way. We also need to focus on power supply ideas too, capacitor, solar, inductive, RF pickup, peltier, for small things that just run. After all, it needs to be fun. This includes that the board needs to be - beautiful. Maybe we could need an artist here. I want to introduce "Visolate" and its "Voronoi Toolpaths" to give a pleasant looking board: http://groups.csail.mit.edu/drl/wiki/index.php?title=Visolate:_Voronoi_Toolpaths_for_PCB_Mechanical_Etch > But in > rational terms the 430 is just another MCU, and lots more possibilities > may be worth considering. Exactly. But we need a chip we are comfortable with to finally got this board off the ground with the people available. Let's settle for MSP430 for now. To continue, we need to get organisation done. Open Hardware and GPL3 licenced software only. We start when all seats are filled. Board design: * We need to collect what parts need to be included. Goodfet is a good start. The Tinkerlog headers are a convenient idea. * Who is doing schematic design ? * Who is doing hardware design and board layout ? Needs an eye for beauty, too. * Who volunteers to do a prototype run ? Maybe we can contact http://43oh.com/ for help in this step. * Who is responsible for manufacturing later ? Documentation task force: * Who is writing documentation ? Plain text manual is sufficient. * Who is writing basic commented Forth and inlined assembly examples ? Mecrisp already contains an assembler, but this doesn't fit into G2553. Examples and analogs tasks: We need a bunch of people in this section. Analog wizards in love with simplicity welcome. * Who is doing nice power supply and energy harvesting schematics ? * Who is doing example projects with source and schematics ? I am offering hints on board schematic design and I volunteer in porting Mecrisp to the board arriving in my snail mail giving Forth a launch. Best wishes, Matthias
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-03 13:33 -0400 |
| Message-ID | <lml0t2$up2$1@dont-email.me> |
| In reply to | #31172 |
On 6/3/2014 5:51 AM, Matthias Koch wrote: >> Can you say what the optical link is for? > > Together with a coil and a large capacitor you can seal your project for > underwater usage and still have a communications channel even in heavy > electrical noise. It can also serve as an ESD-proof debug terminal > remaining in projects that have no electrical communication connector > otherwise in their final form and use the LED for human signaling at the > same time. It is time to introduce the uncommon feature that a LED > connected with both anode and cathode to a microcontroller can serve for > communication. It won't increase the board cost, but gives one > interesting example to try out of the box. If not used for > communication, a LED connected with both wires can serve as ambient > light sensor. > > Mecrisp contains Ledcomm sources both in assembly and Forth, and there > is the pioneering paper called "Very Low-Cost Sensing and Communication > Using Bidirectional LEDs" describing the basic ideas: > http://www.merl.com/publications/TR2003-35 This seems like an odd feature to include in a basic device with an intended use of education. Rather specialized. What specific hardware is needed to add this capability? If you are saying it just needs an LED, any specific type? >> Also, can we get our bearings about what is so great about the MSP430 >> itself? I like it because it evokes the PDP-11 that I programmed in >> high school, and I feel vague unease towards the ARM (more lurking >> complexity) and slight distaste towards the AVR8 (uglier instruction >> set, 8-bit operations). Plus I like that the 430 Value Line is very >> cheap and that 16 bits is a natural cell size for a small Forth. > > At the beginning, I have choosen MSP430 for their very nice instruction > set. Additionally, they have very convenient clocking, atomic IO, run on > unregulated power and have nice analog characteristics and forgiving > electrical characteristics that make them suitable to conquer the rather > uncharted lands of bit-banging mixed with analog effects by experiment - > it is simple to write cycle accurate self-timing code. All this comes > with readable datasheets and a manageable complexity to understand. Can you be specific about the unregulated power and analog features? I am not aware of any specific features of the MSP430 that make it more suitable than other devices. I have seen MCUs run directly from batteries, but regulation is typically needed when the I/O creates current surges and voltage spikes which will upset any digital device. How does the MSP430 deal with this that other MCUs don't? Many MCUs provide analog features such as comparators and opamps. Exactly what "forgiving electrical characteristics does it have? > We should go the rather uncommon road and supply examples on how to do > small useful things just with a few standard discrete components. Most > board vendors are trying to push the border with special parts, but I > don't want to buy parts that are unused afterwards for every experiment > to try out. > > As we focus on introducing Forth ideas, we should not try to push the > border in a direction that others have gone (too?) many times before. > Rather we should give an experimental section showing ideas with common > discrete components and clever software including some that result in > nice give-away or useful-in-the-kitchen type. This includes doing > analogs in the Forth way. We also need to focus on power supply ideas > too, capacitor, solar, inductive, RF pickup, peltier, for small things > that just run. After all, it needs to be fun. So how about if we work on the ideas before we start defining hardware. I like the idea of alternate sources of power. I have been looking at that a bit myself. But I see that as something separate. There is no need to include that on the MCU board. > This includes that the board needs to be - beautiful. Maybe we could > need an artist here. I want to introduce "Visolate" and its "Voronoi > Toolpaths" to give a pleasant looking board: > > http://groups.csail.mit.edu/drl/wiki/index.php?title=Visolate:_Voronoi_Toolpaths_for_PCB_Mechanical_Etch I'm not sure where this is coming from. Mechanical etch is an expensive way of making PCBs. It is used when the volume is very low or when turn around time is primary. Neither of these apply to the effort we are defining. >> But in >> rational terms the 430 is just another MCU, and lots more possibilities >> may be worth considering. > > Exactly. But we need a chip we are comfortable with to finally got this > board off the ground with the people available. > > Let's settle for MSP430 for now. To continue, we need to get > organisation done. Open Hardware and GPL3 licenced software only. We > start when all seats are filled. Organization of tasks is useful, but I don't think we have described the needed hardware yet. So let's pin down our goals so that we can figure out what we want the hardware to do. > Board design: > > * We need to collect what parts need to be included. Goodfet is a good > start. The Tinkerlog headers are a convenient idea. > * Who is doing schematic design ? > * Who is doing hardware design and board layout ? Needs an eye for > beauty, too. > * Who volunteers to do a prototype run ? Maybe we can contact > http://43oh.com/ for help in this step. > * Who is responsible for manufacturing later ? > > Documentation task force: > > * Who is writing documentation ? Plain text manual is sufficient. > * Who is writing basic commented Forth and inlined assembly examples ? > Mecrisp already contains an assembler, but this doesn't fit into G2553. > > Examples and analogs tasks: > > We need a bunch of people in this section. Analog wizards in love with > simplicity welcome. > > * Who is doing nice power supply and energy harvesting schematics ? > * Who is doing example projects with source and schematics ? > > I am offering hints on board schematic design and I volunteer in porting > Mecrisp to the board arriving in my snail mail giving Forth a launch. I know Dirk wanted this board to be used for education. So it would seem useful to define better what analog lessons would be done with the board. In fact, perhaps that is the orientation best taken to define the board. First lay out the education goals and specific lessons to be supported. Then the hardware would follow. I'm still wondering if special hardware is needed. Other than a remote possibility that the LaunchPad can be bricked, what is wrong with it? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Matthias Koch <matthias.koch@hot.uni-hannover.de> |
|---|---|
| Date | 2014-06-06 13:02 +0200 |
| Message-ID | <lms76n$t88$1@newsserver.rrzn.uni-hannover.de> |
| In reply to | #31177 |
> This seems like an odd feature to include in a basic device with an > intended use of education. Rather specialized. What specific hardware > is needed to add this capability? If you are saying it just needs an > LED, any specific type? A clear bright LED whose crystal materials emission spectrum matches its absorption spectrum. Direct bandgap GaAlAs is fine. > Can you be specific about the unregulated power and analog features? I > am not aware of any specific features of the MSP430 that make it more > suitable than other devices. I have seen MCUs run directly from > batteries, but regulation is typically needed when the I/O creates > current surges and voltage spikes which will upset any digital device. > How does the MSP430 deal with this that other MCUs don't? Many MCUs > provide analog features such as comparators and opamps. Exactly what > "forgiving electrical characteristics does it have? MSP430 chips can be powered through IO lines and have good ESD protection. My experience is limited to Zilog Z80, MSP430 and ARM Cortex M. >> This includes that the board needs to be - beautiful. Maybe we could >> need an artist here. I want to introduce "Visolate" and its "Voronoi >> Toolpaths" to give a pleasant looking board: >> >> http://groups.csail.mit.edu/drl/wiki/index.php?title=Visolate:_Voronoi_Toolpaths_for_PCB_Mechanical_Etch >> > > I'm not sure where this is coming from. Mechanical etch is an expensive > way of making PCBs. It is used when the volume is very low or when turn > around time is primary. Neither of these apply to the effort we are > defining. I am suggesting Voronoi boards mostly for beauty, as high current capability is not an issue on small microcontroller boards. > I'm still wondering if special hardware is needed. Other than a remote > possibility that the LaunchPad can be bricked, what is wrong with it? The maximum 9600 baud only terminal known for driver issues that comes with default F1612 Launchpad firmware. Matthias
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-06 17:31 -0400 |
| Message-ID | <lmtbvf$ie5$1@dont-email.me> |
| In reply to | #31241 |
On 6/6/2014 7:02 AM, Matthias Koch wrote: >> This seems like an odd feature to include in a basic device with an >> intended use of education. Rather specialized. What specific >> hardware is needed to add this capability? If you are saying it just >> needs an LED, any specific type? > > A clear bright LED whose crystal materials emission spectrum matches its > absorption spectrum. Direct bandgap GaAlAs is fine. Ok, if that does not require an expensive part it could easily be included on the board or at least the option for the end user to add the part could be provided. >> Can you be specific about the unregulated power and analog features? >> I am not aware of any specific features of the MSP430 that make it >> more suitable than other devices. I have seen MCUs run directly from >> batteries, but regulation is typically needed when the I/O creates >> current surges and voltage spikes which will upset any digital device. >> How does the MSP430 deal with this that other MCUs don't? Many MCUs >> provide analog features such as comparators and opamps. Exactly what >> "forgiving electrical characteristics does it have? > > MSP430 chips can be powered through IO lines and have good ESD > protection. My experience is limited to Zilog Z80, MSP430 and ARM Cortex M. I don't think the MSP430 is significantly lower power than other, similar devices. That depends entirely on what is being done on the chip. Typically the power can be estimated as a uA/MHz rating and the last time I checked was in the 250 uA/MHz region for many comparable CPUs although it might be as low as 100 uA/MHz these days. Hmmm, 100 uA is the rating for a built in pullup in a custom chip someone was discussing in another thread, lol. If ESD protection is a requirement, I'm sure there are many other devices that include that. ESD protection is pretty standard these days. >>> This includes that the board needs to be - beautiful. Maybe we could >>> need an artist here. I want to introduce "Visolate" and its "Voronoi >>> Toolpaths" to give a pleasant looking board: >>> >>> http://groups.csail.mit.edu/drl/wiki/index.php?title=Visolate:_Voronoi_Toolpaths_for_PCB_Mechanical_Etch >>> >> >> I'm not sure where this is coming from. Mechanical etch is an >> expensive way of making PCBs. It is used when the volume is very low >> or when turn around time is primary. Neither of these apply to the >> effort we are defining. > > I am suggesting Voronoi boards mostly for beauty, as high current > capability is not an issue on small microcontroller boards. Looking nice is wonderful, but there are requirements for making a board manufacturable. It would still need solder mask which would not be modified for the aesthetics because in this case form must follow function. >> I'm still wondering if special hardware is needed. Other than a >> remote possibility that the LaunchPad can be bricked, what is wrong >> with it? > > The maximum 9600 baud only terminal known for driver issues that comes > with default F1612 Launchpad firmware. > > Matthias -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-06 16:30 -1000 |
| Message-ID | <dfednaNwZ7fK5A_OnZ2dnUVZ_r2dnZ2d@supernews.com> |
| In reply to | #31252 |
On 6/6/14 11:31 AM, rickman wrote: > I don't think the MSP430 is significantly lower power than other, > similar devices. That depends entirely on what is being done on the > chip. Typically the power can be estimated as a uA/MHz rating and the > last time I checked was in the 250 uA/MHz region for many comparable > CPUs although it might be as low as 100 uA/MHz these days. Hmmm, 100 uA > is the rating for a built in pullup in a custom chip someone was > discussing in another thread, lol. SwiftX makes use of its facility to go to low power mode and recover easily by making the multitasker automatically go to low power mode when no tasks are active. An interrupt that wakes a task will reactivate the part. As a result, we often achieve duty cycles in the microseconds, for overall extremely low power consumption. We haven't seen any other parts (that I know of -- I may not be entirely current) that make this so easy. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-06 22:52 -0400 |
| Message-ID | <lmtups$riv$1@dont-email.me> |
| In reply to | #31254 |
On 6/6/2014 10:30 PM, Elizabeth D. Rather wrote: > On 6/6/14 11:31 AM, rickman wrote: >> I don't think the MSP430 is significantly lower power than other, >> similar devices. That depends entirely on what is being done on the >> chip. Typically the power can be estimated as a uA/MHz rating and the >> last time I checked was in the 250 uA/MHz region for many comparable >> CPUs although it might be as low as 100 uA/MHz these days. Hmmm, 100 uA >> is the rating for a built in pullup in a custom chip someone was >> discussing in another thread, lol. > > SwiftX makes use of its facility to go to low power mode and recover > easily by making the multitasker automatically go to low power mode when > no tasks are active. An interrupt that wakes a task will reactivate the > part. As a result, we often achieve duty cycles in the microseconds, for > overall extremely low power consumption. We haven't seen any other parts > (that I know of -- I may not be entirely current) that make this so easy. I haven't worked with them all, but the sleep when there is no work is a common feature. What makes it harder on other processors? They all have to do the same stuff, switch to an internal clock, shut off the high speed clock to save power, stop the processor pending an interrupt, on wakeup the high speed clock has to be restarted and then switched to once stable then the processing resumed. The problem with this is usually the time it takes for the oscillator to restart. Everything is eating power with no work being done while waiting, so loss of efficiency. If your rate of power mode switching is high, it eats into your savings severely. Can you share some insight into what makes the MSP430 power schemes easier to use? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-07 11:58 +0000 |
| Message-ID | <5392fe7f$0$4867$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #31254 |
In article <dfednaNwZ7fK5A_OnZ2dnUVZ_r2dnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: >On 6/6/14 11:31 AM, rickman wrote: >> I don't think the MSP430 is significantly lower power than other, >> similar devices. That depends entirely on what is being done on the >> chip. Typically the power can be estimated as a uA/MHz rating and the >> last time I checked was in the 250 uA/MHz region for many comparable >> CPUs although it might be as low as 100 uA/MHz these days. Hmmm, 100 uA >> is the rating for a built in pullup in a custom chip someone was >> discussing in another thread, lol. > >SwiftX makes use of its facility to go to low power mode and recover >easily by making the multitasker automatically go to low power mode when >no tasks are active. An interrupt that wakes a task will reactivate the >part. As a result, we often achieve duty cycles in the microseconds, for >overall extremely low power consumption. We haven't seen any other parts >(that I know of -- I may not be entirely current) that make this so easy. Moreover, if you have a low demand application, you can run the chip from the 32 khz crystal 250 uA/Mh equals 250 na/Khz. > >Cheers, >Elizabeth -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-06-07 11:40 -0700 |
| Message-ID | <1c056bb3-48db-46ed-ad6b-52d960dd4599@googlegroups.com> |
| In reply to | #31252 |
On Friday, June 6, 2014 5:31:33 PM UTC-4, rickman wrote: > I don't think the MSP430 is significantly lower power than other, > similar devices. TI started the MSP430 in the late eighties. Back then you needed a power supply able to deliver 1 Amp to feed a microprocessor. Three years ago, when I started to develop a battery supported gadget, I had chosen a Z8encore at first, because the Z8encore has everything what I needed on chip. I even ordered a Forth for this part from MPE. Then I looked for a suitable battery and discovered that a wearable battery will last only a few hours with this chip. I should have done this first. Then I looked at all microprocessors for low current (every year there is a comparing list at one of these electronic magazines), and TI was the only one, claiming one tenth of current needed compared to the next lowest current micro. Meanwhile there is Silicon Labs claiming to need the lowest current, using the same arguments TI is using since more than twenty years. Silicon Labs bought 'Gecko' to achieve this. Cheers, Dirk.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-07 20:01 -0400 |
| Message-ID | <ln0953$d0v$1@dont-email.me> |
| In reply to | #31277 |
On 6/7/2014 2:40 PM, visualforth@rocketmail.com wrote: > On Friday, June 6, 2014 5:31:33 PM UTC-4, rickman wrote: >> I don't think the MSP430 is significantly lower power than other, >> similar devices. > > TI started the MSP430 in the late eighties. > Back then you needed a power supply able to deliver 1 Amp to feed a microprocessor. > > Three years ago, when I started to develop a battery supported gadget, I had chosen a Z8encore at first, because the Z8encore has everything what I needed on chip. I even ordered a Forth for this part from MPE. > > Then I looked for a suitable battery and discovered that a wearable battery will last only a few hours with this chip. I should have done this first. > > Then I looked at all microprocessors for low current (every year there is a comparing list at one of these electronic magazines), and TI was the only one, claiming one tenth of current needed compared to the next lowest current micro. > > Meanwhile there is Silicon Labs claiming to need the lowest current, using the same arguments TI is using since more than twenty years. > Silicon Labs bought 'Gecko' to achieve this. I can't explain what you found. I also can't explain the idea that any manufacturer would have a 10x better power consumption than all the other MCU makers. They all use very similar processes, they all have similar architectures and they all have very similar power saving features. It is very rare for any of the MCUs to stand out in a significant way. That said, I have not looked at the power consumption of many MCUs lately. Doing a quick search I see a lot about power from Renesas. They are claiming 30 uA/MHz in the RX610 line with 1.65MIPS/MHz. That is impressive. Is the MSP430 10x better than that? I'd like to see the info that says this. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-06-08 16:05 -0700 |
| Message-ID | <9de74256-48ac-4b74-89b1-e93e7c5550e0@googlegroups.com> |
| In reply to | #31287 |
On Saturday, June 7, 2014 8:01:45 PM UTC-4, rickman wrote: > On 6/7/2014 2:40 PM, visualforth.com wrote: > > > On Friday, June 6, 2014 5:31:33 PM UTC-4, rickman wrote: > > >> I don't think the MSP430 is significantly lower power than other, > > >> similar devices. > > > > > > TI started the MSP430 in the late eighties. > > > Back then you needed a power supply able to deliver 1 Amp to feed a microprocessor. > > > > > > Three years ago, when I started to develop a battery supported gadget, I had chosen a Z8encore at first, because the Z8encore has everything what I needed on chip. I even ordered a Forth for this part from MPE. > > > > > > Then I looked for a suitable battery and discovered that a wearable battery will last only a few hours with this chip. I should have done this first. > > > > > > Then I looked at all microprocessors for low current (every year there is a comparing list at one of these electronic magazines), and TI was the only one, claiming one tenth of current needed compared to the next lowest current micro. > > > > > > Meanwhile there is Silicon Labs claiming to need the lowest current, using the same arguments TI is using since more than twenty years. > > > Silicon Labs bought 'Gecko' to achieve this. > > > > I can't explain what you found. I also can't explain the idea that any > > manufacturer would have a 10x better power consumption than all the > > other MCU makers. They all use very similar processes, they all have > > similar architectures and they all have very similar power saving > > features. It is very rare for any of the MCUs to stand out in a > > significant way. > > > > That said, I have not looked at the power consumption of many MCUs > > lately. Doing a quick search I see a lot about power from Renesas. > > They are claiming 30 uA/MHz in the RX610 line with 1.65MIPS/MHz. That > > is impressive. Is the MSP430 10x better than that? I'd like to see the > > info that says this. > > > > -- > > > > Rick Rick, My information is three years old, and in my opinion TI was the trailblazer. I visited a TI MSP430 seminar in the nineties back in Nuremberg, Germany. The MSP430 has been developed nearby in Freising. Remember the discussion about global warming? There are people still thinking that's a hoax. Same with low power consumption. Do you know that Intel micros have been the most power hungry ones? They didn't care TI is the trailblazer for low power, and others tried hard to follow, but not everybody did. The United States people don't care about power consumption, electricity is cheap in this country. You can compare this with the fight of car makers to make low energy cars. The fight is still ongoing, these manufacturers don't like highly fuel efficient motors. Only in recent years they are working on concept cars driven by electrical motors. Looking at car manufacturers it should be easy to transfer this attitude to microprocessor manufacturers. I did a research for you. Wasn't easy. But this I found: TI MSP430 has the lowest power consumption. In sleep mode, 0.3 µW = 3 V * 0.1 µA. Some chips in 2xx and 4xx series include 12-bit DACs. The Cypress PSoC has more than one true analog output. Using sleep mode, power consumption as low as 21 µW = 5 V * 4.2 µA Source: http://en.wikibooks.org/wiki/Embedded_Systems/Particular_Microprocessors#brief_selection_guide This comparison shows that the Cypress needs seventy (70) times as much energy than the TI MSP. If you look further, you will find similar differences with other microprocessors.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-08 22:28 -0400 |
| Message-ID | <ln364v$r9o$1@dont-email.me> |
| In reply to | #31302 |
On 6/8/2014 7:05 PM, visualforth@rocketmail.com wrote: > Rick, > > My information is three years old, and in my opinion TI was the trailblazer. > I visited a TI MSP430 seminar in the nineties back in Nuremberg, Germany. The MSP430 has been developed nearby in Freising. Being "trailblazer" doesn't automatically mean we should use the TI part. The question was are they significantly lower power than other devices and I still don't think that is really true. BTW, MCU makers were worrying about power consumption a lot earlier than 3 years ago. > Remember the discussion about global warming? > There are people still thinking that's a hoax. Sure, there are people who think the world is flat and no one went to the moon. Not relevant. > Same with low power consumption. ??? Low power consumption is important in handheld, battery powered devices, by definition. > Do you know that Intel micros have been the most power hungry ones? They didn't care > > TI is the trailblazer for low power, and others tried hard to follow, but not everybody did. The United States people don't care about power consumption, electricity is cheap in this country. I think you are mistaken about both that others couldn't duplicate TI's efforts. I was in a job some 8 years ago and all the MCU makers were big on low power. They all had parts with pretty good numbers. Some were lower than others, but usually because they didn't run as fast. > You can compare this with the fight of car makers to make low energy cars. > The fight is still ongoing, these manufacturers don't like highly fuel efficient motors. Only in recent years they are working on concept cars driven by electrical motors. Auto maker's don't dislike electric motors, they don't like the realllllly long power cord trailing behind the car, lol. The problem with electric cars is the lack of reasonable range. That means most people don't want to drive them. Why build cars you can't make much money on? So each one has at least one model and they are very high priced, so few people buy them. > Looking at car manufacturers it should be easy to transfer this attitude to microprocessor manufacturers. > > I did a research for you. Wasn't easy. But this I found: > > TI MSP430 has the lowest power consumption. In sleep mode, 0.3 µW = 3 V * 0.1 µA. Some chips in 2xx and 4xx series include 12-bit DACs. > The Cypress PSoC has more than one true analog output. Using sleep mode, power consumption as low as 21 µW = 5 V * 4.2 µA > Source: http://en.wikibooks.org/wiki/Embedded_Systems/Particular_Microprocessors#brief_selection_guide Power consumption is complicated. Sleep mode power consumption is only useful to know if you will be putting the processor to sleep most of the time. Even then the exact sleep current is only important if it is in sleep mode well over 99.9% of the time. Then you still need a way to wake it back up, so the power consumption of that circuit is also important. Knowing that the sleep mode current of one of the MSP430 processors is 0.1 uA is not really important info. Remember, in sleep mode the processor is doing nothing. I have chips in my desk drawer that are drawing 0.0 uA of current while doing nothing. If you want to compare power you need to consider the running current, the sleep current, the time it takes to switch on the clocks before you can even start up the processor and the proportion each of these is to the total time. Only then can you compare different processors. BTW, I would never go to a third party for info on any processor. I would never use a wiki for any important data. > This comparison shows that the Cypress needs seventy (70) times as much energy than the TI MSP. If you look further, you will find similar differences with other microprocessors. Here is a better comparison... TI MSP430FR5847 Active mode current 2.5 mA at 8 MHz with 0 wait states Low power mode 3 current 0.6 PSOC CY8C5265LTI-LP050 Active mode current 2.0 mA at 6 MHz, 3.2 mA at 12 MHz with 0 wait states Deep sleep mode current 2.5 uA So you can see that these two specific chips are similar and there is not a 10x difference in power consumption according to the data sheets. I used the PSOC because that was one you had used. I think if you compared the MSP430 to the AVR or many other MCUs designed for low power you will find there are not large differences. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Gary Bergstrom <forthprgrmr@gmail.com> |
|---|---|
| Date | 2014-06-08 20:36 -0700 |
| Message-ID | <caa0b854-a4d2-43fd-bf80-cd895d913968@googlegroups.com> |
| In reply to | #31306 |
I'm getting tired of this. Yes, computing current consumption in a system (not just specs at one freq, temp, voltage, etc) is not for the faint of heart. One could write a book about how to do it correctly. Yes, TI has been a leader. This means that picking their parts will probably put you at or near the front of low power operation. And since they have so much experience, their parts are mature and techniques are well known. But.... Yes, other are catching them and maybe even passed them. Maybe. And Cortex parts are 32 bits - a big advantage if doing calculations of more than 16 bits. Not so much an advantage doing bit twiddling. And M0 parts are impressively inexpensive. But this arguing is tedious. Popping marketing numbers, out of context (the context is a running system), is useless. Stop it. Design a system. Tell us how well it works, or doesn't. Gary
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-06-08 21:38 -0700 |
| Message-ID | <37189aaf-cb0f-45d9-b4ae-23ac3778c908@googlegroups.com> |
| In reply to | #31306 |
On Sunday, June 8, 2014 10:28:52 PM UTC-4, rickman wrote: > I was in a job some 8 years ago and all the MCU makers were > big on low power. They all had parts with pretty good numbers. Some > were lower than others, but usually because they didn't run as fast. > Power consumption is complicated. Sleep mode power consumption is only > useful to know if you will be putting the processor to sleep most of the > time. Even then the exact sleep current is only important if it is in > sleep mode well over 99.9% of the time. Then you still need a way to > wake it back up, so the power consumption of that circuit is also > important. Thanks for your professional review. I am glad to read that you are the expert - I am not an expert. I get my knowledge from the projects I am working on and from manufacturers datasheets. > Here is a better comparison... > TI MSP430FR5847 > Active mode current 2.5 mA at 8 MHz with 0 wait states > Low power mode 3 current 0.6 I don't know where you got these numbers. I have the feeling that I am living in a different universe. Here a copy of the datasheet which I just got: Optimized Ultra-Low-Power Modes – Active Mode: Approximately 100 μA/MHz – Standby (LPM3 With VLO): 0.4 μA (Typical) – Shutdown (LPM4.5): 0.02 μA (Typical) My calculator tells me that 100 μA/MHz are 800 μA @ 8MHz. I got the datasheet from http://www.ti.com/lit/ds/symlink/msp430fr5847.pdf May be you measured the currents by yourself on a atypical MSP430FR5847 ? > PSOC CY8C5265LTI-LP050 > Active mode current 2.0 mA at 6 MHz, 3.2 mA at 12 MHz with 0 wait states > Deep sleep mode current 2.5 uA > > So you can see that these two specific chips are similar and there is > not a 10x difference in power consumption according to the data sheets. Assuming your PSOC numbers are real, you are right: There is not a factor 10, but a factor of 3.33 @ 6 MHz and 2.67 @ 12 MHz in the active mode and a factor of 125 in Deep sleep mode. > I used the PSOC because that was one you had used. I didn't use the PSOC - the PSOC accidentally, for whatever reason, showed up at http://en.wikibooks.org/wiki/Embedded_Systems/Particular_Microprocessors#brief_selection_guide > I think if you > compared the MSP430 to the AVR or many other MCUs designed for low power > you will find there are not large differences. Rick, I don't have the time to make all these comparisons which you like to have. The only chance to get the right picture is that somebody, not as emotionally involved as we are, will do a comparison. The only problem then is that this would be a third party report, and you would never go to a third party for info on any processor. That's called deadlock, because microprocessor manufacturers normally won't compare their parts with microprocessors of other manufacturers. TI did it. But this would be a third party report, too. Sorry, this problem is unresolvable. First time in my life. Sorry that I have to confess this.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-09 14:36 -0400 |
| Message-ID | <ln4uqb$h9k$1@dont-email.me> |
| In reply to | #31312 |
On 6/9/2014 12:38 AM, visualforth@rocketmail.com wrote: > On Sunday, June 8, 2014 10:28:52 PM UTC-4, rickman wrote: >> I was in a job some 8 years ago and all the MCU makers were >> big on low power. They all had parts with pretty good numbers. Some >> were lower than others, but usually because they didn't run as fast. > >> Power consumption is complicated. Sleep mode power consumption is only >> useful to know if you will be putting the processor to sleep most of the >> time. Even then the exact sleep current is only important if it is in >> sleep mode well over 99.9% of the time. Then you still need a way to >> wake it back up, so the power consumption of that circuit is also >> important. > > Thanks for your professional review. I am glad to read that you are the expert - I am not an expert. I get my knowledge from the projects I am working on and from manufacturers datasheets. > >> Here is a better comparison... >> TI MSP430FR5847 >> Active mode current 2.5 mA at 8 MHz with 0 wait states >> Low power mode 3 current 0.6 > > I don't know where you got these numbers. I have the feeling that I am living in a different universe. Here a copy of the datasheet which I just got: > > Optimized Ultra-Low-Power Modes > – Active Mode: Approximately 100 μA/MHz > – Standby (LPM3 With VLO): 0.4 μA (Typical) > – Shutdown (LPM4.5): 0.02 μA (Typical) > > My calculator tells me that 100 μA/MHz are 800 μA @ 8MHz. I got the datasheet from http://www.ti.com/lit/ds/symlink/msp430fr5847.pdf > > May be you measured the currents by yourself on a atypical MSP430FR5847 ? No, I looked at the data tables rather than the marketing section. Go to page 19, "Active Mode Supply Current Into VCC Excluding External Current". The figure they are quoting in the marketing section is likely derived from the figures for a 75% cache hit rate. When running Forth I believe this would be an extremely optimistic ratio, especially with the tiny cache in use. Even if you use the much more favorable number, the point is the parts are comparable, not 10x different. The PSOC is just one device and may not be a good representation of the selection available. >> PSOC CY8C5265LTI-LP050 >> Active mode current 2.0 mA at 6 MHz, 3.2 mA at 12 MHz with 0 wait states >> Deep sleep mode current 2.5 uA >> >> So you can see that these two specific chips are similar and there is >> not a 10x difference in power consumption according to the data sheets. > > Assuming your PSOC numbers are real, you are right: > There is not a factor 10, but a factor of 3.33 @ 6 MHz and 2.67 @ 12 MHz in the active mode and a factor of 125 in Deep sleep mode. 125? 2.5/0.6 is about 4. The 3.3 ratio is not real either. Marketing will always cherry pick numbers. Read the data sheet and do your own analysis. If you really want to compare power consumption you need an example which includes the duty cycle and the rate of switching between modes. I think I mentioned before that the MCU wastes power in the transition between sleep and active modes waiting for the oscillator to start up. >> I used the PSOC because that was one you had used. > > I didn't use the PSOC - the PSOC accidentally, for whatever reason, showed up at http://en.wikibooks.org/wiki/Embedded_Systems/Particular_Microprocessors#brief_selection_guide > >> I think if you >> compared the MSP430 to the AVR or many other MCUs designed for low power >> you will find there are not large differences. > > Rick, I don't have the time to make all these comparisons which you like to have. The only chance to get the right picture is that somebody, not as emotionally involved as we are, will do a comparison. > > The only problem then is that this would be a third party report, and you would never go to a third party for info on any processor. That's called deadlock, because microprocessor manufacturers normally won't compare their parts with microprocessors of other manufacturers. TI did it. But this would be a third party report, too. > > Sorry, this problem is unresolvable. First time in my life. Sorry that I have to confess this. I can't say I understand what you are saying here. My only point is that for the stamp we are talking about there is no real need to go as low power as humanly possible. There are many low power MCUs available (with differences much less than 10x) so that unless we have a specific goal in mind (which must be evaluated against the way the device is used, not an arbitrary data sheet comparison) there is no point in focusing on power consumption as a discriminator in choosing a processor. In fact, so far I have not read a clear rational for building hardware at all. One person pointed out that the LaunchPad is limited to a max data rate of 9600 bps. I can't see that as a significant problem with the educational goal we have in mind. So why does new hardware need to be designed? The LaunchPad is ready to go, $10 price tag, existing docs and user base. What more could you want? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-06-09 02:45 -0700 |
| Message-ID | <af2b6b25-f8c5-4dbc-87b3-5bcf1b8e9d79@googlegroups.com> |
| In reply to | #31306 |
On Monday, 9 June 2014 03:28:52 UTC+1, rickman wrote: > Being "trailblazer" doesn't automatically mean we should use the TI > part. The question was are they significantly lower power than other > devices and I still don't think that is really true. BTW, MCU makers > were worrying about power consumption a lot earlier than 3 years ago. > In the context of an educational system who's purpose is to provide an easy and fun way to learn Forth, neither being a trailblazer or having significantly lower power than a competitor is or important. However, TI have an excellent reputation for supporting hobbyists and developers for the MSP430. They actively encourage experimentation with their parts, and give literally thousands of them away for free as samples every month. I do think that is relevant. Also, the MSP430 is now a very popular chip. As a skill set, exposure to a particular MSP430 family is valuable in and of itself. That is also relevant. That one may be using Forth to develop code on it is not relevant in terms of experience of the chip, in the same way that using C or C++ to develop code on for the MSP430 is not relevant in terms of exposure to the *chip*. > ??? Low power consumption is important in handheld, battery powered > devices, by definition. Yes it is. But it's not particularly important for an education tool. This thing would probably run for a couple of weeks on a couple of AA batteries. What's the point of even thinking about it? > > Power consumption is complicated. Sleep mode power consumption is only > useful to know if you will be putting the processor to sleep most of the > time. This is a somewhat old-fashioned view IMO. In many embedded products, where there is no requirement to poll something every few micro-seconds, you *will* put the processor to sleep. It would be stupid not to. >Even then the exact sleep current is only important if it is in > sleep mode well over 99.9% of the time. Not at all. Why 99.9% of the time? Is that an arbitrary figure selected by you? I suspect that it is. If you are able to achieve a 50/50 duty-cycle between sleep mode and active mode, why is that not "important" (to use your word). Why is that not a significant improvement in power consumption? Why is that not an important design "win"? > Then you still need a way to > wake it back up, so the power consumption of that circuit is also > important. No it isn't. It's entirely irrelevant to the power budget of the MCU. How can TI, or any other MCU give a figure in their data sheets for a circuit that doesn't exist? They can only report on what the requirements are for their part. So external circuitry is entirely irrelevant. > Knowing that the sleep mode current of one of the MSP430 processors is > 0.1 uA is not really important info. I disagree. See my argument above. If you are designing a clock and you can put the chip to sleep for 990 milliseconds of a second per-second, that is a HUGE design win. That's precisely what the MSP430 is aimed at. Have you seen their digital watch based on an MSP430? Did you know that, depending on the mode (if you're not using the accelerometers etc) then chip spends something like 80% of the duty-cycle sleeping? > Remember, in sleep mode the > processor is doing nothing. Not true. It is waiting. That is not doing nothing. There's a very important distinction between waiting and doing nothing: If you're doing nothing, then you're not waiting. > I have chips in my desk drawer that are > drawing 0.0 uA of current while doing nothing. But they're not waiting for anything either, are they? > If you want to compare > power you need to consider the running current, the sleep current, the > time it takes to switch on the clocks before you can even start up the > processor and the proportion each of these is to the total time. Only > then can you compare different processors. On the MSP430 you don't have to worry about switching on clocks and the like. They're all in the chip. That's another important "thing" about the MSP430 that is proving very popular indeed: It requires very little (if any?) support circuitry. Perhaps just a crystal (but, if I remember correctly, you don't always need an external crystal, depending on the part). Please have a look here: http://www.youtube.com/watch?v=Db6TWl5FSGw Or, for even better illustration of how much circuitry you *don't* need, have a look here: http://www.youtube.com/watch?v=K_7Xxq4B2rg On this second video, the only "support" circuitry required is a resistor. > > BTW, I would never go to a third party for info on any processor. I > would never use a wiki for any important data. > Fully agree. It has to be the datasheets. I found this datasheet from TI that looks quite informative: http://www.ti.com/lit/ds/symlink/msp430fr5949.pdf Though a lot of it is gobbledy-gook to a software hack like me. See section 5.5 for an interesting graph of power consumption in active mode. Section 5.6 details sleep mode. Note, this datasheet *is* for the 5949.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-06-09 03:18 -0700 |
| Message-ID | <29b01d68-cd10-4fd2-813a-e5ba143ca4dc@googlegroups.com> |
| In reply to | #31319 |
Now you've got me watching MSP430 videos! Here's a MSP430 driving an LCD panel for three weeks with two 220uF super-capacitors: http://www.youtube.com/watch?v=xbjpQmjwMyU
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-06-09 15:57 -0400 |
| Message-ID | <ln53j0$mtt$1@dont-email.me> |
| In reply to | #31319 |
On 6/9/2014 5:45 AM, Mark Wills wrote: > On Monday, 9 June 2014 03:28:52 UTC+1, rickman wrote: >> Even then the exact sleep current is only important if it is in >> sleep mode well over 99.9% of the time. > > Not at all. Why 99.9% of the time? Is that an arbitrary figure > selected by you? I suspect that it is. If you are able to achieve > a 50/50 duty-cycle between sleep mode and active mode, why is that > not "important" (to use your word). Why is that not a significant > improvement in power consumption? Why is that not an important > design "win"? That number reflects the ratio of power consumption between the two modes. That ratio is well over 1000:1, so 1 part in 1000 is 99.9%. If the power of the sleep mode is not a noticeable portion of the total power, then I don't care how much it is. It can double or triple and it won't impact the total power significantly. >> Then you still need a way to >> wake it back up, so the power consumption of that circuit is also >> important. > > No it isn't. It's entirely irrelevant to the power budget of the > MCU. How can TI, or any other MCU give a figure in their data > sheets for a circuit that doesn't exist? They can only report > on what the requirements are for their part. So external circuitry > is entirely irrelevant. I'm not asking TI to include my circuits in their data sheets. If you want to look at power consumption you can't just look at the MCU. What good is an MCU that can't wake up? >> Knowing that the sleep mode current of one of the MSP430 processors is >> 0.1 uA is not really important info. > > I disagree. See my argument above. If you are designing a clock > and you can put the chip to sleep for 990 milliseconds of a second > per-second, that is a HUGE design win. That's precisely what the > MSP430 is aimed at. Have you seen their digital watch based on an > MSP430? Did you know that, depending on the mode (if you're not > using the accelerometers etc) then chip spends something like 80% > of the duty-cycle sleeping? See above. >> Remember, in sleep mode the >> processor is doing nothing. > > Not true. It is waiting. That is not doing nothing. There's a > very important distinction between waiting and doing nothing: If > you're doing nothing, then you're not waiting. Waiting is NOOP, do nothing. If you are going to argue for the sake of arguing we can end this now. >> I have chips in my desk drawer that are >> drawing 0.0 uA of current while doing nothing. > > But they're not waiting for anything either, are they? If you want to be silly, they are waiting for me to plug them into a working circuit. >> If you want to compare >> power you need to consider the running current, the sleep current, the >> time it takes to switch on the clocks before you can even start up the >> processor and the proportion each of these is to the total time. Only >> then can you compare different processors. > > On the MSP430 you don't have to worry about switching on clocks > and the like. They're all in the chip. That's another important > "thing" about the MSP430 that is proving very popular indeed: > It requires very little (if any?) support circuitry. Perhaps > just a crystal (but, if I remember correctly, you don't always > need an external crystal, depending on the part). > Please have a look here: > > http://www.youtube.com/watch?v=Db6TWl5FSGw > > Or, for even better illustration of how much circuitry you *don't* > need, have a look here: > > http://www.youtube.com/watch?v=K_7Xxq4B2rg > > On this second video, the only "support" circuitry required is a > resistor. What clocks you need depends on your app. Not all uses will work with a 2% accurate timing source. Even then, the clocks on the chip require time to start up, all clocks do. See page 32 of the data sheet... http://www.ti.com/lit/ds/symlink/msp430fr5847.pdf Wake up times range up to 350 uS, no short time. They list the wake up electrical specs as charge since they don't know the voltage you will be using. The deeper sleep modes require about 77 nAs to wake up. At a 1 ms rate this is 77 uA. At 3.0 volts Vcc that is about 230 uW, no small power even using the internal clocks. If your app wakes once per second then it is a much smaller 230 nW. >> BTW, I would never go to a third party for info on any processor. I >> would never use a wiki for any important data. >> > Fully agree. It has to be the datasheets. > > I found this datasheet from TI that looks quite informative: > http://www.ti.com/lit/ds/symlink/msp430fr5949.pdf > > Though a lot of it is gobbledy-gook to a software hack like me. > See section 5.5 for an interesting graph of power consumption in > active mode. Section 5.6 details sleep mode. Note, this datasheet > *is* for the 5949. I have to say the power sections I have looked at are great! I've never seen so much clear info on an MCU before. Actually, the interesting graph is 5.7 and 5.8. This shows the low power mode current plus the wake up current (not including the active current which depends on your app). Looks the same as my figures above, 77 uA at 1 ms (1 kHz). Notice the LPM3.5 curve ends around 2000 Hz. That is because you are getting close to the point where all the time is spent waiting for the clock to start. I was working with an Atmel part once and they didn't spec the ESR and other parameters for the crystal. I said something about this to the FAE and he contacted the factory. Lo and behold they put info in the data sheet for the ESR. But this is a function of frequency and they added a table with four points. What about the frequencies between those points? lol I think TI is doing a little better. BTW, they use the same data sheet for the MSP430FR5869, MSP430FR5868, MSP430FR5867, MSP430FR58671, MSP430FR5859, MSP430FR5858, MSP430FR5857, MSP430FR5849, MSP430FR5848, MSP430FR5847, MSP430FR58471. SLASE34 – MAY 2014 -- Rick
[toc] | [prev] | [next] | [standalone]
| From | visualforth@rocketmail.com |
|---|---|
| Date | 2014-06-08 16:20 -0700 |
| Message-ID | <0c492257-32b4-4e45-b279-3eb697ae42a4@googlegroups.com> |
| In reply to | #31287 |
On Saturday, June 7, 2014 8:01:45 PM UTC-4, rickman wrote: > Doing a quick search I see a lot about power from Renesas. > They are claiming 30 uA/MHz in the RX610 line with 1.65MIPS/MHz. That > is impressive. Is the MSP430 10x better than that? I'd like to see the > info that says this. I don't know where you got this data. It's a pity that you hide your resources. I googled for the RX610 and found the following: Operating frequency 8 to 100 MHz Power supply voltage VCC = PLLVCC = AVCC = 3.0 to 3.6V, VREFH = 3.0 to AVCC Supply current 50 mA (typ.) (regular specifications) Source: RX610 Group Datasheet http://www.renesas.com/products/mpumcu/rx/rx600/rx610/Documentation.jsp
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web