[CCC DEV] The third button problem - update

[Matt Jadud]

(Bringing the dev list back in, because I think it's relevant.)

On Thu, Feb 10, 2011 at 11:26, Steve Pretty
<steve.g.pretty at btinternet.com> wrote:
> Thanks for your brainstorming thoughts!
>
> How much memory does a CHAN require (e.g. a CHAN INT)?

I think a word. (All channels are just a word, regardless of the size
of data they communicate... if I recall correctly.) The channel word
is where the synchronization primitives do their work.

> "building blocks" are then "wired" together by a set of CHANs.   Well, that
> is the way that the Plumbing book leads you to think about the way a "basic

Yep. That's the right model. And, it's a pretty good way to think
about parallel programming, in general. (There are other models, but
getting one model right is a good step.)

> user" might be using the library.  Clearly, if a CHAN is expensive in RAM
> (an of course we only have 1 or 2Kbytes) that will place a constraint on how
> large a net the user can assemble.  Each "building block" will also need
> some RAM.

Yes. But, you're also using RAM for variables, and loop counters,
and... so. It is possible to max out RAM, but lately, I've been maxing
out flash on the smaller AVRs before RAM. Fortunately, RAM needs are
known at compile-time, so you don't get surprised at runtime.

Normally, I don't worry about RAM usage for channels, but here we have
a design that uses large arrays of channels... which, perhaps we can
get rid of. That's not a bad optimization to make, perhaps?

Truly, we're still developing our understanding of what kind of
(useful) programs we can write in these spaces. I have a sensor
project that maxes out flash on a 328 device, and used up the RAM on a
1280. (I think it did, anyway.) However, I haven't looked closely to
see  how we might improve the occam-level code in that case.

Ultimately, it would be nice to be on an ARM with 256K+ of flash and
64K or more RAM. That would be really, really comfortable.

Cheers,
M