[hpsdr] Odyssey dsPIC33 RAM usage
Murray Lang
murray.lang at bbnet.com.au
Tue Jun 3 08:02:35 PDT 2008
Frank Brickle wrote:
...
> There isn't enough asynchronicity (?) to justify multitasking.
...
> If we had time to get fancy we'd be using freeRTOS, but that's mostly
> for the insult, not because it's needed.
> ...
freeRTOS looks very interesting and I'm looking forward to trying it
out. The reason I'd be looking at a cooperative multitasking kernel is
not for the logical concurrency but for the decoupling, though I don't
know if what I'm imagining can be neatly achieved with a 3rd party product.
The genesis of this line of thinking was the concept of calculation
modules joined by connectors. This is not original and is exemplified by
GNU Radio, though in my mind the connectors were distinct surface level
entities and the graph built by modules logically connecting to them
rather than to each other. The relationships could be static or modified
at run-time (eg switching in filters or reconfiguring between TX and
RX). Ideally the (C) code that joined everything could be generated by
some graphical tool. I like the GNU Radio approach of gluing things
together in Python but it limits the potential targets.
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.
> It's not *exactly* on point, but there's an old article from the
> Computer Music Journal, ...etc
Found the TOC but can't get to the body.
Thanks again.
Murray VK6HL
--
"Can't repeat myself...can't repeat myself." - Bono.
1212505355.0
More information about the Hpsdr
mailing list