If I understand you correctly, then I need to create another block uhd
self.uhd_usrp_source = uhd.usrp_source ( ",". join (("", "")),
uhd.stream_args ( cpu_format = "fc32", channels =
range (1), ), )
so I created it. But I don’t understand how it works since I don’t connect
it anywhere and I get an error
[WARNING] [RFNOC] [legacy compat] Not enough FIFO ports to connect, not
all TX sinks will be connected [WARNING] [RFNOC] [legacy_compat] No DDCs
detected. You will only be able to receive at the radio frontend rate.
[WARNING] [RFNOC] [legacy_compat] No DUCs detected. You will only be able
to transmit at the radio frontend rate. [WARNING] [RFNOC] Assuming max
packet size for 0 / Radio_0 thread [thread-per-block [0]: <block
uhd_rfnoc_FIFO (7)>]: RuntimeError: On node 0 / FIFO_0, output port 0 is
already connected.
If somewhere there are examples of how to get to gpio correctly, I would
be very grateful if you would provide them to me. I figured out the FPGA
firmware and now the only problem is gpio.
пн, 11 мая 2020 г. в 17:58, Michael Dickens <michael.dick...@ettus.com>:
> Hi Ivan - I was out last week; here now for a few days. Please keep
> supp...@ettus.com on CC so that someone there can try to help you when
> I'm away.
>
> Here's a summary of the discussion with the Ettus R&D person I spoke with
> about accessing the GPIO via GRC: you have to create a UHD USRP Source/Sink
> object, then you use it to access the underlying C++ USRP object (via
> Python) to obtain the GPIO API. You can't access the UHD GPIO API from
> RFNoC blocks; there is no USRP object to provide access.
>
> Are you still having issues with the FPGA creation? If so, please update
> me on where you're at and I'll do what I can to help. - MLD
> ---
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
>
> On Thu, May 7, 2020 at 7:38 AM Ivan Zahartchuk <adray0...@gmail.com>
> wrote:
>
>> Hello. Sorry to bother you so often. But I really want to understand this
>> board and firmware. I solved the problem with the fact that I did not
>> create an image for FPGA. The problem was that at startup, the
>> rfnoc_ce_auto_inst_e31x.v configuration file is created, which also tells
>> which blocks to compile for VIvado. But the next time you call
>> ./uhd_image_builder, this file is not replaced with a new one, but the
>> rfnoc_ce_auto_inst_e310.v file is created, which does not participate in
>> further work. But I also had questions about the GPIO.
>>
>> вс, 3 мая 2020 г. в 14:09, Ivan Zahartchuk <adray0...@gmail.com>:
>>
>>> Hello. Your colleagues haven’t answered anything yet? Tell me, could you
>>> generate firmware for RFNoC and drop it to me. Sorry to ask a lot, I just
>>> can not test the error with generating a bit file for FPGA differently.
>>>
>>> ср, 29 апр. 2020 г. в 08:11, Ivan Zahartchuk <adray0...@gmail.com>:
>>>
>>>> Thanks! I found out that the problem in the firmware comes from
>>>> applications for creating this firmware. After opening the firmware using
>>>> Vivado, I found in it the same FIR block that I did not add there. Perhaps
>>>> this is due to the fact that I installed the wrong version of Vivado.
>>>> Because I also don’t generate the dts file that is needed for firmware. I
>>>> installed Vivado 18.3 HL System Edition.
>>>>
>>>> ср, 29 апр. 2020 г. в 00:12, Michael Dickens <michael.dick...@ettus.com
>>>> >:
>>>>
>>>>> Hi Ivan - Let me discuss your query with the Ettus R&D guy who handles
>>>>> gr-uhd. Hopefully he'll be able to clarify your query. - MLD
>>>>> ---
>>>>> Michael Dickens
>>>>> Ettus Research Technical Support
>>>>> Email: supp...@ettus.com
>>>>> Web: https://ettus.com/
>>>>>
>>>>>
>>>>> On Mon, Apr 27, 2020 at 7:59 PM Ivan Zahartchuk <adray0...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Unfortunately for all this time I have not come a step closer to solving
>>>>>> my problems. I don’t know how to solve the problem with flashing fpga.
>>>>>> I even reinstalled ubuntu but it did not help. The only assumption is
>>>>>> that the board has its own memory that is not erased after overwriting
>>>>>> the SD card. But this is also doubtful.
>>>>>> In addition, I still didn’t get to switch to the GPIO through the RFNoC
>>>>>> block and I am thinking about returning to version 3.14. But honestly I
>>>>>> would like to deal with this version.
>>>>>>
>>>>>>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
