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 1 of 3  [1] 2 3  Next page →

#12509 — double tasking with two interpreters

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?

[toc] | [next] | [standalone]

#12510

On 5/27/12 12:47 PM, Paul Rubin 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?

Well, I think there are simpler ways. Assume you have one register 
(called U) pointing to the status area of the "current" user or task, 
and one register each for the current task's S and R. User variables 
contain the parameters that control its interpreter (and other things); 
they are accessed via the U register. Assuming further that all task 
switches take place in Forth words such as STOP or PAUSE (i.e., not 
interrupt code), then all you need to do is push R onto the data stack, 
save S in the user area, and change U to the next task. Very fast task 
switch, and the current task has the use of all the registers.

I agree, the MSP430 has a lovely instruction set.

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]

#12511

"Elizabeth D. Rather" <erather@forth.com> writes:
> Well, I think there are simpler ways. Assume you have one register
> (called U) pointing to the status area of the "current" user or task,
> and one register each for the current task's S and R. 

OK, but now you no longer have the optimizations of keeping TOS and the
instruction pointer in registers, most of the machine registers are
being left unused, and you're consuming more memory with that stuff that
could have been in registers.  Avoiding all that was the idea of having
a separate register subset for each task.

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

#12512

On May 27, 9:35 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erat...@forth.com> writes:
>
> > Well, I think there are simpler ways. Assume you have one register
> > (called U) pointing to the status area of the "current" user or task,
> > and one register each for the current task's S and R.
>
> OK, but now you no longer have the optimizations of keeping TOS and the
> instruction pointer in registers, most of the machine registers are
> being left unused, and you're consuming more memory with that stuff that
> could have been in registers.  Avoiding all that was the idea of having
> a separate register subset for each task.

If you have one register for the User page, one for S and R, and eight
registers available for use, you could have a shadow register for TOS
and S and push IP and R onto S.

So there's 7 registers in use: ,R ,S ,S' U TOS IP and IP'.

If you are toggling, you can have the two distinct task switches as
independent task switch operations, with the pending task switch
stored in the task switch vector register. So rather than a task
switch vector per user page, there's only one RAM location for the
task-switch. When task switch 1 runs, it stores the vector for task
switch 2 and visa versa.

So the task switch would be:

Task 1:
(1) Store Task2 task switch in SWITCH vector location
(2) Stores User1 base in U
(3) Jump to common task switch ...

Task 2:
(1) Store Task1 task switch in SWITCH vector location
(2) Stores User2 base in U
(3) Jump to common task switch ...

Common:
(1) Push TOS then ,R on S
(2) Swap S and S'
(3) Swap IP and IP'
(4) NEXT

I don't know that processor, but generically, if there is not register
swap instruction, there is a free register to execute the register
swaps.

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

#12513

On 5/27/12 3:35 PM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> Well, I think there are simpler ways. Assume you have one register
>> (called U) pointing to the status area of the "current" user or task,
>> and one register each for the current task's S and R.
>
> OK, but now you no longer have the optimizations of keeping TOS and the
> instruction pointer in registers, most of the machine registers are
> being left unused, and you're consuming more memory with that stuff that
> could have been in registers.  Avoiding all that was the idea of having
> a separate register subset for each task.

You can certainly keep TOS in a register... just one more thing to push 
on the stack and pop off again (1 instruction each). As for I, it is set 
from the top of the return stack when a task wakes up.

And the rest of the machine registers are hardly "unused" -- they're 
available for the code that's running.

When we're addressing the task of implementing Forth on a new processor, 
register allocation and usage is the first and most important 
consideration in the design. I suggest that you download the SwiftX 
evaluation version for the MSP430 and spend some time reading the 
manual, in the parts that describe register utilization and the 
multitasker.  It'll give you a lot of ideas. That is, of course, a cross 
compiler, but as I recall it can run an interpreter in the target.

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]

#12517

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:7xmx4tckcg.fsf@ruckus.brouhaha.com...
> 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?

My first impression is: "No, it's not silly."  But, I'm not familiar with
MSP430.  Is there a "known, sensible method" for it?  I don't know.


I'd think the idea is sound if:

1) both sets of the "4 or 5 registers" is not corrupted by other processes,
tasks, applications, etc such as the OS, i.e, preserved.  That way, you
don't need to save and restore those registers between task switches.
That reduces overhead.

2) you are using two sets of stacks.  I.e., each task has it's own
data/parameter stack and return/control-flow stack.  That prevents one task
from corrupting the other upon a task switch.  Of course, you've stated that
two of those registers will be DP and RP.  So, you may have taken care of
this issue already.

If done that way, to switch tasks, you'd only need to switch stacks and use
the other register set.  Of course, every low-level word or primitive that
directly accesses a specific register will need two versions ... one for
each register set.  That could be an issue.  You might try to make sure only
the low-level address interpreter word(s), e.g., NEXT, use the registers,
and the low-level Forth words, i.e., stack words, e.g., R> >R DUP SWAP,
don't use registers ...  If you can do that, then you only need to duplicate
a small number of words, one for each register set.  But, I'm not exactly
sure how you'd limit register usage that much.  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?  And,
there are quite a handful of Forth stack words, yes?  E.g., if >R needs to
access both DP and RP to move data, you'd need a >R specific for each
register set, yes?  How do you get >R to use, say, register R3 for task #1
and use, say, register R8 for task #2?  This sort of implies to me that DP
and RP might need to be/use the same two registers for both tasks, and be
saved/restored on each task switch.  This way you wouldn't have to rewrite
all those stack operations.  Or, maybe you need to code a branch which uses
a flag into each stack word to select which register to use...

Am I correctly understanding what you are trying to do?


Rod Pemberton

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

#12518

"Rod Pemberton" <do_not_have@notemailntt.cmm> writes:
> My first impression is: "No, it's not silly."  But, I'm not familiar with
> MSP430.  Is there a "known, sensible method" for it?  I don't know.

Well, what I actually meant by "known sensible method" "do other systems
do it that way?".

>
> I'd think the idea is sound if:
>
> 1) both sets of the "4 or 5 registers" is not corrupted by other processes,
> tasks, applications, etc such as the OS, i.e, preserved. 

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 ;-).

> Of course, every low-level word or primitive that
> directly accesses a specific register will need two versions 

That's a good point.  Maybe there could be a common entry sequence for
such words, that canonicalizes the register assignment.  On the other
hand it would impose a few instructions of overhead on each such call,
including for frequent words like DUP or SWAP, to save a few
instructions on the presumably less frequent operation of task
switching.

Thanks.

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

#12521

On May 28, 12:21 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> That's a good point.  Maybe there could be a common entry sequence for
> such words, that canonicalizes the register assignment.  On the other
> hand it would impose a few instructions of overhead on each such call,
> including for frequent words like DUP or SWAP, to save a few
> instructions on the presumably less frequent operation of task
> switching.

That's why you have one data stack and one return stack register in
use. If you want to have exactly two tasks, and want to avoid using
RAM for register storage, you can shadow a register. But unless that
processor has an atomic register swap, you'll need a spare register to
do the swap:

Store #U1/#U2 in U
Store ST in X
Store S in ST
Store X in ST

... as opposed to:
Store S in U,0
Store #U1/#U2 in U
Store U,0 in S

So you save two RAM locations at the cost of dedicating a register.

You can get rid of the next task information storage entirely if you
are toggling two tasks, since you can *infer* the new U from the
current U. Easiest if to place U1 at address 0, and U2 immediately
following, so if each U has, say, 16 bytes, then in pseudo-assembly

SWITCH:
   LOAD [X] with [TOST]
   LOAD [TOST] with [TOS]
   LOAD [TOS] with [X]
   LOAD ([R])-- with [IP]
   LOAD {[S])-- with [R]
   LOAD [X] with [ST]
   LOAD [ST] with [S]
   LOAD [S] with [X]
   TEST [U] with #0
   BREQ SWITCH1
   LOAD [U] with #0
   BRAN SWITCH2
SWITCH1:
   LOAD [U] with #16
SWITCH2:
   JUMP ([IP])++

That uses eight registers [S] [ST] [TOS] [TOST] [R] [U] [IP] [X]
... and if its a cooperative toggle, you have one extra slot on the
current return and data stacks in between task switches, so the
occasional register hungry primitive can push TOS onto S and IP onto R
at the outset and pop them back at the end, and you have three work
registers.

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

#12523

On 5/28/12 6:21 AM, Paul Rubin wrote:
> "Rod Pemberton"<do_not_have@notemailntt.cmm>  writes:
>> My first impression is: "No, it's not silly."  But, I'm not familiar with
>> MSP430.  Is there a "known, sensible method" for it?  I don't know.
>
> Well, what I actually meant by "known sensible method" "do other systems
> do it that way?".
>
>>
>> I'd think the idea is sound if:
>>
>> 1) both sets of the "4 or 5 registers" is not corrupted by other processes,
>> tasks, applications, etc such as the OS, i.e, preserved.
>
> 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!

SwiftX could certainly generate a cross-compiled target program for 
that, but it would be helpful to have a larger MSP430 around for 
interactive testing.

>> Of course, every low-level word or primitive that
>> directly accesses a specific register will need two versions
>
> That's a good point.  Maybe there could be a common entry sequence for
> such words, that canonicalizes the register assignment.  On the other
> hand it would impose a few instructions of overhead on each such call,
> including for frequent words like DUP or SWAP, to save a few
> instructions on the presumably less frequent operation of task
> switching.

We usually assign a few registers to running the Forth VM: S and R 
(stack pointers), I (interpreter pointer) and U (user pointer). T (TOS) 
if there are enough registers. An ITC needs one more, W (word pointer, 
the word being called, and also the access into the data space of 
words). The rest (accumulators) are designated as scratch, and always 
available to words without saving and restoring.

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]

#12528

"Elizabeth D. Rather" <erather@forth.com> writes:
> 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, 

Yes, I mentioned in the original post, two address interpreters.
I figure the text interpreter would be on a tethered host.

> SwiftX could certainly generate a cross-compiled target program for
> that, but it would be helpful to have a larger MSP430 around for
> interactive testing.

There is a bigger MSP430 with iirc 16k of program flash and 512 bytes of
ram, that can apparently run an interactive Forth (Camelforth based,
www.4e4th.eu - there was a thread about it a while back).

Apparently recent TI Launchpads are being shipped with the bigger
processor, though it's still advertised as coming with the smaller one.
I've continued to think in terms of the smaller one for "production"
purposes.

If you made an evaluation download of a tethered SwiftForth for the
Launchpad board, it could get to be pretty popular, I imagine.

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

#12532

On 5/28/12 8:11 AM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> 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,
>
> Yes, I mentioned in the original post, two address interpreters.
> I figure the text interpreter would be on a tethered host.
>
>> SwiftX could certainly generate a cross-compiled target program for
>> that, but it would be helpful to have a larger MSP430 around for
>> interactive testing.
>
> There is a bigger MSP430 with iirc 16k of program flash and 512 bytes of
> ram, that can apparently run an interactive Forth (Camelforth based,
> www.4e4th.eu - there was a thread about it a while back).
>
> Apparently recent TI Launchpads are being shipped with the bigger
> processor, though it's still advertised as coming with the smaller one.
> I've continued to think in terms of the smaller one for "production"
> purposes.
>
> If you made an evaluation download of a tethered SwiftForth for the
> Launchpad board, it could get to be pretty popular, I imagine.

The default target kernel for a tethered SwiftX (that's the 
cross-compiler series) is about 6K, so it still wouldn't fit on the 
basic Launchpad. It's possible to strip that down to <1K, but that 
doesn't leave a lot of functionality.

For only $59 you can get the EZ430-RF2500 (MSP430F2274, 32K flash, 1K 
SRAM), and SwiftX runs fine on that. It would give you a lot more room 
for interesting development.

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]

#12533

"Elizabeth D. Rather" <erather@forth.com> writes:
> The default target kernel for a tethered SwiftX (that's the
> cross-compiler series) is about 6K, so it still wouldn't fit on the
> basic Launchpad. It's possible to strip that down to <1K, but that
> doesn't leave a lot of functionality.

Hmm, I'm surprised it's that large, but if the new Launchpads
start "officially" using the bigger (16k) chip, then it's fine.

> For only $59 you can get the EZ430-RF2500 (MSP430F2274, 32K flash, 1K
> SRAM), and SwiftX runs fine on that.

I think you know what a Launchpad costs, so the EZ430-RF2500 is pretty
expensive by comparison.

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

#12535

On 5/28/12 11:36 AM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> The default target kernel for a tethered SwiftX (that's the
>> cross-compiler series) is about 6K, so it still wouldn't fit on the
>> basic Launchpad. It's possible to strip that down to<1K, but that
>> doesn't leave a lot of functionality.
>
> Hmm, I'm surprised it's that large, but if the new Launchpads
> start "officially" using the bigger (16k) chip, then it's fine.

Well, it "throws in" a set of things that seem most useful. Since it's 
supplied in source, it's entirely configurable. And there's a "strip" 
function that you can apply when you have your application all finished 
and running that automatically deletes words that are never called.

>> For only $59 you can get the EZ430-RF2500 (MSP430F2274, 32K flash, 1K
>> SRAM), and SwiftX runs fine on that.
>
> I think you know what a Launchpad costs, so the EZ430-RF2500 is pretty
> expensive by comparison.

Yeah, but still not much. It really all depends on what one wants to use 
it for.

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]

#12536

"Elizabeth D. Rather" <erather@forth.com> writes:
> Well, it "throws in" a set of things that seem most useful. Since it's
> supplied in source, it's entirely configurable. And there's a "strip"
> function that you can apply when you have your application all
> finished and running that automatically deletes words that are never
> called.

I see, it's sort of a runtime library, and it's preloaded by default so
that when you poke at it interactively, everything you need is there
ahead of time.  I could imagine a cross compiler keeping up with you as
you type--so when you refer to a word, it goes and loads it for you on
the fly--but that's likely more trouble than it's worth.

Meanwhile I do see that the current Launchpad Quick Start Guide

 * http://www.ti.com/lit/ml/slac432a/slac432a.pdf

says "LaunchPad includes a pre-programmed MSP430G2553 device" (that is
the bigger device with the 16k of flash).  The marketing stuff still
says it comes with the smaller (2k) part.  So this is cool.

>> I think you know what a Launchpad costs, so the EZ430-RF2500 is pretty
>> expensive by comparison.
>
> Yeah, but still not much. It really all depends on what one wants to
> use it for.

Yeah, if I were a hardware developer intending an end target of a custom
circuit, using a fancy dev system would be worth it, but I'm more
interested in running stuff directly on Launchpads.

Meanwhile I see that TI has just released source code for the PC side of
the Launchpad boot loader:

  http://www.43oh.com/2012/05/ti-releases-bsl-for-the-msp430/

That might be useful (either directly or as guidance for how the process
works) if you want to support the board with Swift.

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

#12537

On 5/28/12 2:14 PM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> Well, it "throws in" a set of things that seem most useful. Since it's
>> supplied in source, it's entirely configurable. And there's a "strip"
>> function that you can apply when you have your application all
>> finished and running that automatically deletes words that are never
>> called.
>
> I see, it's sort of a runtime library, and it's preloaded by default so
> that when you poke at it interactively, everything you need is there
> ahead of time.  I could imagine a cross compiler keeping up with you as
> you type--so when you refer to a word, it goes and loads it for you on
> the fly--but that's likely more trouble than it's worth.

Yes, it's a runtime library with lots of capabilities, 34 files last 
time I counted. It's really a lot easier, I think, for you to look at 
the list of things loaded and, once you've made some progress on your 
application, take out stuff you know you don't need. Here's the list for 
the EZ:

\ FILES INCLUDED BY BUILD

INCLUDE %SWIFTX\SRC\MSP430\REG_22x4   \ MSP430F2274 hardware equates
INCLUDE %SWIFTX\SRC\MSP430\CONFIG     \ Common configuration
INCLUDE CONFIG                        \ Target configuration
INCLUDE %SWIFTX\SRC\MSP430\USER       \ User variables
INCLUDE %SWIFTX\SRC\MSP430\CORE       \ Core word set
INCLUDE %SWIFTX\SRC\CORE              \ Common core words
INCLUDE %SWIFTX\SRC\MSP430\EXTRA      \ Miscellaneous extensions
INCLUDE %SWIFTX\SRC\MSP430\STRING     \ Core string operators
INCLUDE %SWIFTX\SRC\STRING            \ Core string operators
INCLUDE %SWIFTX\SRC\MSP430\EXCEPT     \ Exception handling
INCLUDE %SWIFTX\SRC\MSP430\DOUBLE     \ Double-precision numbers
INCLUDE %SWIFTX\SRC\DOUBLE            \ Double-precision numbers
INCLUDE %SWIFTX\SRC\MSP430\MATH       \ Core math operators
INCLUDE %SWIFTX\SRC\MIXED             \ Mixed-precision operators
INCLUDE %SWIFTX\SRC\MSP430\OPT        \ Initialize code optimizer
INCLUDE %SWIFTX\SRC\VIO               \ Vectored I/O functions
INCLUDE %SWIFTX\SRC\EXCEPT            \ Common exception handling
INCLUDE %SWIFTX\SRC\OUTPUT            \ Core & facility output functions
INCLUDE %SWIFTX\SRC\OUTPUT2           \ Double output functions
INCLUDE %SWIFTX\SRC\NUMBER            \ Numeric input conversion
INCLUDE %SWIFTX\SRC\METHODS           \ Methods and VALUE
INCLUDE %SWIFTX\SRC\MSP430\TASKER     \ Multitasker
INCLUDE %SWIFTX\SRC\TOOLS             \ Debug tools
INCLUDE %SWIFTX\SRC\DUMP1             \ Memory dump
INCLUDE %SWIFTX\SRC\MSP430\VECTORS_RAM \ Interrupt vectors
INCLUDE %SWIFTX\SRC\MSP430\LPM        \ Low Power Mode control
INCLUDE %SWIFTX\SRC\MSP430\XTL        \ JTAG cross-target link
INCLUDE %SWIFTX\SRC\MSP430\STEPPER    \ Single-step debug support
INCLUDE %SWIFTX\SRC\ACCEPT            \ Generic terminal input
INCLUDE %SWIFTX\SRC\MSP430\TIMERA-ALT \ Timer A timing functions
INCLUDE %SWIFTX\SRC\TIMING            \ Common timing functions
INCLUDE %SWIFTX\SRC\MSP430\FLASH      \ Resident flash programming
INCLUDE APP                           \ **YOUR APPLICATION LOADED HERE**
INCLUDE %SWIFTX\SRC\MSP430\START      \ Common initialization
INCLUDE %SWIFTX\SRC\MSP430\EZ430-RF2500\START   \ Power-up init.

(sorry, I had to squinch the lines up to prevent wraparound in my email 
editor).

> Meanwhile I do see that the current Launchpad Quick Start Guide
>
>   * http://www.ti.com/lit/ml/slac432a/slac432a.pdf
>
> says "LaunchPad includes a pre-programmed MSP430G2553 device" (that is
> the bigger device with the 16k of flash).  The marketing stuff still
> says it comes with the smaller (2k) part.  So this is cool.

What does "preprogrammed" mean? Presumably some sort of debugger with 
the target support for the bootloader. SwiftX wouldn't use any of that 
stuff (it has its own equivalents), so I wonder if it would be possible 
to reprogram it? Probably locked, though.

>>> I think you know what a Launchpad costs, so the EZ430-RF2500 is pretty
>>> expensive by comparison.
>>
>> Yeah, but still not much. It really all depends on what one wants to
>> use it for.
>
> Yeah, if I were a hardware developer intending an end target of a custom
> circuit, using a fancy dev system would be worth it, but I'm more
> interested in running stuff directly on Launchpads.

The EZ430-RF2500 is awfully small and cute, too, and a lot more capable.

> Meanwhile I see that TI has just released source code for the PC side of
> the Launchpad boot loader:
>
>    http://www.43oh.com/2012/05/ti-releases-bsl-for-the-msp430/
>
> That might be useful (either directly or as guidance for how the process
> works) if you want to support the board with Swift.

We'd be a lot more interested if there were a more useful target processor.

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]

#12538

"Elizabeth D. Rather" <erather@forth.com> writes:
> \ FILES INCLUDED BY BUILD
> ...

Lots of stuff, looks useful.
>> says "LaunchPad includes a pre-programmed MSP430G2553 device" 
> What does "preprogrammed" mean? Presumably some sort of debugger

I think it means it's programmed with an LED blinking demo application.
The boot loader if I understand correctly is in ROM and communicates
with a formerly closed PC application, the source code of which is just
released, making it easier to write the host side of a tethered system.

>> the Launchpad boot loader: ..
> We'd be a lot more interested if there were a more useful target processor.

The target processor seems quite nice.  16k of flash, 0.5k of ram,
counters and timers and uarts galore, a/d and d/a converters, etc.  This
is quite a bit better than the AVR8 stuff in the lower Arduinos from
what I can tell, or the 8051, etc.  There are also some even fancier
MSP430'S that won't fit in the Launchpad but that there are also
inexpensive TI boards for.

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

#12541

On 5/28/12 3:53 PM, Paul Rubin wrote:
> "Elizabeth D. Rather"<erather@forth.com>  writes:
>> \ FILES INCLUDED BY BUILD
>> ...
>
> Lots of stuff, looks useful.
>>> says "LaunchPad includes a pre-programmed MSP430G2553 device"
>> What does "preprogrammed" mean? Presumably some sort of debugger
>
> I think it means it's programmed with an LED blinking demo application.
> The boot loader if I understand correctly is in ROM and communicates
> with a formerly closed PC application, the source code of which is just
> released, making it easier to write the host side of a tethered system.
>
>>> the Launchpad boot loader: ..
>> We'd be a lot more interested if there were a more useful target processor.
>
> The target processor seems quite nice.  16k of flash, 0.5k of ram,
> counters and timers and uarts galore, a/d and d/a converters, etc.  This
> is quite a bit better than the AVR8 stuff in the lower Arduinos from
> what I can tell, or the 8051, etc.  There are also some even fancier
> MSP430'S that won't fit in the Launchpad but that there are also
> inexpensive TI boards for.

The MSP430G2553 looks usable, although it's awfully convenient to have a 
little more RAM to download code for testing before you add it to the 
kernel in flash. The smaller processors don't seem very useful, though.

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]

#12574

On 28 Mai, 21:53, Paul Rubin <no.em...@nospam.invalid> wrote:
> ... There are also some even fancier
> MSP430'S that won't fit in the Launchpad but that there are also
> inexpensive TI boards for.

Are you writing about TI's MSP-EXP430FR5739 Experimenter Board ?

DB.

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

#12568

Paul Rubin wrote:
> Apparently recent TI Launchpads are being shipped with the bigger
> processor, though it's still advertised as coming with the smaller
> one.

You actually get both - the big and the small one.

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

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

#12571

On 5/29/12 10:16 AM, Bernd Paysan wrote:
> Paul Rubin wrote:
>> Apparently recent TI Launchpads are being shipped with the bigger
>> processor, though it's still advertised as coming with the smaller
>> one.
>
> You actually get both - the big and the small one.
>

What's unclear to me is the availability of the big one for user code.

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]

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web