• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by JColvin

  1. I'm hoping that one of our applications engineers will be able to chime in with a recommended fix or push a new update in a reasonable time frame since I don't personally know what would need to be done (I've only managed to set aside enough time to teach myself some basic combinatorial logic in FPGA land so far). So, either-or?
  2. JColvin


    Hmm. Are these standard alkaline batteries or are they NiCd/NiMH batteries? If they are one of the latter, I'm not sure what the problem might be. I'll ask one of my co-workers to see if they have any thoughts on this. Thanks, JColvin
  3. Hi wanderso, I can't personally speak towards the tcl error you're receiving; I'll ask some of our applications engineers to look into this and amend it. As for the the code running about a 1000x slower, this is apparently (according to what another user found on this thread) a usleep() function being macro'ed to milliseconds rather than microseconds. I thought this would have been fixed by the appropriate engineers who wrote the code since that particular post isn't new, but apparently that isn't the case...I'll also make sure this gets corrected. Thank you, JColvin
  4. Hi Jane123, I'm not so sure about the toolchains taking weeks to get up and running, but I did at least learn some compiler terminology that I didn't know. Definitely a different style of post than your other one, which is intriguing (at least to me). Let me know if you have any questions. Thanks, JColvin
  5. JColvin

    PmodDA3 (and Zybo)

    Hi Jun, Unfortunately, the output range will still only be from 0V to 2.5V. The reason for this is because pin 4 on the AD5441A (the reference voltage pin) is set with the 2.5V reference. According to the associated datasheet, the output voltage is dependent on this and will only range from 0V to whatever that voltage reference is. A higher reference voltage (as high as Vdd) could have been provided rather than the 2.5V reference, but I'm uncertain as to the reason why it was not done; even the datasheet for the chip recommends multiple times (at least in the pin description sections) that the reference pin is connected to a 2.5V reference voltage. I don't know if this is because the chip performs better at that voltage or some other reason, but regardless of how frustrated the two of us might be over this, the maximum output voltage in this case is 2.5V. I'm sorry I couldn't be of more help. Thanks, JColvin
  6. Hello megaxoplasma, To answer your other question about the default bit file, the factory program that is loaded onto the Nexys 4 DDR is (according to another applications engineer) actually a complex MicroBlaze project, so you would not be able to easily observe how the LEDs are working on that default project, nor do we have that project posted to our Wiki (although I'm not sure why). If you would like an additional resource in addition to the advice that hamster and Dan kindly provided, I would recommend looking at the GPIO demo on the Nexys 4 Resource Center on our Wiki (link), which cycles through different colors on the Tri-color LED. Thanks, JColvin
  7. Hello, I am not super familiar with the WaveForms SDK, but I believe the answer is yes. According to the WaveForms SDK reference manual, you are able to use FDwfEnum to build a list of the all of the compatible devices, and then open and use the various devices as you need based on their index value from the list that was previously built. Let me know if you have any more questions. Thanks, JColvin
  8. JColvin

    PmodDA3 (and Zybo)

    Hi Jun, I personally can't speak towards your second question, but in terms of the first question I suspect (I don't know for certain) that (presuming JP1 has the jumper loaded) that you are seeing a voltage a J3, pin 1 because of the connection to DVDD via the jumper. The jumper exists so that the AD5541A has a voltage supply on pin 1 and a reference voltage on pin 4 (from the ADR441). If you are applying your own external voltage, you can remove the JP1 jumper to help ensure that no "back-powering" occurs to the Pmod host port. Beyond that, you would only need to make sure that the voltage applied to AVDD (pin 1 on J3) is between 3.0V and 5.5V, as per the schematic note. Let me know if this makes sense. I'll ask some of our applications engineers about your second question. Thanks, JColvin
  9. Hi Daniel, I'm sorry to hear that you keep encountering issues with the WaveForms software. I'm personally not able to offer any advice, but I have asked the appropriate applications engineer to take a look at this thread; they are in a different timezone than I am though, so I don't know how long it will be before they check back in to the Forum. Thank you for your patience, JColvin
  10. JColvin


    Hi SHKLO, Digilent does not manufacture the BBB, so we can't fully speak towards it. Looking at it's reference manual though and the associated datasheet for the power management chip, it appears that battery input voltage range needs to be between 2.75V and 5.5V, and judging from this thread, it appears to be a fairly strict requirement (based on the responses by Gerald, who is the author of the BBB system reference manual). What voltage is your battery power supplying? Thanks, JColvin
  11. Hi riscy00, Those of here on the Digilent end of things (I can't speak for the community on this forum at large) don't have any experience with a PicoTest Injector or the CleverScope, so we can't really speak for them. I'm also not sure what you are referring to when you say "I can see you have been working on AP300 unit to compare with this setup"; I'm not aware of Digilent working with that particular product. We have a tutorial on our reference site showing how to use the Network Analyzer: https://reference.digilentinc.com/learn/instrumentation/tutorials/ad2-network-analyzer/start, but I'm not certain what your question is. Are wanting to know how you would set up the software to run the network analyzer or how you would attach the leads on the Analog Discovery or something different? As for your last question, no, you would not need the new Analog Discovery 2 in this situation over the original Analog Discovery. Thanks, JColvin
  12. JColvin


    Hi Avatar, What I ended up doing with Digilent boards to load a sketch onto them was to use the System Exec VI that's available in the Connectivity>Libraries and Executables pallete. All of the Digilent boards can be programmed by pic32prog (link to github on it) which I then used the System Exec VI to call. In terms of parameters for the pic32prog, what I ended up using was -d <COMPORT> and -b <baudrate>, with a baudrate value of 115200. So what I ended up providing to the command line terminal on the System Exec VI was a string in the following style: cmd/c <pathfile to pic32prog.exe> -d <COM port being used by MCU> -b 115200 <pathfile to .hex file to upload> My path files had some spaces in them, so I needed to modify the string values as per this thread: http://forums.ni.com/t5/LabVIEW/Using-System-Exec-VI-to-pass-Dir-Paths-with-spaces-to-Program/m-p/2118566#M688174. The hex file you can by having the Arduino IDE do verbose output; it'll list where the .hex file is stored on your computer at the end of compilation (at least for me). If you are not using a PIC32 chip (which the pic32prog.exe can target) you would instead need to use AVRDUDE, which I personally haven't used, but it's another program that can be called from the command line. It looks like ladyada has a nice tutorial on using it here: http://www.ladyada.net/learn/avr/avrdude.html. I guess the big thing to note here is that you would still need to do the compilation and code testing on the board you're using with the Arduino IDE. This LabVIEW method will then just upload the pre-made program onto the board(s) for you. If you wanted to have a little more customization via LabVIEW to run the Analog Shield, I know LabVIEW MakerHub LINX has SPI functionality where you can have LabVIEW send SPI commands to the Arudino board and essentially mimic what the Analog Shield library does, but through LabVIEW. Let me know if you have any more questions. Thanks, JColvin
  13. Hello, I have moved your question to the Scopes and Instruments section of the Forum where the engineer best suited to answer your question will be able to see and respond to your question more easily. As for your question 3, we will work with you through an RMA as needed. Thank you, JColvin
  14. Hi Yiyi123, I would recommend STMicroelectronics to get the ideal response from them about their component. Those of us here at the Digilent Forum will not be able to speak with authority on their part. Thanks, JColvin
  15. Hi ailee, You are correct in your schematic that you posted. The grounds do need to be tied together to ensure that each part has the same reference point so you get your true 5V and 12V differences. What you'll end up doing is when you drive one of the input pins high on the ULN2803 part, the corresponding output will become a sink, allowing the 12V line you attached to COM (and powering your solenoid values) to let electricity flow (ignoring the technicalities of which way energy is actually flowing) from your 12V COM to the positive input on the solenoid, to the negative input, and then (essentially) to ground present on your output pin. If you drive the MCU pin attached to an input on the Darlington Transistor Array IC low, the corresponding output pin is placed in a high impedance state so no energy will flow. To get the IC's in parallel, yes you would just logically connect them as if they are stacked on top of each other. Ideally the two ICs will be identical so that the current flow will be split evenly between them so you wouldn't end up overheating one or the other, but to an extent there aren't any guarantees with that. Realistically though, and from my personal experience, there won't be anything else you need to do to get this circuit working or protected. I'd be comfortable wiring up your circuit as you presented at my desk (presuming I had the hardware) without any worries. Let me know if you have any more questions. Thanks, JColvin
  16. Hi J, I agree that we do not currently have a comprehensive tutorial for designing with Vivado and SDK since (as you likely know) there are a huge range of things to explore. At the moment, the best thing we have (that I personally used) is this getting started with Vivado guide. Thanks, JColvin
  17. Hello again, I spoke with the Pmod Product Manager and learned that for the Zybo Pmod Pack demo they ran into the same problem and just ended up using female right angle header (visual reference) they had lying around to get the Pmod TMP3 attached. She (the product manager) is going to look into getting a cable and header or something similar incorporated into the Pmod Packs (as needed per pack type). As a side note, I also learned that the new I2C style will be a 6-pin header (or 12-pin) with the I2C lines and the ground/power so that all of the I2C based Pmods can just plug into Pmod Host ports without any fuss. The function of the two extra pins will probably vary from Pmod to Pmod as necessary and how the pull-up resistors will be implemented needs to be ironed out, but I'm at least personally encouraged that oddball group of the Pmod family is being more formally accepted. Thanks, JColvin
  18. Hi Sol (and Dan), I guess the short answer (I'll give the longer one too) is that this is (clearly) an oversight on Digilent's part; there is no convenient way to plug in the Pmod TMP3 into the Zybo without a DTE cable and a gender-changer pin set (link for visual reference). I'll speak to our Pmod Product Manager so we can get this amended by either including the cable and pin header with the Pmod Pack or changing the Pmod TMP3 for a different one. The longer answer is that this is a leftover artifact from what the I2C protocol based Pmods used to be. They merited (and still do to some extent) their own hardware style since you did not need a full 6 pins (like SPI based Pmods do) and they also need to have the pull-up resistors on both their clock and data lines. I2C (as you likely know) can be nicely "daisy-chained" together so you can have multiple I2C based chips on that single bus, so I2C based Pmods were designed to have a matching "top" and "bottom" pin header so you could daisy-chain them with other Pmods or system boards. But then the orientation of the pins becomes kinda funky; if the long portion of the pins are parallel to the board and you plug them into a Pmod port (like every other Pmod) you lose that daisy-chaining capability as well as running into the problem of whether or not your Pmod had pull-up resistors built in or not. If you used cables with that orientation, the next Pmod or chip in line (so-to-speak) would physically have to be sitting on top of the host board, which isn't really the best plan when you have contact points on the top and bottom of the dev boards that could easily short out if not handled with care. So, it was decided to put the I2C pins perpendicular to the PCB base, much like the Pmod TMP3 is oriented. It was then presumed not to be a problem; if you used the I2C option on the Pmod ACL, you could just plug the I2C portion into the Pmod host port, making sure the power and ground pins appropriately lined up, and then went on with your life (albeit with a tilted system board thanks to the 12 pin connector). But not all of the I2C based Pmods account for that, and the Pmod TMP3 is not the only culprit. That being said, I have heard (I don't tend to participate in those conversations much anymore) that Digilent is working an alternate I2C standard, hopefully one that will address these issues, but I don't know when that will be implemented. Regardless, I'll speak with the Pmod Product Manager and see what we can do for you in a reasonable time frame. Thanks, JColvin
  19. Hi DerekM, Do you mind posting your code for other users to see if they happen to also be using the Pi to run the Pmod IOXP (and Pmod KYPD or whatever they have attached)? Thanks, JColvin
  20. Very cool! I will be sure to provide a link from our Resource Center to the Frtizing page you linked to. Thanks, JColvin
  21. Hi Dan, Thank you for your feedback! We're working on figuring out the best way to give all of our reference manuals a consistent look and feel without overloading anybody with information nor providing a semi-redundant/useless description for Pmods that don't need a lot of extra help (like the Pmod DIP). I personally did a lot of work on the PmodOLEDrgb reference manual, so I will be sure to take a look at it today and get it more usage (user? application? not sure what word I'm looking for here) friendly. I'm certainly excited to see the project you're working come to completion. As you probably know, many of Digilent's FPGA projects with Pmods use MicroBlaze which is nice, but certainly isn't for everybody. Thanks, JColvin
  22. Hi Flyline, That makes sense. I was wondering if it would be due to a rollover problem, but I imagined that rollover problems would be present in both situations so I didn't run look into how the math might work. Thanks for the explanation!
  23. JColvin

    XADC demo

    Hi Manas, I presume you are working with one of Digilent's XADC demos. Which board are you working with? Thanks, JColvin
  24. Hi Flyline, Thanks for the catch on the DisplayClear command! I have updated the library available on the PmodCLS Resource Center with the corrected code. I'm not sure why the '0' was in there, but I suspect it was a leftover artifact from some of the other functions where users need to specify a particular location for the action to occur. I am not certain I fully understand the difference between the two listings though. I can see that Listing 1 ends up putting tWait at a greater value than the CORE_MS_TICK_RATE * mS by adding the current core timer value, but I would think the while loop then intrinsically accounts for that mathematically since from my understanding Listing 2 accounts for the initial core timer reading on the left-hand-side of the '<' as tStart, rather than including it on the right-hand-side within tWait. Thanks, JColvin
  25. Hi Alain, From my understanding, and as Dan mentioned, the library associated with the PmodNIC100 is specifically designed for the Microchip part that is present in the PmodNIC100. As the ESP8266 is a WiFi chip from a different manufacturer, there is no guarentee that the library for the PmodNIC100 will be compatible with the ESP8266 or vice-versa. The chipKIT-Core was specifically designed by the chipKIT community to allow users to program chipKIT boards within the Arduino IDE; it doesn't necessarily imply compatibility between hardware. In theory, the PmodNIC100 is compatible with other pieces of hardware, presuming you have the appropriate software code, but as he noted, I have not seen this done. Thanks, JColvin