Re: [Discuss-gnuradio] updated packet format on USRP inband signaling

[Eric Blossom]

On Mon, Feb 26, 2007 at 04:39:32PM -0500, Brian Padalino wrote:
> On 2/26/07, Eric Blossom <address@hidden> wrote:
> >On Mon, Feb 26, 2007 at 09:44:37PM +0100, Martin Dvh wrote:
> >> MASKED_WRITE:
> >> What I also miss is a masked write to registers:
> >> Write Register:
> >>
> >>           Opcode:     OP_WRITE_REG_MASKED
> >>
> >>          
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>          |     Opcode    |       6       |    mbz    |     Reg Number    
> >|
> >>          
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>          |                        MASK                                   
> >|
> >>          |                        Register Value                         
> >|
> >>          
> >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >> A Masked write would save you from needing to do a read, modify,
> >> write over the BUS when you only want to change a single bit.
> >
> >Good idea.  I'll add it.
> 
> Can't the host figure out what the new value should be using its
> shadowed values?  Under which circumstances would you want to use the
> mask without the host already knowing the contents of the register if
> it had already been written?

If there are multiple processes running on the host(s) that can send
commands, then shadows don't work out well.

Also, although we've been talking about USB, I'm hoping to use what we
come up with in this conversation for the Gigabit ethernet interface
too.  So far, the main difference I see is that ethernet packets are
variable length.

> Another concern I had was with multiple read commands and the
> timestamp.  If a control packet is sent down with multiple read
> commands and a timestamp of NOW - the first read is done ASAP and the
> timestamp field filled with the current time.  Is this the way it
> should work, or should the timestamp represent the time the last piece
> of data was read?  Should there be some other type of message which
> states a second timestamp at the end of the received control packet to
> say how long it took for the operation to complete?

I'm for keeping it as simple as possible.  Absent a compelling use case
for some other behavior, I suggest that we pick some intepretation
(either the beginning or the end of processing) for the timestamp on
the reply packet.   I'm leaning towards "beginning", which is similar
to the interpretation of the timestamp on IN packets.

One could also imagine a scenario where one of the registers that was
readable was mapped to the time base.  Then your READ_REG_REPLY
would have _that_ time in it ;)

Eric