Popular Content

Showing most liked content since 01/18/18 in all areas

  1. 2 likes
    An FPGA can be a useful "swiss army knife", but all the nice features aren't easily accessible. Enter "LabToy": A batteries-included collection of utilities, just double-click and go. As the name implies, this isn't meant to compete against "real" test equipment. The main selling point is like a pocket knife - this fits into a shirt pocket and the power tools don't. And speaking of "selling points", it's free to use. So what do we have here: - Digital data: Shows the input state of all pins - Analog data: Readings from the two ADCs, up to about 700 ksps sustained (XADC "simultaneous sampling" mode, phase-accurate between channels) - Streaming data logger: Both analog and digital data can be written to a .vcd file, to be shown in gtkwave. There is no limit to the capture length. - Analog signal generator: 8 fully independent channels, sine, square wave, the usual suspects. Well, the DACs won't win any audiophile awards, but they are usable. - "Programmable" digital LED mode: Configurable pulse width to suppress short glitches, or edge detect with a built-in pulse generator to highlight them. - Analog LED mode: Shows the input value of the ADC in real time Some screenshots: 1k sine / cosine from DAC jumpered to ADC (in gtkwave) The digital signal is the generator's sync output that can be recorded as a digital input. Realtime display of the inputs. With pocket knives in mind ("this button will unlock the large blade, allowing it to be manually returned to its folded position") I decided to keep the screen uncluttered and put descriptions into tooltips. The large displays are the average voltage readings from the ADC. The smaller ones show the digital inputs in groups of four. Generator controls (frequency, minimum voltage, maximum voltage, phase). The voltage scaling is a bit unusual (typically there is "AC magnitude" and "DC offset") but I chose this approach because it shows clearly the limitations of the 0..3.3V output range. Most people will probably leave all this at the default values for a full-scale signal. Data capture Example: The output in gtkwave after I touched a jumper cable to the digital inputs on the DIL connector. +++ DO NOT USE THE +5V OUTPUT P24 FOR THIS KIND OF TEST +++ (3.3 V is available on the PMOD connector, bottom row) The red "undefined" marks flag the first input in an 8-bit group. In this example, they aren't too meaningful, but they can alert me to the fact that no data events have been observed yet. LED control The two numbers give the number of consecutive 1 or 0 samples (at 125 MHz) before a signal change is propagated to the LED. E.g. put 125 million there and it'll take one second after changing the input state for the LED to light / go dark. Those can be used interactively to study an unknown signal. "Level": no further processing ("level" mode and 1 / 1 sample counts is equivalent to directly connecting the LED to the physical input) "Edge" mode generates a brief pulse on signal changes, the LED is dark otherwise. "Invert" flips the input right next to the pin (0 becomes 1, black becomes white and man gets himself killed on the next zebra crossing -DA). How to get it: The file is attached: labToy0v1_beta.exe The installer unpacks a single .exe. Happy hacking! Requirements: Windows 64 bit (!) .NET 4.5 FTDI libraries CMOD A7 35 T (not 15 T). Warnings: Direct access to digital IO pins is an inherently dangerous activity. "PROVIDED WITHOUT WARRANTY OF ANY KIND" means Just That. And beware of the +5V pin. PS: If you try it, kindly let me know whether it works, or what goes wrong.
  2. 1 like
    Hi @freakuency, Glad to hear that installing the cable drivers solved the issue. cheers, Jon
  3. 1 like
    Solved by this: /opt/Xilinx/Vivado/2017.4/data/xicom/cable_drivers/lin64/install_script/install_drivers
  4. 1 like
    Hi @bdina77, Glad to hear you are able to get your design working. I have not heard of this being an issue. I would guess that this is due to the power up of the different rails and IC's. cheers, Jon
  5. 1 like
    @Newport_j, It's just a text file. Feel free to open it up in your favorite editor, make a back up copy and then edit it (You'll need to for most projects ...) Dan
  6. 1 like
    Hi @jpnbino The wait function is intended to handle execution to the main application processes and to notify the script execution to stop. This will return false after the Stop button in the Script tool is pressed or returns true after the specified time. while(wait(1.5)){ // enter loop every 1.5 seconds while not stopped //... } for ... if(!wait()) break // quit loop when stopped function ... if(!wait()) return // return when stopped if(!wait()) throw "stopped" // abort execution when stopped
  7. 1 like
    I have successfully made AD2 running on Orange PI PC Plus. I have also configured VNC (over WiFI) using the tutorial: https://diyprojects.io/armbian-access-remote-desktop-orange-pi-vnc/#.Wn7FXq7T5hF BUT VERY IMPORTANT - do not use/install tightvncserver - instead use vnc4server. There are issues with keyboard input in tightvnc & QT. sudo apt-get install vnc4server
  8. 1 like
    Hello @zener, Here is the datasheet for those diodes: https://www.onsemi.com/pub/Collateral/NSQA6V8AW5T2-D.PDF. Thanks, JColvin
  9. 1 like
    Hi @jpeyron, Noted with thanks. Will reply you if I have any doubts again. Regards, vader92
  10. 1 like
    My comments about your project was based on this statement. As to "free added value deal" ( I understand your confusion as I and possibly D@n are the only ones who understand what I meant to say ) I was referring to posting uncompensated content that involves time and effort but becomes "added value" to a third party. Again, this comment was in the context of the idea that you were posting nothing but an executable application. Simply trying to answer Digilent customer questions is also a form of uncompensated work but less time consuming. This is how user forums work and there isn't any subterfuge involved so I'm not complaining.
  11. 1 like
    Thank you for welcome. Today was my first successful run of Qt GUI application on my ZyboZ7-20 after months of digging through the whole stack (FPGA - LX kernel - User Land). Currently I am trying to make frambuffer driver to start moving data via xilinx_dma driver. At the moment I have to program VDMA IP registers (MM2S_StartAdresses, MM2S_STRIDE, MM2S_HSIZE and MM2S_VSIZE) manually. There is something not yet ok in framebuffer driver and binding it with xilinx_dma driver. I will try with DRM driver (ADI or Xilinx as start point) since it is more decent technology as framebuffer. Once the project is in good shape I will consider adding it to Digilent project vault.
  12. 1 like
    For your information: The partial reconfiguration license is now included in Vivado System Edition and Design Edition seats at no additional cost since 2017.1. The Partial Reconfiguration feature is also available for purchase for WebPack additions, at a new lower cost.
  13. 1 like
    Hi @zuleikha, Here is an Avnet forum thread that goes through a few possibilities and some solutions to the "No Target with ID 64 in the System" error. I would also suggest to go through Getting Started with Zynq tutorial. Here is our resource center for the zedboard as well cheers, Jon
  14. 1 like
  15. 1 like
    Hi, the MPSSE mode of a FTDI chip in the JTAG adapter will do the trick. It can do SPI-like full-duplex up to 30 MBits/second. There is a clock signal so the data signal can be anything. Accessing that is a bit tricky (it goes via JTAG's USERx opcode) but the easiest option might be to connect an external FTDI chip SPI-style (transmit, receive, clock, some chip select signal for simple sync). I'm heavily using the "SPI" via JTAG option myself, but it's a bigger project to make that work. A basic MPSSE driver for the FTDI chip (not JTAG but direct connection) can be done in a day or two. If interested, check out FTDI's application notes on MPSSE and SPI. I wouldn't touch their JTAG example code...
  16. 1 like
    Hello @rileyh88, Currently those of us here at Digilent are not aware of any plans for a new Home Bundle for LabVIEW NXG. We will definitely forward this feedback to the LabVIEW team at NI. Thank you, JColvin
  17. 1 like
    Congratulations. That was the hard part... Study the schematic of your board around the VGA connector. There will most likely be several "bits" for each red/green/blue that are combined with resistors. Looks like you picked the lowest bit (with the highest resistor). This can be used to change the brightness level of each channel. For a quick-and-dirty write test, try this (didn't build it myself) // note: define those regs before using them for the first time reg [10:0] myAddr = 848-1; // screen base address reg [7:0] myData = 65-1; "A" reg myWriteEnable = 1'b0; always @(posedge anyClockYouLikeVgaClkWillDoToo) begin if (myAddr < 11'd880) begin myAddr <= myAddr + 11'd1; myWriteEnable <= 1'b1; myData <= myData + 8'd1; end else begin myWriteEnable <= 1'b0; end end ... sk61_VGA myGraphicsCardInstance(... .clkConfig(anyClockYouLikeVgaClkWillDoToo), .in_we(myWriteEnable), .in_addr(myAddr), .in_data(myData), .out_data( ... leave this open, until you want to read from mem ...), ...);
  18. 1 like
    Hi @Shuvo Sarkar, Unfortunately, I do not have experience with XAPP1167 OpenCV HLS. Hopefully on of the more experience community members will have some input for you. cheers, Jon
  19. 1 like
    Hi @Mahesh, I suppose the answer is both will work, but if you want to just run the project with minimal additional work on your part, I would use 2016.4. If you are wanting to use an alternate version of the "host" software (Vivado), some additional changes might be needed to make the project work for that different version; in general the sources will not need any changes (though that isn't always the case as you see in this thread), but the final compiled/premade will likely need re-built for that version of the software. On a side note, this situation is also true for other software platforms like LabVIEW or Arduino; sometimes the already existing code works, sometimes it needs updated. Thanks, JColvin
  20. 1 like
    @deppenkaiser Hi, The answer is that you can create new UIO devices. If you create more UIO devices, they will show up in /dev as UIO3, UIO4, UIO5, and so on
  21. 1 like
    Hi @Mahesh, I was able to get the arty-Z7-20 hdmi out to generate a bitstream in vivado 2017.4. To do this you new a fresh project. Then upgrade the ip cores by clicking tools->repots->report ip status and upgrade/generate the ip cores. Then create a wrapper. The DVI2RGB ip core has been updated since this project was made. Because of the updated ip core you will need to change the xdc pin names in the xdc file. From hdmi_hpd_tri_i to HDMI_HPD_tri_i , from hdmi_ddc_scl_io HDMI_DDC_scl_io and from hdmi_ddc_sda_io to. HDMI_DDC_sda_io. Next generate bitstream. The rest should be the same steps to get project working. cheers, Jon
  22. 1 like
    Hi @cassini, I do not have a lot of experience with HDMI projects. I have reached out to more experienced engineers about your forum thread to see if they have any input for you. Have you looked through the DVI2RGB documentation here? thank you, Jon
  23. 1 like
    Hi @ClockGuy, From what I recall, the ball is actually pretty stable after the fan speed is set (+/- 1 inch or so). In terms of the on/off frequency, it looks like I used milliseconds in terms of turning it on and off in a 100 millisecond timeframe. There is an idle timeout through of 6 seconds (same value for 6 seconds in a row) so you would want to remove that functionality from the code though. The rheostat (more commonly called a potentiometer in this field) will work fine as a replacement for the accelerometer. Thanks, JColvin
  24. 1 like
    I think there is a confusion. I am not talking about IO buffer (i.e., "physical ports") here. A port list is a list of inputs and outputs of your module as you declared here: Vivado needs a top module. The top module contains a port list that Vivado is going to wire to physical pins. Your top module is pwm that's why Vivado does what it did. Instead, use a top module that instantiates axi and pwm like so: top_module ( output pwm_out, inout DDR_... ... inout FIXED_IO... ... ); Vivado tries automatically to figure out which is your top module. If you have more than one hierarchie it picks whatever. In this case you can manually tell Vivado which your top module is. To put it simple: remove all inputs and outputs in your top module that you don't want Vivado to wire at pins.
  25. 1 like
    Hey Jiandan, If you're using the OpenScope MZ with WaveForms live you will never need to program it using the Arduino IDE, MPLAB or the PICkit3. All firmware updates should be done through the WaveForms Live software. WaveForms Live is available offline as well and is built into the Digilent Agent (see details in the FAQ under Is WaveForms Live available offline). WaveForms live uses the Digilent Agent to load firmware onto the OpenScope MZ at the 1250000 baud rate, so the baud rate is not the issue if you're able to do that successfully. It sounds like the hex file generated by the Arduino IDE is not generated correctly and does not work. -Kristoff
  26. 1 like
    I searched for inactive driver in the Windows device manager and found out that there appear 2 x USB Serial Converter A and 2 x USB Serial Converter B. I deleted all of them and powered the board. Now both boards work.
  27. 1 like
    3.7.10 digilent.waveforms_v3.7.10.exe Added: - Spectrum Analyzer Markers Fixed: - SDK Electronics Explorer enumeration - Scope Math channel unit presets 3.7.9 digilent.waveforms_v3.7.9.exe Fixing: - Logic Analyzer Event view double click for signals 3.7.8 digilent.waveforms_v3.7.8.exe Changed: - Impedance Analyzer: - view names - solid line for magnitude Fixed: - Impedance Analyzer admittance |Y| value 3.7.7 digilent.waveforms_v3.7.7.exe Added: - Scope and Logic trigger detector for trigger source Fixed: - warning message when connecting to EExplorer - Patterns trigger on Digital Discovery
  28. 1 like
    Hey, We did a lot of testing with the 1250000 baud rate because we were concerned that some USB ports might have problems. We've described a known issue cause by this baud rate, but it only affects USB 2.0 'Full Speed' ports (remember USB 'High Speed' is faster than 'Full Speed)', and only when transfering large buffers of data. We have never found this baud rate the be an issue during firmware loading since it uses many small data packets. Can you provide more details about your system and the USB port you're using? Have you tried other ports on the same computer and other computers? Thanks! -Kristoff
  29. 1 like
    Hey, This blog post has an overview of the 'stretch goal' features and links to more info. Let us know if you have any questions as you get started with the data logger. Thanks! -Kristoff
  30. 1 like
    @tom@nrl There's another project here: https://forum.digilentinc.com/topic/4784-s3-starter-board-programmer/ Do browse the Project Vault! And please do post feedback for any of these projects that you spend the time to read through and try out.. community projects benefit from community input.
  31. 1 like
    Hyperlink on the Wiki page is fixed now.
  32. 1 like
    Hi @vader92, Here is a hackster project that uses the uno and the Pmod HB3 along with a motor. It also has code for you to use. cheers, Jon
  33. 1 like
    Hi @Jon Frey 1. Yes, it is more of a software feature and beside AD2 it can also be used with AD1 and EExplorer. 3. The impedance analyzer usage is flexible. It can be used with wires, breadboard, custom adapter board or bnc adapter. It lets you specify custom probe impedance to match your wiring/circuit. a. The AC/DC option in the software is intended to switch the input coupling of the device, but so far there is no device with such dynamic option. The AC/DC scope input selection should only influence the analysis at low frequencies, like below 100Hz. b. The AWG output impedance does not influence the analysis since only the relation between scope measurements is taken in account. However when analysing low impedance loads (and low reference resistor, <100Ohms) due to output impedance the signal amplitude is more likely to drop reducing the measurement resolution. 4. In analyzer mode the values in top right show the load value at the frequency point which is closer to 45* input phase. The options in the dropdown take effect for running instrument or for the next run. 5. The compensations are not carried. Separate set is stored for meter and analyzer mode, since in these modes different frequency steps are used. The compensation for meter mode calculate compensation values for "nice" frequency steps like 10Hz, 20Hz, 50Hz, 100Hz, ... 10MHz 6. Thank you for the observation.
  34. 1 like
    Hi @Shuvo Sarkar, It is hard to tell what is going on from your picture. Please copy and paste the contents of the tcl console into a file and attach it. Also could you include a full screen shot of you block design. It appears that your project does not have a wrapper. I would start with a fresh project. To do that click into the project folder. In proj double click cleanup and this should clean up the project. Next load the tcl scrip. Once the project has loaded. Click in tools->reports->report ip status and upgrade/generate the IP cores if there are any IP cores that are needing to be upgraded. Then create a wrapper if there is not one as in you project above. Then you can generate a bitstream. thank you, Jon
  35. 1 like
    Hi @fandrei, I have used the HDMI-IN here without issue while the Zybo-Z7-20 was powered through the usb cable. thank you, Jon
  36. 1 like
    Hi @Bryce, At the bottom of the Arty resource center here is the 3D CAD model. thank you, Jon
  37. 1 like
    @xc6lx45, You must like experimenting with the reaction of Africanized bee colonies to jack-hammers. I'm in a feisty mood today so what the heck... There is absolutely a place for hard CPU core based FPGA devices like the Zynq. I don't even feel the needs to support that statement. For almost all low power applications the FPGA can't compete with a commercial uC or DSP. I tend to be more sympathetic with you on soft CPU cores using FPGA resources. The exception is when you are pursuing a project that is a labour of love. Implementing a full-stack Ethernet interface in HDL makes no sense to me. There are times when post configuration programmability might push me toward a soft processor. But then I'd use an Atmel clone that someone else's software toolchain. If someone ( I can think of someone ) makes a great soft processor that is compatible with the gcc toolchain I might be interested. By and large HDLs get almost everything done that needs to be done. BTW there's thread in another section in the Digilent forum dedicated to just this topic... which would be a better place to post your argument.
  38. 1 like
    Hi, here is the file on google drive: https://drive.google.com/file/d/1w5bB3QoOe6YPBvX45e82ZW1CK0tdeHh4/view?usp=sharing
  39. 1 like
    @CurtP, Let's see ... The ZipCPU doesn't officially implement a JSR instruction either, even though the compiler *really* wants one. To deal with this case, I taught the assembler and disassembler that a particular two instruction combination was the JSR instruction: MOV 2+PC,R0 followed by JMP <address>. Typically, this was implemented as a long jump to the address, since the assembler never knew where the address would be 'til link time, and the linker wanted to place a 32-bit address into the instruction stream somewhere. As I mentioned before, my long jumps were implemented by loading the value following the current instruction word into the PC, and woodenly encoded as LW (PC),PC. Actually ... the ZipCPU doesn't even have jump instructions per se, but the assembler hides this lack. The ADD instruction provides the other alternative: ADD.C <offset>,PC adds, if the condition C is true, the given offset to the PC. The assembler will quietly turn BRA, BNZ, BLT, etc. into this instruction if the target fits, and the disassembler replaces these instructions with their Bxx equivalents. The C-library will require sub-word addressable memory for its string operations. Plan on needing arbitrary 16-bit and 8-bit load and store capability, or giving up on the C-library and implementing portable code. An unconditional jump does need the capability to load an arbitrary value into the PC, yes. At issue, though, is how you will come back to your machine code and place that address into your instruction stream after compilation and assembly have both finished without knowing what the value should be. GNU's binutils helps, but you'll still need to write the hooks for your own processor. So, moving on to push and pop. The most common case for these routines is when you want to add (or remove) an item from the stack. In my case, GCC calculates the stack size ahead of time, and then subtracts the stack size for the whole routine upon startup. Any register saves will be immediately placed into known positions on the stack afterward. Hence, the startup for a subroutine might look like: subroutine: SUB 24,SP STO R0,(SP) STO R1,4(SP) STO R2,8(SP) STO R3,12(SP) ... compiler generated user code goes here LOD R0,(SP) LOD R1,4(SP) LOD R2,8(SP) LOD R3,12(SP) JMP R0 ; This is the ZipCPU's return instruction The neat thing about how I've set up the bus is that only the first of these loads or stores will cost any bus delays. The second and subsequent (in any string of them) will cost only one additional clock--depending, of course, on the speed of the memory at the other end. For INT/IRET instructions ... the ZipCPU supports two modes a user mode (where interrupts are enabled) and a supervisor mode (where interrupts are disabled). On an interrupt or an exception, the CPU just switches register sets in order to switch modes. The actual mode is kept in the flags register, so any write that changes this mode will cause the CPU to switch modes and hence register sets. Incidentally, this makes it *really* easy to write interrupt routines: they are just written in "C" as part of the supervisor code. When the supervisor is ready to switch to the user mode, it just issues a zip_rtu() command. This turns into an OR 0x100,CC instruction which turns on the interrupt enabled bit and the CPU switches modes. Incidentally ... getting the pipeline working for this, including all of the corner cases, was a real pain in the bitstream. To implement a system call, I'd just call a function. That function would contain the one assembler instruction, "LDI 0,CC", which would then disable interrupts, switching the CPU to supervisor mode--leaving all the user registers intact as though the function were actually called. From supervisor mode, the software can do what it then likes with those register values. There are other possibilities for entering supervisor mode as well. For example, a division by zero error, hitting a debugging break point, at the conclusion of a single-stepped instruction, on a bus error, after hitting an illegal instruction, trying to execute an instruction from non-existent memory, etc. When the supervisor code has dealt with whatever the exception was, it just calls zip_rtu() which executes a built-in RTU (return-to-userspace) instruction. There are other built-ins to help out as well, such as zip_save_context(contextp); which stores the user registers into the array pointed by contextp and zip_restore_context(contextp) which does the reverse, etc. Hence, to swap tasks, you set a timer interrupt. When that interrupt goes off, you save the registers into an array associated with the current task, and then load the registers from the task you want to switch to. Once you then return to userspace, the task swap is complete. Still, the "tough" question early on is: how will you simulate your design, how will you visualize your pipeline, and how will you debug your software (and CPU) once you move to the actual hardware. These are the real questions you need to answer up front and immediately. Everything else follows from the answers you give to these questions. Dan
  40. 1 like
    @CurtP, Simple pipeline's aren't. Indeed, debugging the pipeline with all of its corner cases has been a challenge for me and I just wanted to build the simplest pipeline I could. You might wish to start planning for this ahead of time, since I was perpetually surprised by little nuances I wasn't expecting. I mean, seriously, who would ever load a register from a value pointed to by the same register? "LOD (R0),R0" ... it doesn't make sense, why would you do that? Well, GCC created code that did that which my CPU then needed to accommodate. If you are interested in register renaming and/or out of order execution and stuff ... think now, before you start, about how you wish to represent the state information from within your CPU as you debug it. This will be important to you. Without a good way to view and inspect the problem, you won't be able to move forward to working code. Will you be supporting unaligned instructions? Classical RISC ISA's don't, but it's something to consider. When I was designing my own instruction set, the requirement of only writing one register to the register set at a time prevented me from implementing such instructions as push/pop or iret. In hind sight, GCC handled the missing push/pop so well you'd hardly know they are missing. Indeed, the CPU is probably faster as a result. Oh, I should mention regarding flags ... GCC (or any C compiler for that matter) will want the ability to compare and branch off of any signed or unsigned comparison. That's =, !=, <, >, <=. and >=. In other words, you will need to support (somehow) 11 conditions. The ZipCPU sort of cheats and supports only 7 of these, but it's something to remember. Also, the flags can be a hassle to get the sign bit and overflow bit right. Don't forget to adjust the sign bit to keep it correct in case of overflow, or your extreme comparisons won't work. Looking over your ISA, I noticed ... You don't seem to have any conditional branch instructions. Are these the j?? instructions? Do you have a JSR instruction? I don't see any multiply or divide instructions. I didn't have multiply or divide instructions in my first iteration, and needed to come back and add them in. The ones I now have are three 32x32 bit multiplies returning the top 32 bits if signed, the top 32 bits if unsigned, and the bottom 32-bits. I've also got two 32x32-bit divide instructions, one signed and one unsigned. The compiler would love me to have a remainder function, or even a 64x32 divide, but in the ZipCPU architecture those require some software to accomplish. I didn't see any NOOP instruction. That was another afterthought instruction of my. Sure, you could move register A to register A, but such an instruction might stall waiting for A to become available, whereas the NOOP doesn't need to read any instructions. How about that memory access: will your ISA allow 8-bit byte access to memory? I had to come back and add byte and halfword instructions into my ISA as an afterthought, when I couldn't get the C-library to compile without them. While from your description it doesn't sound like you'll struggle from this, I had to wrestle with the realities of linking when I first discovered how a linker worked. There are two basic instructions the linker wants to adjust: load a value into a register, and jump to a location. The first one was fairly easy, I took two instructions and I could load any value into any general purpose register. The second one was harder, but I eventually wrote something similar to what you've described above. I consider this the LOD (PC),PC instruction--or load the value at the next memory address in the instruction stream into the PC. It's the only instruction I have like it, as all my other instructions fit into 32'bit words with no immediate's following. If you are interested, you can see my own instruction cheat sheet here, or a longer discussion of the ISA here. Good luck! Holler if you get stuck, or when you discover you can't get as far in VHDL as I did in Verilog ... Dan
  41. 1 like
    Hi @hawdai, In the reference manual here in section 8.2 High-Speed Pmod it show that traces are routed 100 ohm (+/- 10%) differential. Cheers, Jon
  42. 1 like
    @deppenkaiser You could absolutely write a custom linux hardware driver to access your own IP cores from linux. However, if you have never written a linux hardware driver before, this is probably not a great idea. The linux hardware driver system can be quite challenging if you have never been exposed to it. Probably the simplest option is to declare your IP hardware as a "generic-uio" device to the kernel. From that point you can mmap the hardware into virtual memory and then control your hardware using direct access of registers from a user-space program. I have some examples of UIO devices and how to use them posted here. In that folder, you can see code that will mmap UIO hardware into your virtual memory and then there are UIO implementations using this for PWM and GPIO IP cores. Let me know if you have any questions and if you need examples of setting up your ip-core as a generic-uio device. Regards, Mitchell
  43. 1 like
    Hi @anurag, Generally speaking, if you define a pin on an FPGA to be an output and then accidentally supply a matching input voltage (for example 3.3V output and supplying a 3.3V input) there should not be any problems. However, if your output was instead 0V and you accidentally gave it a 3.3V input voltage, you would likely damage the FPGA pin. If you are concerned about this, what I would recommend to help mitigate this would be to implement some external resistors (in series) between the FPGA output pin and your input voltage. The Pmod port on the Cmod A7 already implements these series resistors for you, but the DIP pins do not. Realistically speaking, if you are aware of the potential issue of damaging the board, the knowledge of that should keep you from accidentally connecting incorrect voltages to one another. Otherwise, I might recommend using color coded wires to help ensure all of your signals go to the right places. Let me know if you have any other questions. Thanks, JColvin
  44. 1 like
    Hi @Old Printer RPi support is still dead in the water ... but there is a VIABLE ALTERNATIVE !!! I can confirm the findings of forum user @agaelema: it works fine on an Orange Pi PC plus. See this Forum Post for all the details: Using Digilent Analog Discovery in Orange Pi PC PLus Merry Christmas !
  45. 1 like
    Hi, I've created a custom software program in C++ that uses analog discovery 2 and I have two questions. 1. I want to read some data using I2C interface, but I'm having trouble on the idea of how should I set up a "typical I2C" interface in C++. Is there an example anywhere on how exactly can this be accomplished in C++? 2. When reading the on-board temperature value in C++ I keep receiving a constant value if I'm doing multiple reads in a row. How can I fix it so that every time I read the AD2 on-board temp value I would get an updated temp value not the initial value? Thank you!
  46. 1 like
    Hey Kabron, You can store WaveForms Live on the SD card for use when you have no internet connection. If you launch a browser and navigate to the IP address of the OpenScope MZ it will check if your host (where PC, phone, etc) has an internet connection and then: If your host does have an internet connection the OpenScope MZ will redirect the browser to load WaveForms Live from waveformslive.com. The load times are much faster from waveformslive.com than from the Open Scope MZ sd card. If your host does not have an internet connection it will load WaveForms Live from SD card on the OpenScope MZ. If you always have internet access or plan to use the Android / iOS app, you don't need the SD card. We're also planning to add the ability to log data to the SD card as part of one of our Kickstarted stretch goals. Let us know if you have any more questions about this. Thanks! -Kristoff
  47. 1 like
    Hi @Michelle The StaticIO controlled from Script won't provide exact timing. For stepper motor control it is better to use the Patterns. In case you need to automate, like changing the signal frequency you can do it with the Script tool. Here you have some posts about the Script and StaticIO if you need it.
  48. 1 like
    Hi @shabbirahmed Unfortunately no, the protocol interpreters are in the application.
  49. 1 like
    Hello everybody! Since I was sharing this image with others, I thought I'd share it here at Digilent as well. The attached image shows the frequency response of several FFT windows, including the well-known rectangle and Hanning windows. The blue window is one I've put together, but haven't shared the FPGA source code used to implement it. I challenge anyone to do better. Oh, and one other comment ... all but the Hanning window can be used in an invertible FFT process. Dan
  50. 1 like
    We use original USB controller chips. The "Unknown device" indicates missing driver or hardware failure. Please verify the Hardware IDs of the device in Windows Device Manager: - USB\VID_0403&PID_6014: the device is identified correctly Make sure to install WaveForms including the Adept Runtime section which contains the USB driver. Make sure the driver version is 2.12.0 or 2.10.0. The new 2.12.6 seems to work correctly too, but 2.12.4 is wrong. See the steps above to update the driver. - UNKNOWN or USB\VID_0000&PID_0000: hardware problem Try using another cable, USB plug and computer.