[hpsdr] Odyssey dsPIC33 RAM usage

[Frank Brickle]

On Tue, Jun 3, 2008 at 11:02 AM, Murray Lang <murray.lang at bbnet.com.au>
wrote:


> Anyway, it eventually occurred to me that if the connectors were queues and
> the calculation modules called by a central executive in a daisy chain then
> the whole thing was just a cooperative multitasking system. So in essence
> what I am looking to achieve is GNU Radio Lite, with the flow graph being
> just the arrangement of tasks. It probably won't stand up to any scrutiny.


One last observation about this, and then I will retire from haranguing you
and the group.

Is there some reason the connections can't be messages?  That kind of IPC is
not incompatible with cooperative multitasking, as shown by, for example,
GNU pth.

My interest in this approach was piqued especially by the way Erlang handles
messages with large binary payloads. In Erlang, when the sending and
receiving processes live within the same node -- essentially, when they
share an address space, as threads do within single processes -- then
payloads over a certain size aren't copied, they're stored on a special
heap, and the messages point to the heap locations. What makes this "safe"
is that the receiving process can't modify the payload. It does eliminate
copying overhead associated with the message passing, though.

One can imagine constructing a pool of buffers, associating the buffers with
messages, and endowing each calculation module with a mailbox of its own and
the ID of its successor mailbox. Reordering the calculations would then
amount to simply reassigning the successor mailboxes as needed. With one
level of indirection this would allow restructuring the algorithms on the
fly. Sequencing is thereby automatic, and there's no obstacle to making
independent subgraphs that get scheduled cooperatively.

Anyway, enough public rumination. Thanks for the chat.

73
Frank
AB2KT

-- 
The only thing we have to fear is whatever comes along next. -- Austin Cline
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20080603/c5ecd6ee/attachment-0003.htm>