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

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

tethered Forth

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

Contents

  tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 12:25 -0700
    Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-07 10:40 -1000
      Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 15:05 -0700
        Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-07 17:09 -0500
          Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 15:38 -0700
            Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-08 02:09 -0500
        Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-07 22:21 -1000
          Re: tethered Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2013-09-08 11:39 +0200
          Re: tethered Forth "Ed" <invalid@invalid.com> - 2013-09-09 22:42 +1000
          Re: tethered Forth Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-09-16 15:16 +0200
            Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-16 07:20 -1000
    Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-07 16:13 -0500
      Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-07 18:00 -0700
      Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-08 11:00 -0700
        Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-08 08:55 -1000
          Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-14 15:59 -0700
            Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-14 17:56 -1000
              Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-15 22:27 -0700
                Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-15 21:18 -1000
                  Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-16 22:46 -0700
                    Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-17 02:45 -0500
                Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-16 03:19 -0500
            Re: tethered Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-15 12:56 -0500
            Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-15 19:47 -0700
              Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-15 18:49 -1000
                Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-16 11:58 -0700
      Re: tethered Forth hughaguilar96@yahoo.com - 2013-09-10 20:47 -0700
    Re: tethered Forth bob.nash1@gmail.com - 2013-09-10 17:27 -0700
    Re: tethered Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-11 12:54 +0000
      Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-14 15:53 -0700
        Re: tethered Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-15 17:14 +0000
          Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-15 12:48 -0700
            Re: tethered Forth Gary Bergstrom <forthprgrmr@gmail.com> - 2013-09-17 13:46 -0700
              Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-17 18:55 -0700
                Re: tethered Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-09-17 15:51 -1000
                Re: tethered Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-18 11:19 +0000
                  Re: tethered Forth Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-09-18 15:46 +0200
                  Re: tethered Forth Paul Rubin <no.email@nospam.invalid> - 2013-09-18 08:43 -0700
                Re: tethered Forth Brad Eckert <hwfwguy@gmail.com> - 2013-09-18 09:10 -0700
                Re: tethered Forth rickman <gnuarm@gmail.com> - 2013-09-18 20:20 -0400

Page 2 of 2 — ← Prev page 1 [2]

#25718

Paul Rubin <no.email@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> The concept we're trying to maintain is that the host is
>> transparent.
> 
> OK, I think I get it, this stuff about copying stacks around is just an
> implementation artifact and it would work as well if every token
> (including literals) were transferred to the target immediately.
> This is cool, it's as if you're talking to the target all the time.

And it makes testing easy.  You can do stuff like

host : testing
   n 0 do
     args [target] word word word
     [host] args word word word
        -compare if  ... test failed ...  then
   loop ;

Host words can call target words and pass arguments on the stack, so
you can run the same words on each and compare the results.  This is
like RPC but far easier to use.

Andrew.

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

#25700

Paul Rubin <no.email@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> "2 3 + ."
>> The host interpreter processes the line. 2 and 3 go initially on the
>> host stack, which is passed to the target. 
> 
> When is it passed to the target?  As soon as the 3 is processed on the
> host side?  Or when + is looked up (and found) in the target dictionary?
> 
> What happens if you say "2 3 dup"?  Does the host stack still have
> "2 3" while the target stack has "2 3 3"?

There is only one stack: it is either on the host or the target.

Andrew.

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

#25684

Paul Rubin <no.email@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> You type some numeric arguments and the name of your new
>> definition. The arguments, which went onto your host's stack, are
>> passed to the target, which is then commanded to execute the new
>> definition. ...
>> All the execution occurs on the target, but the host is providing the
>> compiler, assembler, target memory managem...
> 
> This is a part I'm wondering about.  How do you decide what gets
> run on the host?  E.g. if I type "2 3 + ."  are you saying 2 and 3
> go on the host stack, then + copies the host stack to the target
> stack, and . runs on the target and sends output back to the host?
> Why does "2" not immediately push 2 on the target stack?  

It could be done that way, but it doesn't happen because 2 is not a
word in the target dictionary.

Andrew.

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

#25693

On Saturday, September 14, 2013 6:59:08 PM UTC-4, Paul Rubin wrote:
> 
> Why does "2" not immediately push 2 on the target stack?  
> 
It could. You could have a dedicated debug task with its own data and return stacks. Elizabeth described the SwiftX XTL, which probably evolved from earlier Forths.

When I got around to inspecting the 8051 version of SwiftX, I was surprised at how lightweight the implementation was. But it doesn't have to be done that way, and there are reasons you might not want to. 

I've run a debug task where the host-based interpreter pushed numbers onto the target stack right away and it worked fine. This was on a CPU that didn't have interrupts. The UART was polled by the debug task, which was in the PAUSE chain.

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

#25696

On 9/15/13 4:47 PM, Brad Eckert wrote:
> On Saturday, September 14, 2013 6:59:08 PM UTC-4, Paul Rubin wrote:
>>
>> Why does "2" not immediately push 2 on the target stack?
>>
> It could. You could have a dedicated debug task with its own data and return stacks. Elizabeth described the SwiftX XTL, which probably evolved from earlier Forths.
>
> When I got around to inspecting the 8051 version of SwiftX, I was surprised at how lightweight the implementation was. But it doesn't have to be done that way, and there are reasons you might not want to.
>
> I've run a debug task where the host-based interpreter pushed numbers onto the target stack right away and it worked fine. This was on a CPU that didn't have interrupts. The UART was polled by the debug task, which was in the PAUSE chain.
>

Sure, there are lots of ways of implementing it. The target has a task 
which is communicating with the host. That might or might not be one of 
the tasks executing the target application, but at least in early stages 
of debugging it is.

The SwiftX concept of having the host stack echo the stack of the target 
task that's doing the communication simplifies things for the user, who 
simply doesn't have to think about the host as an intermediary. The 
objective is to make the host as transparent as possible. Since the host 
already has the capability of exhibiting its stack, there are no other 
mechanisms needed to monitor the target's stack, providing their 
contents are kept the same.

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]

#25708

On Monday, September 16, 2013 12:49:14 AM UTC-4, Elizabeth D. Rather wrote:
 
> The SwiftX concept of having the host stack echo the stack of the target 
> task that's doing the communication simplifies things for the user, who 
> simply doesn't have to think about the host as an intermediary. The 
> objective is to make the host as transparent as possible. Since the host 
> already has the capability of exhibiting its stack, there are no other 
> mechanisms needed to monitor the target's stack, providing their 
> contents are kept the same.
> 

This approach provides a way to bring up a new port quickly. Get the tether code working first, without ISRs or PAUSE, and use it to debug the kernel. Then integrate it a little better with, say, an ISR.

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

#25615

On Saturday, September 7, 2013 2:13:10 PM UTC-7, Andrew Haley wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
> > Is idt normal when using one, to develop against the target from
> > beginning to end,
> 
> Yes.  IME there really isn't much point developing on the host.
> 
> The traditional reason for developing on the host was that the
> environment on the target was crap.  Once you make it not crap -- by
> using Forth -- all reasons for developing on the host evaporate.

MFX developed on the host. It wasn't that the target environment was "crap" --- the target processor just didn't exist yet. Throughout most of the development of MFX, the MiniForth itself was under development. The definition of the MiniForth changed on an almost daily basis. Both MFX and the motion-control program were completed using simulation prior to the MiniForth existing as a physical chip.

This is the best way to develop a new processor. I think it is a big mistake to develop a new processor and then afterward develop a compiler for it --- because you don't know what instructions you want until you have the compiler working and discover that your compiler is generating inefficient code with the instructions that you have, and would generate better code with a different instruction set. The processor and the compiler are developed in conjunction so that each can be molded to fit the other.

It is true that developing on the host and uploading entire programs to the target, is not very interactive. With a tethered system, you are uploading portions of code to the target on the fly, and the whole process is interactive, similar to developing on the target itself as in a traditional Forth. That is what I've heard anyway, as I've never used a tethered system.

After I left Testra, they used MFX to write a traditional Forth that ran on the target. Most likely, the just didn't know how to write a tethered system. I could do it, but I was gone by that time. Anyway, the MiniForth is a pretty big processor and it can support a traditional Forth easily, so a tethered system wasn't really needed. I think that tethered systems would mostly be useful for processors that are too small to support both a Forth compiler and an application program.

The problem with a traditional Forth on a processor such as the MiniForth, is that it can only be used to develop Forth code, but not assembly-language code. This is because the processor is Harvard architecture, with the Forth code and the data in one memory, and the machine-code in another memory --- the latter being memory that can't be written to by the processor itself. Because of this, Testra must still be using my MFX when they need to write assembly-language code --- it is just not possible to do that with a Forth running on the MiniForth itself.

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

#25614

I routinely program for Target processors with 256 bytes of ram and 8K of flash (Silicon Laboratories C8051F300 or C8051F850).  For many projects I use both tethering and a standalone interpreter.  

Standalone interpreters are nice if you want to exercise the chip using commands sent from a dumb terminal.  Or, to implement complex functionality using a basic command repertoire and scripting (poor man's Forth).  The overhead for the standalone interpreter I use is 447 bytes and 6 bytes per interpretable definition (count, first three chars and 2-byte execution vector).

Tethering is nice because you don't have to define each command to be exercised.  Target overhead is trivial: the tether can just receive a two-byte execution vector and jump to it, signaling the Host when done.  Multi-byte responses are possible (and straightforward to implement) but beyond the scope of this response.

On I/O restricted processors (such as the one ATtiny85), the tethering (and standalone) is a bit trickier.  If you have a UART and a serial port to burn (two I/O lines), fine.  Otherwise, using a one-wire tether, you need to deal with line turnaround, bit-banged serial, etc.

Solutions for this exist, but are beyond the scope, etc.

Having used several SwiftX products from Forth, Inc., I can say that a tethered development environment, well-implemented, is a pleasure to use. 

BTW, the C8051F850 chip is only $0.88 in small quantity and has 2+ I/O ports and UART.  Perhaps worth checking out.  You can get it soldered on a Toolstick daughtercard for $10 (includes on-board LEDs and switches).  The programming adapter is about $17.  But, it is an 8051 processor and perhaps of little interest to Arduino fans.

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

#25626

On Sat, 07 Sep 2013 12:25:48 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>Tethering has the advantage that the text interpreter runs on a PC,
>while the target processor only needs a tiny address interpreter, or
>even just a boot point to jump to native code produced by the compiler.
>
>What are the disadvantages?  What are the main difficulties of
>implementing a tethered Forth, compared to a regular one?

Very few. The main issues are always the comms link and the Flashing.

>Is it normal when using one, to develop against the target from
>beginning to end, or do you code on a desktop environment first (other
>than parts that twiddle the target hardware intensively, and even that
>can use emulations)?

It's rare that a PC can run an extrusion pump ... or ...

Tethered or umbilical systems have been around since at least the
1980s - I remember presenting a paper on the topic at a Rochester
conference only to be followed by two more from other people. The
issue nowadays is that you can buy a much more capable 32 bit CPU,
e.g. Cortex-M0, for the same money as a small 8-bitter. The only
exception is if you need huge volume. At the same time, Forth
compilers now have much better code generation and clients want
much more complex applications.

The Adafruit example is only a little cheaper than something like
an STM32 Discovery board, which is far more capable. If you just
like small CPUs, TI's MSP430 Launchpads are good, as is the core
itself.

If you go with a modern CPU, the choice of standalone or umbilical
development is a matter of preference.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#25666

stephenXXX@mpeforth.com (Stephen Pelc) writes:
> The Adafruit example is only a little cheaper than something like
> an STM32 Discovery board, which is far more capable.

Yeah, the nice thing about the Adafruit board is it's really tiny, and I
get the impression it's less fuss to program.  You've been using the
STM32?  Is there much headache getting it booted and running, without
some monstrous dev environment from Keil or whatever?

> If you just like small CPUs, TI's MSP430 Launchpads are good, as is
> the core itself.

I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
tiny ATmega boards are actually more powerful (plus smaller).  I guess
the next thing up in very small boards is the Teensy 3.0.

My immediate application for the attiny board involves just monitoring a
few sensors and triggering an output pin on certain sensor events.  An 8
bitter seems fine for that.

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

#25680

On Sat, 14 Sep 2013 15:53:57 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>You've been using the
>STM32?  Is there much headache getting it booted and running, without
>some monstrous dev environment from Keil or whatever?

The MPE Forth ARM/Cortex cross compiler, including the Stamp edition,
supports the STM32F4 processors. You do not need a big environment
to develop for them.

>I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
>tiny ATmega boards are actually more powerful (plus smaller).  I guess
>the next thing up in very small boards is the Teensy 3.0.

How is an AVR more powerful than an MSP430? Just because the chips
on the Launchpad are RAM limited says nothing about the relative
merits of the families. Without an explanation of your priorities,
I don't understand what you want.

>My immediate application for the attiny board involves just monitoring a
>few sensors and triggering an output pin on certain sensor events.  An 8
>bitter seems fine for that.

IMHO, in this environment the distinction between 8. 16, and 32 bit
CPUs is irrelvant. Adafruit will sell you a minimal LPC810 kit for
very little. That's an 8 pin 32 bit CPU.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#25690

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>>I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
>>tiny ATmega boards are actually more powerful (plus smaller). 

> How is an AVR more powerful than an MSP430? Just because the chips
> on the Launchpad are RAM limited says nothing about the relative
> merits of the families. 

The comparison is specifically between the Atmega processors found on
(e.g.) the Teensy boards, vs the MSP430 processor found on the
Launchpad.  The Atmegas are more powerful than the largest Launchpad
processor in the sense of having more program capacity and ram.  There
may be other members of the MSP430 family that have more capacity than
the Atmega, but they are not compatible with the Launchpad.  The bigger
MSP430's are rather expensive and it probably makes more sense to use an
ARM.  The most interesting MSP430's are the FRAM models and it would be
great if they made some Launchpad compatible versions.

> IMHO, in this environment the distinction between 8. 16, and 32 bit
> CPUs is irrelvant. Adafruit will sell you a minimal LPC810 kit for
> very little. That's an 8 pin 32 bit CPU.

Thanks, I see http://www.adafruit.com/products/1336 and it's indeed
interesting, but it's a bag of parts rather than being a complete,
assembled board like the Trinket.  Loading code into it apparently
involves a complex procedure, while for the Trinket I can just plug in a
USB cable and run AVRDude.  It also has just 4k of program flash, vs 8k
for the Trinket, 16k for the Launchpad, 32k for the Atmega32u4, etc.
The Digispark (http://digistump.com/products/1) is comparable to the
Trinket and even plugs directly into a USB port.

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

#25733

On Sunday, September 15, 2013 3:48:00 PM UTC-4, Paul Rubin wrote:
> ... (Stephen Pelc) writes:
> 
> >>I do have an MSP430 Launchpad but with 16k flash / 512B ram, some of the
> >>tiny ATmega boards are actually more powerful (plus smaller). 
> 
> > How is an AVR more powerful than an MSP430? Just because the chips
> > on the Launchpad are RAM limited says nothing about the relative
> > merits of the families. 
> 
> The comparison is specifically between the Atmega processors found on
> (e.g.) the Teensy boards, vs the MSP430 processor found on the
> Launchpad.  The Atmegas are more powerful than the largest Launchpad
> processor in the sense of having more program capacity and ram.  There
> may be other members of the MSP430 family that have more capacity than
> the Atmega, but they are not compatible with the Launchpad.  The bigger
> MSP430's are rather expensive and it probably makes more sense to use an
> ARM.  The most interesting MSP430's are the FRAM models and it would be
> great if they made some Launchpad compatible versions.
> 
There are two flavors of the TI MSP430 Launchpad.  The $10 value line version and the $13 one with more memory - 8k RAM, 128k flash.  That should be big enough.  The two are binary compatible so moving from one to the other is trivial.
As to which family is more "powerful" - memory size is not a good determination of "power" of an embedded processor.

As Stephen has noted, the 32bit ARM boards are also quite available and run rings around the 8/16 bit chips.  And the mA/MIPS numbers rival the best as does the price.  Hard to justify sticking with the old other than familiarity and inertia.

Gary

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

#25739

Gary Bergstrom <forthprgrmr@gmail.com> writes:
> There are two flavors of the TI MSP430 Launchpad.  The $10 value line
> version and the $13 one with more memory - 8k RAM, 128k flash.

Thanks!  The bigger one is a new and interesting development that I
didn't know about.  It must have just been released recently, after they
increased the Value Line launchpad price from $4.30.  Some info is here:

http://processors.wiki.ti.com/index.php/MSP430F5529_LaunchPad

It has USB but looks like you need some kind of proprietary libraries in
order to use it :-(

> As Stephen has noted, the 32bit ARM boards are also quite available
> and run rings around the 8/16 bit chips.  And the mA/MIPS numbers
> rival the best as does the price.  Hard to justify sticking with the
> old other than familiarity and inertia.

The MSP430 seemed like a sweet spot for a while, but now looks unhappily
squeezed between 8 and 32 bitters.  You're probably right that there's
not much point any more to large MSP430's, unless you get one with
special hardware features like FRAM.

8 bitters still have their place as they are available in small packages
and are simpler to program, at least using FOSS tools.

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

#25740

On 9/17/2013 3:55 PM, Paul Rubin wrote:
> Gary Bergstrom <forthprgrmr@gmail.com> writes:
>> There are two flavors of the TI MSP430 Launchpad.  The $10 value line
>> version and the $13 one with more memory - 8k RAM, 128k flash.
>
> Thanks!  The bigger one is a new and interesting development that I
> didn't know about.  It must have just been released recently, after they
> increased the Value Line launchpad price from $4.30.  Some info is here:
>
> http://processors.wiki.ti.com/index.php/MSP430F5529_LaunchPad
>
> It has USB but looks like you need some kind of proprietary libraries in
> order to use it :-(

FORTH, Inc. uses TI's library for the Windows side, and a native USB 
driver based on (but quite different from) their code.

>> As Stephen has noted, the 32bit ARM boards are also quite available
>> and run rings around the 8/16 bit chips.  And the mA/MIPS numbers
>> rival the best as does the price.  Hard to justify sticking with the
>> old other than familiarity and inertia.
>
> The MSP430 seemed like a sweet spot for a while, but now looks unhappily
> squeezed between 8 and 32 bitters.  You're probably right that there's
> not much point any more to large MSP430's, unless you get one with
> special hardware features like FRAM.
>
> 8 bitters still have their place as they are available in small packages
> and are simpler to program, at least using FOSS tools.

The big advantage of the MSP430 remains its ability to run really low 
power. The SwiftX kernel on the MSP has an adapted multitasker loop that 
automatically optimizes the use of low power mode, so it has duty cycles 
measured in microseconds.

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]

#25758

On Tue, 17 Sep 2013 18:55:51 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>8 bitters still have their place as they are available in small packages
>and are simpler to program, at least using FOSS tools.

"at least using FOSS tools". That's the rub. Sometimes you need to
buy tools, especially if you need advanced tools.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#25762

Stephen Pelc schrieb:
> "at least using FOSS tools". That's the rub. Sometimes you need to
> buy tools, especially if you need advanced tools.

I disagree, at least for software tools.
Not everyone likes to sign an NDA to see compiler sources.
You are right that FOSS tools available today in this niche still need work,
but I have done a big step forward for MSP430 and I am just filling the gap for ARM Cortex chips.

On some types of hardware tools, I agree.

Matthias

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

#25766

stephenXXX@mpeforth.com (Stephen Pelc) writes:
> "at least using FOSS tools". That's the rub. Sometimes you need to
> buy tools, especially if you need advanced tools.

Even if you're willing to buy tools on the host side, some applications
require 100% auditability of the target code.  It might be ok in such a
situation to compare the source code going into a proprietary compiler
with the assembly code coming out as part of the audit, but there can't
be any mysterious binary blobs running in the target, and this seems
hard to avoid with some devices, notoriously the Raspberry Pi.  .

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

#25768

On Tuesday, September 17, 2013 9:55:51 PM UTC-4, Paul Rubin wrote:
> 
> The MSP430 seemed like a sweet spot for a while, but now looks unhappily
> squeezed between 8 and 32 bitters. 

The MSP430 is a way for TI to sell chips. If I need an MCU with a 24-bit ADC in it, they have a 430 derivative at a nice price point. I suspect that chips with sensitive analog peripherals would be easier to build with lower power CPUs.

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

#25783

On 9/17/2013 9:55 PM, Paul Rubin wrote:
> Gary Bergstrom<forthprgrmr@gmail.com>  writes:
>> There are two flavors of the TI MSP430 Launchpad.  The $10 value line
>> version and the $13 one with more memory - 8k RAM, 128k flash.
>
> Thanks!  The bigger one is a new and interesting development that I
> didn't know about.  It must have just been released recently, after they
> increased the Value Line launchpad price from $4.30.  Some info is here:
>
> http://processors.wiki.ti.com/index.php/MSP430F5529_LaunchPad
>
> It has USB but looks like you need some kind of proprietary libraries in
> order to use it :-(
>
>> As Stephen has noted, the 32bit ARM boards are also quite available
>> and run rings around the 8/16 bit chips.  And the mA/MIPS numbers
>> rival the best as does the price.  Hard to justify sticking with the
>> old other than familiarity and inertia.
>
> The MSP430 seemed like a sweet spot for a while, but now looks unhappily
> squeezed between 8 and 32 bitters.  You're probably right that there's
> not much point any more to large MSP430's, unless you get one with
> special hardware features like FRAM.
>
> 8 bitters still have their place as they are available in small packages
> and are simpler to program, at least using FOSS tools.

There is price too.  8 bit MCUs are still cheaper than 16 bit parts 
which are cheaper than 32 bit parts.  Of course this only matters if you 
are high volume because the difference has gotten pretty small.

-- 

Rick

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web