ruzzmon

Members
  • Content count

    27
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ruzzmon

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. ruzzmon

    Xilinx VHDL UART Example

    Is anybody working on this or interested in working on this? I doubt I'd have the knowledge and skill at this point to do it myself... Thanks
  2. ruzzmon

    Xilinx VHDL UART Example

    Hi guys, That opencores project Jaxartes posted seems like a perfect fit! In the future this means we could generate hardware peripherals for DesignLab library that could be instantiated as either standalone or ZPUino-connected which I think is pretty neat and adds some flexibility and reusability. Thanks
  3. ruzzmon

    Xilinx VHDL UART Example

    Hey Jack, Any chance you were able to implement this idea already into DesignLab? I couldn't seem to find it. I was looking for an easy way (drop-in) to communicate with some registers on the FPGA without the ZPUino/other soft processors. Any other suggestions to do this would be useful as well. In fact, it'd be really cool if there was something like a UART that could talk to the wishbone bus registers directly. Is that possible? That would mean we could reuse all the work that people may put into developing wishbone compatible peripherals but who may not need the power/functionality of the ZPUino. Thanks
  4. ruzzmon

    DesignLab 1.0.4 Released!

    Hi Alvie - sorry I dropped off a bit there. I need high speed because I'm generating pulses through a DAC (so I can vary the amplitude also). I'm using this board to drive an ASIC for testing purposes. I actually did realize I should go ahead and build an FPGA block in VHDL so I'm working on that. Thank you for the detailed explanation, it is very useful for my understanding of the reason for delays. Also the variability of cache hits/misses explains the jitter I was seeing.
  5. ruzzmon

    DesignLab 1.0.4 Released!

    Thanks for the example Jack! I figured out my problem was not the code itself, but rather the frequency of my calls to the timer. Do you or Alvie have an idea of how often we can call the timer? A maximum operation frequency for example? I'd like to use the timer to make calls to write a signal/reconstruct a waveform and so the faster I can call the timer the better. Ideally a step-size of 1µs (1MHz) would be perfect but I can probably deal with 2µs step sizes without issue. Any tips to increase the speed? Your example works up to 1MHz (and probably higher; I tried 2MHz but that didn't work) but my own code, which does some additional processing, tops out at 600kHz (which I think I can make work for me but I want some additional 'buffer' room). For example, I would assume that my code must execute much faster than my minimum step-size and to accomplish this I'd need to optimize my code. Is there anything else than improving my code? Perhaps something like running two timers in parallel, both at 500kHz (assuming I can split my code as such). Thanks for any insight you guys may have and apologies this isn't directly about 1.0.4.
  6. ruzzmon

    DesignLab 1.0.4 Released!

    Hi guys - is there a workaround for the timers? I wanted to try and use periodicHZ but I see in this thread that it may not be fully functional yet. Is that correct? In my test code, it looks like my function would get called periodically (didn't check the frequency) but the rest of my program would not execute. It appears to get stuck in setup() right after I initialized the timer. Thanks!
  7. ruzzmon

    DesignLab 1.0.4 Released!

    Thanks Jack - that seems to have it working again. May I suggest running a few of your examples as a test suite prior to a release. It may help you find and address these problems before we try to report them and will also save us some headaches. 1.04 had an error in SPI code and SPIADC and you have examples for both. Also, I have switched over to Alvie's new VGA adaptor and the results are excellent (Papillio Pro). Thanks
  8. ruzzmon

    DesignLab 1.0.4 Released!

    If anyone has the AnalogWing, can you please test it out with the AnalogWing example in 1.04 (after modifying the SPIADC.h) per my previous post (#4 above). I don't seem to get any output (zeros across all channels) and I'm not sure if anything changed or if something else went wrong hardware-wise with my wing. Thanks
  9. ruzzmon

    DesignLab 1.0.4 Released!

    Hey guys - there's a compilation error for anything that uses SPI in my new 1.0.4 installation that has been there from the previous 1.0.3 installations. This example is from the analog wing example. The fix is easy (comment out line 16 of libraries/SPIADC/SPIADC.h). I thought I had seen this change made previously in github. Or perhaps the fix is actually supposed to be elsewhere? Build options changed, rebuilding allIn file included from WING_Analog.ino:50:C:/DesignLab-1.0.4/libraries/SPIADC/SPIADC.h:16: error: redefinition of `struct CS'C:/DesignLab-1.0.4/hardware/zpuino/zpu20/libraries/SPI/SPI.h:55: error: previous definition of `struct CS'Error compiling.
  10. ruzzmon

    Working on DesignLab 1.0.3 release.

    Here's that same output for another sketch/circuit I'm working on that has all Wishbone slots occupied in the circuit. There are 6 DACs in that (I'd like to be able to access more eventually; I had posted about requesting a Wishbone expander). I'm posting this because the output doesn't make sense to me. I assume that slots 12 and 13 should show registered as well. Slot 12 is VGA and Slot 13 is the character map. We already know something is up with the DACs in slots 6, 8, 9, 10, and 11. Device at slot 0 NOT registeredDevice at slot 1 registeredDevice at slot 2 NOT registeredDevice at slot 3 NOT registeredDevice at slot 4 NOT registeredDevice at slot 5 registeredDevice at slot 6 NOT registeredDevice at slot 7 NOT registeredDevice at slot 8 NOT registeredDevice at slot 9 NOT registeredDevice at slot 10 NOT registeredDevice at slot 11 NOT registeredDevice at slot 12 NOT registeredDevice at slot 13 NOT registeredDevice at slot 14 registeredDevice at slot 15 NOT registeredAnd here's the circuit: While we're at it, are any of the slots defined in 'register.h' fixed and unavailable? If not, what are the other slots (not shown on the circuit) being used for? I'm getting a little confused with this move to more modular peripherals (which I think is a great idea). Thanks
  11. ruzzmon

    Working on DesignLab 1.0.3 release.

    Hi Alvie, I had tried that earlier, but that too didn't work. Here's the error: C:/DesignLab-1.0.3/hardware/zpuino/zpu20/cores/zpuino/DeviceRegistry.h: In function `void loop()':C:/DesignLab-1.0.3/hardware/zpuino/zpu20/cores/zpuino/DeviceRegistry.h:41: error: `static bool ZPUino::DeviceRegistry::isRegistered(int)' is protectedEDIT: I modified DeviceRegistry.h and made the function public. Here's the output: Device at slot 0 NOT registeredDevice at slot 1 registeredDevice at slot 2 NOT registeredDevice at slot 3 NOT registeredDevice at slot 4 NOT registeredDevice at slot 5 NOT registeredDevice at slot 6 NOT registeredDevice at slot 7 NOT registeredDevice at slot 8 NOT registeredDevice at slot 9 NOT registeredDevice at slot 10 NOT registeredDevice at slot 11 NOT registeredDevice at slot 12 registeredDevice at slot 13 NOT registeredDevice at slot 14 NOT registeredDevice at slot 15 NOT registered
  12. ruzzmon

    Working on DesignLab 1.0.3 release.

    Hi Alvie, I'm getting this error when I try to compile your for loop: error: `isRegistered' is not a member of `ZPUino::BaseDevice'
  13. ruzzmon

    Working on DesignLab 1.0.3 release.

    I've attached a screenshot of the circuit I'm using to test. This is Jack's example from earlier in this thread with one more DAC attached. I'm using a Pro and disconnected the flex pins. Thanks for the clarification about the flex pins, that makes sense. Slots are 12 and 13: Is there any workaround at this point to enable multiple DACs? Multiple (different) peripherals appear to work ok. I have SPI and VGA working. I have not tried multiple of the same peripheral other than DACs though. Perhaps the identification method has to do with this?
  14. ruzzmon

    Working on DesignLab 1.0.3 release.

    Hi Alvie, Not sure what 'correct' is supposed to look like, but adding your code and using both SigmaDelta and SigmaDelta1 with the begin(pin1, pin2) calls results in this: SigmaDelta0 at slot 12SigmaDelta1 at slot 255I then instantiated two new DACs like you showed (0xff) and this is the output I get: Sigmadelta at slots 12 and 255I made no changes to the circuit. Just for fun, I tried instantiating a 3rd DAC (without an equivalent in the circuit) and got the same output: Sigmadelta at slots 12 and 255 and 255There's also no difference if I use begin() or begin(pin1, pin2). Is there any way to force slot assignment? I thought that's what 0xff was doing but then that wouldn't make sense to assign them both to 0xff... a setSlot(slot num) function perhaps?
  15. ruzzmon

    Working on DesignLab 1.0.3 release.

    Thanks Alvie for getting to the bottom of this. Unfortunately, I've run into another problem with the DACs. I've modified Jack's example earlier in this thread to illustrate (see attached). When I have two DACs (or more), it seems only one set of pins are getting assigned. In other words, with 2 DACs I should have 4 channels output, but I only see two that are functioning, and the other two are held at some non-zero value (equivalent to 65535). I've attached the example to demonstrate this. You will see two DACs, hard-wired to WING_AL0 through WING_AL4 in the circuit. In the code, I've only initialized one SigmaDelta DAC with wing pins AL0, AL1. Using an oscilliscope, I see output only on WING_AL2 and WING_AL3, which was never initialized. The end result is only one DAC can be assigned and accessed at a time. And begin(left_channel_pin, right_channel_pin) appears to have no effect. Can you both take a look at this and let me know if I'm incorrectly initializing something or if there's a mistake with my circuit somewhere? Or perhaps there's another bug? Thanks SigmaDelta_DAC_twoDACs.zip