Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: blocks and overlays question Date: Tue, 27 Sep 2016 15:36:17 -0700 Organization: A noiseless patient Spider Lines: 19 Message-ID: <87wphx3r8e.fsf@jester.gateway.pace.com> References: <87inth5hk5.fsf@jester.gateway.pace.com> <87eg455e41.fsf@jester.gateway.pace.com> <8760ph5b3g.fsf@jester.gateway.pace.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="2aed369a7b4699bde3e169ff4d831123"; logging-data="32100"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5YYj/UqJMTuNyRcHcVz5n" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:QCuV7QKT8LLoJC31bzei0GTM8ys= sha1:VpyO8DF9akSlEC5NBSpOQFBlobI= Xref: csiph.com comp.lang.forth:51409 "Elizabeth D. Rather" writes: >> with the ability to reclaim the ram using overlays, compiling from >> source sounds more attractive. > Much simpler and cleaner. I think this can even be ok even if it's compile-to-flash like with several of the existing MCU Forths. >> How many block buffers did a usable block system actually need > Two is a minimum for decent operation. Beyond that, it really depends > on how much RAM you have and other issues. With flash, you want to > minimize writes. Good point--if the system is logging data or otherwise frequently updating flash pages, write wear is an issue. If flash is only written occasionally (like when someone edits code and saves it) then it probably doesn't matter, if it's good for a few thousand cycles. The chip also has a few bytes of NVRAM in case a measurement or two needs to be updated a lot and survive power cuts.