Re: [Discuss-gnuradio] Re: Help with Verilog: write_count

[Eric Blossom]

On Mon, Nov 20, 2006 at 03:30:06AM -0800, seph 004 wrote:
>
> 
> >   I changed the host code by removing the multiplier for the "max
> >   bytes" argument. I assumed that this would let me send the exact
> >   number of bytes that the user entered. For my final application,
> >   I'm only looking to store a very small number of samples on the
> >   FPGA.
> 
> 
> >   If this was the wrong modification to the host code, then how
> >   exactly would one go about sending a small number of samples (say
> >   400 I and Q samples) without breaking the code?
> 
> You can send any multiple of 128 complex samples.  No need to hack the
> host library. Take your pick: 128, 256, 384, 512
> 
> Eric

> Am I correct in saying then that the max_bytes variable determines
> the number of samples sent? 

I'm not sure of which max_bytes variable you are referring to.

> I'm not sure but the verilog seemed to be able to cope if the number
> of samples was some other value besides 128 or any multiple of it.

Nope.  It knows how to deal with _only_ 512 byte packets.  
Remember those questions about WR & ~count[8]?

> I'd really like to be able to control the number of samples that go
> to the board exactly.

> Regards
> Lance


If you want to control the exact number of bytes that go to the board,
you're going to have some work to do.

If 384 samples is OK, then just wire up a gr.vector_source_c to a
usrp.sink_c and you're done.  Just provide the vector_source_c with a
list of 384 complex values.  It will send them, then stop.

I suggest that you start by reading the USB 2.0 spec, particularly the
part about the peripheral.  IIRC it's chapter 9.  You'll be sending
"short" writes across the USB.  Neither our host code, nor our
firmware knows how to deal with those.

You can generate an arbitrary write using the libusb "usb_bulk_write"
method, but at that point you are on your own.  You will have to hack
the host code, the FX2 code and the verilog.  Note also that your
throughput will go down (you're basically throwing away all the "fast
usb" code).

If you're patient, the in-band signaling plus mblocks that we're
talked about on the list will get you closer.  All of this is unlikely
to come together until sometime in Q1.   Good progress is being made
on the mblocks, but we have yet to actually start refactoring all the
USRP host and verilog code.

Good luck!
Eric