[hpsdr] Cyclone II with Nios core for SDR

[Murray Lang]

Thanks Bob.
Yes, the development kit comes with a C compiler. Threads are fun aren't 
they! So simple to create but so full of surprises.
Both pieces of DttSP are relevant here, but I won't get a clear picture 
of the best approach until I've played with the kit for a while. For 
example it would be nice to write a Jack look-alike library for the 
codec so that more of the reference code can be used verbatim, but 
niceties can be very time consuming.

BTW  I'm having CVS problems with DttSP, but I'll post to its mailing 
list if I can't resolve them.

Cheers,
Murray

Robert McGwier wrote:
> Murray:
>
> I have not done any NIOS programming but I presume there is a C compiler?
> The rate of bug repair on DttSP has slowed to a crawl because there 
> are very few bug reports on it anymore.   Frank and I have removed the 
> last of the threading lunacy content I put in to deal with what we 
> perceived as hardware switching problems with the SDR-1000 (which were 
> nonexistent).
>
> DttSP v 2.0 is two different pieces.  One is the library of routines 
> and the other is the reference implementation using jack as the audio 
> system and expecting a linux-like OS to be the host console/process.   
> You would need to replace these routines in main and update with 
> routines that will allow you to communicate with the FPGA/NIOS II core 
> and run your process under uC/OS-II RTOS.
>
> Good luck!
>
> Bob
>
>
> Murray Lang wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>> Hi Jay,
>> I know that you learn most from failures, but I need to be selective 
>> with my spare time these days.
>> I've only just discovered DttSP myself, but it seems as good a place 
>> as any to start. Nios is a DSP IP (Intellectual Property not Internet 
>> Protocol) core that drops into a Cyclone II FPGA and takes advantage 
>> of that FPGAs specialised multiplier elements. The development kit 
>> also comes with a Nios port of the uC/OS-II RTOS, which seems to have 
>> all of the threading and synchronisation primitives you would need. 
>> There's plenty of memory on the development board.
>>  
>> I suspect it would be more painstaking than difficult - replace POSIX 
>> thread and synch calls with uC/OS equivalents; replace FTTW calls 
>> with whatever the Nios libraries provide; replace I/O calls (now that 
>> could be painful). The biggest problems I've had in the past with 
>> porting between operating systems (apart from GUI inconsistencies) is 
>> where a different thread scheduling algorithm exposes incorrectness 
>> in thread synchronisation that didn't manifest in the original. Since 
>> DttSP has already been ported between Linux and Win32, any such bugs 
>> should have been smoked out.
>>
>> Anyway, in the absence of alarm bells I'll push ahead.
>>
>> Murray
>>
>>   
>


 1165970946.0