All Activity

@Kevin.C Will SHA512 work? I downloaded the rpm packages from our website and ran rpm -qip and looked at the signature field. All of them, with the exception of Waveforms, appears to be signed with RSA/SHA512. Please let me know if this works and I will work with Attila to get Waveforms signed with SHA512. malexander@vm-u22-lts:~/Downloads$ ls digilent.adept.runtime-2.27.9.aarch64.rpm digilent.adept.runtime-2.27.9.x86_64.rpm digilent.adept.utilities-2.7.1.i686.rpm digilent.adept.runtime-2.27.9.armhf.rpm digilent.adept.utilities-2.7.1.aarch64.rpm digilent.adept.utilities-2.7.1.x86_64.rpm digilent.adept.runtime-2.27.9.i686.rpm digilent.adept.utilities-2.7.1.armhf.rpm digilent.waveforms_beta_3.22.18.x86_64.rpm malexander@vm-u22-lts:~/Downloads$ rpm -qip *.rpm Name : digilent.adept.runtime Version : 2.27.9 Release : 1 Architecture: aarch64 Install Date: (not installed) Group : System Environment/Libraries Size : 25044427 License : see /usr/share/doc/digilent.adept.runtime-2.27.9/EULA and /usr/share/doc/digilent.adept.runtime-2.27.9/license-openssl-ssleay.txt Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:39 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.runtime-2.27.9-1.src.rpm Build Date : Mon 30 Jan 2023 02:03:57 PM PST Build Host : rpi4-ubuntu64 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Runtime Description : The Adept Runtime consists of the shared libraries, firmware images, drivers, and configuration files necessary to communicate with Digilent's devices. Name : digilent.adept.runtime Version : 2.27.9 Release : 1 Architecture: armhf Install Date: (not installed) Group : System Environment/Libraries Size : 21202338 License : see /usr/share/doc/digilent.adept.runtime-2.27.9/EULA and /usr/share/doc/digilent.adept.runtime-2.27.9/license-openssl-ssleay.txt Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:54 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.runtime-2.27.9-1.src.rpm Build Date : Mon 30 Jan 2023 01:27:45 PM PST Build Host : rpi4-ubuntu32 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Runtime Description : The Adept Runtime consists of the shared libraries, firmware images, drivers, and configuration files necessary to communicate with Digilent's devices. Name : digilent.adept.runtime Version : 2.27.9 Release : 1 Architecture: i686 Install Date: (not installed) Group : System Environment/Libraries Size : 23160188 License : see /usr/share/doc/digilent.adept.runtime-2.27.9/EULA and /usr/share/doc/digilent.adept.runtime-2.27.9/license-openssl-ssleay.txt Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:54 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.runtime-2.27.9-1.src.rpm Build Date : Mon 30 Jan 2023 11:31:24 AM PST Build Host : michael-u16-32 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Runtime Description : The Adept Runtime consists of the shared libraries, firmware images, drivers, and configuration files necessary to communicate with Digilent's devices. Name : digilent.adept.runtime Version : 2.27.9 Release : 1 Architecture: x86_64 Install Date: (not installed) Group : System Environment/Libraries Size : 25120940 License : see /usr/share/doc/digilent.adept.runtime-2.27.9/EULA and /usr/share/doc/digilent.adept.runtime-2.27.9/license-openssl-ssleay.txt Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:55 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.runtime-2.27.9-1.src.rpm Build Date : Mon 30 Jan 2023 11:47:30 AM PST Build Host : michael-u16-64 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Runtime Description : The Adept Runtime consists of the shared libraries, firmware images, drivers, and configuration files necessary to communicate with Digilent's devices. Name : digilent.adept.utilities Version : 2.7.1 Release : 1 Architecture: aarch64 Install Date: (not installed) Group : Applications/Communications Size : 6042364 License : see /usr/share/doc/adeptruntime/copyright Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:55 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.utilities-2.7.1-1.src.rpm Build Date : Tue 13 Jul 2021 05:14:31 PM PDT Build Host : rpi4-ubuntu64 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Utilities Description : Adept Utilities is a set of command line applications that can be used in conjunction with the Adept Runtime to manage and communicate with Digilent's devices. Currently Adept Utilities consists of three applications: Digilent Adept Utility (dadutil), Digilent JTAG Config Utility (djtgcfg), and Digilent NetFPGA-SUME Flash Configuration Utility (dsumecfg). The Adept Utility provides a command line interface for discovering Digilent devices, querying device information, manipulating the device table, and setting device information. The JTAG Config Utility allows users to initialize, program, and erase FPGAs and CPLDs on Digilent boards using a command line interface. The NetFPGA-SUME Flash Configuration Utility allows users to write bit or bin files to a specific section of the flash memory on Digilent's NetFPGA-SUME. For more information please consult the associated man documentation. Name : digilent.adept.utilities Version : 2.7.1 Release : 1 Architecture: armhf Install Date: (not installed) Group : Applications/Communications Size : 6013249 License : see /usr/share/doc/adeptruntime/copyright Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:56 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.utilities-2.7.1-1.src.rpm Build Date : Tue 13 Jul 2021 05:43:01 PM PDT Build Host : rpi4-ubuntu32 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Utilities Description : Adept Utilities is a set of command line applications that can be used in conjunction with the Adept Runtime to manage and communicate with Digilent's devices. Currently Adept Utilities consists of three applications: Digilent Adept Utility (dadutil), Digilent JTAG Config Utility (djtgcfg), and Digilent NetFPGA-SUME Flash Configuration Utility (dsumecfg). The Adept Utility provides a command line interface for discovering Digilent devices, querying device information, manipulating the device table, and setting device information. The JTAG Config Utility allows users to initialize, program, and erase FPGAs and CPLDs on Digilent boards using a command line interface. The NetFPGA-SUME Flash Configuration Utility allows users to write bit or bin files to a specific section of the flash memory on Digilent's NetFPGA-SUME. For more information please consult the associated man documentation. Name : digilent.adept.utilities Version : 2.7.1 Release : 1 Architecture: i686 Install Date: (not installed) Group : Applications/Communications Size : 6013794 License : see /usr/share/doc/adeptruntime/copyright Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:56 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.utilities-2.7.1-1.src.rpm Build Date : Tue 13 Jul 2021 04:15:52 PM PDT Build Host : michael-u16-32 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Utilities Description : Adept Utilities is a set of command line applications that can be used in conjunction with the Adept Runtime to manage and communicate with Digilent's devices. Currently Adept Utilities consists of three applications: Digilent Adept Utility (dadutil), Digilent JTAG Config Utility (djtgcfg), and Digilent NetFPGA-SUME Flash Configuration Utility (dsumecfg). The Adept Utility provides a command line interface for discovering Digilent devices, querying device information, manipulating the device table, and setting device information. The JTAG Config Utility allows users to initialize, program, and erase FPGAs and CPLDs on Digilent boards using a command line interface. The NetFPGA-SUME Flash Configuration Utility allows users to write bit or bin files to a specific section of the flash memory on Digilent's NetFPGA-SUME. For more information please consult the associated man documentation. Name : digilent.adept.utilities Version : 2.7.1 Release : 1 Architecture: x86_64 Install Date: (not installed) Group : Applications/Communications Size : 6039466 License : see /usr/share/doc/adeptruntime/copyright Signature : RSA/SHA512, Tue 19 Mar 2024 10:37:56 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.adept.utilities-2.7.1-1.src.rpm Build Date : Tue 13 Jul 2021 04:45:04 PM PDT Build Host : michael-u16-64 Packager : Digilent, Inc. <support@digilentinc.com> Vendor : Digilent, Inc. Summary : Digilent Adept Utilities Description : Adept Utilities is a set of command line applications that can be used in conjunction with the Adept Runtime to manage and communicate with Digilent's devices. Currently Adept Utilities consists of three applications: Digilent Adept Utility (dadutil), Digilent JTAG Config Utility (djtgcfg), and Digilent NetFPGA-SUME Flash Configuration Utility (dsumecfg). The Adept Utility provides a command line interface for discovering Digilent devices, querying device information, manipulating the device table, and setting device information. The JTAG Config Utility allows users to initialize, program, and erase FPGAs and CPLDs on Digilent boards using a command line interface. The NetFPGA-SUME Flash Configuration Utility allows users to write bit or bin files to a specific section of the flash memory on Digilent's NetFPGA-SUME. For more information please consult the associated man documentation. Name : digilent.waveforms Version : 3.22.18 Release : 1 Architecture: x86_64 Install Date: (not installed) Group : Engineering/misc Size : 68189182 License : see /usr/share/doc/digilent-waveforms/copyright Signature : RSA/SHA1, Fri 12 Apr 2024 01:23:28 AM PDT, Key ID 134da9ebeb58bc22 Source RPM : digilent.waveforms-3.22.18-1.src.rpm Build Date : Fri 12 Apr 2024 01:23:10 AM PDT Build Host : attila-u16-64 Summary : Digilent WaveForms Description : Digilent WaveForms Application, Runtime and SDK. Support for Digilent Scopes & Instruments products.

Hi @Clyde, I have moved your question to a more appropriate section of the Forum where the engineer most familiar with the Analog Discovery Pro 3450 will be able to give accurate insight into this. I know that the trigger DIO signals themselves are protected by ESD diodes and PTC thermistors, but I am uncertain about digital supplies themselves regarding overcurrent protection. Thanks, JColvin

Hi @jmckinney I'm largely not familiar with FreeRTOS, but is there a chance that the data cache could be messing with the ability of the DMA to pull block descriptors from memory? https://www.freertos.org/FreeRTOS_Support_Forum_Archive/May_2016/freertos_Zync_UDP_TCP_with_DMA_IP_f531ef1cj.html seems potentially relevant. Caching issues are a pretty standard problem with non-scatter-gather DMA, where it just makes data unable to be seen by either side unless you flush or invalidate as appropriate. Pointers in block descriptors that aren't coming through as expected could cause all sorts of issues. If that's the cause, might be worth trying to disable the caches entirely, though I'm not sure how this affects the FreeRTOS setup. If you haven't, I'd also try putting an ILA on the DMA's AXI4-full master interfaces. Thanks, Arthur

Hi @BEBERL, If the transducer is analog based, i.e. sends out some sort of voltage based on the measured pressure, it might be possible to interface the Analog Discovery device (whether AD2 or the newer AD3) with it. I'm guessing it is analog based on the picture that shows 3 wires (presumably power, ground, and the signal) going into the extension cable. If it instead uses some sort of serialized digital interface, you would then have to figure out the communication scheme that it uses, which could be quite a bit of debugging to figure out as I'm not readily seeing any documentation for it. If this is the case, the Analog Discovery device could still potentially interface with the transducer, but the level of effort to get it working, if at all, is a big unknown. If it is an analog output signal, you would need some sort of physical adapter to readily connect to the wires (or be willing planning on splicing the cable open to connect to the individual wires via a breadboard or soldering pin headers to them). You could then use the analog input channels on the Analog Discovery device to measure the variable voltage coming out of the transducer as well as some sort of math channel to convert the measured voltage to the correct units. I'm presuming there is some sort of documentation out there that would tell you what first or second order linear equation the transducer follows. As for powering the transducer, the Analog Discovery device can probably do that for you as well with its external power supplies. The catch with this is that I don't know what voltage the transducer operates at. If you have some sort of datasheet regarding the electrical specifications of the transducer as well as the wiring setup, I might be able to provide a more conclusive answer for you. Thanks, JColvin

Hi, This model has a built in power supply. Does this power supply have the ability to set the current limit? Is the output current protected against an excessive current draw? Thanks.

Manually updating did the trick... thanks.

You should manually update the hardware specification: https://digilent.com/reference/programmable-logic/guides/vitis-update-hardware-specification. Vitis generally won't see changes to the filesystem. When just overwriting the copy of the file buried in the platform project, I'd be concerned that Vitis might need to extract other files from it, which it might not happen automatically during a build - I expect it won't see the copy without the manual update. One common issue that could come up after this (though I don't think you'll run into it here) is that if your XSA file has a different name, the extracted bitstream name changes. In this case, you'd need to go into the system projects Run/Debug Configurations, and change the path to the file to reflect the name of the new XSA.

Use mcc172_a_in_scan_start first to start the acquisition, then use mcc172_a_in_scan_status to determine the number of samples in the buffer. Study the attached C program. It requests 256 samples and displays the loop execution time, samples read, channel 0, channel 1, and the number of samples left in the buffer after the read. continuous_scan2.c

Hi @Fausto thank you for your reply. QuickDAQ now starts and I have tested it with a DT9816-S.

Hi @AKA The DIO drive on AD2 is 4mA. On AD3 is by default 4mA but can be adjusted with C API FDwfDigitalIODriveSet

I was able to find an echo.c which does UDP and used ncat --udp 192.168.1.10 7 to test it.... it does echo back. I found a youtube video of a dma loopback (data to axi_fifo and back). So I added the appropiate blocks on the .bd schematic and the code they had written on the main.c on top of the code that was there from the echo project. It is giving me an error saying this when I go build it: ../src/main.c:36:10: fatal error: xaxidma.h: No such file or directory. Not sure how to get around this. I did export a new .xsa file from Vivado. When I export the .xsa file it is in the directory where the .xpr file is for Vivado. But looking at the property of the .xsa file in the vitis environment it is down projext.sw/design_1_wrapper\export\design_1_wrapper\hw\design_1_wrapper.xsa so wondering if that is the problem (it does not see the new dma block in the schematic). You would think Vitis would see that it changed and copy??? it to the correct directory. Nevertheless I copied the .xsa to that directory and it still gave me an erorr. I am hoping to get the dma lookback working along side the UDP loopback. Then modify things so I send via DMA the udp buffer p to the axi fifo on the PL side. Finally remove the path out of fifo back to dma module and have my logic in the PL read the fifo once the data is there so I can send it out serially (cant use an axi_uart since it is straight data and clk....clk on data is being sent out (no start bit etc) ). Here is the new schematic

Hello everyone! I'm trying to boot PetaLinux with a GUI to run my QML application. The board is connected to my FHD display via HDMI, and the display color depth is 24, but FBDEV shows 32 in PetaLinux. This is a part of my devicetree_config file: &amba_pl { digilent_hdmi { compatible = "digilent,hdmi"; clocks = <&axi_dynclk_0>; clock-names = "clk"; digilent,edid-i2c = <&i2c0>; digilent,fmax = <150000>; port@0 { hdmi_ep: endpoint { remote-endpoint = <&pl_disp_ep>; }; }; }; xlnx_pl_disp { compatible = "xlnx,pl-disp"; dmas = <&axi_vdma_1 0>; dma-names = "dma0"; /* * See Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt * to find the equivalent DRM fourcc code for the format selected in * the Frame Buffer Reader, then see See include/uapi/drm/drm_fourcc.h * to find the corresponding 4-char string that should be placed here. */ xlnx,vformat = "XR24"; xlnx,bridge = <&v_tc_out>; port@0 { pl_disp_ep: endpoint { remote-endpoint = <&hdmi_ep>; }; }; }; }; I have installed Qt, Matchbox, and X11 packages. After booting, I faced a color issue even before the QML app was running. I tried to change the color depth in Xorg and adjust the fbdev display parameters, but received an "FBDEV INVALID ARGUMENT" error. I also tried to change the xlnx and vformat mode; after making changes and completely rebuilding, there was no video output at all. However, I finally found that axi_vdma outputs not RGB but BGR color scheme, which might be the reason for the issue. PetaLinux 2022.1 or 2020.1, Ubuntu 18.04, Digilent Zybo Z7. BSP, hardware and OS configs from oficial Digilent repository. Any ideas?

The USB-2416-4AO counter input has a pull-up resistor, so an external one is unnecessary. Connect the Scaler's +Output to the counter input and the -Output to the ground.

Use the following download for LabVIEW 8.5 support. https://files.digilent.com/archive/MCCDAQ_CD/Archive_6.35/mccdaq.exe

Hi Everyone, I am new to this forum. I am a PhD student at the Wake Forest School of Medicine. I am looking at using Utah Medical DELTRAN 6069 ultrasonic pressure transducers in our cardiovascular mock flow loop. I was wondering if these sensors were compatible with the Discovery 2 Pro system? Thanks in advance for the help! Best, Brandon

Hi Paul, Yeah, this is a result of the local memory being too small. It's come up in other threads, and as I understand it, you can adjust the memory size from the Address Editor: Thanks, Arthur

Hi @artvvb [Aha, that does work fine if I'm typing, just not when I copy/paste. Thanks.] Cheers for those references. I've been working through the '.../getting-started-with-ipi' guide that you linked, to try out a basic MicroBlaze C project. As you suggested, I followed the steps for boards without DDR memory (even though it's present on my board). I've nearly made it to the end of the guide, but am now hitting this error in Vitis when I try to build the C code: [...] /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: microblaze_flash_wrapper_app.elf section `.heap' will not fit in region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' overflowed by 1856 bytes collect2.real: error: ld returned 1 exit status make: *** [makefile:38: microblaze_flash_wrapper_app.elf] Error 1 My guess is that this error is caused by a mistake I made, much earlier in the tutorial. I misunderstood what the 'Local Memory' setting was referring to when configuring the MicroBlaze IP block, and so (thinking that I wouldn't need much of it) I set it to 8k rather than 32k. I've had a poke around in the block diagram and I now can't see any way to alter this setting. (Specifically, I'm wanting to alter the 'Local Memory' value that was originally set via the Run Block Automation dialog when I added the MicroBlaze IP to the diagram.) But this isn't too surprising, as I also note that the tutorial, in the section on configuring the MicroBlaze, has this to say: So, I've got two questions at the moment: Could that 'Local Memory' setting really be the cause of the compiler error I'm seeing? If so, is there a better way to fix that setting now, without needing to wipe the block diagram (and rebuild it correctly this time)? Many thanks, Paul.

Hi @artvvb [Aha, that does work fine if I'm typing, just not when I copy/paste. Thanks.] Cheers for those references. I've been working through the '.../getting-started-with-ipi' guide that you linked, to try out a basic MicroBlaze C project. As you suggested, I followed the steps for boards without DDR memory (even though it's present on my board). I've nearly made it to the end of the guide, but am now hitting this error in Vitis when I try to build the C code: [...] /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: microblaze_flash_wrapper_app.elf section `.heap' will not fit in region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' /home/pdw/Xilinx/Vitis/2022.1/gnu/microblaze/lin/x86_64-oesdk-linux/usr/bin/microblaze-xilinx-elf/microblaze-xilinx-elf-ld.real: region `microblaze_0_local_memory_ilmb_bram_if_cntlr_Mem_microblaze_0_local_memory_dlmb_bram_if_cntlr_Mem' overflowed by 1856 bytes collect2.real: error: ld returned 1 exit status make: *** [makefile:38: microblaze_flash_wrapper_app.elf] Error 1 My guess is that this error is caused by a mistake I made, much earlier in the tutorial. I misunderstood what the 'Local Memory' setting was referring to when configuring the MicroBlaze IP block, and so (thinking that I wouldn't need much of it) I set it to 8k rather than 32k. I've had a poke around in the block diagram and I now can't see any way to alter this setting. (Specifically, I'm wanting to alter the 'Local Memory' value that was originally set via the Run Block Automation dialog when I added the MicroBlaze IP to the diagram.) But this isn't too surprising, as I also note that the tutorial, in the section on configuring the MicroBlaze, has this to say: So, I've got two questions at the moment: Could that 'Local Memory' setting really be the cause of the compiler error I'm seeing? If so, is there a better way to fix that setting now, without needing to wipe the block diagram (and rebuild it correctly this time)? Many thanks, Paul.

Hi RATHNA, Digilent currently doesn't support Code Composer Studio for any of our products. Thanks, Arthur

Is there a way to get a copy of ULxLV.dll from the Labview 8.5 era?

Thanks, @JColvin! Would love to get this conversation started.

I'm using Vivado 2023, but I believe that particular adept version was added by ISE, since the dates of the files do match with the ISE installation! Many thanks again for taking time on this S

N/A

Hi @attila So, if I understand you correctly, I configure and run my pattern with DigitalOut_SPI.py and then use DigitalIn_Spi_Spy.py to capture the data. Correct? I tried to run the my version of DigitalOut_SPI4.py (attached) but I can not see how to control the CS correctly. Also, how do I insert hardware delays between frames? For example, if I wanted to burst SPI commands every 1ms. Right now I have it set to repeat 2x, but I need the CS to go high between each frame. Can you tell me how to do that? See scope shot of CS staying low for both 32 clock frames. Also, how do I get MSB first out instead of LSB first? Sorry for all the questions, but I am new to this...I tried searching the forum for similar questions and answers. Thanks! DigitalOut_SPI v4.py

@scorbetta This makes a lot more sense now because support for network devices was added in 2020. To the best of my knowledge Vivado includes the libraries in a subdirectory underneath the Vivado directory and loads them from there. This is something I can confirm with Xilinx - can you tell me which version(s) you have installed? I think at one point we were installing files in /usr/local/lib64 but moved to /usr/lib64, so it's possible that those files may be left over from an older installation that was performed using the install script from the tar.gz instead of the debian package manager. I believe that warning message you are seeing can safely be ignored. Thanks, Michael