this isn't exactly GNU Radio, but porting librtlsdr to Plan 9 would enable interesting signal processing applications. it would be doable as a GSoC project since the majority of the work would involve switching from libusb to Plan 9's usb (this was a project suggestion for 2013).
there are several useful apps that use rtlsdr, written in C and portable to Plan 9 (AM/FM receiver, AIS, ADS-B, etc.). alternatively, Plan 9 nodes can be a receiver network to feed GNU Radio running on another OS. On Wed, Feb 5, 2014 at 6:41 AM, Shane Morris <[email protected]> wrote: > You mention the word "heterogeneous" but I think it should take this tack: > > For what I'd like to do, I would require GNU Radio running on the host > (ie, ARM) CPU. GNU Radio isn't going to run under Plan 9 on an ARM target, > as much as I'd like. You also mention "to be (much) more interesting than a > standard ARM..." but in effect, it already is. > > I could be barking up the wrong tree here, and I made a suggestion of > Styx-on-a-chip to ease development times, and also student commitment, it > will have to talk to Linux at the end of the day, lets start now? > > > On Wed, Feb 5, 2014 at 11:46 PM, erik quanstrom <[email protected]>wrote: > >> > Oh, its ok. I like the GSoC idea. I just don't think I'm GSoC material, >> I'm >> > hardware type, even if I will be a uni student this year going forward - >> > "If it draws blood, its hardware" as the old maxim goes. >> >> it's great to hear the enthusiam, but sadly, it seems over >> ambitious. >> >> to work with this heterogeneous co-processor with the usual tools, >> and be any more interesting than a standard arm, i think at least >> the following needs to be done >> 1. bootstrap the arm processor get plan 9 running. >> 1a. program the fpga with adapteva's binary blob. >> 1b. drivers for a minmal set of devices. >> 2. write a compiler/assembler/linker for the epiphany multicore; >> populate /epi/include. a emulator may need to be written. >> 3. write the libmach hooks for the same >> 4. write the asm for /sys/src/lib*/epi (or at least libc) >> 5. decide what kind of operating framework the epi >> should have, and write the appropriate glue. it's not >> clear to me that a standard kernel could work at all. >> (what kind of coherence model is there?) >> >> this can't be done by one gsoc student in a summer. >> and there's the open ended question of how to use the >> epi coprocessor. >> >> a very bright, gifted, experienced, stubborn, and diligent >> student might have some hope of accomplishing 1/1a or >> a significant part of 2. but that's a stretch. 3, 4 seem >> to be properly sized for one student gsoc. 5 is unknown. >> >> so, in order to have something usable at the end, one would >> need 5 students, 5 mentors, someone to do 1b, and sort of a >> scrum master to help coordinate. >> >> i see several serious risks to this idea. >> a. what if we get less than 5 students, or mentors, or slots? >> b. sadly, not all students complete the summer. how do we >> recover if even one person drops out? >> c. do we have someone qualified to be scrum master for >> 10 people (5 students and 5 mentors)? with enough time? >> d. 5 is open ended. >> >> this seems too big a leap, given the student success rate is >> not yet 100%. >> >> so if you're a student still excited about this project, reframing >> the problem so that it stands alone (even if it's just bootstrapping >> the arm chip) seems like the best option to me. >> >> now i could be wrong or overly pessamistic, so i'd love to >> hear other opinions. >> >> - erik >> > >
