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

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

double tasking with two interpreters

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

Contents

  double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-27 15:47 -0700
    Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-27 13:58 -1000
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-27 18:35 -0700
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-27 20:14 -0700
        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-27 18:38 -1000
    Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-28 12:08 -0400
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 09:21 -0700
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-28 10:11 -0700
        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 07:24 -1000
          Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 11:11 -0700
            Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 11:23 -1000
              Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 14:36 -0700
                Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 12:52 -1000
                  Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 17:14 -0700
                    Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 15:33 -1000
                      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-28 18:53 -0700
                        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-28 22:34 -1000
                        Re: double tasking with two interpreters Dirk Bruehl <dirk.bruehl@usa.net> - 2012-05-29 14:57 -0700
            Re: double tasking with two interpreters Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-29 22:16 +0200
              Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-29 10:57 -1000
                Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-29 14:23 -0700
          Re: double tasking with two interpreters Rugxulo <rugxulo@gmail.com> - 2012-05-29 00:22 -0700
      Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-28 12:42 -0400
        Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-28 13:07 -0400
          Re: double tasking with two interpreters Coos Haak <chforth@hccnet.nl> - 2012-05-28 21:39 +0200
        Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-29 12:56 +0000
      Re: double tasking with two interpreters Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-29 22:12 +0200
    Re: double tasking with two interpreters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-29 08:19 +0000
    Re: double tasking with two interpreters stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-29 11:52 +0000
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-29 11:17 -0700
        Re: double tasking with two interpreters stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-29 20:15 +0000
          Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 09:12 -0700
            Re: double tasking with two interpreters Dirk Bruehl <dirk.bruehl@usa.net> - 2012-05-30 20:20 -0700
      Re: double tasking with two interpreters Dirk Bruehl <dirk.bruehl@usa.net> - 2012-05-29 11:25 -0700
    Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-29 12:52 +0000
      Re: double tasking with two interpreters stephenXXX@mpeforth.com (Stephen Pelc) - 2012-05-29 13:29 +0000
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-29 08:29 -0700
        Re: double tasking with two interpreters John Passaniti <john.passaniti@gmail.com> - 2012-05-29 14:24 -0700
          Re: double tasking with two interpreters Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-30 01:59 -0700
            Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 03:05 -0700
              Re: double tasking with two interpreters Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-30 03:19 -0700
                Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 08:24 -0700
            Re: double tasking with two interpreters John Passaniti <john.passaniti@gmail.com> - 2012-05-30 07:20 -0700
              Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-31 11:32 +0000
                Re: double tasking with two interpreters John Passaniti <john.passaniti@gmail.com> - 2012-06-01 07:07 -0700
      Re: double tasking with two interpreters "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-05-29 11:55 -0400
        Re: double tasking with two interpreters "Elizabeth D. Rather" <erather@forth.com> - 2012-05-29 08:23 -1000
      Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-29 11:39 -0700
        Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-29 12:26 -0700
        Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-30 09:34 +0000
          Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 03:02 -0700
            Re: double tasking with two interpreters Arnold Doray <invalid@invalid.com> - 2012-05-30 14:10 +0000
              Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-30 08:34 -0700
                Re: double tasking with two interpreters Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-31 11:44 +0000
                  Re: double tasking with two interpreters Alex McDonald <blog@rivadpm.com> - 2012-05-31 07:02 -0700
            Re: double tasking with two interpreters BruceMcF <agila61@netscape.net> - 2012-05-31 07:17 -0700
      Re: double tasking with two interpreters David Kuehling <dvdkhlng@gmx.de> - 2012-05-31 10:09 +0200
        Re: double tasking with two interpreters Paul Rubin <no.email@nospam.invalid> - 2012-05-31 02:07 -0700

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

#12572

"Elizabeth D. Rather" <erather@forth.com> writes:
> What's unclear to me is the availability of the big one for user code.

Yes, it is available for user code.  "Preprogrammed" means it comes in
the box with a demo application that blinks the LEDs.  It's flash memory
so you can overwrite that program with your own program.  Take a look at
4e4th.eu for a Forth-preprogrammed version (click the UK flag at the
upper right of the white box with the German text).

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

#12539

Hi,

On May 28, 12:24 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 5/28/12 6:21 AM, Paul Rubin wrote:
>
> > We're talking about a microcontroller with 128 bytes of ram and 2k of
> > program flash.  There are no other processes, OS, or anything like that ;-).
>
> That's pretty small! So, when you say you want to run "two interpreters"
> I assume you mean "address interpreters"? Usually an unmodified
> "interpreter" in Forth means text interpreter, which you definitely
> don't have room for!

I hate to intrude, esp. since I have no tips, but I just had to
mention this (though caveat that I don't know its internals well, and
I'm no embedded pro):

http://en.wikipedia.org/wiki/Atari_2600

MOS 6507 @ 1.19 MHz, 128 bytes RAM, 4 kB ROM, introductory price: 199
USD, retail availability Oct. 14, 1977 (U.S.)

Heck, even later, we weren't much further along, comparatively:

http://en.wikipedia.org/wiki/Atari_Lynx

MOS 65SC02 @ 3.6 Mhz w/ Suzy (16-bit custom CMOS cpu @ 16 Mhz), 64 kb
RAM, 128-512k ROM, $179 USD, 1989 (U.S.)

...

My point is: sheesh, they still sell things that are as weak as the
2600? I've vaguely heard woes about how "painful" it was to code for
the 2600, esp. since it had so little RAM. Heck, even the ROMs were
too small, which is one of the main reasons (among others) why the
official 2600/VCS "port" of Pac-Man sucked so bad (4 kb ROM) while the
later port of Ms. Pac-Man (8 kb ROM) was much much better.

Okay, I'm way out of my element here, just found it interesting.   ;-)

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

#12519

"Rod Pemberton" <do_not_have@notemailntt.cmm> wrote in message
news:jq07rf$rcp$1@speranza.aioe.org...
> "Paul Rubin" <no.email@nospam.invalid> wrote in message
> news:7xmx4tckcg.fsf@ruckus.brouhaha.com...
...

> Some of the registers, e.g.,
> IP, W, and TOS, are basically independent of Forth words, but others,
e.g.,
> DP and RP, aren't.  Forth stack words are dependent on DP and RP, yes?

Sorry, I was thinking SP but wrote DP ...
That goes for the rest of post too, SP and RP.


RP

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

#12520

"Rod Pemberton" <do_not_have@notemailntt.cmm> wrote in message
news:jq09sj$1g3$1@speranza.aioe.org...
> "Rod Pemberton" <do_not_have@notemailntt.cmm> wrote in message
> news:jq07rf$rcp$1@speranza.aioe.org...
> > "Paul Rubin" <no.email@nospam.invalid> wrote in message
> > news:7xmx4tckcg.fsf@ruckus.brouhaha.com...
> ...
>
> > Some of the registers, e.g., IP, W, and TOS, are basically independent
> > of Forth words, but others, e.g., DP and RP, aren't.  Forth stack words
> > are dependent on DP and RP, yes?
>
> Sorry, I was thinking SP but wrote DP ...
> That goes for the rest of post too, SP and RP.
>

Argh...

Maybe I should've asked if DP meant "data pointer" or "dictionary
pointer".  If data, then my original reply was correct.  If dictionary, then
my "sorry" reply is correct.


RP

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

#12530

Op Mon, 28 May 2012 13:07:36 -0400 schreef Rod Pemberton:

> "Rod Pemberton" <do_not_have@notemailntt.cmm> wrote in message
> news:jq09sj$1g3$1@speranza.aioe.org...
>> "Rod Pemberton" <do_not_have@notemailntt.cmm> wrote in message
>> news:jq07rf$rcp$1@speranza.aioe.org...
>>> "Paul Rubin" <no.email@nospam.invalid> wrote in message
>>> news:7xmx4tckcg.fsf@ruckus.brouhaha.com...
>> ...
>>
>>> Some of the registers, e.g., IP, W, and TOS, are basically independent
>>> of Forth words, but others, e.g., DP and RP, aren't.  Forth stack words
>>> are dependent on DP and RP, yes?
>>
>> Sorry, I was thinking SP but wrote DP ...
>> That goes for the rest of post too, SP and RP.
>>
> 
> Argh...
> 
> Maybe I should've asked if DP meant "data pointer" or "dictionary
> pointer".  If data, then my original reply was correct.  If dictionary, then
> my "sorry" reply is correct.
> 
> 
> RP

DP is the user variable that containst the value of HERE

: HERE DP @ ;
: ALLOT DP +! ;

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#12546

In article <jq09sj$1g3$1@speranza.aioe.org>,
Rod Pemberton <do_not_have@notemailntt.cmm> wrote:
>"Rod Pemberton" <do_not_have@notemailntt.cmm> wrote in message
>news:jq07rf$rcp$1@speranza.aioe.org...
>> "Paul Rubin" <no.email@nospam.invalid> wrote in message
>> news:7xmx4tckcg.fsf@ruckus.brouhaha.com...
>...
>
>> Some of the registers, e.g.,
>> IP, W, and TOS, are basically independent of Forth words, but others,
>e.g.,
>> DP and RP, aren't.  Forth stack words are dependent on DP and RP, yes?
>
>Sorry, I was thinking SP but wrote DP ...
>That goes for the rest of post too, SP and RP.

That (and SSP) is the reason I promote naming those DSP adn RSP.

>
>
>RP
>
>


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

#12567

Rod Pemberton wrote:

> "Paul Rubin" <no.email@nospam.invalid> wrote in message
>> Is this silly?
> 
> My first impression is: "No, it's not silly."

I think this is silly.  Why not just exchange the few registers you need 
in the PAUSE code?  For TOS+SP+RP+IP, you need a total of 12 moves (or 
xors if you don't like tmp registers ;-) to get the two sets exchanged.

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

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

#12540

Paul Rubin <no.email@nospam.invalid> writes:
[Only two tasks]
>I'm wondering if it's a known, sensible method, to simply have two
>copies of the address interpreter, one of them using (say) R0 through
>R4, and the other using R5 through R9, to hold the DP, RP, TOS, etc.
>Then a task switch would just mean jumping from one interpreter to the
>other.

There are some consequences:

If you want to do tranditional indirect or direct-threaded code, you
don't just have to duplicate the primitives, but everything that calls
that that you use in the given task.  And you would have to compile
your code specifically for the task.  And you have to enhance the
dictionary structure and compiler to support all that.  That does not
sound attractive.

An alternative would be to have a different inner interpreter.  I
think a good option would be indirect threading with two code fields.
I.e., the header would look like this:

Name field
Link field
Code Field 1 (used by interpreter 1)
Code Field 2 (used by interpreter 2)
Body

The CFAs/XTs (in colon definition bodies, and for passing to EXECUTE)
would always point to code Field 1.  Interpreter 2 would add the
offset for using Code Field 2 inside NEXT (depending on the CPU this
might not cost extra).  CREATE/DOES> is left as an exercise to the
reader.

I don't think that this method is known, although there is some
related work in implementing Prolog's read/write modes in
interpreters.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2012: http://www.euroforth.org/ef12/

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

#12544

On Sun, 27 May 2012 15:47:27 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>While most programs are single task and some are multi-tasking with N
>tasks, a significant bunch (say for bidirectional i/o on some port) use
>exactly two tasks.  A classic thread Forth uses 4 or 5 registers in the
>address interpreter and a multitasker has to swap these around to some
>storage area on task switch, burning cycles and memory.  The MSP430
>variant I'm looking at has just 128 bytes of ram, so it's not plentiful.
>
>I'm wondering if it's a known, sensible method, to simply have two
>copies of the address interpreter, one of them using (say) R0 through
>R4, and the other using R5 through R9, to hold the DP, RP, TOS, etc.
>Then a task switch would just mean jumping from one interpreter to the
>other.

Although it's good intellectual effort to ask how to fit into such
constrained environments, you should also ask why you should do so.

You can have a Cortex-M0 at lower price and power with more memory
and resources. US$0.55 in volume from Nuvoton or ST.

MSP430 is becoming more popular because the Lauchpads cost $4.30.
We got Nuvoton and some STM32 boards for less. My Raspberry Pi
cost a bit more but came in a much smaller box than a Launchpad.

Stephen (the modernist one)

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

#12560

stephenXXX@mpeforth.com (Stephen Pelc) writes:
> Although it's good intellectual effort to ask how to fit into such
> constrained environments, you should also ask why you should do so.

That's what's available on these boards ;-).

> You can have a Cortex-M0 at lower price and power with more memory
> and resources. US$0.55 in volume from Nuvoton or ST.

I looked into this a little, I saw some around 70 cents in qty 5000 at
digi-key, still pretty good.  But, the package is quite a bit larger and
I think the power consumption is higher, than what's available in
MSP430's, or (even smaller) AVR8's, PIC's, etc.  There is an AVR in a
2*2mm package that can run an RTC on around 2 microwatts of power.[1]
MSP430's are a bit bigger, but still pretty small.

> MSP430 is becoming more popular because the Lauchpads cost $4.30.
> We got Nuvoton and some STM32 boards for less.

Interesting.  Do they have anything like the retail accessibility of the
Launchpads, and comparable FOSS toolchains and so on?

> My Raspberry Pi cost a bit more but came in a much smaller box than a
> Launchpad.

Lucky you, RPi's are about $200 on ebay right now.  Apparently new
orders currently are being quoted November delivery dates.

Aside from that, the RPi is a tiny workstation using something like 300
mA at 5 volts, while a Launchpad is more easily embeddable and uses
around 1 mA on unregulated 2-3V when active, and near zero power when
idle.

> The real problem is the assumption of 128 bytes. Why deal with
> the 1970s in the 2010s?

In that case, remind me again why we're talking about Forth ;-).

----

[1] http://embeddedsystemnews.com/atmels-tinyavr-flash-avr-microcontroller-package.html

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

#12569

On Tue, 29 May 2012 11:17:39 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>> MSP430 is becoming more popular because the Lauchpads cost $4.30.
>> We got Nuvoton and some STM32 boards for less.
>
>Interesting.  Do they have anything like the retail accessibility of the
>Launchpads, and comparable FOSS toolchains and so on?

There are a gazillion free and FOSS toolchains for ARM and Cortex.
MPE has broken them all at one time or another. Start with Code
Sourcery. But note that significant Forth developments come from
the vendors, especially for embedded systems.

In terms of hobby access, look for the STM32F4 Discovery board (yum,
yum) and the STM32F0 board. Whether it's $4.30 or $12, who cares?
Personally, I think it's a USAnian disease to worry about hardware
price alone. At board level, the cost of silicon is rapidly declining
towards zero, leaving the cost of the board dependent on the PCB
and the volume.

Yes, you probably can achieve slightly less idle power with a an
MSP430, but what matters is system consumption. There are several
people, e.g. Energy Micro, who will argue that system consumption
on a Cortex-M3 is better than that of an MSP430.

We have clients who use ARMs for underwater instrumentation, and
they report that the new hardware uses less overall power than the
previous 16 bit hardware. The 32 bit systems are just so much more
power efficient at doing the crunching.

>> The real problem is the assumption of 128 bytes. Why deal with
>> the 1970s in the 2010s?
>
>In that case, remind me again why we're talking about Forth ;-).

Because Forth moved on significantly about 10-15 years ago and the 
functionality per 100kb of Forth cannot be beat. Even with the
text interpreter left in. Once you accept the changes of the 
modern world, you can stop worrying about 128 bytes on an
embedded system. You can have full-blown text interpreter and
life becomes quite delightful again.

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]

#12610

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>>> We got Nuvoton and some STM32 boards for less. ...
> There are a gazillion free and FOSS toolchains for ARM and Cortex.

I remember looking into the STM32 boards and finding they need
proprietary tools, but maybe I missed something.  I certainly didn't
think of them as operating in the same space as the Launchpad or Arduino
(i.e. very low power control-oriented device).  Maybe I'm wrong about
the toolchain:

  http://cu.rious.org/make/stm32f4-discovery-board-with-linux/

It looks attractive other ways too:

  http://www.ecnmag.com/products/2011/10/stm32f4-discovery-kit-now-available

> In terms of hobby access, look for the STM32F4 Discovery board (yum,
> yum) and the STM32F0 board. Whether it's $4.30 or $12, who cares?

The STM32F4 appears to be about $15, still very affordable.  The
Launchpad is attractive in that I can load some code, attach a battery
to it, and slap it into something without worrying about it for a long
time.  It can probably run for months on a penlight cell.

>>In that case, remind me again why we're talking about Forth ;-).
> Because Forth moved on significantly about 10-15 years ago

I tried to figure out what significant change came to Forth 10-15 years
ago, and found:

   Forth has been a recognized programming language since the
   1970's. ColorForth is a redesign of this classic language for the
   21st century. It also draws upon a 20-year evolution of minimal
   instruction-set microprocessors. Now implemented to run under
   Windows, it can also stand-alone without an operating system.

I'm not sure if that's what you had in mind ;-)

> you can stop worrying about 128 bytes on an embedded
> system. You can have full-blown text interpreter and life becomes
> quite delightful again.

It looks like I can have a text interpreter on the bigger Launchpad chip
(16k flash, 0.5k ram), which could be pretty cool.  Now if there were
just an ultra-cheap Bluetooth interface, I could control it from a
phone.  I don't know why the embeddable ones I can find are so
expensive.  Hmm, maybe I could use an audio interface instead (plug
cable between Launchpad and the phone's mic/headphone socket, with
low-speed software modems at each end).

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

#12626

On 30 Mai, 12:12, Paul Rubin <no.em...@nospam.invalid> wrote:
>
> The STM32F4 appears to be about $15, still very affordable.  The
> Launchpad is attractive in that I can load some code, attach a battery
> to it, and slap it into something without worrying about it for a long
> time.  It can probably run for months on a penlight cell.

If $15 is not a problem, you may look at TI's MSP-EXP430FR5739
Experimenter Board for $29 with 16KB FRAM / 1KB SRAM - you can run it
on a penlight cell much longer, FRAM values are safe even without
battery! May be you only need a super cap to run it for several month!

Shortly after I started with Forth in 1984 I read about FRAM, and
recently the FRAM microcontroller, the micro of my dreams, came into
life: In my opinion the MSP430FR5739 is the ideal microcontroller to
run Forth on it - doesn't have FLASH, only mostly nonvolatile RAM
(16k) to store programs and data. That's why I encouraged Michael to
put a Forth on it: look at http://www.camelforth.com - Contributed:
MSP430 FRAM (MSP-EXP430FR5739) or at http://www.forth-ev.de/repos/CF430FR/

There is enough room on it to establish your special double task
feature.

DB.

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

#12562

On 29 Mai, 07:52, stephen...@mpeforth.com (Stephen Pelc) wrote:
>
> You can have a Cortex-M0 at lower price and power with more memory
> and resources. US$0.55 in volume from Nuvoton or ST.
>

I never heard about Nuvoton before, so I googled for Nuvoton, and I
read "Nuvoton Technology Corp. was founded upon future expectation to
create a new era by innovative inspiration." Nuvoton is a 2008 Winbond
spin off based in Taiwan.

They have a myriad of different types of ARM micros at Nuvoton, and a
myriad of distributors is listed on their webpage - but no part
related link.

The smallest Nuvoton ARM device is $2.18, the MSP430G2553 is $2.64,
each per single unit @ DigiKey.
Operating current of the Nuvoton Mini51 series is 4mA @ VDD = 3.3V at
12 MHz,
operating current of TI's MSP430G2553 is 3mA @ VDD = 3.3V at 12 MHz.
Both have sleep modes, and while the MSP430 Standby Mode is specified
with 0.5 μA,
the Mini51 Standby Mode is specified with 10 μA.
The smallest Mini51 is 33-pin QFN, the MSP430G2553 is the same size or
20pin TSSOP, and is available as 20pin DIP, which is important for
people like me.

> MSP430 is becoming more popular because the LaunchPads cost $4.30.
> We got Nuvoton and some STM32 boards for less.

Stephen, please share your knowledge about these Nuvoton and some
STM32 boards which you got for less. I found two boards at www.nuvoton.com,
the NuTiny-Mini51 SDK ($28.50 @ DigiKey) and the Nu-LB-Mini51 ($48.45
@ DigiKey). Ten time as much as the LaunchPad - more powerful, I am
sure, but that's not the point.

STM ARM boards start with $7.99 @ Mouser, $49.60 @ DigiKey.

How much would I have to pay to get a board for educational purposes
containing Forth?

Regards,
Dirk Bruehl.

> My Raspberry Pi
> cost a bit more but came in a much smaller box than a Launchpad.
>
> Stephen (the modernist one)
>
> --
> Stephen Pelc, stephen...@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]

#12545

In article <7xmx4tckcg.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>I'm looking at the MSP430, whose instruction architecture is sort of
>like a PDP-11, with less regularity in the address modes, but the upside
>is that it has 16 registers (a few of them special purpose) instead of 8.
>
>While most programs are single task and some are multi-tasking with N
>tasks, a significant bunch (say for bidirectional i/o on some port) use
>exactly two tasks.  A classic thread Forth uses 4 or 5 registers in the
>address interpreter and a multitasker has to swap these around to some
>storage area on task switch, burning cycles and memory.  The MSP430
>variant I'm looking at has just 128 bytes of ram, so it's not plentiful.
>
>I'm wondering if it's a known, sensible method, to simply have two
>copies of the address interpreter, one of them using (say) R0 through
>R4, and the other using R5 through R9, to hold the DP, RP, TOS, etc.
>Then a task switch would just mean jumping from one interpreter to the
>other.
>
>Is this silly?

With all due respect yes. The greatest problem with 128 bytes of
RAM is to fit 2 stacks and a user area. With 2 tasks those areas
have to be duplicated.

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]

#12547

On 29 May 2012 12:52:14 GMT, Albert van der Horst
<albert@spenarnc.xs4all.nl> wrote:

>>Is this silly?
>
>With all due respect yes. The greatest problem with 128 bytes of
>RAM is to fit 2 stacks and a user area. With 2 tasks those areas
>have to be duplicated.

The real problem is the assumption of 128 bytes. Why deal with
the 1970s in the 2010s?

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]

#12553

On May 29, 9:29 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> The real problem is the assumption of 128 bytes. Why deal with
> the 1970s in the 2010s?

Because those are the devices on the sub-$10 board in question?

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

#12573

On Tuesday, May 29, 2012 9:29:19 AM UTC-4, Stephen Pelc wrote:
> The real problem is the assumption of 128 bytes. 
> Why deal with the 1970s in the 2010s?

Many of the systems I've worked on in the past-- and many that I continue to work on-- are multiprocessor systems.  The main processor may be a big 32-bit microcontroller, but it's not the only processor in the system.  In one recent system, we offloaded the processing needed for the front panel (32 12-segment LED bargraphs, a character LCD, a bunch of switches) onto a small 8-bit microcontroller, freeing the main processor of updating all that and making the interface simpler.  The same system had a network audio card that for legacy reasons had a parallel bus interface, but the module on that card was serial.  Slapping a tiny 8-bit microcontroller there was the way we bridged those two worlds.  Another system had a small 8-bit microcontroller that acted as a system-level supervisory watchdog.

Here's another example:  We're considering using the i.MX28 (an ARM-based SoC from Freescale) for an upcoming project.  Unfortunately, it's SPI implementation is painful and to get around that pain, we're going to need to either write a lot of clever code on the i.MX28 or we're going to have to do something externally.  I'm advocating going external and we'll likely use a small 8-bit microcontroller with a lot of I/O pins to handle the SPI issues and absorb a lot of the "glue" logic that we need.  

The people who believe that 8-bit microcontrollers-- especially tiny ones-- are dead are the people who apparently don't have to be concerned with costs or who haven't yet figured out that factoring in hardware (by using multiprocessing) can make systems simpler and easier.

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

#12584

On May 29, 10:24 pm, John Passaniti <john.passan...@gmail.com> wrote:
> On Tuesday, May 29, 2012 9:29:19 AM UTC-4, Stephen Pelc wrote:
> > The real problem is the assumption of 128 bytes.
> > Why deal with the 1970s in the 2010s?
>
> Many of the systems I've worked on in the past-- and many that I continue to work on-- are multiprocessor systems.  The main processor may be a big 32-bit microcontroller, but it's not the only processor in the system.  In one recent system, we offloaded the processing needed for the front panel (32 12-segment LED bargraphs, a character LCD, a bunch of switches) onto a small 8-bit microcontroller, freeing the main processor of updating all that and making the interface simpler.  The same system had a network audio card that for legacy reasons had a parallel bus interface, but the module on that card was serial.  Slapping a tiny 8-bit microcontroller there was the way we bridged those two worlds.  Another system had a small 8-bit microcontroller that acted as a system-level supervisory watchdog.
>
> Here's another example:  We're considering using the i.MX28 (an ARM-based SoC from Freescale) for an upcoming project.  Unfortunately, it's SPI implementation is painful and to get around that pain, we're going to need to either write a lot of clever code on the i.MX28 or we're going to have to do something externally.  I'm advocating going external and we'll likely use a small 8-bit microcontroller with a lot of I/O pins to handle the SPI issues and absorb a lot of the "glue" logic that we need.
>
> The people who believe that 8-bit microcontrollers-- especially tiny ones-- are dead are the people who apparently don't have to be concerned with costs or who haven't yet figured out that factoring in hardware (by using multiprocessing) can make systems simpler and easier.

Not at all. Why use an 8-bit part, if you can buy a 16-bit part for
the same price? Have you actually looked at the price of the MSP430
family in quantity? They're cheap as chips. They pack a whole range of
IO features, and have flash and RAM all inside the chip, reducing
board layout costs and PCB sizes, power consumption, and heat
dissipation. They're every bit as good as any 8-bit MCU I can recall,
though being 16-bit makes them a lot better IMHO. 8-bit processors
rapidly become a fiddly pain in the arse if you want to do any math -
16 bit makes it a bit easier, especially as they usually come with 32
bit multiply and divide, whereas most 8 bit parts have no MUL/DIV at
all.

Regarding your 8 bit MCU driving 32 12 segment displays, how, and why?
Why wouldn't you use discrete bar drivers? That's what they're for.
Did your 8 bit MCU have 32 ADCs? Clearly not. So how did you multiplex
32 audio signals into (possibly one?) ADC channel, and how did you
multiplex the output to each individual bar display. And how did you
do this fast enough that the displays were accurate? I presume the bar
displays were scaled in db's? How did you multiplex the input, perform
the calculation (I guess it could be a simple look-up), and the
multiplex the output fast enough to update 32 bar graph's in real time?

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

#12589

Mark Wills <markrobertwills@yahoo.co.uk> writes:
> though being 16-bit makes them a lot better IMHO. 8-bit processors
> rapidly become a fiddly pain in the arse if you want to do any math -
> 16 bit makes it a bit easier, especially as they usually come with 32
> bit multiply and divide,

The cheap msp430's that run in the launchpad don't have mul/div either.
The multiplier in the models that have it is fairly fast as such things
go, though.

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

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

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

csiph-web