Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

OT: New TI MSP430 Ultra Low Power Chip

Back to article view | Back to comp.lang.forth

Contents

  OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-06-27 03:35 -0700
    Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-28 09:29 -0700
      Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-28 21:19 -0400
        Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-28 20:57 -0700
          Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-06-28 22:26 -0700
            Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-28 22:33 -0700
              Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <bruce.mcfarling@gmail.com> - 2014-06-29 07:44 -0700
              Re: OT: New TI MSP430 Ultra Low Power Chip stephenXXX@mpeforth.com (Stephen Pelc) - 2014-06-29 14:53 +0000
                Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-06-29 09:04 -0700
      Re: OT: New TI MSP430 Ultra Low Power Chip albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-29 10:00 +0000
        Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-29 19:16 -0700
          Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 16:58 -0400
            Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 14:43 -0700
              Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 17:55 -0400
                Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 15:34 -0700
                  Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 19:09 -0400
                    Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 19:13 -0400
                    Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 17:52 -0700
                      Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-06-30 22:20 -0400
                        Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-06-30 22:10 -0700
                          Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-01 04:42 -0400
                            Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-01 07:55 -0700
                          Re: OT: New TI MSP430 Ultra Low Power Chip Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-01 17:19 +0200
    Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-06-29 19:49 -0700
      Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-06-30 01:38 -0700
        Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-06-30 07:22 -0700
        Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-06-30 15:29 -0700
          Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-01 01:51 -0700
            Re: OT: New TI MSP430 Ultra Low Power Chip Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-07-01 10:26 -0500
            Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-01 11:08 -0700
              Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-01 12:59 -0700
            Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-01 15:02 -0400
              Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-01 13:02 -0700
                Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-01 17:25 -0700
                  Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-01 20:44 -0700
                    Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-02 12:11 -0400
                      Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-02 10:19 -0700
                        Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-02 15:30 -0400
                          Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-02 19:25 -0700
                            Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-03 00:28 -0400
                              Re: OT: New TI MSP430 Ultra Low Power Chip BruceMcF <agila61@netscape.net> - 2014-07-03 00:25 -0700
                                Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-03 02:17 -0700
                                  Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-03 09:31 -0700
                                Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-03 14:23 -0700
                                  Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-03 17:53 -0400
                                    Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-03 15:25 -0700
                                      Re: OT: New TI MSP430 Ultra Low Power Chip rickman <gnuarm@gmail.com> - 2014-07-03 19:53 -0400
                                        Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-03 17:38 -0700
                                          Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-03 18:21 -0700
                    Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-04 19:14 -0700
                      Re: OT: New TI MSP430 Ultra Low Power Chip bruce.mcfarling@gmail.com - 2014-07-04 22:52 -0700
                      Re: OT: New TI MSP430 Ultra Low Power Chip "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-05 02:21 -0400
              Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-02 01:04 -0700
                Re: OT: New TI MSP430 Ultra Low Power Chip albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-02 11:59 +0000
              Re: OT: New TI MSP430 Ultra Low Power Chip m.a.m.hendrix@tue.nl - 2014-07-04 01:29 -0700
                Re: OT: New TI MSP430 Ultra Low Power Chip Mark Wills <markwills1970@gmail.com> - 2014-07-04 04:17 -0700
                Re: OT: New TI MSP430 Ultra Low Power Chip "Elizabeth D. Rather" <erather@forth.com> - 2014-07-04 09:01 -1000
                  Re: OT: New TI MSP430 Ultra Low Power Chip mhx@iae.nl - 2014-07-04 22:51 -0700
                    Re: OT: New TI MSP430 Ultra Low Power Chip Paul Rubin <no.email@nospam.invalid> - 2014-07-04 23:05 -0700
                      Re: OT: New TI MSP430 Ultra Low Power Chip mhx@iae.nl - 2014-07-05 00:54 -0700
                  Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-06 17:00 -0700
                    Re: OT: New TI MSP430 Ultra Low Power Chip albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-07-07 11:00 +0000
                Re: OT: New TI MSP430 Ultra Low Power Chip hughaguilar96@yahoo.com - 2014-07-04 18:54 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#32094

On 7/1/2014 1:10 AM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>>> slightly larger 8 pin package.  There is a CSP-package Cortex M4 part
>>> with something like 128KB of ram after all.
>> I don't understand.  That's what the WCSP is.  No lead frame, just a die.
>
> What I mean is that there's a very small M4 WCSP and that makes me
> expect that the die itself is small, and they could put it into a small
> leaded package if only they didn't insist on supplying so many pins.
> But, maybe I'm wrong.

It depends on what you mean by "small".  Look at the image on the page I 
gave a link for.  If the chip is a 4 mm sq CSP it would likely not fit 
in anything smaller than a TSSOP leaded package which I believe has a 6 
mm wide body.


>> I had the impression you liked the CSP packages, but I guess not.
>
> I don't see a matter of like or dislike.  CSP sounds like a great idea
> for making stuff tiny in respectable quantities, but using CSP parts
> unfortunately seems beyond the capabilities of the small-quantity ghetto
> PCB fabs and assembly processes that I can afford to use.
>
>> If you can use the outer 12 pins only, I expect you can use this part
>> without a lot of expense.
>
> Oh that's interesting, I wonder if it's designed so that the important
> stuff is on the outer pins.  I'll check the data sheet.

That is not an unusual trick for FPGAs where they shove pins at you like 
they were free and it can take 6 layers or more to get all the pins 
routed to the outside of the footprint.  If you aren't using them all, 
just route the ones you need from the inner and outer edges and if 
ground and power are not convenient route them through unused pads.  You 
can get about half the pins from a large BGA routed without needing the 
tiny via sizes.

-- 

Rick

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

#32096

rickman <gnuarm@gmail.com> writes:
> If the chip is a 4 mm sq CSP it would likely not fit in anything
> smaller than a TSSOP leaded package which I believe has a 6 mm wide body.

Hmm, ok, I guess the die is bigger than I thought, and wonder if it's
to accomodate the large number of CSP pins.  FRAM may also use more area
per cell than flash.  Freescale has a line of CSP parts:
http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=KINETIS_MINI_SERIES
They mention the solder balls are directly on the chip without
interposers:
 http://cache.freescale.com/files/analog/doc/app_note/AN3846.pdf

Some of them are pretty small despite being 32-bit cpus with lots of
resources compared to the MSP430's.  They also have small QFN packages
though I don't know how difficult those are to use (any advice would be
appreciated). 

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

#32097

Paul Rubin wrote:

> rickman <gnuarm@gmail.com> writes:
>>> slightly larger 8 pin package.  There is a CSP-package Cortex M4 part
>>> with something like 128KB of ram after all.
>> I don't understand.  That's what the WCSP is.  No lead frame, just a die.
> 
> What I mean is that there's a very small M4 WCSP and that makes me
> expect that the die itself is small, and they could put it into a small
> leaded package if only they didn't insist on supplying so many pins.
> But, maybe I'm wrong.

CSP means "chip scale package". It really is just the chip, some lead balls 
on top of it (the top side is where the logic is, it's then upside down on 
the board), and some black coating to avoid light getting on the chip.  
That's all.  A CSP package is a chip directly put on a board, without bond 
wires and such.

>> I had the impression you liked the CSP packages, but I guess not.
> 
> I don't see a matter of like or dislike.  CSP sounds like a great idea
> for making stuff tiny in respectable quantities, but using CSP parts
> unfortunately seems beyond the capabilities of the small-quantity ghetto
> PCB fabs and assembly processes that I can afford to use.

Yes.  It becomes harder with the parts becoming smaller.

>> If you can use the outer 12 pins only, I expect you can use this part
>> without a lot of expense.
> 
> Oh that's interesting, I wonder if it's designed so that the important
> stuff is on the outer pins.  I'll check the data sheet.

Quite unlikely.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#32063

On Friday, June 27, 2014 3:35:15 AM UTC-7, Mark Wills wrote:
> MSP430FR6989 16 MHz Ultra-Low-Power Microcontroller featuring 128 KB FRAM, 2KB SRAM, 75 IO, LCD.

When are you going to port your TurboForth over to the MSP430? 

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

#32067

On Monday, 30 June 2014 03:49:38 UTC+1, hughag...@yahoo.com  wrote:
 
> When are you going to port your TurboForth over to the MSP430?

I think there's enough versions on the MSP430 already. MPE has 
one, Forth Inc. has one, and there are a number of others. 
I don't see what I could bring to the party, to be honest. If 
I were to do a version of Forth for the MSP430 it would be a
very straight-forward subroutine threaded system, with code and 
data mixed (taking full advantage of the freedom that the FRAM 
gives you).

I'm waiting for some PCBs that I ordered to arrive, then I can 
solder the MSP430FR5949 that I have as a free sample from to it 
and maybe start hacking.

I need to get my head around the BSL (bootstrap loader) and/or 
JTAG as a means of getting some code into the chip. Haven't 
looked too deeply into it yet - too many other irons (mostly 
guitar/music related) in the fire!

The 128K FRAM MSP430 is probably over-kill for the kind of thing
that I would use one for. I'm thinking about reading instruments
(possibly over a CAN or SPI bus) and making them available via
MODBUS RTU as a MODBUS slave. That kind of thing.

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

#32072

On Monday, June 30, 2014 4:38:21 AM UTC-4, Mark Wills wrote:

> I think there's enough versions on the MSP430 already. MPE has 
> one, Forth Inc. has one, and there are a number of others.

Among tinkerer systems, I saw that there's a Camel Forth for MP430.
 
> I need to get my head around the BSL (bootstrap loader) and/or  
> JTAG as a means of getting some code into the chip. Haven't 
> looked too deeply into it yet - too many other irons (mostly 
> guitar/music related) in the fire!

Like I said, the idea of loading a permanent store image over a serial link is one of the two things that caught my eye ~ it would be great for a low overhead spin up to using the chip, which is especially important in agrarian areas of low income nations ~ but I didn't dig enough to find out what is the time-overhead.

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

#32083

On Monday, June 30, 2014 1:38:21 AM UTC-7, Mark Wills wrote:
> On Monday, 30 June 2014 03:49:38 UTC+1, hughag...@yahoo.com  wrote:
> 
> > When are you going to port your TurboForth over to the MSP430?
> 
> I think there's enough versions on the MSP430 already. MPE has 
> one, Forth Inc. has one, and there are a number of others. 
> I don't see what I could bring to the party, to be honest. 

Support. A well-written manual. Enthusiasm. Etc...

I still think the MSP-430 would be a good choice for controlling irrigation. Focus on a specific application area like this, that a lot of people are interested in, and provide libraries of related code --- you'll get a big following.

> If 
> I were to do a version of Forth for the MSP430 it would be a
> very straight-forward subroutine threaded system, with code and 
> data mixed (taking full advantage of the freedom that the FRAM 
> gives you).

Nooooo! Don't mix code and data. ANS-Forth should never have been wishy-washy and said that code and data may be mixed or may be separate --- they should have said one way or the other (that is what a standard does, is decide one way and stick with the decision) --- separate is by far the better choice, and that is what I'm doing in my language.

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

#32095

On Monday, 30 June 2014 23:29:39 UTC+1, hughag...@yahoo.com  wrote:
> Nooooo! Don't mix code and data. ANS-Forth should 
> never have been wishy-washy and said that code and
> data may be mixed or may be separate --- they should
> have said one way or the other (that is what a standard
> does, is decide one way and stick with the decision) ---
> separate is by far the better choice, and that is what 
> I'm doing in my language.

I agree that a standard should mandate as much as possible.
I'm interested to understand why you think separate code/data
spaces are advantageous. I haven't given it much thought so I 
don't really have an opinion either way. What are the benefits,
in your opinion?

Cheers

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

#32098

Mark Wills <markwills1970@gmail.com> wrote:
> On Monday, 30 June 2014 23:29:39 UTC+1, hughag...@yahoo.com  wrote:
>> Nooooo! Don't mix code and data. ANS-Forth should never have been
>> wishy-washy and said that code and data may be mixed or may be
>> separate --- they should have said one way or the other (that is
>> what a standard does, is decide one way and stick with the
>> decision) --- separate is by far the better choice, and that is
>> what I'm doing in my language.
> 
> I agree that a standard should mandate as much as possible.
> I'm interested to understand why you think separate code/data
> spaces are advantageous. I haven't given it much thought so I 
> don't really have an opinion either way. What are the benefits,
> in your opinion?

Some architectures (take a bow, x86!) perform spectacularly badly when
data writes and instructions share the same cache line.  But I can't
think of any reason why a language standard needs to specify where
code is stored -- it can't make any difference to a standard Forth
program.  I don't even know how a Forth standard would specify such a
thing.  It's just an implementation decision.

Andrew.

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

#32100

On Tuesday, July 1, 2014 1:51:23 AM UTC-7, Mark Wills wrote:
> On Monday, 30 June 2014 23:29:39 UTC+1, hughag...@yahoo.com  wrote:
> > Nooooo! Don't mix code and data. ANS-Forth should 
> > never have been wishy-washy and said that code and
> > data may be mixed or may be separate --- they should
> > have said one way or the other (that is what a standard
> > does, is decide one way and stick with the decision) ---
> > separate is by far the better choice, and that is what 
> > I'm doing in my language.
> 
> I agree that a standard should mandate as much as possible.
> I'm interested to understand why you think separate code/data
> spaces are advantageous. I haven't given it much thought so I 
> don't really have an opinion either way. What are the benefits,
> in your opinion?

It is mostly just a matter of convenience. When you are meta-compiling code that accesses data, you typically have to ALLOT or comma data into the dictionary, and also compile code into the dictionary that accesses this data. When it is possible for data and code to be mixed, you have to first ALLOT enough room for your data, then execute your meta-compiling code. If data and code are separate, then you can mix the code that commas in data and the code that meta-compiles. If code and data are separate, then code that commas and code that meta-compiles can be mixed, but if code and data are mixed, then code that commas and code that meta-compiles have to be separate. This is mostly an issue when you have data that is initialized at compile-time (so you want to use comma) rather than being uninitialized (so you can use ALLOT).

Allowing code and data to be mixed (and hence requiring code that commas and code that meta-compiles to be separate) is just one of those weird and pointless restrictions that the poor ANS-Forth user has to work-around --- he has to remember to keep his code that commas and code that meta-compiles separate, or he gets puzzling bugs that confuse him and waste his time. These bugs may occur on some ANS-Forth compliant systems but not on other ANS-Forth compliant systems.

The problem with ANS-Forth is that it says "may or may not" throughout and doesn't really standardize anything. The programmer has to always assume the worst-case scenario (that his code and data are mixed) in order to write code that will work on any ANS-Forth compliant system. This is effectively the same as making the worst-case scenario the standard. Actually, it is worse, because the programmer has to figure out what the worst-case scenario is, so he can do that. A lot of programmers don't give much thought to figuring this kind of thing out. They just write code and test it on their ANS-Forth compliant system, and if it works they assume that it will work on any ANS-Forth compliant system --- but it may fail on other ANS-Forth systems. ANS-Forth is just too complicated! It is too difficult to write code that is guaranteed to work on any ANS-Forth system --- most code that is supposedly ANS-Forth is actually vendor specific --- this is a lot like not having a standard at all.

Also, in regard to efficiency, it is best to pack all of your code together and pack all of your data together separately, to minimize cache thrashing --- mixing code and data is a novice-level blunder than any decent assembly-language programmer would embarrassed by --- that ANS-Forth allows code and data to be mixed is an indictment of the ANS-Forth committee in regard to how little they know about assembly-language, and this makes the whole Forth community appear to be novice-level. I'm mostly familiar with the x86, but I think that what I said about cache-thrashing is true on any processor that has code and data caches (the Pentium did have code and data caches in the early 1990s when the ANS-Forth committee was developing ANS-Forth, so they have no excuse for not knowing this stuff).

When compiling to a Harvard Architecture processor (such as the MiniForth that my MFX targeted), it is necessary to assume that code and data are separate. So, why not just standardize this, and assume the same thing on processors (such as the x86) that don't strictly require this. The reason why the x86 doesn't require this, is that it wasn't required on the 16-bit x86 and so the modern processors had to not require it in order to be able to run legacy 16-bit programs that have code and data mixed together. If it wasn't for supporting legacy programs though, then the modern processor designers would just require code and data to be separate --- because making them separate is much more efficient as you avoid cache thrashing, and cache thrashing is the #1 speed killer on modern processors. When ANS-Forth allows code and data to be mixed, this makes ANS-Forth look like a dinosaur --- as if our only goal is to support legacy programs, and we have no intention of writing new programs, and no concern about efficiency.

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

#32102

On Tuesday, July 1, 2014 2:08:48 PM UTC-4, hughag...@yahoo.com wrote:
> It is mostly just a matter of convenience.

Most well argued justification there for declaring that any implementation using one or the other is not standard Forth.

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

#32101

On 7/1/2014 4:51 AM, Mark Wills wrote:
> On Monday, 30 June 2014 23:29:39 UTC+1, hughag...@yahoo.com  wrote:
>> Nooooo! Don't mix code and data. ANS-Forth should
>> never have been wishy-washy and said that code and
>> data may be mixed or may be separate --- they should
>> have said one way or the other (that is what a standard
>> does, is decide one way and stick with the decision) ---
>> separate is by far the better choice, and that is what
>> I'm doing in my language.
>
> I agree that a standard should mandate as much as possible.
> I'm interested to understand why you think separate code/data
> spaces are advantageous. I haven't given it much thought so I
> don't really have an opinion either way. What are the benefits,
> in your opinion?

I think you have that exactly backwards.  A standard should specify the 
minimum possible and still achieve the goals of the standard.  There is 
no purpose to specifying if code and data should be kept separate, that 
depends entirely on the platform being used to implement the application.

Please keep in mind that one of the objectives of the standard was to 
accommodate as many existing and future architectures as possible.

-- 

Rick

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

#32103

On Tuesday, July 1, 2014 3:02:42 PM UTC-4, rickman wrote:
> I think you have that exactly backwards.  A standard should specify the  
> minimum possible and still achieve the goals of the standard.  There is 
> no purpose to specifying if code and data should be kept separate, that 
> depends entirely on the platform being used to implement the application.
>
> Please keep in mind that one of the objectives of the standard was to  
> accommodate as many existing and future architectures as possible.

However, bear in mind that if the primary purpose of making a claim about what the standard "should have done" is to support finding fault with the standard, then there's few more direct routes than making a claim that the standard "should have done" something that was, in the circumstances of the time, impossible to do, and which would have directly contradicted the explicit goals of the activity.

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

#32107

On Tuesday, July 1, 2014 1:02:19 PM UTC-7, BruceMcF wrote:
> On Tuesday, July 1, 2014 3:02:42 PM UTC-4, rickman wrote:
> > I think you have that exactly backwards.  A standard should specify the  
> > minimum possible and still achieve the goals of the standard.  There is 
> > no purpose to specifying if code and data should be kept separate, that 
> > depends entirely on the platform being used to implement the application.
> 
> > Please keep in mind that one of the objectives of the standard was to  
> > accommodate as many existing and future architectures as possible.
 
> However, bear in mind that if the primary purpose of making a claim about what the standard "should have done" is to support finding fault with the standard, then there's few more direct routes than making a claim that the standard "should have done" something that was, in the circumstances of the time, impossible to do, and which would have directly contradicted the explicit goals of the activity.

What were the "explicit goals of [ANS-Forth]"?

Nowhere in the standard is the user explicitly told that code that commas and code that meta-compiles can't be mixed together. This is just a weird pointless restriction of ANS-Forth --- and it is not even documented --- so the poor devil learning ANS-Forth has to find out about the restriction the hard way (by writing a program that works on some ANS-Forth compliant systems, but doesn't work on other ANS-Forth compliant systems, and he is baffled by the problem in front of his customers).

This restriction could be dropped by standardizing that code and data are separate, and the old legacy code will continue to work --- so why not get rid of the restriction? This was not "impossible to do" in 1994 --- this was a no-brainer.

Originally, the reason why code and data was mixed, was to save memory. The compiler-writer has to decide how much memory to allocate for code and how much to allocate for data. If you only have 8KB of RAM, then do you split it up 4KB/4KB or 5KB/3KB or what? If you just provide the full 8KB for the dictionary, and intermix code and data freely, then neither code nor data will run out of memory first. That was 30 years ago though --- those kinds of issues don't exist on modern desktop computers --- the restriction on not being able to mix code that commas with code that meta-compiles was not necessary in 1994.

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

#32109

On Tuesday, July 1, 2014 8:25:30 PM UTC-4, hughag...@yahoo.com wrote:
> What were the "explicit goals of [ANS-Forth]"?

I'm startled that such an incisive critic of the Forth94 process has engaged of such extensive criticism of how well Forth94 achieved their purposed while remaining ignorant of what those purposes were:

"The purpose of this Standard is to promote the portability of Forth programs for use on a wide variety of computing systems, to facilitate the communication of programs, programming techniques, and ideas among Forth programmers, and to serve as a basis for the future evolution of the Forth language."

Three purposes, your suggestion contradicts each of the three.

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

#32119

On 7/1/2014 11:44 PM, bruce.mcfarling@gmail.com wrote:
> On Tuesday, July 1, 2014 8:25:30 PM UTC-4, hughag...@yahoo.com wrote:
>> What were the "explicit goals of [ANS-Forth]"?
>
> I'm startled that such an incisive critic of the Forth94 process has engaged of such extensive criticism of how well Forth94 achieved their purposed while remaining ignorant of what those purposes were:
>
> "The purpose of this Standard is to promote the portability of Forth programs for use on a wide variety of computing systems, to facilitate the communication of programs, programming techniques, and ideas among Forth programmers, and to serve as a basis for the future evolution of the Forth language.."
>
> Three purposes, your suggestion contradicts each of the three.

Hugh's dislike for the ANS forth standard and a number of other related 
topics is well known and has been the subject of many, many kB of posts 
here and likely elsewhere.  Could I ask that these issues not be 
discussed in this thread further?  I'd really like to keep this thread 
for the stated topic.  There are so many other threads where Hugh is 
encouraged to rant that I think it is superfluous to continue this here.

How about a new topic, "Hugh Rails Against Forth"?

-- 

Rick

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

#32126

On Wednesday, July 2, 2014 12:11:54 PM UTC-4, rickman wrote:
> Hugh's dislike for the ANS forth standard and a number of other related  
> topics is well known and has been the subject of many, many kB of posts 
> here and likely elsewhere.  Could I ask that these issues not be 
> discussed in this thread further?

OK. I'm more interested in what is the smallest resource of these FRAM chips that would be suitable for a free-standing Forth94 system with a micro-SD socket, UART console and CORE and FILE words.

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

#32130

On 7/2/2014 1:19 PM, bruce.mcfarling@gmail.com wrote:
> On Wednesday, July 2, 2014 12:11:54 PM UTC-4, rickman wrote:
>> Hugh's dislike for the ANS forth standard and a number of other related
>> topics is well known and has been the subject of many, many kB of posts
>> here and likely elsewhere.  Could I ask that these issues not be
>> discussed in this thread further?
>
> OK. I'm more interested in what is the smallest resource of these FRAM chips that would be suitable for a free-standing Forth94 system with a micro-SD socket, UART console and CORE and FILE words.

What would be your intended application?  Interesting that you want a 
micro-SD card along with a serial port, a serial port being not widely 
used anymore and the micro-SD card holding an awful lot of data... up 
to 16 GB or so.

When you say "smallest resource", do you mean physically or the internal 
resources like RAM, etc?  A simple stroll down their selection guide 
should tell you that.  The power source is likely to be the big 
footprint though (battery, AC adapter, etc).

-- 

Rick

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

#32137

On Wednesday, July 2, 2014 3:30:48 PM UTC-4, rickman wrote:
 
> What would be your intended application?
The normal remote site agrarian development stuff ~ a bit of weather data logging, daily power supply monitoring, radio fidonet email relay, etc. One of the most important features is low resale value for the widget so security can be focused on the radio, solar panels, generator, etc.

> Interesting that you want a micro-SD card along with a serial port, a serial
> port being not widely used anymore and the micro-SD card holding an awful lot
> of data... up to 16 GB or so.

To be sure, but 1GB sd-cards are pretty cheap in quantity and their use in some mobile phones make readers readily available if the reader on hand were to go missing.

I was thinking of the UART as the simplest approach to in-field programming, since I know of several ways to talk to a UART and get a console over either Blu Tooth or USB. But if there are easier ways nowadays to have a back port that can add either Blu-Tooth or USB access with most of the smarts on the side of the plug that plugs into the widget, that'd be good too.

> When you say "smallest resource", do you mean physically or the internal  
> resources like RAM, etc?  A simple stroll down their selection guide 
> should tell you that.

Internal resources. I've never implemented a free standing Forth on a processor like the MP430, I don't know how much SRAM and FRAM would be reasonable (shockingly I didn't see any application note at TI that address the issue, either). Physical size wouldn't be an issue, no matter how small the chip the device would have to be made big enough to bolt down.

> The power source is likely to be the big footprint though (battery, AC adapter, etc).

I expect the power source would be a large deep cycle 12v battery powered by solar and biodiesel generator, perhaps backed up by a couple of AA batteries hidden inside the case somewhere.

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

#32139

On 7/2/2014 10:25 PM, BruceMcF wrote:
> On Wednesday, July 2, 2014 3:30:48 PM UTC-4, rickman wrote:
>
>> What would be your intended application?
> The normal remote site agrarian development stuff ~ a bit of weather data logging, daily power supply monitoring, radio fidonet email relay, etc. One of the most important features is low resale value for the widget so security can be focused on the radio, solar panels, generator, etc.
>
>> Interesting that you want a micro-SD card along with a serial port, a serial
>> port being not widely used anymore and the micro-SD card holding an awful lot
>> of data... up to 16 GB or so.

Low resale value?  You mean low cost?  I think you are saying you want 
this cheap enough that you won't care so much if it is damaged or 
destroyed, right?


> I was thinking of the UART as the simplest approach to in-field programming, since I know of several ways to talk to a UART and get a console over either Blu Tooth or USB. But if there are easier ways nowadays to have a back port that can add either Blu-Tooth or USB access with most of the smarts on the side of the plug that plugs into the widget, that'd be good too.

So the serial port is not for interfacing to things being read or 
controlled, it is for configuration?


>> When you say "smallest resource", do you mean physically or the internal
>> resources like RAM, etc?  A simple stroll down their selection guide
>> should tell you that.
>
> Internal resources. I've never implemented a free standing Forth on a processor like the MP430, I don't know how much SRAM and FRAM would be reasonable (shockingly I didn't see any application note at TI that address the issue, either). Physical size wouldn't be an issue, no matter how small the chip the device would have to be made big enough to bolt down.

It's not very often anyone says they want little in the MCU.  The cost 
of the MSP430 with 16 kB of FRAM is around $2 at 1000 each.  Can you 
care about saving another $0.25 by using the 8 kB version?  If you 
aren't shipping 100k units this small price delta just is not important.


>> The power source is likely to be the big footprint though (battery, AC adapter, etc).
>
> I expect the power source would be a large deep cycle 12v battery powered by solar and biodiesel generator, perhaps backed up by a couple of AA batteries hidden inside the case somewhere.

Ok, so size, weight and power are not issues.  Is price the only 
constraint?  Any idea how large your app would be?

-- 

Rick

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web