On 26/05/11 05:01PM, Rodrigo Alencar wrote:
> On 26/05/11 10:23AM, David Lechner wrote:
> > On 5/11/26 10:02 AM, Rodrigo Alencar wrote:
> > > On 26/05/11 09:46AM, David Lechner wrote:
> > >> On 5/10/26 4:30 AM, Rodrigo Alencar wrote:
> > >>> On 26/05/09 06:42PM, David Lechner wrote:
> > >>>> On 5/8/26 12:00 PM, Rodrigo Alencar via B4 Relay wrote:
> > >>>>> From: Rodrigo Alencar <[email protected]>
> > >>>>>
> > >>>>> Add documentation for the AD9910 DDS IIO driver, which describes
> > >>>>> channels,
> > >>>>> DDS modes, attributes and ABI usage examples.
...
> > >>>>> +Digital ramp generator (DRG)
> > >>>>> +----------------------------
> > >>>>> +
> > >>>>> +The DRG produces linear frequency, phase or amplitude sweeps using
> > >>>>> dedicated
> > >>>>> +hardware. It is controlled through three channels: a parent control
> > >>>>> channel
> > >>>>> +(``digital_ramp_generator``) and two child ramp channels
> > >>>>> +(``digital_ramp_up``, ``digital_ramp_down``). DRG destination is set
> > >>>>> when
> > >>>>> +ramp attributes are written, i.e. writing to ``frequency`` or
> > >>>>> ``frequency_roc``
> > >>>>> +sets the destination to frequency.
> > >>>>
> > >>>> Would it be better to say that the destination is set when the the
> > >>>> value is non-zero? Otherwise, how would one change the destination
> > >>>> once set?
> > >>>
> > >>> Destination is only one, so you just need to write phase or phase_roc,
> > >>> if you want
> > >>> to target phase then. Does that not sound intuitive?
> > >>
> > >> I was thinking about if you needed to change the configuration.
> > >> If you set it to phase, then want to change it to frequency, how
> > >> could you do that if 0 is a valid value for phase?
> > >>
> > >> Also how could you know which is selected by reading back the
> > >> values if 0 is a valid value?
> > >
> > > This is where Jonathan raised some concerns, so it is a good oportunity
> > > for you
> > > to provide your inputs! Right now, I am returning -EBUSY on read of an
> > > attribute
> > > where its destination is not selected. As pointed out, the destination
> > > selection
> > > is happening when writting to the attribute. In the previous patch,
> > > Jonathan
> > > suggested frequency_active, phase_active and scale_active to track mode
> > > priority,
> > > and It could be leveraged here for DRG destination selection. I havent
> > > gone for
> > > that because I was not willing to add that to all the channels given that
> > > it is
> > > mostly used for debugging, so I added frequency_source, phase_source and
> > > amplitude_source to debugfs instead.
> >
> > The "last write wins" with the others changing to EBUSY makes more sense to
> > me now. If the docs said that, I missed it. Otherwise, that would be a
> > helpful
> > thing to add to the docs here.
> >
> > >
> > > Destination selection for RAM mode is firmware based at this point.
> >
> > Seems reasonable.
> >
> > > Destination selection for Parallel mode is still not clear... could use
> > > those *_active attributes or separate channels.
> >
> > Since there are _offset attributes proposed for parallel input already,
> > could we just make it the same where you have to write one of those
> > attributes?
>
> Different from the DRG, both RAM and Parallel mode has this extra polar
> destination, which targets both amplitude and phase at the same time.
>
> For parallel mode I have the attributes:
> - frequency_scale: applied when destination is frequency
> - frequency_offset: applied when destination is frequency
> - scale_offset: applied when destination is polar
> - phase_offset: applied when destination is polar
>
> In parallel mode, there aren't knobs like those for amplitude and phase
> destinations. With the *_active thing or similar, polar can be both
> phase_active and scale_active enabled at the same time. However, this
> would not behave the same way Jonathan suggested, i.e. to be used for
> mode priority indication... it would be used for destination configuration
> instead.
I was thinking, and it might be good to define this now because of the
fact I might need to create other 3 channels for the parallel mode (Maybe
that is fine and we can create them later if needed).
One thing to note is that in parallel mode, although the format pins (F0, F1)
that defines the parallel destination are synchronized with PDCLK (parallel port
clock), we cannot really send multiple formats in a single session, so we
cannot interleave destinations. Then, if having separate channels we would need
to contraint that (only one destination works at a time) with the available
scan masks.
Now, also related to the IIO backend support but for the DRG channel...
Anticipating new ABI for the IIO backend, currently I have the following to
expose ramp control from the FPGA IP:
- toggle_en: To allow the backend to control DRCTL pin, toggling it in response
to DROVER, according to the configured dwell modes.
- ramp_delay: the delay between ramp sweeps in seconds
- burst_count: amount of ramps in a burst of ramps
- burst_delay: delay between bursts in seconds (valid when burst_count > 0)
Would also be good if I can get a comment on those! Maybe toggle_en can be
removed as the other ones only make sense when there is dwell and when this
toggle is enabled. So toggle enabled can be set by default whenever we are
not in bidirectional continuous, i.e., we are dwelling at either max or min
limits (or both).
Just to summarize the motivation for those attributes... the idea to create
those ramp patterns is to allow a receiver that performs stretch processing
to assemble a "radar data cube" of data, where FFT applied to each dimension
gives different insights on the detected object: range, velocity and direction.
Each ramp would give a row, a burst gives a matrix, and with multiple antennas
one gets a 3D block of data.
...
--
Kind regards,
Rodrigo Alencar
