Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.forth
Subject: Re: New "Forth" MCU Board, ChipStick
Date: Tue, 05 Apr 2016 02:12:56 -0700
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <87zit8pgfb.fsf@nightsong.com>
References: <ndhuv2$4tk$1@dont-email.me> <ndkpnd$v2j$3@dont-email.me> <bcb78e3b-795d-4106-82d5-706f3934e0c5@googlegroups.com> <ndl4tn$asv$1@dont-email.me> <33379c59-49ee-48ba-8d72-24d6d78a5971@googlegroups.com> <ndm9u4$m6l$2@dont-email.me> <ab27ccfd-afa1-4f89-b055-f22973503669@googlegroups.com> <ndojvl$54v$1@dont-email.me> <c39e30dd-0b92-4f0a-b1bf-c141f73ec751@googlegroups.com> <8737r3sloc.fsf@nightsong.com> <092057c0-e91f-49cf-8d69-506df8d03b1d@googlegroups.com> <87y48vql51.fsf@nightsong.com> <dec96967-7877-4606-83b2-f7540b4c260f@googlegroups.com> <87twjhrk9l.fsf@nightsong.com> <0273c125-c337-4fd0-8073-e9355b4ddc9b@googlegroups.com> <nduj3c$ait$1@dont-email.me> <d94afd83-1fc8-454d-9abb-b064ea08971a@googlegroups.com> <878u0sr2wy.fsf@nightsong.com> <cc8245c4-e0fb-44b6-b1c9-5dbd6c635c01@googlegroups.com> <ndvou9$n15$1@dont-email.me> <50caa4ea-c3eb-4cf6-aed1-204ee234434b@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="52eac348160ce62b68e4635eee7cc854"; logging-data="10406"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19qk8IWsT5xzayvH3bEvCxD"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:4y8DCY1kq2YWOCFM7mSv6g1M7RA= sha1:kc1YH2Ch3xBqUr1jpYdvN/cBrNg=
Xref: csiph.com comp.lang.forth:46519

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> Speaking of FRAM, I know that the FRAM memory has limited number of
> cycles for both read and write - not only for write like the flash.
> 10^14 is quite a number, but when executing a program from FRAM
> (read cycles) that can be not enough... especially on tight loops...
> Maybe this is the reason TI included some normal SRAM on the chips?

I don't know about read wear, but yes, that's why there's SRAM, which is
also a little bit faster than FRAM.  I'd put the stacks and address
interpreter and a few other critical things in SRAM and the rest in FRAM
or off-chip flash.  That might use 0.5k of SRAM leaving a fair amount
for user code and variables that they could put there.

FRAM sounds way better than flash since you don't have to erase pages
(slow and burns energy etc).  You just update it a word at a time like ram.