[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