Popular Content

Showing most liked content since 12/21/17 in all areas

  1. 2 likes
    I wanted to add this post(rather a long time I know) that I have found a solution to my problem. My original intent was to read, using LVDS, a TI3423 development board from the Digilient Arty board. Utilizing the PMOD header I was able to connect and read values from the ADC. Here are the details so that anyone wanting to do the same thing can benefit from my journey through Xilinx hell. Using Xilinx Vivado I used a SelectIO IP block. I then set the input to DDR and 2 lanes at 6 bits per lane and changed the input points to differential LVDS25. Since the bank is 3.3Vdc the differential input voltage can be seen on the inputs as long as you use 50ohm resistors across the P/N pairs. I used a small bread board where my resistors reside. The key to the data was the frame clock which frames the data. Xilinx does not mention how to use this clock and only by extensive searching their forums did I find a guru who states the frame clock can be used on the div_clk_in. On the SelectIO block IP under the clocks tab you have to change the clock to internal which will enable the div_clk_in input. This is where you land the frame clock. The SelectIO block expects differential inputs for the data but only wants single ended inputs for the clock and the frame. I had to place Utility Buffers under the Base IP catalog to bring in differential inputs from the ADC. To read the data I used the Microblaze uC, uart and 2 axi gpio ip blocks. I monitor the the frame clock and when it changes states I read the 12 bit word and transfer it out over uart. Cheers, Curt
  2. 2 likes
    Hey @tester11, Lets clean up the history really quick because I feel like I am unclear on something still: 1) Are you using the Arty Z7-10 or the Arty Z7-20? I can provide some links to petalinux materials, but before I do that we should make sure that is the right route for you... I think this will be determined by how you want to do your Wifi, as Dan suggested above. Really, if you are locked down with the Pmod Wifi, then I actually recommend you use baremetal (no Petalinux) instead, because that wifi module only works with our bare metal TCP/IP stack (not the Linux stack). If you are OK with using a USB wifi dongle instead, then that opens you up to Petalinux. Here is a breakdown of the different experiences you will have integrating Wifi into your project if you go bare metal vs. petalinux: Petalinux Hardware: USB Wifi Dongle System setup: Medium-Hard. You have to build a linux system and load it onto an SD card. If your needs for the system are not very advanced (e.g. not a lot of third party software), this is easier. The process can be difficult if you run into problems or need to do something that is not typical. Good news is this process is well documented for the Arty Z7-20 by digilent with complete petalinux docs from Xilinx. Additional help provided on this forum. Network Software Development: Easy. You can use the third-party networking library of your choice. Basically the experience will be the same as if you wanted to write a simple networking program that worked on a Linux PC. Bare Metal Hardware: Pmod Wifi System Setup: Easy. Export to SDK, use the demos included with our Pmod Wifi IP core. Software is developed directly in Xilinx SDK and and can also be programmed/debugged on the hardware directly from this tool. Easy to generate an SD card image with your final program too that will run right when the Arty Z7 is powered on. Digilent has several tutorials for this available here: https://reference.digilentinc.com/reference/programmable-logic/arty-z7/start . You should check out the Getting started with Vivado IP Integrator and then Getting Started with Digilent Pmod IPs. Network Software Development: Medium-Hard. You will need to modify the bare-metal examples to satisfy your application requirements. If you are comfortable with bare-metal (think Arduino-like, but without all of the fancy C++ libraries) programming, this should be approachable for you. The fact that Xilinx SDK has a good integrated debugger will be helpful for you to debug this application as it is running. Based on those description, which route would you choose?
  3. 2 likes
    @jpeyron, @aksaltaaf, Why not implement a simple wired SPI protocol between the two boards? No PmodBT required, only a couple of wires required? Dan
  4. 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.
  5. 1 like
    Hi Thausikan, The Nexys Video has a DMA example found at https://github.com/Digilent/NexysVideo/tree/master/Projects/dma This uses microblaze, audio codec, and the ddr memory to implement a small recorder. It may help with your design. Hope this helps! -Sam
  6. 1 like
    Hi, here is the file on google drive: https://drive.google.com/file/d/1w5bB3QoOe6YPBvX45e82ZW1CK0tdeHh4/view?usp=sharing
  7. 1 like
    if you find nothing better - it's a fairly popular component - I've made it work the hard way, once upon a time. See attachment. This was on a Spartan 6. CS4344_DAC_demo.zip sk61_CS4344_DAC.v
  8. 1 like
    Thanks, I'm glad to hear that. I'll look forward to trying some things out with the WF32 board!
  9. 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
  10. 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
  11. 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
  12. 1 like
    Hey João, We've been working with some Bluetooth modules for other products lines (pmods and system boards). If all goes well this could be something we bring to the instrumentation line in the future, but we don't have any immediate plans to create an OpenScope variant with Bluetooth. -Kristoff
  13. 1 like
    @zygot, Oh, I'm around, but you guys have given me a lot of reading material to go through. Well, that and I haven't been waiting on the synthesizer as much so I haven't been hitting reload on the Digilent forum page as often. @CurtP, What @zygot is trying to point out is that I've built my own CPU, the ZipCPU, as a similar labor of love. It's not a forth machine, but a basic sixteen 32-bit register design, with two register sets of that size. It's also small enough to fit on Digilent's CMod S6 while running a small O/S. I'd love to offer you an example register file module, however my own register "file" never managed to get separated out from the rest of the CPU such as you are trying to do. I struggled to find a clean way to do so, and so didn't. If you are curious, you can search the main CPU source and look for "regset" and see how I handled it. In particular, the ZipCPU register file accepts only one write to the register file per clock--not two. I was convinced that two writes per clock would leave the CPU vulnerable to coherency problems--assuming the block RAM's even supported it. This register set supports one write and three reads per clock. Two of those reads are for an instruction, the third is to support the debug port. (You are thinking about how to debug your CPU already, aren't you?) I've also written several instructional blog's on this and similar topics. These cover my view that you should start building a CPU by first building its peripherals, then a debug port to access and test the peripherals, before starting on the CPU itself. Further blog articles discuss how to build a debugging port into the CPU, how to debug the CPU from that port when using a simulator as well as when online. I've discussed pipelining strategies, and presented how the ZipCPU pipeline strategy works. More recently, I've been working with formal methods. I've therefore presented a demonstration of how formal methods can be used to verify that a bus component works as designed, and then offered a simple prefetch as an example. I'm hoping to post again regarding how to build an instruction prefetch and cache, as well as how to formally verify that such a module works, but I haven't managed to clean up my code enough to present it in spite of presenting why such a proof would be so valuable. While I didn't use formal methods to build the CPU initially, I've been finding more bugs using formal methods than I had otherwise, so you might say that I've become a believer. As a result, I'm right now in the process of formally verifying as much of the CPU's modules as I can. I've managed to formally verify three separate prefetch modules, including the one with a cache, the memory access components, the instruction decoder. I've also managed to formally verify several CPU related peripheral components, such as the (yet to be integrated) MMU, counters, timers, an interrupt controller, bus arbiters, bus delay components and more. This has been my current focus with the CPU. Once I finish it, I'm hoping to write about how to use the ZipCPU in case others are interested (and I know they are). I know @zygot dislikes my blog, but you might find a lot of useful information available there to describe the things you've discussed above. Dan
  14. 1 like
    I have both a Pynq and a ZyboZ7. The Pynq has been able to run Arty examples, and the XDC files are basically identical. There might be one peripheral change (microphone?) but everything else that I can remember is 1:1. I don't have any experience with PetaLinux, but I think if you want to go that direction you should try to find a group of users or examples for your board. The most likely place will be on Arty or Zybo. Pynq is more or less marketed to Jupyter users and research. One last thing, if you are looking into video HDMI I would recommend the ZyboZ7 because it has 'cable hider' equalization devices on board to clean the signal. This helps the device lock to HDMI. I have been much happier with my ZyboZ7 for video RX.
  15. 1 like
    Hi This should be really easy to answer by the knowledgeable folks here. If I just use the xdc constraints and map the pin in an FPGA design, will this route to the pmod pin mapped to a specific FPGA pin bypassing GPIO. Of course I would not have any PMOD IP for the particular pmod in my design. I am looking for a way to get a 10Mhz clock I added to the clock wizard easily out to a pmod pin. Any examples would be great Thanks Laurence
  16. 1 like
    Your instincts are very good.. it's great to not have to give advise because the audience has already figured it out for them self.. Insight is hard to come by and can be as important as textbook knowledge. The RTL view of post-route logic ( not the board design schematic ) is a good way to verify that what you want is what you got... and can help resolve confusion. Sometimes you just have to rework your logic to get what you want from the synthesis tool. I still create play projects just for the purpose of understanding the nuances of a particular design/syntax strategy and see what the simulator says and how the bitstream behaves in real hardware.
  17. 1 like
    You are wise and entering this with "eyes wide open"; I am confident that you will be successful and be rewarded for your efforts. As to textbooks, all of mine are currently boxed up as I am about to relocate.... Ashenden's VHDL textbook is a standard reference, though my copy is a bit dated. Sorry, the titles or authors of other books don't come to mind. Altera's Quartus reference manual has some excellent guidance on how to write text syntax that their synthesis tool understand. They also have an excellent "cookbook" of coding syntax for various structures like registers, counters, state machines, etc. Of course imitating good coding styles is not the same as understanding why they are good. Both Altera and Xilinx offer application notes as well example designs with source code. The material can be daunting, even for seasoned professionals, so don't get discouraged by the learning curve. Of course, sometimes you run into a problem that just doesn't get solved after hours of effort and this forum might help with that. The tools are not perfect and can be an impediment on their own.
  18. 1 like
    @Neuromod There are a few ways to answer your question. The first step to supplying a useful answer(s) would be to ask a few questions. What is your level of expertise in FPGA development? What do you want to do with either of the boards that you are eyeing? I don't have direct experience with the Pynq ( nor the Arty for that matter ) and have no interest in either. I do have considerable experience with FPGA development. It's my impression ( and this is based on what I read when the board first appeared ) that the Pynq is more of a "ecosystem" meant to make FPGA development more accessible to non-technical users. I admit to a negative bias with respect to this class of products, some of which is based on experience. That is not to say that the Pynq hardware isn't a better fit for you... but likely if you are a sophisticated and knowledgeable FPGA developer you might have quite a bit of work to get around a lot of barriers to using the board independently of said ecosystem. If you are not a knowledgeable and sophisticated FPGA developer then it depends on how closely your intended use for the board is to what canned IP the ecosystem provides. Understand that my comments reflect biases based on general experience and not the particular boards under discussion. In general, attempts to make FPGA development easy for the casual hobbyist don't deliver on their (implied) promises from my experience. But if you provide more information you are likely to get a wider range of replies and more useful answers.
  19. 1 like
    Hi @csong, You have a private message with the solution. Best regards, Bianca
  20. 1 like
    Hi @david22, I personally haven't used the DSDB, since that appears to be NI only board (it doesn't look like Digilent ever sold it), but I know Digilent has made some VIs for a couple of those Pmods (the Pmod ACL2 and the Pmod ALS) which are part of LabVIEW MakerHub's LINX. The Pmod ACL2 and Pmod ALS also have some c++ demos available on their individual Resource Centers (ACL2 and ALS) as well as IP cores for Vivado if you are comfortable working with HDL. Unfortunately the Pmod GYRO2 has been retired for a few years, so we do not have any existing code examples for using it. If you have not done so already, you may also try asking on the NI Forums for some more experienced advice as none of the Digilent engineers have much experience with the NI Elvis II board. Let me know if you have any questions. Thank you, JColvin
  21. 1 like
    Hi @csong, If you are not seeing the device in the windows device manager, I believe the device will need reprogrammed. I have tagged the appropriate engineer ( @Bianca) who will provide you with additional information. Thanks, JColvin
  22. 1 like
    Hi Blueshark, This page may also be useful https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-ddr-sram-to-ddr-component/start?s[]=ram2ddr This is the module that the looper demo that Jon referenced uses. (Hi Jon!) It may need some adjusting since its the arty but I'm not sure. -Sam
  23. 1 like
    I configured my program slightly differently so I don't need to do this anymore. Thanks for checking!
  24. 1 like
    Hi @victory460, James was correct, it is an issue in the source code for the SoftwareSerial library. The PIC32MZEFG100 does not have an SIDL bit in the CNCON register like the older chips. You can get around this by commenting out those lines in SoftwareSerial.cpp for now. I have added an ifndef line to fix this in the Digilent Core v1.0.4 which i just uploaded. Hope this helps! Tommy
  25. 1 like
    Hi @Allan, In this situation you do not need to use the XADC IP core. You would use the same block design from the internal flash led but instead of choosing the leds in the the GPIO IP core you choose custom. Then you would make the wrapper and constrain the pins names from the wrapper in the the Zybo Z7-10's xdc here. cheers, Jon
  26. 1 like
    We don't use the Arduino IDE for development. We use MPLABX. The MPLABX project setup varies depending on what you want to do, but you should be able to create a new project, target the correct PICMZ, import the source code and build it. You'll also need to setup a programmer / debugger and any other supporting resources you decide to use. Since this setup is pretty open ended we decided to leave it up to users to choose how to setup their environment based on their specific requirements. -Kristoff
  27. 1 like
    Future projects may include clones of other machines or consoles (Apple II, the infamous NES, TRS-80, Amiga there are lots to choose from) and some other projects such as hardware LSTM (long short term memory, used for AI). The challenge for some will be memory (meaning I'll have to make a design that speaks AXI and uses the PS's DDR memory) since things like space for the NES game ROM memory or Amiga 500/1000 memory (including OS ROMs). The really big ones like loading a game ROM also aren't suitable for my python ROM-to-hdl script nor Vivado's RAM initialization file workflows.
  28. 1 like
    Hey, Sounds like it must be a bad board. @JColvin can you help Jose with the RMA process. Thanks! -Kristoff
  29. 1 like
    Haha I'm glad you like it. Keith, Dharsan and I have had a lot of fun working on it. Let us know if you have any questions. -Kristoff
  30. 1 like
    Hi @tester11, Some of the Arduino styled header digital I/O pins are left disconnected do to the Arty-Z7-10 having less I/O pins. The reference manual here in section 16 Arduino/chipKIT Shield Connector along with section 16.1 Shield Digital I/O discuss this situation. This is why the other project would not work with changing the board to the Arty-Z7-10. Here is a completed project using Vivado 2017.4 with the Arty-Z7-10 with the Arduino styled header using the Pmod OLEDrgb and the Pmod WIFI. This uses the Pmod OLEDrgb main.c as the other projects did as well. The connections for the Pmod OLEDrgb are the same as i shown in the pictures attached above. cheers, Jon
  31. 1 like
    Hey, The CSV takes a little reformatting. I removed the header row, deleted the time columns and empty space colums. After that I was able to import with the default settings, and configure it as a SPI channel to decode. I attached the original CSV exported from WaveForms Live and an example of the CSV formatted for import into PulseView. Arduino code: #include <SPI.h> #define CS 8 void setup() { pinMode(CS, OUTPUT); //pinMode(11, OUTPUT); digitalWrite(CS, HIGH); SPI.begin(); SPI.setClockDivider(SPI_CLOCK_DIV128); } void loop() { digitalWrite(CS, LOW); SPI.transfer('O'); SPI.transfer('P'); SPI.transfer('E'); SPI.transfer('N'); SPI.transfer('S'); SPI.transfer('C'); SPI.transfer('O'); SPI.transfer('P'); SPI.transfer('E'); SPI.transfer(' '); SPI.transfer('M'); SPI.transfer('Z'); digitalWrite(CS, HIGH); delay(1000); } WaveformsLiveData - Formatted.csv WaveformsLiveData.csv
  32. 1 like
    PuTTy allows to set an arbitrary rate of the COM ports. http://www.putty.org/
  33. 1 like
    @mbo Have you completed the Getting Started with Pmod IP Cores tutorial through to using Vivado SDK and programming your board? Your hardware looks fine. Using Pmod Header JF would be significantly more difficult than using any other header, since the MIO/EMIO pins don't use the same drivers as the AXI SPI controller that the Pmod CAN IP core wraps. The MIO pins are configured by customizing the Zynq7 Processing System block in Vivado IPI (they appear in the block design as part of the FIXED_IO interface). You can use the LoopBack.c example to make sure that your Zybo can talk to the Pmod CAN. LoopBack places the CAN controller into a mode where the controller receives it's own messages in hardware, so it is a good way of making sure that your hardware works. After that, you can program your hardware onto both Zybos, connecting each to a CAN, and connecting each of the CANs to one another. You can program one Zybo with the RX.c example and the other with the TX.c example. This set up should be able to send a packet defined in the example code from one Zybo to the other. You can demonstrate that this communication has happened by connecting both boards to serial terminals. Thanks, Arthur
  34. 1 like
    Hi @tester11, Are you trying to connect the pmod wifi and the pmod oledrgb to the arduino header from your other thread here. If so you need to right click on the pmod out and pmodoledrgb out and click make external. I would then delete your current wrapper and re-create the wrapper to ensure that the changes get updated. Then you need to constrain the pins that the wrapper creates for the different pmods using the xdc here(Arty-Z7_20). Since you are wanting to use the Digital I/O from the Arduino header and not the Pmod ports you will use chipkit digital pins in the xdc. I can give further assistance on what this should be if you attach the updated wrapper that includes the pmod out being made external. Also you can click into the concat block and reduce the width to one since you are only using the one interrupt. I would also use something like this to connect the pmod to the arduino header. cheers, Jon
  35. 1 like
    You can use the microSD card on the Arty Z7 for both boot and application data. I recommend following the HTTPServer example included with the PmodWIFI for a great example of how to access data that is stored on the microSD card from your application. That demo hosts a webserver found on the microSD (maybe that is the same thing you want to do... ) . If you wanted to boot from SD card while also using the SD card to hold the webserver, you would just put the BOOT.bin file directly next to all of the webserver files and it should work fine. If you still don't want to use SD for boot for some reason, it is also possible to boot from the onboard Quad SPI flash, but that is typically less convenient to program than a microSD card.
  36. 1 like
    Hi @theUltimateSource, Here is a xilinx forum thread that discusses the zynq memory map and how to find more information about it. cheers, Jon
  37. 1 like
    Hi @tester11, I would suggest looking at the PetaLinux Tools Documentation Reference Guide for the version of petalinux you will be using. Here is the Petalinux wiki. I have also reached out to our embedded linux engineer to see if they have any additional input. cheers, Jon
  38. 1 like
  39. 1 like
    @jvalls, You picked a good platform. I love my CMod-S6. It has taught me to appreciate every logic unit on the board. You can see what I did with mine here: a home-made CPU running a fully multi-tasking O/S! I personally never used the I/O planner. I instead found the master UCF file and edited it for my own purposes. (I must be crusty--I trust text files that I can edit over anything I can point-and-click with a mouse). For the most part, all I ever did was to change the names of the pins I wanted to use and commented pins I wasn't using. You may need to use the schematic to trace the pins from their I/O connections all the way to the FPGA names used in the UCF file. It can be annoying, but it's quite doable. Hope this helps, Dan
  40. 1 like
  41. 1 like
    HI @xc6lx45, You should tri-state the other pins (configure as inputs). The buffer isn’t necessary. We missed removing it from the design. It has been removed from some upcoming designs. thank you, Jon
  42. 1 like
    Hi @B SULLY, In the end, Xilinx will be the ultimate authority on their license policies, but my understanding is that a "node locked license" (as per this Answer Record) restricts the software to only be used with one computer/machine/dongle. It doesn't matter what board is used so long as it is inherently supported by the software. As for the "Device locked license" (as per this Answer Record), you are then limited to the chip that the software targets, so if the software targeted a XC7Z010, you will be able to target that same FPGA, even if it's not the same physical copy of the board. So yes, if you got a replacement Zybo it should work with your existing software. I personally don't have any advice for your other questions though as I don't have any experience on DSP or SDR applications. Thanks, JColvin
  43. 1 like
    Take my advice with a grain of salt. But why would you want to introduce the extra complexity of a RN-42 BT protocol and all that could go wrong with that PMOD set up? if there are no distance requirements between the to FPGAs Dan's idea feels like the best rout.
  44. 1 like
    @sausemichel, There is an Open Source Arty A7 project that uses a ZipCPU without microblaze. It both describes in the spec how to set up the MIG controller, as well as offering Verilog examples of how I did it--should that be of interest to you. I also made heavy use of the board file (it's legible XML) to get there--should you run into trouble along the way. Dan
  45. 1 like
    Unfortunately it looks like Xilinx's Video Mixer IP requires an additional license to use (I have not looked into pricing). This means that (without buying the license for the mixer) modifying the hardware pipeline would probably require a custom IP, which would be quite difficult. I should also note that I am not aware of anyone at Digilent that has used the Video Mixer IP before, so any questions about that would probably have to go to Xilinx. For the coordinate systems used in the DemoScaleFrame function, the comments at variable declaration are helpful. The most relevant here is at the declaration of xcoDest and ycoDest. int xcoDest, ycoDest; // Location of the destination pixel being operated on in the destination coordinate system The for loop that contains the Bilinear interpolation function "handles all three colors". This means that within the byte-buffer destFrame, each set of three consecutive bytes represents the R,G,B color values for that pixel with 8 bits of data apiece. The macro DEMO_STRIDE defines the line length of the video buffer - noting that the buffer is always sized to be able to contain 1920x1080x3 bytes of color data, regardless of what resolution is actually being used. What this means is that to index into an area of the destination frame outside of the for loop - which may be helpful if the target color of pixels that are indexed earlier in the for loop depends on the color of later pixels - you can set a destination index, iDest, to be 3 * 1920 * (the y coordinate of your pixel) + 3 * (the x coordinate of your pixel). The RGB values of this pixel will be placed at the memory addresses destFrame[iDest], destFrame[iDest+1], and destFrame[iDest+2]. EDIT: I just noticed the phrase pixel averaging in your post, the rest of my response is just describing this. Could you explain what you mean by blurring the area of the input frame? There are a lot of different algorithms to do something like this... As an example of what I mean, you could figure out what each of the pixels in the area to be blurred would be if they were bilinearly interpolated, take a weighted greyscale conversion of each of the pixels, then take the average of these greyscale pixels, then write that average to each of the color channels of each of the pixels in the target area. I don't believe that the result of this method would look particularly good (a grey box, where just how grey it is depends on the input frame), but might be another good step. -Arthur
  46. 1 like
    I had suspected that this wouldn't work but it was worth exploring. Yes: please ask your dev team if this is something that can be done. For the future: Is there any possibility that the OpenScope MZ can support the WiFi connection of a smartphone or tablet directly without needing a host WiFi network? In other words, the OpenScope would serve as the hotspot / access point that the phone connects to. As a person who uses WiFi technology without understanding the underlying principles, this seems like an obvious choice. I suspect that it is not easy but I am asking if it is possible to do this. Many thanks! dwayne
  47. 1 like
    Unfortunately that won't work with the current version of WaveForms Live. We use the same source code to build WaveForms Live for the browser and as iOS and Android apps. Since the browser cannot talk to hardware directly (for security reasons) we use the Digilent Agent to bridge the gap. We do not have a version of the Digilent Agent that works on iOS or Android at the moment. I'll make a note to investigate this to see if there is a reasonable solution. -Kristoff
  48. 1 like
    @bkzshabbaz, As promised.. check out the S3 Programmer project in the Digilent Project Vault
  49. 1 like
    Hi, I recieved my new OpenScope today (10th of july), after I got a defective circuit board. Connected it to my laptop running Windows 10(64). Everything worked right out of the box! Watched all the youtube videos with no problems. Great! I understand thinks break, sometimes your out of luck and get a faulty product. Just want to say that I thing you guys handled it very well. Even the returning of the package with the old board was prearranged with labels for FedEx. I managed to get FedEx to pick up the old one the same day. Thanks! Jasper
  50. 1 like
    Hello Heinecke, Lab 5 in the Advanced Embedded System Design for Zynq will step you through the process of building a boot image for a hello_world project and configuring the QSPI Flash and an SD card with the Zynq Boot Image. I'm looking for the Factory Loaded Demo and will get back to you once I have found it. I hope the above lab helps you. Andrew