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

Phil Harman pvharman at arach.net.au
Thu Apr 13 05:33:01 PDT 2006


Chris,

"I'm not sure I fully understand your comment that the USB port has to be
"polled"."

The spec for the FED 4550 USB interface states that you can't use any 
blocking code at all. Hence you have to call the USB functions at regular 
intervals or the USB I/O hangs.

BTW -  GNU USRP  uses bulk transfer in order to get a 32MBps transfer rate 
over USB 2.

Phil...
----- Original Message ----- 
From: "Christopher T. Day" <CTDay at lbl.gov>
To: <pvharman at arach.net.au>
Cc: "Eric Ellison" <ecellison at comcast.net>; "High Performance Software 
Defined Radio Discussion List" <hpsdr at hpsdr.org>
Sent: Thursday, April 13, 2006 7:20 PM
Subject: RE: [hpsdr] FW: hpsdr] [FPGA_USB] Review/Comments FPGA_USB 
Board -April 5, 2006


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





-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.1/309 - Release Date: 11/04/2006




-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.1/310 - Release Date: 12/04/2006


 1144931581.0


More information about the Hpsdr mailing list