• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JColvin

  1. Hi @Josh K, Well to be honest, it is possible to get the FT4232 chips supported but the specific external EEPROM image that is required is not available or available to be licensed at this point in time. Thanks, JColvin
  2. Hi @Josh K, I apologize for the delay. I spoke with one of our design engineers and learned that unfortunately, Adept is not able to support the FT4232 chips. Thanks, JColvin
  3. Hi @tuhin, From your picture that you attached, it looks like the physical setup is fine, though your Basys 3 is set to boot from whatever is stored on the SPI flash rather than a bitstream which could be a problem if the board is getting power cycled at the wrong time. I would recommend setting JP1 to JTAG rather that QSPI to help eliminate this potential problem. However, there is no way for us to know that the bitstream that you have put on your Basys 3 outputs the individual bits to each individual I/O pin on the Pmod ports or that the Analog Discovery has been correctly configured to read the signals with the Logic Analyzer instrument outside of your claim. I would echo the recommendations from Dan and hamster suggested of using the built-in analyzer that Vivado has or simulate it otherwise as this avoids using any additional hardware as well as any additional troubleshooting that comes with getting the hardware properly connected and synced. Alternatively, you could also attempt to show your 16-bit output on the on-board LEDs on the Basys 3 if you want a visual representation of what is happening (and proof that something is running). Thanks, JColvin
  4. For other readers of this thread, the matching post was responded to here:
  5. Hi @Matt B, I'm not certain how to do this in script, but you can choose to set a trigger to occur based on the length of a pulse width input, though I don't think it will readily test between a range of pulse times. I have attached a screenshot of what the settings would look like for the trigger. Let me know if you have any questions about this. Thank you, JColvin
  6. Hi @Neil22, Is this FT232H you are referencing a separate module or is the JTAG SMT2 that you are referring to? If not, what does your OS report the JTAG SMT2 to be in the Device Manager and can the Digilent Adept software see the JTAG SMT2? Thanks, JColvin
  7. Hi @ARD1996, Yeah, that's about as far as I got as you noted earlier in the quote you found in the Read.VI, but my bosses haven't had me rededicate my time towards this again (and it would take a awhile for me to relearn the material) so I'm not sure if I'll be able to readily help debug/engineer this. Thanks, JColvin
  8. JColvin

    RMS Voltage

    Hi @PYL, This won't be directly solved by Digilent functions as the displaying of the measured WaveForms is done by an NI made VI. However, based on this thread, you can use CTRL+Space Bar to search for some potentially helpful VI's to find the peaks. Doing a bit of looking, the Waveform Min Max VI and the Peak Detector VI may be of use to you. You'll probably need to do some extra configuration and processing if you want the peak values shown for each frequency, but this should be doable in LabVIEW (from my limited experience with LabVIEW anyway). Thanks, JColvin
  9. Hi @D4ILYD0SE, I don't know for certain what you are looking for with regards to the chip clock portions but WSystem.c for me (at least in the pic32 cores) defines how the peripheral bus clock is calculated and has the readCoreTimer function, so that might be a good place to start looking. Thanks, JColvin
  10. Hi @federicopy, The Digilent staff do not have experience with using multiple Microblaze instances on a single FPGA so we won't be a lot of help in that regard. Based on the Microblaze Reference Guide it is possible to do a multi-instance setup though. The folks over on the Xilinx forum will have more experience and knowledge on how to set this up. Thanks, JColvin
  11. JColvin

    GPS Pmod

    Hi @cepwin, Have you added the Vivado library to your Vivado 2019.1 installation? You can do this from inside Vivado by Choosing settings in the Project Manager in the upper left, expand the IP selection in Project Settings and choose Repository. You can then add in the path to the Vivado-Library from Digilent (which you can download from our GitHub here). This should let you generate the bitstream. Otherwise, you don't need to open up Vivado at all. If you have a fresh project you can open Xilinx SDK 2019.1, choose the workspace folder when it prompts you as the sdk folder source (as an example, mine is C:\Users\jcolvin\Documents\VivadoPrj\Arty-S7-PmodGPS_Vivado_2019_1\Arty-S7-PmodGPS_Vivado_2019_1.sdk) and wait for SDK to finish loading the workspace. When it is completed, you should see the hardware platform_0, the PmodGPS application folder, and the PmodGPS_bsp. You can then click the Xilinx tab at the top of the GUI, and choose to program the FPGA with the bitstream it finds. You will then want to connect to your board with your serial terminal of choice (I used TeraTerm) otherwise you won't see anything printing out. I then right-click on the PmodGPS application folder and choose Run As->Launch on Hardware (System Debugger). I then see the data printing out on the serial terminal. Is this what you did for your project? Thanks, JColvin
  12. Hi @wfjmueller, I have passed your request on to our design engineers. As an aside from a guy that answers forum questions and doesn't do any cost analysis or design or anything like that, one thing that I would offer to consider is that with a higher speed chip will come with higher speed/quality components and extra design work to make sure it works as intended. Couple that with margin and I imagine (again, just random forum person speculating) that the cost would not be quite as comparable to the Nexys A7 with the 100T chip as you might like. Certainly some components could be eliminated from the board, but it's hard to justify to the right people to make an essentially custom board that is notably different than all of the "Digilent style" products that have been made that maybe (if we're generous) 15 people on the forum are interested in, but there's no guarantee that what is created meets what the imagined product would be by those 15 people (and realistically they probably all want different things). And on an extra side note, I'd also be okay with a non-Zynq board too. Thanks, JColvin
  13. Hi @D4ILYD0SE, Those of us here at Digilent aren't familiar with the ICD 4, so we won't be of much help in that regard in terms of it's usage. I'm not familiar with the TCP examples in UECIDE (or UECIDE since Digilent uses the Arduino IDE with the Digilent Core), but presuming it's similar, it should produce a .hex file that you can then load onto your board so the examples with TCP could be created and then have file loaded by MPLAB X. This won't have the bootloader portion if it as you mentioned, but it could be useful for you. @Larry Standage might know a bit more with regards to what is programming environment is compatible with ICD 4, though I will let them speak for themselves on that point. Thanks, JColvin
  14. Hi @ARD1996, I found those two VI's that you referenced. As for the block of text that you quoted, that is was some of my findings and thoughts while working with the Pmod NAV VI. The issue at had is less with LINX, LabVIEW, and Pmods as much as it is with correctly interpreting the data from the on-board chip on the Pmod NAV that calculates the data. The data is stored within the Pmod NAV in two's compliment format which means the most significant bit (the MSB) dictates whether or not the rest of the data should be interpreted as positive or negative data. I would recommend taking a look at the Wikipedia article on Two's complement for more details on how to interpret it. As a fair warning, as this material was created nearly 3 years ago, I do not recall if it works correctly or not. Let me know if you have any questions about this. Thanks, JColvin Collect16BitXYZdata_helperVI.vi Twos_complement_with_negativeOutput_helperVI.vi
  15. Hi @ARD1996, I looked through my old material, and found in a folder called "Minor Tweaks or Review needed" a number of VI's that I designed for the Pmod NAV. They were all last modified in late 2016 and haven't been looked at since then, so I do not how well it will work, but at least at lot of the base line is there. The existing Pmods added to LINX will have their own examples that detail how each of them work in the block diagrams in text boxes. I believe the ones I have attached do the same explanation, though based on what I had typed, there is at least some funkiness with the 2's complement conversion that is used. Thanks, JColvin PmodNAV_calibrate.vi PmodNAV_close.vi PmodNAV_loadCalibrationValues.vi PmodNAV_open.vi PmodNAV_openForLoop.vi PmodNAV_read.vi
  16. JColvin


    Hi @Nikitha, I have moved your thread to a more appropriate section of the forum where the engineer much more experienced with the Analog Discovery 2 will be able to see and respond to your question. Thanks, JColvin
  17. JColvin

    RMS Voltage

    Hi @PYL, I am taking a look to see if that is readily feasible within the LabVIEW material. The material that was created for Analog Discovery 2 and LabVIEW was created back in late 2016 though and has not had any further development work since then so I am uncertain of how much help we will be able to provide. Thank you, JColvin
  18. Hi @zygot, I am learning about the academic pricing option, but haven't heard back a verdict yet. The price would be around $600; you can view this on the academic price list that is freely available on the Academic pricing page. As for the KC705 boards licenses, I think it will technically work as they are both the same FPGA chip (XC7K325T-2FFG900C) so even if the license was device locked I do not think Vivado will prevent you from using it with a different board (since conceivably you could have two KC705 boards and only one license, but it would work on both boards). This was something that could be done with Digilent boards back when we had Design Edition vouchers for some of our entry level 7-Series boards (prior to Xilinx changing what was offered in the free webpack version, namely the ILA). Thank you, JColvin
  19. Hi @Peggy, If you are connected to Wifi, then you will be able to get an accurate timestamp; this is shown a bit more in this thread where we got the time elapsed since epoch and printed it out over a serial port using the functions built into the DEIPck library (which the OpenLogger uses). However, it was also done in the Arduino IDE, and I am uncertain where you would incorporate it into the OpenLogger code to get it to save in it's own file (or at the top of each .log file)? This also doesn't solve why the SD card you have is saving at that particular time and date since it is not the epoch time (January 1st 1970). The firmware engineer out on their honeymoon this week, but I will ask them about this once they return to the office. Thanks, JColvin
  20. Hi @pgmaser, I would look at the Spartan 3 Resource Center then which has the Xilinx made user guide (including details on the SRAM and flash). I don't believe you have control over the Done LED. Otherwise, I would recommend that you check that the FPGA configuration mode is set up correctly (as described in the Xilinx User Guide). Otherwise, there are also a number of projects for the Spartan 3 listed in it's Resource Center as well. What is the purpose of the second link you provided? It seems to have no relevance to FPGAs. Thanks, JColvin
  21. Hi @Paul Chang, There are a couple of issues that this could be. The easiest things to check would be to use a different microUSB cable and/or a different USB port on your computer. Otherwise, the next step would be to check that you have the latest version of the FTDI driver. For a Windows OS, this can be done by going into the Device Manager, opening up the Universal Serial Bus controllers section, right-clicking the USB Serial Converter and going to the driver tab. The latest driver version is for Windows and can be found on the FTDI website here: https://www.ftdichip.com/Drivers/D2XX.htm. If that is updated, uninstalling and then reinstalling the driver would be a good option to try next. Thanks, JColvin
  22. Hi @CNg33, I would recommend looking at this thread for the state of the log conversion. Thank you, JColvin
  23. Hi @stever, Thanks for sharing the solution you found! Thanks, JColvin
  24. Hi @sgrobler, The short answer is we are working on it (much like the statement has been for the last few months). The problem at hand is that engineers most familiar with the OpenLogger have retired, changed jobs, or been told from on high to focus on a different project at Digilent, leaving the project to others who are unfamiliar with the firmware and already have full days with their own Digilent tasks. As a small bit of good news, the engineers more familiar with the firmware are finally getting some more time to help out with the OpenLogger material (rather than something else) and so have been able to help provide some feedback on getting this necessary feature working. Bad news is that change hasn't fully happened yet. Other short answer of what needs done: Modify the parseFileHeader function in the dlog-utils.cpp to recognize when a file header that matches the OpenLogger style shown in the OpenLogger.h so that it supports both OpenScope MZ and OpenLogger Modify the convertToCsv function in the dlog-utils.cpp to also supports the OpenLogger with it's own set of timestamp, values, and units for an arbitrary amount of channels (and which channels) that are being sampled. Because of the multiple channels and the continuous logging nature, each conversion will probably need to be "chunked" out so that less powerful computers don't run into memory problems. Hopefully this gives some insight on the state of things. Thanks, JColvin P.S. - for my part on the OpenLogger project, I mostly just created and populated a number of the pages on the Digilent reference site, in case you were curious P.P.S. -- @benl, the channel map should be working as you suspect, but clearly this is a bug that hasn't been resolved yet. I'm not familiar enough with the OpenLogger code to know where to look for the error though.
  25. Hi @pgmaser, You can find the details for the what FPGA pin is associated for the Spartan 3E-1600 in it's user guide that Xilinx created (available on the right hand side of it's Resource Center under Documentation, conveniently linked here for you. LED0, as per page 18 under Discrete LEDs, is linked to D4. This is verified on page 4 of the schematic as well. I presume you were looking at the Spartan 3E starter kit user guide which is using a 500 variant of the Spartan 3 rather than a 1600 variant of the Spartan 3, hence the difference in FPGA pins. An example UCF file for the entire Spartan 3E 1600 is available at the end of the previously mentioned user guide starting on page 163. I am not certain what you mean by "writing to the LCD in 4-bit mode and then turning off the memory chip in the process". Are you referring to the memory chip present on the LCD screen? Based on the Memory Map section on page 44 of the user guide, I don't think you would be able to write to the display while having the memory turned off, though you can just keep the LCD screen turned off with the display off command, fill in whatever you like to the display memory, and then turn the display back on. As for a timing diagram, you would have to find the datasheet of the Sitronix ST7066U graphics controller or one of the functional equivalents that are also listed on page 44 of the user guide. The CPLD (as per page 127 of the user guide) coordinates behavior between the different FPGA configuration memories such as the two PROMs, so if you are using the flash memory, I imagine it is needed for production runs. I don't believe we have the JED code available for it, nor do I think it is readily possible to extra the configuration and display the HDL on ISE, though I am not very familiar with that end of things. Thank you, JColvin