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

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

new embedded forth

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

Contents

  new embedded forth Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> - 2016-09-02 09:45 -0700
    Re: new embedded forth Cecil Bayona <cbayona@cbayona.com> - 2016-09-02 13:01 -0500
      Re: new embedded forth Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> - 2016-09-02 11:08 -0700
        Re: new embedded forth Cecil Bayona <cbayona@cbayona.com> - 2016-09-02 13:48 -0500
    Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-11 23:45 -0700
      Re: new embedded forth Cecil Bayona <cbayona@cbayona.com> - 2016-09-12 09:51 -0500
        Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-12 13:15 -0700
          Re: new embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 22:46 +0200
            Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-12 14:30 -0700
          Re: new embedded forth Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> - 2016-09-13 01:11 -0700
            Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-13 01:32 -0700
              Re: new embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-13 11:13 +0200
                Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-13 10:25 -0700
                  Re: new embedded forth rickman <gnuarm@gmail.com> - 2016-09-13 13:55 -0400
              Re: new embedded forth Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> - 2016-09-13 02:37 -0700
      Re: new embedded forth rickman <gnuarm@gmail.com> - 2016-09-12 21:39 -0400
        Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-12 18:57 -0700
          Re: new embedded forth rickman <gnuarm@gmail.com> - 2016-09-12 22:13 -0400
            Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-12 19:26 -0700
              Re: new embedded forth rickman <gnuarm@gmail.com> - 2016-09-13 13:46 -0400
                Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-13 15:59 -0700
                  Re: new embedded forth rickman <gnuarm@gmail.com> - 2016-09-30 19:06 -0400
                    Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-30 17:37 -0700
                      Re: new embedded forth rickman <gnuarm@gmail.com> - 2016-10-01 10:41 -0400
                        Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-10-03 13:21 -0700
                    Re: new embedded forth Paul Rubin <no.email@nospam.invalid> - 2016-09-30 17:50 -0700
                Re: new embedded forth Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-14 07:45 +0200
                  Re: new embedded forth Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-30 15:32 +0200
        Re: new embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-13 11:14 +0200
    Re: new embedded forth Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> - 2016-10-07 04:44 -0700
      Re: new embedded forth JUERGEN <epldfpga@aol.com> - 2016-10-07 04:59 -0700
        Re: new embedded forth Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> - 2016-10-07 05:45 -0700
          Re: new embedded forth rickman <gnuarm@gmail.com> - 2016-10-08 10:57 -0400
            Re: new embedded forth Cecil Bayona <cbayona@cbayona.com> - 2016-10-08 10:06 -0500
            Re: new embedded forth JUERGEN <epldfpga@aol.com> - 2016-10-08 08:16 -0700
      Re: new embedded forth Cecil Bayona <cbayona@cbayona.com> - 2016-10-07 12:25 -0500

Page 1 of 2  [1] 2  Next page →

#50623 — new embedded forth

Hello everyone,

I am pleased to inform you of a new embedded FORTH: "FAST FORTH."

My goal was to quickly develop code for a small microcontroller.
And as when one program is eager to see the result on the target, it is best to reduce interfaces and to ensure that those that are essential to be fast.

After much trial and error, I have come to this: a text editor (Scite), a serial communication software (TeraTerm), a USB to UART bridge (PL2303TA cable, $ 2) and finally the target, a MSP430FR5738 whose FRAM lets not waste time compiling... and, unfortunately ? Windows 10.

Written in assembler, FAST FORTH is small: < 6kb ... with its own embedded assembler.

And fast. The serial link uses the XON / XOFF protocol which overcomes the famous 50 ms delay between each line : with a MSP430 clocked at 8 MHz (and TeraTerm), reliable communication can be done up to 1,843,200 bds.

Interest is the end result. With my own version of FAST FORTH (16 threads) on a MSP430FR5738 @ 24 MHz & 6Mbds, coretest.4th is loaded, compiled and executed, all in 1/3 second (real baud rate = 1Mbds).

I hope it will appeal to hackers.

Regards,
J.M. Thoorens

https://gitlab.com/Jean-Michel/FastForthForMSP430fr5xxx

[toc] | [next] | [standalone]

#50624

On 9/2/2016 11:45 AM, Jean-Michel Thoorens wrote:
> Hello everyone,
>
> I am pleased to inform you of a new embedded FORTH: "FAST FORTH."
>
> My goal was to quickly develop code for a small microcontroller.
> And as when one program is eager to see the result on the target, it is best to reduce interfaces and to ensure that those that are essential to be fast.
>
> After much trial and error, I have come to this: a text editor (Scite), a serial communication software (TeraTerm), a USB to UART bridge (PL2303TA cable, $ 2) and finally the target, a MSP430FR5738 whose FRAM lets not waste time compiling... and, unfortunately ? Windows 10.
>
> Written in assembler, FAST FORTH is small: < 6kb ... with its own embedded assembler.
>
> And fast. The serial link uses the XON / XOFF protocol which overcomes the famous 50 ms delay between each line : with a MSP430 clocked at 8 MHz (and TeraTerm), reliable communication can be done up to 1,843,200 bds.
>
> Interest is the end result. With my own version of FAST FORTH (16 threads) on a MSP430FR5738 @ 24 MHz & 6Mbds, coretest.4th is loaded, compiled and executed, all in 1/3 second (real baud rate = 1Mbds).
>
> I hope it will appeal to hackers.
>
> Regards,
> J.M. Thoorens
>
> https://gitlab.com/Jean-Michel/FastForthForMSP430fr5xxx
>

Nice, is it setup so that the CPU characteristics are on a file of it's 
own or are they embedded in the Forth code? I ask because it would be 
nice to adapt it to other devices.

Thanks
-- 
Cecil - k5nwa

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

#50625

Le vendredi 2 septembre 2016 20:01:13 UTC+2, Cecil - k5nwa a écrit :
> On 9/2/2016 11:45 AM, Jean-Michel Thoorens wrote:
> > Hello everyone,
> >
> > I am pleased to inform you of a new embedded FORTH: "FAST FORTH."
> >
> > My goal was to quickly develop code for a small microcontroller.
> > And as when one program is eager to see the result on the target, it is best to reduce interfaces and to ensure that those that are essential to be fast.
> >
> > After much trial and error, I have come to this: a text editor (Scite), a serial communication software (TeraTerm), a USB to UART bridge (PL2303TA cable, $ 2) and finally the target, a MSP430FR5738 whose FRAM lets not waste time compiling... and, unfortunately ? Windows 10.
> >
> > Written in assembler, FAST FORTH is small: < 6kb ... with its own embedded assembler.
> >
> > And fast. The serial link uses the XON / XOFF protocol which overcomes the famous 50 ms delay between each line : with a MSP430 clocked at 8 MHz (and TeraTerm), reliable communication can be done up to 1,843,200 bds.
> >
> > Interest is the end result. With my own version of FAST FORTH (16 threads) on a MSP430FR5738 @ 24 MHz & 6Mbds, coretest.4th is loaded, compiled and executed, all in 1/3 second (real baud rate = 1Mbds).
> >
> > I hope it will appeal to hackers.
> >
> > Regards,
> > J.M. Thoorens
> >
> > https://gitlab.com/Jean-Michel/FastForthForMSP430fr5xxx
> >
> 
> Nice, is it setup so that the CPU characteristics are on a file of it's 
> own or are they embedded in the Forth code? I ask because it would be 
> nice to adapt it to other devices.
> 
> Thanks
> -- 
> Cecil - k5nwa

there are general configuration files:
devicemap.map and deviceInit.inc
then a file.inc per device to init its I/O, FRAM, WDT ...

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

#50626

On 9/2/2016 1:08 PM, Jean-Michel Thoorens wrote:
> Le vendredi 2 septembre 2016 20:01:13 UTC+2, Cecil - k5nwa a écrit :
>> On 9/2/2016 11:45 AM, Jean-Michel Thoorens wrote:
>>> Hello everyone,
>>>
>>> I am pleased to inform you of a new embedded FORTH: "FAST FORTH."
>>>
>>> My goal was to quickly develop code for a small microcontroller.
>>> And as when one program is eager to see the result on the target, it is best to reduce interfaces and to ensure that those that are essential to be fast.
>>>
>>> After much trial and error, I have come to this: a text editor (Scite), a serial communication software (TeraTerm), a USB to UART bridge (PL2303TA cable, $ 2) and finally the target, a MSP430FR5738 whose FRAM lets not waste time compiling... and, unfortunately ? Windows 10.
>>>
>>> Written in assembler, FAST FORTH is small: < 6kb ... with its own embedded assembler.
>>>
>>> And fast. The serial link uses the XON / XOFF protocol which overcomes the famous 50 ms delay between each line : with a MSP430 clocked at 8 MHz (and TeraTerm), reliable communication can be done up to 1,843,200 bds.
>>>
>>> Interest is the end result. With my own version of FAST FORTH (16 threads) on a MSP430FR5738 @ 24 MHz & 6Mbds, coretest.4th is loaded, compiled and executed, all in 1/3 second (real baud rate = 1Mbds).
>>>
>>> I hope it will appeal to hackers.
>>>
>>> Regards,
>>> J.M. Thoorens
>>>
>>> https://gitlab.com/Jean-Michel/FastForthForMSP430fr5xxx
>>>
>>
>> Nice, is it setup so that the CPU characteristics are on a file of it's
>> own or are they embedded in the Forth code? I ask because it would be
>> nice to adapt it to other devices.
>>
>> Thanks
>> --
>> Cecil - k5nwa
>
> there are general configuration files:
> devicemap.map and deviceInit.inc
> then a file.inc per device to init its I/O, FRAM, WDT ...
>
Good, thanks for the info, the MSP430 devices are great, my only regret 
is the lack of high speed clock, but I understand, the point of their 
family is low power consumption.

I downloaded a copy and will look at later next week, the board I have a 
board that uses the MSP430FR5969, somewhere I also have a board with for 
use with the MSP430G2513IN20

-- 
Cecil - k5nwa

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

#50873

Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> writes:
> FAST FORTH is small: < 6kb ...  MSP430FR5738...

Do you think it could work on the MSP430G2553?  That one's of interest
because of its PDIP package and use in the original Launchpad.

Do you think TI cares much about the MSP430 line any more, vs. mostly
concentrating on ARM?

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

#50896

On 9/12/2016 1:45 AM, Paul Rubin wrote:
> Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> writes:
>> FAST FORTH is small: < 6kb ...  MSP430FR5738...
>
> Do you think it could work on the MSP430G2553?  That one's of interest
> because of its PDIP package and use in the original Launchpad.
>
> Do you think TI cares much about the MSP430 line any more, vs. mostly
> concentrating on ARM?
>
I would tend to think that they will make them for quite a while as 
there are a lot of them in the field.

I hope they still care and make new devices, but in any case I will do 
new projects of any serious intent on ARM CPUs but the MSP430 are fun to 
program and I have both boards and 2553 chips in stock so I will use 
them to play with.

I believe this interesting Forth requires FRAM memory which works quite 
differently from FLASH, its easier for write to and has way longer life. 
Too bad they don't have FRAM Dip devices, I would buy some.
-- 
Cecil - k5nwa

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

#50912

Cecil Bayona <cbayona@cbayona.com> writes:
>> Do you think TI cares much about the MSP430 line any more
> I hope they still care and make new devices...
> Too bad they don't have FRAM Dip devices, I would buy some.

Yes, that would be great.  Besides FRAM, they also have some 430's that
can run as low as 1 volt or so, i.e. you can run them on a penlight cell
with no voltage boost.  I don't know of any ARM stuff with these
features.  Also I think recent 430s have lower static power consumption
than most of the ARMs out there, though ARM is now ahead in performance
per watt with the cpu busy.  Static power is important if the device is
usually idle, as many are.

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

#50916

In article <87twdkg9he.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Cecil Bayona <cbayona@cbayona.com> writes:
>>> Do you think TI cares much about the MSP430 line any more
>> I hope they still care and make new devices...
>> Too bad they don't have FRAM Dip devices, I would buy some.
>
>Yes, that would be great.  Besides FRAM, they also have some 430's that
>can run as low as 1 volt or so, i.e. you can run them on a penlight cell
>with no voltage boost.  I don't know of any ARM stuff with these
>features.  Also I think recent 430s have lower static power consumption
>than most of the ARMs out there, though ARM is now ahead in performance
>per watt with the cpu busy.  Static power is important if the device is
>usually idle, as many are.

The Egel/noforth project has 4 examples involving low power modes
of the 430.
http://noforth.bitbucket.org/site/egel%20for%20launchpad.html#e05x

The lowest power consumption in the examples is at about one tenth of
a micro ampere, so low that it is hard to measure.

There is no way ARM is attacking that market any time soon.

Groetjes Albert
-- 
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]

#50921

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> The Egel/noforth project has 4 examples involving low power modes
> of the 430.

Nice!

> There is no way ARM is attacking that market any time soon.

They are, and they're competitive, but I have the impression that it's
more complicated to program because of additional setup for the modes
and stuff.  I dunno though, I'm just a server jock.

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

#50927

Le lundi 12 septembre 2016 22:15:59 UTC+2, Paul Rubin a écrit :
> Cecil Bayona writes:
> >> Do you think TI cares much about the MSP430 line any more
> > I hope they still care and make new devices...
> > Too bad they don't have FRAM Dip devices, I would buy some.
> 
> Yes, that would be great.  Besides FRAM, they also have some 430's that
> can run as low as 1 volt or so, i.e. you can run them on a penlight cell
> with no voltage boost.  I don't know of any ARM stuff with these
> features.  Also I think recent 430s have lower static power consumption
> than most of the ARMs out there, though ARM is now ahead in performance
> per watt with the cpu busy.  Static power is important if the device is
> usually idle, as many are.

By default FAST FORTH fall down to LPM0 mode when nothing to do.
in all examples furnished in the \MSP430-FORTH folder that run under interrupt, you can select up to LPM4 default mode with the MSP430FRx9xx devices. The supply current is then below 1µA. 

Actually, with FAST FORTH on a MSP-EXP430FR5969 launchpad clocked @ 500kHz plus a 115200bds XON/XOFF terminal, the active current measured when downloading source file @ 3.6kbytes/s is 175µA. 

About the lack of FRAM DIP package, it's very interesting to weld a MSP430FR TSSOP onto a pcb adaptor as : http://www.nkcelectronics.com/assets/images/smd-0013.jpg, 
because MSP430FR devices supersede MSP430G ones with better hardware drivers (eUSCI,RTC,MPY,...). 

With MSP430FR, it seemed interesting to provide a ultra light programming solution able to mix the high-level language FORTH and assembly language. With an ARM, it seems pretentious to want to compete GCC.

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

#50928

Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> writes:
> About the lack of FRAM DIP package, it's very interesting to weld a
> MSP430FR TSSOP onto a pcb adaptor as :
> http://www.nkcelectronics.com/assets/images/smd-0013.jpg,

Hmm, that's interesting, though it's a rather big board that involves
SMT soldering etc.  The G2553 style narrow PDIP is much more attractive
and it's nice that it plugs into the Launchpad board.  I'd frankly be
happy with a 430 that competes with the popular Atmega328.  That means
32kb of flash and 2k of ram, say, in the same package as the G2553.  It
would still be a cheap part and a fairly nice Forth environment could go
in there, rather than the minimal ones in the 2553.

> With MSP430FR, it seemed interesting to provide a ultra light
> programming solution able to mix the high-level language FORTH and
> assembly language. With an ARM, it seems pretentious to want to
> compete GCC.

I guess that's a reasonable way to look at things, if you don't mind a
heavyweight external toolchain.  I've thought of Forth on a small ARM
more as a lightweight interactive configuration and debugging tool than
as an implementation language, tbh.

For what it's worth I'm pretty sure there the 430 has a GCC target.  I
know that the Atmega AVR's do.

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

#50929

In article <874m5kfbej.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> writes:
>> About the lack of FRAM DIP package, it's very interesting to weld a
>> MSP430FR TSSOP onto a pcb adaptor as :
>> http://www.nkcelectronics.com/assets/images/smd-0013.jpg,
>
>Hmm, that's interesting, though it's a rather big board that involves
>SMT soldering etc.  The G2553 style narrow PDIP is much more attractive
>and it's nice that it plugs into the Launchpad board.  I'd frankly be
>happy with a 430 that competes with the popular Atmega328.  That means
>32kb of flash and 2k of ram, say, in the same package as the G2553.  It
>would still be a cheap part and a fairly nice Forth environment could go
>in there, rather than the minimal ones in the 2553.

Same package is sort of unreasonable.
There is the Dupont board around of F149. It has 2 K and 61 K flash.
And it has a truckload of I/O to make all that programming space pay off.
Then you've a truckload of pins ...

http://home.hccnet.nl/anij/nof/boards/msp430f149%20dupont%20board.pdf

>
>> With MSP430FR, it seemed interesting to provide a ultra light
>> programming solution able to mix the high-level language FORTH and
>> assembly language. With an ARM, it seems pretentious to want to
>> compete GCC.
>
>I guess that's a reasonable way to look at things, if you don't mind a
>heavyweight external toolchain.  I've thought of Forth on a small ARM
>more as a lightweight interactive configuration and debugging tool than
>as an implementation language, tbh.
>
>For what it's worth I'm pretty sure there the 430 has a GCC target.  I
>know that the Atmega AVR's do.

Of course.

Groetjes Albert
-- 
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]

#50943

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>32kb of flash and 2k of ram, say, in the same package as the G2553.
> Same package is sort of unreasonable.
> There is the Dupont board around of F149. It has 2 K and 61 K flash.
> And it has a truckload of I/O to make all that programming space pay off.
> Then you've a truckload of pins ...

That's an issue that's been bugging me for a while... lots of program
space doesn't necessarily you need lots of pins.  Anyway the Atmega328
has 32k of flash and 2.5k of ram and is in a similar package to the
G2553.  It's very popular from its use in the Arduino and probably fills
lots of sockets that a 430 might have filled.  There's a LPC ARM part in
an 8-pin PDIP that I think has 32k of flash and 4k of ram, etc.

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

#50946

On 9/13/2016 1:25 PM, Paul Rubin wrote:
> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>> 32kb of flash and 2k of ram, say, in the same package as the G2553.
>> Same package is sort of unreasonable.
>> There is the Dupont board around of F149. It has 2 K and 61 K flash.
>> And it has a truckload of I/O to make all that programming space pay off.
>> Then you've a truckload of pins ...
>
> That's an issue that's been bugging me for a while... lots of program
> space doesn't necessarily you need lots of pins.  Anyway the Atmega328
> has 32k of flash and 2.5k of ram and is in a similar package to the
> G2553.  It's very popular from its use in the Arduino and probably fills
> lots of sockets that a 430 might have filled.  There's a LPC ARM part in
> an 8-pin PDIP that I think has 32k of flash and 4k of ram, etc.

It keeps coming back to the really high volume apps.  Adding I/Os to a 
die doesn't cost much so that when the die is larger and more I/Os fit 
around it, they are included.  More I/Os on the package adds testing 
time and so cost, but I/Os don't have to be pinned out in a package.  So 
a maker can have larger chips in smaller packages with fewer I/Os if the 
market justifies it.

Carrying parts in the product line has a cost and most MCU makers have a 
*huge* product line already.  I suspect the larger dies in smaller 
packages aren't kept in the standard line so much, but if you want 
10,000,000 next year, they will qualify the combo and you can buy all 
you want.  They likely still won't add it to the standard product line.

-- 

Rick C

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

#50931

Le mardi 13 septembre 2016 10:32:08 UTC+2, Paul Rubin a écrit :
> Jean-Michel Thoorens writes:
> 
> > With MSP430FR, it seemed interesting to provide a ultra light
> > programming solution able to mix the high-level language FORTH and
> > assembly language. With an ARM, it seems pretentious to want to
> > compete GCC.
> 
> I guess that's a reasonable way to look at things, if you don't mind a
> heavyweight external toolchain.  I've thought of Forth on a small ARM
> more as a lightweight interactive configuration and debugging tool than
> as an implementation language, tbh.
> 
> For what it's worth I'm pretty sure there the 430 has a GCC target.  I
> know that the Atmega AVR's do.

Previously I programmed a small applications on a ATtiny861. The development time was very long. This is why I developed FAST FORTH on MSP430FR, so that I can test a correction of code two seconds after writing it, I'm happy!

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

#50923

On 9/12/2016 2:45 AM, Paul Rubin wrote:
> Jean-Michel Thoorens <jeanmichel.thoorens@gmail.com> writes:
>> FAST FORTH is small: < 6kb ...  MSP430FR5738...
>
> Do you think it could work on the MSP430G2553?  That one's of interest
> because of its PDIP package and use in the original Launchpad.
>
> Do you think TI cares much about the MSP430 line any more, vs. mostly
> concentrating on ARM?

Why would you think TI didn't care about the MSP430?  They sell a whole 
bunch of them and likely there is no ARM that will fill exactly the 
niche of some of the MSPs when you consider all the factors.

I think every processor can fit in mainstream sockets so the selection 
often is one of pennies for really high volumes or engineer's preference 
for lesser volumes (which makers don't really care much about).  It is 
the corner cases that determine which processor you use based on 
technical reasons.  Otherwise it is just price for the big jobs.  I 
don't think the MSP430 looses on price a lot and can often fit niches 
that other MCU lines don't necessarily fit.

-- 

Rick C

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

#50924

rickman <gnuarm@gmail.com> writes:
> Why would you think TI didn't care about the MSP430?  They sell a
> whole bunch of them and likely there is no ARM that will fill exactly
> the niche of some of the MSPs when you consider all the factors.

Well they are even giving the MSP designation to ARM cpus now (MSP432 is
based on Cortex M4).  Of course they'll keep shipping existing 430
models as long as people keep buying them, so my question is more about
whether there will keep being new designs.  I do get the impression that
there aren't that many new design wins for the 430.  There is apparently
some process limitation that prevents them from making ARMs with FRAM
but maybe they'll get around that somehow.

> Otherwise it is just price for the big jobs.  I don't think the MSP430
> looses on price a lot and can often fit niches that other MCU lines
> don't necessarily fit.

Well I mentioned a few niches, but as you say, they are niches.  I do
think designers care about future compatibility and capabilities as well
as the short-term price, and I dunno that the 430's are really cheaper
than ARMs for comparable parts, especially at the higher end.

I'm also awed by the low price of some of the Espressif wifi parts
(ESP8266 and so on).  They use a MIPS-inspired 32-bit instruction set
roughly comparable to a Cortex M3, not binary compatible but there's a
GCC toolchain for it.  I don't think they have any process advantages or
anything like that, so all I can think of is that they're lowering costs
by not having to pay ARM royalties.

Take a look at wemos.cc sometime -- their D1 wifi board is a favorite in
some circles around here.  It's crazy cheap, quite powerful, and runs
Lua (NodeMCU) and Micropython as well as the usual C stuff.

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

#50925

On 9/12/2016 9:57 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Why would you think TI didn't care about the MSP430?  They sell a
>> whole bunch of them and likely there is no ARM that will fill exactly
>> the niche of some of the MSPs when you consider all the factors.
>
> Well they are even giving the MSP designation to ARM cpus now (MSP432 is
> based on Cortex M4).  Of course they'll keep shipping existing 430
> models as long as people keep buying them, so my question is more about
> whether there will keep being new designs.  I do get the impression that
> there aren't that many new design wins for the 430.  There is apparently
> some process limitation that prevents them from making ARMs with FRAM
> but maybe they'll get around that somehow.

I think this is all speculation.  I don't watch MCUs as much as FPGAs so 
I haven't seen anything to indicate a lack of design wins.  It wouldn't 
seem impossible that the low end ARMs were capable of fitting most MSP 
sockets, but I don't know one way or the other.


>> Otherwise it is just price for the big jobs.  I don't think the MSP430
>> looses on price a lot and can often fit niches that other MCU lines
>> don't necessarily fit.
>
> Well I mentioned a few niches, but as you say, they are niches.  I do
> think designers care about future compatibility and capabilities as well
> as the short-term price, and I dunno that the 430's are really cheaper
> than ARMs for comparable parts, especially at the higher end.

If you are designing for high volume sockets all that really matters is 
a chip that will meet the requirements at the lowest price.  If a new 
requirement is added to a new product they start selection again.

I've seen this before where literally pennies determined the viability 
of a product.  They had a part selected and were in development but 
couldn't get the peripheral to work right.  It was something where they 
were using a feature in a corner case (or maybe just outside) and it 
just wasn't working right.  If he couldn't get the feature to work right 
it would cost another five cents and they would kill the project.  I 
don't think I ever found out how it turned out.


> I'm also awed by the low price of some of the Espressif wifi parts
> (ESP8266 and so on).  They use a MIPS-inspired 32-bit instruction set
> roughly comparable to a Cortex M3, not binary compatible but there's a
> GCC toolchain for it.  I don't think they have any process advantages or
> anything like that, so all I can think of is that they're lowering costs
> by not having to pay ARM royalties.

Has MIPS gone royalty free?


> Take a look at wemos.cc sometime -- their D1 wifi board is a favorite in
> some circles around here.  It's crazy cheap, quite powerful, and runs
> Lua (NodeMCU) and Micropython as well as the usual C stuff.

I've got a CPU in an FPGA module with bluetooth on board I want to get 
working.  I look at too many things and complete too few.

-- 

Rick C

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

#50926

rickman <gnuarm@gmail.com> writes:
> I've seen this before where literally pennies determined the viability
> of a product. 

I know things are like that for very high volumes but it's got to be
less extreme for moderate ones.

>> Espressif ... use a MIPS-inspired 32-bit instruction set
> Has MIPS gone royalty free?

My hazy understanding is something like:

1) Espressif doesn't license a core, they designed it themselves.
2) It's not literally a MIPS instruction set--it just resembles MIPS
   and presumably avoids any restrictions that would get in their way.
3) The early MIPS instruction sets are in fact currently royalty-free,
   though the current ones may be encumbered.
4) Some original MIPS people were/are involved with the Espressif
   company, so there is some MIPS heritage either way.

I'm not sure of any of the above, so any combination of it might be wrong.

> I've got a CPU in an FPGA module with bluetooth

For some reason bluetooth stuff is more expensive than wifi stuff these
days.  Royalties may have something to do with it.

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

#50945

On 9/12/2016 10:26 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> I've seen this before where literally pennies determined the viability
>> of a product.
>
> I know things are like that for very high volumes but it's got to be
> less extreme for moderate ones.

The moderate volume apps don't determine if a product is kept or dropped.

I remember speaking with a salesman once about an application for 
explosive fuses.  I think it was for a very tiny MCU that would be in 
the fuse.  The ultimate one time use application.  lol  They were 
cutting price to the bone and I think were even going to roll a special 
version of the MCU.  If this were a medium volume app it would have 
barely received the time of day from the factory team.


>>> Espressif ... use a MIPS-inspired 32-bit instruction set
>> Has MIPS gone royalty free?
>
> My hazy understanding is something like:
>
> 1) Espressif doesn't license a core, they designed it themselves.
> 2) It's not literally a MIPS instruction set--it just resembles MIPS
>    and presumably avoids any restrictions that would get in their way.

Ok, but...

> 3) The early MIPS instruction sets are in fact currently royalty-free,
>    though the current ones may be encumbered.
> 4) Some original MIPS people were/are involved with the Espressif
>    company, so there is some MIPS heritage either way.

In this case it works because Espressif is using the CPU internally to 
their parts.  A bastard offshoot of a mainstream processor won't get 
much attention from the large vendors because while specifics for a 
given design will change as a product matures, they often aren't willing 
to toss out the entire body of software and start over.  This is more 
the time required than the cost, time to market can be more important 
the few pennies mentioned before.  So a non-standard CPU can mean 
difficult porting when the newer CPU versions come out that enable newer 
versions of the products.

Espressif is happy with this core as they won't have any trouble 
supporting it but will have to fund the next generation themselves. 
Will they ever be price competitive if they have to break in the new 
process generation 100% on their own?  That can be expensive.  A company 
like Intel lives and dies by staying on the bleeding edge.  Espressif 
will find they are the AMD of the market always 6 months behind their 
competitors with higher power and slower speeds and larger dies while 
their competitors get the advantage of the ARM lever getting their 
product to market in the new process that much quicker.

There is a reason why so many companies are happy to pay ARM their 
royalties.


> I'm not sure of any of the above, so any combination of it might be wrong.
>
>> I've got a CPU in an FPGA module with bluetooth
>
> For some reason bluetooth stuff is more expensive than wifi stuff these
> days.  Royalties may have something to do with it.

Really?  Where do you see that?

-- 

Rick C

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web