Hi Michael, if you are certain that having the templates for QA in either python or cpp (any specific language you are using from these two for the unit tests?) is useful for you (and potentially for other users), then I will push them back.
>From this discussion, I will also set a more descriptive warning then the "newmod" template is not found. On Thu, Jul 13, 2017 at 5:45 PM, Michael Wentz <mchlw...@gmail.com> wrote: > Hi Nicolas, > > Thanks for the feedback. Interesting since I had a few blocks with > underscores in the name and had just removed the underscore from the XML > that UHD uses. > > Regarding the QA tests, I tried porting some of the code I was using > before and am mostly getting 'timeout on chan 0' when using vector > source/sink to send test vectors through. In the past I had some success > with this, not only when using GR but with other tests I wrote using only > UHD. From my prospective it would definitely be nice to repeat the type of > tests I do in RTL simulation with hardware in the loop, i.e. doing a > loopback through the FPGA with signals generated from software. > > -Michael > > On Thu, Jul 13, 2017 at 7:18 AM, Nicolas Cuervo <nicolas.cue...@ettus.com> > wrote: > >> Hello Michael, >> >> It seems that 'import sys' is missing from the top of >>> gr-ettus/python/utils/rfnocmodtool >>> >> Yeah, this was known actually, and the fix is there. It just needs to be >> pushed public. We are sorry you had to face this. >> >> >>> After changing that, I ran into this problem: >>> >>> rfnocmodtool newmod test >>> Could not find rfnoc-newmod source dir >>> >>> It turns out that gr-ettus/modtool_newmod.py is not set up for people >>> that do not use PYBOMBS but do have a custom install prefix. All I had to >>> do was copy that over to PYBOMBS_PREFIX and then newmod worked. I would >>> have thought my install prefix would have been set up in any necessary >>> files during cmake? >>> >> The path hint that the modtool uses is PyBombs (as you correctly point >> out) and the common /usr/local/ and such. When the path is custom, >> rfnocmodtool requires the path of the newmod to be given with the >> "--srcdir" option. >> >> $ rfnocmodtool help newmod >> General options: >> . >> . >> . >> newmod: >> New out-of-tree module options >> >> --srcdir SRCDIR Source directory for the module template. >> >> Maybe a more descriptive "Could not find message" would be required, >> where it is said that the --srcdir option might be required to be >> explicitly given. >> >> >>> I was also wondering if there are reasons why underscores are not >>> allowed in block names >>> >> The underscores are not allowed in the names because we use them to >> designate block identifiers. This means, for example, that under the hood >> we refer to the "RFNoC: Radio" on channel 0 as 0/Radio_0 and so on. Given >> this, some naming that has underscores in it will lead to code >> mismatches and conflicts that could only be solved by code refactoring. >> This is the reason why we just added this constraint as a requirement. >> >> >> , and why the QA templates were removed (I liked using these to do tests >>> with hardware in the loop)? >>> >> We sincerely thought that no one was using this, as having hardware in >> the loop for, lets say, a python QA code, was not a trivial use case. If >> you are willing to elaborate on exactly how you are achieving this, we >> would not be against bringing the QA templates back. >> >> Regards, >> - Nicolas >> >> >> >> >>> -Michael >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
