[hpsdr] FW: hpsdr] [FPGA_USB] Review/Comments FPGA_USB Board -April 5, 2006

[Christopher T. Day]

Phil,

I'm sure any code you have would be really useful. I'd love to have it.
Not having a good compiler will clearly be a pain, though.

I'm not sure I fully understand your comment that the USB port has to be
"polled". From my reading of the spec, I would have thought that with
the Transfer Complete interrupt bit, TRNIE, enabled you'd be interrupt
driven, and using the PingPong Buffering would mean that you always
owned a buffer to work with for the interrupting endpoint. True, if
you're trying to send an audio stream with Bulk Transfers - I guess the
only thing possible over something that looks like a COM port at the PC
end - you'll be really busy moving the data around. But then I get to
jump back on my Isochronous Transfer hobby-horse and claim that's how
the transfers should be done; then I could enable the Streaming Serial
Port, hand that descriptor permanently over to the USB engine and the
CPU wouldn't be involved in the audio transfers at all. Of course, there
would have to be something with some intelligence attached to the SSP,
but don't we all believe we're supposed to heave an FPGA or CPLD or
something like that at that part of the problem?

Anyway, this is rather early-morning, pre-coffee ramblings for me, so it
could easily make no sense.


	Chris - AE6VK




-----Original Message-----
From: pvharman at arach.net.au [mailto:pvharman at arach.net.au] 
Sent: Wednesday, April 12, 2006 5:59 PM
To: Christopher T. Day
Cc: Eric Ellison; High Performance Software Defined Radio Discussion
List
Subject: Re: [hpsdr] FW: hpsdr] [FPGA_USB] Review/Comments FPGA_USB
Board -April 5, 2006

Hi Chris,

I did manage to get the 10 bit A/D converter on the 18F4550 to act as a
mic 
input and send it over the USB interface to the PC. Bill, KD5TFD wrote
some 
Java code that read from the PC side (the 18F4550 looks like an
additional COM 
port) and allowed me to view the data. 

It was very obvious then that the Full Speed USB was not going to be
fast 
enough for all the functions we wanted in the HPSDR. 

The 18F4550 needs its USB port to be continually polled so your code
becomes a 
state machine. I wrote quite a lot of test code for the chip and I think
it is 
fine for a project were you want to replace an RS232 interface with USB.


The FED C compiler, which at the time we started was the only one that 
supported the USB on the 18F4550, was and is full of bugs, even for a
hobby 
project I would not use it. That's a shame since the concept is very
good and 
the simulation facilities, if they always worked, would be a great help.

I've written quite a lot of C code for the PIC in the past and have
always 
used the CCS compiler - also has plenty of bugs but you could usually
find a 
stable release and resist the urge to take the next upgrade - not sure
if they 
support USB on the 4550 as yet. 

Let me know if you want my sample code for the FED compiler. 

73's  Phil...VK6APH 



 1144927219.0