• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    JColvin got a reaction from skinnypanda in want to get user input from terminal on bare metal zedboard   
    I'll be honest in saying that I've read through this thread a few times now, but I don't understand how the breakdown in communication happened. I do not think it is my place to decide who is right or wrong or who started what, nor is a random forum thread on the internet the place to do it; we're all adults who know they can learn more things regarding FPGAs/SoC hardware and software tools.
    But I'll try to answer some of the original questions.
    Not terribly difficult with the existing Xilinx functions, though I had to do some digging to find them.
    These functions are the same ones used in zygot's original reply:
    ^This is checking for serial data being available
    ^This one gets gets the actual character and stores it in a user variable.
    You can then do a switch case statement like zygot did to process if the user chose 'y' or 'n' or could do a if else if statement style like the one that is available on Xilinx's Github, https://github.com/Xilinx/embeddedsw/blob/master/XilinxProcessorIPLib/drivers/uartps/examples/xuartps_low_echo_example.c (which uses the same XUartPS_ functions from various Xilinx provided libraries) that takes a letter character received in the serial terminal and then spits back out the opposite case (upper or lower) of that same character. You could then modify either example to do some other function once it gets that that particular case/if statement. I can't find the power supply for my zedboard at the moment, but I was able to readily confirm that Xilinx's example worked as is on a blank C application project on a Arty Z7-10 (using Tera Term) that had more or less the exact same block design as created in the tutorial you linked (minus the custom IP) in Vivado/Vitis 2020.1. The caveat with the Xilinx example is that it's a blocking function in the sense that it's doing nothing else while waiting for the user input; maybe that's fine for your system, maybe not.
  2. Like
    JColvin got a reaction from attila in Waveforms with accelerometer . Digilent Analog Discovery 2 with PMOD ACL2 . Java Script SPI   
    Hi @SIB-V2,
    I pulled out a Pmod ACL2 and an Analog Discovery 2 and was able to get the existing Pmod ACL2 example with WaveForms (under Protocol -> SPI tab -> Custom tab -> Pmod ACL2 example) working on the first try with using the same wire setup that you show in your picture in this specific post (https://forum.digilentinc.com/topic/19237-waveforms-with-accelerometer/?do=findComment&comment=52066, though this post shows that you are attempting to use the Pmod ACL code in the Sensor tab rather than the Pmod ACL2 code in the Custom tab). The example as it's currently structured only runs through a single iteration rather than providing multiple pieces of data over time. I will also concede that the measured temperate is confusing (it is thankfully not 2 degrees Celsius in my office), but that it is because it's measuring the internal temperature of the chip with respect the environment rather than reporting absolute temperature, but I also don't plan on specifically using an accelerometer to measure absolute temperature.
    I also took a look at the work spaces you attached and noticed the following things.
    Direct_protocol_test -- You don't have a supplies tab open to provide a 3.3V power supply to the board and the DQ2 and DQ3 are also mapped to DIO 4 and DIO 5, respectively, which are already being used in your other pin assignments that you changed for some reason. Once you open the Supplies tab and set up a 3.3V voltage and change DQ2 and DQ3 to other DIO pins (I changed them to DIO 0 and DIO 1), the script works.
    SPI_test --- You have the same issue with DQ2 and DQ3. You also use "write" with a lowercase 'w' rather than "Write" with an uppercase 'W'. Additionally you use the wrong command to read the device IDs; you use the write command '0x0A' rather than '0x0B' to read the device ID which is what the code is attempting to do. You later do the exact same thing with the second (correctly capitalized) Write function sending a write command rather than read command. Once I changed those details and added back in the lines of code that set the module into measurement mode rather than leaving it in standby mode which is the default state of the ADXL362, I started successfully receiving data though I'm not sure what data conversion you're doing for each variable, though I can tell you that you are doing it incorrectly because the ADXL362 does not provide data in the registers MSB to LSB as you are presuming it does in you calculations. The module as per the datasheet instead provides bits 7 through 0, then bits 15 through 8 of the two bytes which is why the built in sample code Attila has pointed to does some bit manipulation and rearranging.
    I didn't check the logic analyzer tool that you had pulled up in this workspace.
    You also have the SPI clock running at 5 kHz where as the datasheet recommends a serial clock rate between 1 MHz and 8 MHz, especially for multibyte transfers like you are doing.
    SPI_test_2 --- Looking at the protocol tab, there are the same issues with DQ2 and DQ3, the lack of turning on measurement mode, slow SPI clock, and the conversion is incorrect as explained previously. Again, once I added in measurement mode to your else statement and fixed DQ2 and DQ3, I started receiving data correctly.

    The script seems to work (or at least provides numbers) when I adjusted DQ2 and DQ3 in the Protocol tab to non DIO 4 and DIO5 values; by default it does not work. You can also specify the details specifically in the setup. The Power Control register bit of the script only sets up measurement and the ultralow noise mode, not the adjust the autosleep function that is mentioned in the comments. I didn't look into it much though.
    SPI_test_3 --- Looking at the protocol tab, there are the same issues with DQ2 and DQ3, the lack of turning on measurement mode, slow SPI clock, and wrong conversion that you are performing. Again, once I added in measurement mode to your else statement and fixed DQ2 and DQ3, I started receiving data correctly. I didn't check the script.
    SPI_test_4 --- For the protocol tab, this only needed the DQ2 and DQ3 to be fixed. I didn't look at the script tab.
    SPI_test_5 --- The protocol tab is successfully reading back the 4 register values as configured. I didn't check the script tab. 
    Based on my experiences though, which to be fair is only a single person with only one Pmod ACL2 to test, I think that the WaveForms software and the Analog Discovery 2 is supremely well supported by Digilent and specifically Attila.
    If you have any questions or comments, please let me know.
  3. Like
    JColvin got a reaction from Resul in How to set CC/CV mode with code?   
    Hi @Resul,
    I believe this change is implemented starting with beta version 3.16.33: https://forum.digilentinc.com/topic/8908-waveforms-beta-download/.
    Let us know how this goes for you.
  4. Like
    JColvin got a reaction from druiz in How to restore FT2232 EEPROM back to factory settings?   
    HI @druiz
    The detail I was looking for is that it uses a JTAG-SMT2-NC (which I found out via Xilinx's schematics for the KCU105). I have sent you a PM with some instructions.
  5. Like
    JColvin reacted to skinnypanda in ERROR : (XSDB Server)ERROR: [Hsi 55-1571] The design file project_1_wrapper/export/project_1_wrapper/hw/zed.xsa is already opened   
    LED's are blinking and serial ports are talking!
    oooooh, MAN this feels good.
    thanks again for the help.
  6. Like
    JColvin reacted to ivansavy in Vitis removes drivers and hardware files during platform build   
    Including the xil_io.h header removes the error and allows me to successfully run the application. I assumed that my custom IP header contained all the necessary operations, but I traced them and there was no mention of the read/write operations. Looking at my other applications, they all include files which somehow trace to xil_io.h.
  7. Like
    JColvin got a reaction from Brando Davalos in How to run scripts for AD2 from a command line terminal?   
    Hi @Brando Davalos,
    The WaveForms SDK, which is included as part of the WaveForms software download, is what you are looking for. There are a number of examples, including Python based examples, that come as part of the installation. You can learn more about it on it's Resource Center here: https://reference.digilentinc.com/software/waveforms/waveforms-sdk/start.
    If you have any specific questions about the WaveForms SDK, feel free to ask them in the Test and Measurement section of the our Forum where the engineer most familiar with the WaveForms SDK will be able to see and respond to your questions.
  8. Like
    JColvin reacted to Stargo_44 in Digient ChipKit WF32 "To Target Found"   
    I've resolved my issue by following those steps in this link :
  9. Like
    JColvin reacted to emexb in CMOD A7: possibly burned I/O testing, how can I do this?   
    I finally found the problem!
    By sending a dump command (sending d through RealTerm, which will clear the buffer on the synth) the XFM2 finally worked with the Arduino.
  10. Like
    JColvin reacted to charkster in cmod a7 xadc, which sequencer channels can I use from the 2 analog inputs?   
    Hi @JColvin,
    Thank you very much!! I should have looked at the schematic. I raised pin 15 voltage to 3.3V and saw full range on the 12bit value. I have a really good XADC configuration which is working well for me. I will post it tomorrow if others are interested. It converts a single channel continuously and has a data valid signal.... very simple.
    Great support is why my company buys Digilent.
  11. Like
    JColvin reacted to attila in Installing an Analog Discovery 2 on a M1 Macbook Air.   
    For the record, here is the same post with answers:
  12. Like
    JColvin got a reaction from Ahmed Alfadhel in NN activation functions   
    Hi @Ahmed Alfadhel,
    Those of us at Digilent don't have any direct advice to offer regarding neural networking, but a cursory internet search yielded these two papers (link1, link2) that might be of interest to you.
  13. Like
    JColvin reacted to reddish in Announcing pydwf 1.0 - a Python package for the Digilent Waveforms devices   
    Hi all,
    I am happy to announce version 1.0 of pydwf, a comprehensive Python package for using Digilent Waveforms devices from Python.
    The pydwf package is fully open source and released under an MIT license.
    On GitHub: https://github.com/sidneycadot/pydwf On PyPI: https://pypi.org/project/pydwf/ On Read The Docs: https://pydwf.readthedocs.io/en/latest/   (HTML and PDF) The package works from Python 3.6 onwards, on any platform supported by Digilent (Windows, Linux, macOS).
    Install it using pip3 like this:
    $ pip3 install pydwf The next step would be to look at the documentation, and perhaps run an example or two.
    Some features
    An easy-to-use, class-based API; Pretty comprehensive documentation (with improvements planned); Quite a few examples on how to use pydwf for some real-life applications; A cool logo :-) Alternatives

    Alternatives to pydwf exist, such as using Python's ctypes module directly (which is what the Python examples provided by Digilent do), and the older "dwf" package (https://pypi.org/project/dwf/). I think pydwf is a lot nicer to use than either of these, and I hope you will agree.
    Future work
    Most importantly, I want to keep up with new releases of the DWF C library as they come along. Next, I'd like to further improve the documentation, to include more information about what all the settings mean. The Digilent SDK is great, but its documentation does not go down to the nitty-gritty detail of explaining what each setting does precisely, which is something I miss. Through a combination of experimentation and asking on this forum, I hope to tackle this in the pydwf documentation. Lastly, I'd like to provide more examples, e.g. to clearly explain the correct way to use the different acquisition modes of the AnalogIn and DigitalIn instruments, to demonstrate the powerful but complex possibilities of analog and digital triggering, and so on. Feedback

    Please let me know if you use the pydwf package, if you're happy with it (or not), and if there's anything you want to see improved.
    To report specific issues, please use the GitHub issue tracker.

    I spent quite a bit of time on all of this over the past few years; three months ago I decided to bite the bullet and aim for a proper public release with documentation, examples, and all that. There are certainly areas where improvement is still possible, but as of now I think the package is of sufficient quality to be useful to people other than myself.
    I hope the work will prove useful to some of you!
    Best, Sidney
  14. Like
    JColvin got a reaction from Jan Kok in Documentation Question   
    Hi @baricaptain,
    I apologize for the delay.
    The xdc files for all Digilent boards cab be found on our GitHub here: https://github.com/Digilent/digilent-xdc/.
    I will make sure the manuals are appropriately updated to direct readers to the appropriate location.
  15. Like
    JColvin got a reaction from gigametre in How to restore FT2232 EEPROM back to factory settings?   
    Hi @gigametre,
    I have sent you a message.
  16. Like
    JColvin reacted to Steve Ives in Brand New Basys 3 User -- Can't get Vivado to see it   
    I received a new Micro USB cable and I am making progress.  I now see what I should be seeing under 'Device Manager.'   I also see that the Adept App connects.  
    So, thank you very much.  It appears that my first Micro USB Cable was deficient. 
  17. Like
    JColvin got a reaction from rappysaha in Genesys ZU-5EV   
    Readers of this thread (including myself) may be surprised to learn that I received a company email yesterday evening notifying me that the Genesys ZU 5EV has moved out of the prototyping phase and into the production phase.
    I do not have a release date/timeline/quarter to share (despite me asking for one) or other details to share at the moment, but still wanted to give out this update. Screenshot of evidence attached as promised.  

  18. Like
    JColvin got a reaction from lukelouyu in [Zybo z720] Integrate the External sensor and Pmod ESP32   
    Hi @lukelouyu,
    I guess I am a bit confused; if you are able to get the pH and EC sensor working as expected with the xadc demo that you linked (which seems to be originally designed for the Zedboard for an older version of Vivado based on the screenshots used) and getting expected voltages after doing some conversions, I'm not certain what issue you are running into; just not being able to then generate the bitstream after adding more Pmods?
    I'm not certain what problem you are seeing with the Peripheral I/O pins on the Zynq block reconfiguration screenshot; from what I can see it is the same as the Digilent block configuration that I have for the Zybo Z7-20 on Vivado 2019.2. One screenshot in the Lab3 document shows disabling Timer0 for the APU, but that is already done by default in the Digilent board files for the Zybo Z7-20. I'm guessing they needed to do it in the tutorial because the tutorial creators were using a different set of board files for the Zedboard and didn't have the Zynq IP pre-configured as needed.
    I don't have all of the Pmods with me while working from home to test anything, but I did the following steps to get a bitstream and successfully reporting data received by the xadc (which Pmod JA) is attached to on a serial terminal in Vivado 2019.2
    Add Zynq IP to new empty block design and run block automation with board preset Double click on Zynq IP to add a second PL Fabric clock (FCLK_CLK1) at 100 MHz for the Pmod ESP32 From the board tab, add in the different Pmods to their connectors (ALS JB, AQS JC, HYGRO JD, ESP32 JE) but not clicking run connection automation. Add in XADC wizard IP. Double click on the IP to reconfigure the defaults to enable Channel Sequencer and have vauxp6, 7, 14, and 15 enabled and vp/vn disabled. Make Vauxp# and Vauxn# on the XADC wizard IP external. Run Connection Automation. Make sure to have three clock sources (master, slave, and bridge if I recall the names correctly) for both the GPIO and UART AXI interfaces on the Pmod ESP32 be set to the 100 MHz clock in the pop-up where you select which things you want to automate. I left all of the other connections to be default, but you can specify for them to use the default 50 MHz fabric clock. Validate the design, acknowledge the messages on negative DQS skews, and create a wrapper. In the sources tab, add a constraints file with the following details:
    set_property -dict { PACKAGE_PIN N15   IOSTANDARD LVCMOS33 } [get_ports { vauxp14_0 }]; #IO_L21P_T3_DQS_AD14P_35 Sch=JA1_R_p           
    set_property -dict { PACKAGE_PIN L14   IOSTANDARD LVCMOS33 } [get_ports { vauxp7_0 }]; #IO_L22P_T3_AD7P_35 Sch=JA2_R_P             
    set_property -dict { PACKAGE_PIN K16   IOSTANDARD LVCMOS33 } [get_ports { vauxp15_0 }]; #IO_L24P_T3_AD15P_35 Sch=JA3_R_P            
    set_property -dict { PACKAGE_PIN K14   IOSTANDARD LVCMOS33 } [get_ports { vauxp6_0 }]; #IO_L20P_T3_AD6P_35 Sch=JA4_R_P             
    set_property -dict { PACKAGE_PIN N16   IOSTANDARD LVCMOS33 } [get_ports { vauxn14_0 }]; #IO_L21N_T3_DQS_AD14N_35 Sch=JA1_R_N        
    set_property -dict { PACKAGE_PIN L15   IOSTANDARD LVCMOS33 } [get_ports { vauxn7_0 }]; #IO_L22N_T3_AD7N_35 Sch=JA2_R_N             
    set_property -dict { PACKAGE_PIN J16   IOSTANDARD LVCMOS33 } [get_ports { vauxn15_0 }]; #IO_L24N_T3_AD15N_35 Sch=JA3_R_N            
    set_property -dict { PACKAGE_PIN J14   IOSTANDARD LVCMOS33 } [get_ports { vauxn6_0 }]; #IO_L20N_T3_AD6N_35 Sch=JA4_R_N Generate a bitstream and export the xsa including the bitstream I kept getting various errors on the Vitis side of things with the xadc so I haven't gotten to debug those, but if you are able to reliably use the xadc code you posted, adding in other Pmods to the associated block design should in theory be more straightforward. I'll keep looking into it tomorrow.
  19. Like
    JColvin got a reaction from rappysaha in Genesys Zu-3EG HDMI Tx and Rx port Connection   
    Hi @rappysaha,
    I don't believe you will be able to do this as the appropriate IC's aren't loaded and the 3EG is lacking the GTH transcievers needed, as noted in the Genesys ZU Reference Manual and schematic. I have reached out to get official confirmation on this.
  20. Like
    JColvin got a reaction from rappysaha in Genesys ZU-5EV   
    Hi @rappysaha,
    I have not heard any updates at this point in time.
    I will be sure to post any updates that I hear (and have verifiable evidence for) on this thread.
  21. Like
    JColvin got a reaction from rappysaha in Genesys ZU-5EV   
    The latest information that I have heard is that we are hoping for a late Q1 release, though this can vary depending on a number of factors. If it's any consolation, it's a later release date than Digilent would like it to be as well.
  22. Like
    JColvin got a reaction from Muhammed Kawser Ahmed in ZYBO BSP old version   
    Digilent would need to create and release a different version of the build in order for the BSP projects to work on different versions of Petalinux. I do not know when this will be done, though considering the past history of similar questions on our Forum, I wouldn't anticipate on this being done soon.
  23. Like
    JColvin got a reaction from helloworld1029 in About daisy Chaining the I2C Pmod   
    Hi @helloworld1029,
    I'm not sure that Digilent has any examples for daisy-chaining I2C Pmods together in Vivado/Vitis/SDK. The forum post you are referring to is for putting two Pmods on the same port, but one 6-pin Pmod uses the top half of the Pmod host port and the other Pmod uses the bottom half of the Pmod host port, which is not daisy chaining.
    I haven't attempted to create such a design, but this won't be easy to accomplish in the block design portion and have everything get properly ported over to Vitis. The reason for this is that with daisy chaining, you'll effectively be having the two Pmod IPs attempting to place their IO buffers and scripted constraints on the same pins, which Vivado will (wisely) complain about and not let you do. Using a more general AXI I2C controller rather than a Pmod IP may also be a wiser option in terms of accounting for both Pmods on the software side in Vitis/SDK.
    I would probably attempt two different methods. One would be to leave out the daisy-chained Pmod entirely from the block design to avoid having to fight with Vivado/Vitis to get it "properly" ported over to Vitis and only have the first I2C module in the block design. You could then account for other modules in the daisy chain on the software side through other helper functions.
    The other would be have both blocks in the design, much like you have done in your screenshot since both should get imported in the hardware platform/.xsa to the Xilinx software tool appropriate to whatever version you are using. It'll then be much easier to adjust or copy over as appropriate the existing libraries/functions so that they both work on the I2C module that the Xilinx tools think is directly connected to the Pmod port. I'd probably do this by porting over the further downstream Pmod library functions into the libraries of the directly connected module, and then adjusting the main.c function as appropriate to talk to the different modules as the design requires.
    To be clear, there are multiple approaches that could be taken to this particular design; but all of them will require different amounts of finagling in the Xilinx tools to make the design work.
  24. Like
    JColvin got a reaction from Erosand in CMPS2 compass module with Arduino - Heading steps accuracy   
    Hello @Erosand,
    I do not know when I will have time to fix the library (or I guess the single file) but I identified a few weird things that are likely resulting in problems.
    The CMPS2_init() sets the global maximum variable to -32768, and the global minimum variable to 32767. This mismatch causes problems later. Global midpoint is set to 0. The CMPS2_read_XYZ() inside of the CMPS2_getHeading() then checks to see if the measured X and Y data (after already converting it into mG, so they aren't even the same units) is greater than the global maximum variable and the less than the global minimum variable. Because of bullet point 1, this (mostly likely) sets the global max and min values to be exactly the same as the measurement value. The global midpoint is set to the average of these two values, so exactly the same value. In the CMPS2_getHeading() a Reset function is performed (to get an opposite phase shift I guess) after bullet point 2 and then CMPS_read_XYZ is performed again. However, because the global max and min values have not been reset, the new measurement data is getting compared to the exact same data. I guess in theory if you continually repeated this process as the module was rotated around, you would get the max and min values for the X and Y axis, but this isn't done in the code. So the max or minimum may have changed slightly, but not both, and the global midpoint is the bifurcation of this potential small change. I might be misunderstanding the code though. In the CMPS2_getHeading() after bullet point 3, it says offset is eliminated between the two measurements, but all it does is assign the calculated offset to a temporary variable, component[i]. In the CMPS2_getHeading() after bullet point 4, it then uses these calculated offsets, rather than actual values, to compare to the global midpoint, in order to determine what quadrant and thus what equation should be used to determine the corresponding degree heading. I'll ask around to see if somebody will be able to address some of these changes.
  25. Like
    JColvin reacted to zakkjf in Trying to find correct board files/ board packages for older Zybo board   
    Nevermind! I figured it out. Rev B worked the whole time and SDK "hello world" now prints from the terminal perfectly - the Zynq module simply needed the input clock set to match the board 50Mhz (For some reason the Zynq peripheral defaults to 33MHz, which is incorrect for how the Zybo boards are configured)