UmTRX integration into UHD

Max.Suraev at fairwaves.ru Max.Suraev at fairwaves.ru
Sat Feb 11 11:47:52 UTC 2012


Thank you for prompt reply Thomas. Some additional questions are inline.

11.02.2012 02:00, Thomas Tsou пишет:

> How messy would option 1 be? Option 2 (or 3) more closely follows the
> existing UHD model where the shared code is mainly limited to the
> transport. I think that would be the best approach unless option 1 can
> be done very cleanly.

I think we would stick to option 3 (separate umtrx folder) - because it'll become
pretty messy over time (essentially every place where clock or codec controller is
used requires alteration). Also It seems that with this approach it will be easier to
push UMTRX support into upstream once it's mature enough.

> What is the difference between option 2 and 3? Does option 2 create a
> second impl class within the usrp2 directory? I think a separate
> directory is appropriate.

This brings up another question: where does dispatching happens? E. g. which codepath
is used to choose between usrp1, usrp2 and umtrx?

For example If we use option 2 (separate impl file inside usrp2) and treat UmTRX as a
special revision of usrp2 than dispatching happens in usrp2_iface.hpp: "enum
rev_type" and every time get_rev() is checked.

> b100 and usrp1 implementations were created based on copies of
> existing usrp2 / e100 code without explicit class reuse. For example,
> b100 / e100 / usrp1 exist separately, but share the same ad9862 codec.
> There is some copied code between the three codec versions, but that
> was less messy than creating a unified codec impl for all three.

Is there some technical reason why we can't use something like '#include
"../usrp2/io_impl.cpp"' inside /umtrx/umtrx_iface.hpp for example? Or it's purely
question of aesthetics?

-- 
best regards,
Max, http://fairwaves.ru



More information about the UmTRX mailing list