alvieboy Posted February 22, 2015 Report Share Posted February 22, 2015 Magnus: thanks a lot for the rationale.However: Since I had that "issue" with SigmaDelta, I attempted a simple PWM (which is also in ZPUino repo). And same thing happens.My understanding is that the "noise" is already in the source, but somehow it's shaped/dithered by most players/DAC, and this does not happen with our approach.Still, you are correct - I will redimension the SigmaDelta accordingly, but increasing freq. may require more expensive components on the LP filter. Not all caps can handle +200MHz, the ESR is too high. Same for inductors...Alvie Link to comment Share on other sites More sharing options...
alvieboy Posted February 22, 2015 Report Share Posted February 22, 2015 Magnus: thanks a lot for the rationale.However: Since I had that "issue" with SigmaDelta, I attempted a simple PWM (which is also in ZPUino repo). And same thing happens.My understanding is that the "noise" is already in the source, but somehow it's shaped/dithered by most players/DAC, and this does not happen with our approach.Still, you are correct - I will redimension the SigmaDelta accordingly, but increasing freq. may require more expensive components on the LP filter. Not all caps can handle +200MHz, the ESR is too high. Same for inductors...Alvie Link to comment Share on other sites More sharing options...
sn00zerman Posted February 24, 2015 Report Share Posted February 24, 2015 Just as a side-note to my question of the band-width of USB1.1 devices on a USB2.0 bus/hub, I can answer myself :-) You can connect as many USB1.1 devices that consume 12mBit per device, to fill up the total USB2.0 bandwith of 480mBit.When I connect one USB1.1 device and send a block of data to it, takes exactly the same amount of time as sending different blocks (with the same size) to different USB1.1 devicesin parallel. (multiple simultaneous threads in my dotNET application) So, I currently have 18 (only 15 connected in the movies in the article on my site http://www.digitalplayground.be/?p=2232 ) RGB panels, running a live-feed from my macbook Pro :-)(I can even output the videostream from my webcam to the large 160x96 RGB LED panel)Still 42 panels short to finish my project :-) (320x196 pixels) Link to comment Share on other sites More sharing options...
alvieboy Posted February 24, 2015 Report Share Posted February 24, 2015 I may be missing something here... you say "160x96" panel (a 5x3 matrix of 32x32 panels, hence 15 panels). How many teensy there ? Note that Papilio does not support USB. For that you need a bit more work. The USB on-board is an FTDI, which basically presents you a serial port. Regarding USB, that's not entirely correct. You can attempt to use full BW, but you won't be able to - USB is quite complex, and even with large bulk/isochronous transfers, you cannot simply divide it like that. As rule of thumb, assume ~75% bw will be available. Alvie Link to comment Share on other sites More sharing options...
sn00zerman Posted February 24, 2015 Report Share Posted February 24, 2015 3 Teensys :-) Still need to connect the 6th panel to every teensy, making it 192x96 pixels. (there was a problem with one panel, had to ask for a replacement)75% will be enough. When I do my calculation, in theory I could hookup 40 teensy, but I will only need 10 of them. (so, about 25% is enough) Hmm, sorry to hear that Papilio only does have FTDI (115K is definitely not enough "speed"). But I think I go with an ENCJ28J60 or something. Should be possible to get something workingover a network connection fast enough :-) Link to comment Share on other sites More sharing options...
ruzzmon Posted February 24, 2015 Report Share Posted February 24, 2015 Ok, here are the news for Sigma Delta. I switched back to the old approach, and I see now a full voltage swing from 0V to 3.3V. I'll syncronize with jack so we can do this in designlab too. 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? ThanksSigmaDelta_DAC_twoDACs.zip Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 Yes, looks like a "detection" issue. Can you do this please:Serial.print("SigmaDelta0 at slot "); Serial.println(SigmaDelta.getSlot());Serial.print("SigmaDelta1 at slot "); Serial.println(SigmaDelta1.getSlot());If any of these looks incorrect, try instantiating them by hand, like this:SigmaDelta_class MySigmaDelta0(0xff);SigmaDelta_class MySigmaDelta1(0xff);void setup(){ MySigmaDelta0.begin(); MySigmaDelta1.begin(); Serial.print("Sigmadelta at slots "); Serial.print(MySigmaDelta0.getSlot()); Serial.print(" and "); Serial.println(MySigmaDelta1.getSlot());}Looks like the library always maps both devices to 1st instance. It's a bug, but can be solved this way for now. Alvie Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 Kris, Hmm, sorry to hear that Papilio only does have FTDI (115K is definitely not enough "speed"). But I think I go with an ENCJ28J60 or something. Should be possible to get something workingover a network connection fast enough :-) It's an FTDI, not a real RS232 channel 3MBit/s works perfect, you can even get it up to 6Mbit or even more with an improved receiver. And this brings in another question. Magnus, Jack, you think it may be possible to use MPSSE mode on 1st channel, but not use the JTAG/BSCAN interface ? Link to comment Share on other sites More sharing options...
sn00zerman Posted February 25, 2015 Report Share Posted February 25, 2015 So, that's the 3 Mbit you where refering to, now I understand !3 MBit would not be enough, but 6 Mbit/sec would be enough to control 8 panels at 24-bit color / 25 fps.(even with 75% load on the USB)I'm learning every day :-) thanks,Kris Link to comment Share on other sites More sharing options...
mkarlsson Posted February 25, 2015 Report Share Posted February 25, 2015 Kris, It's an FTDI, not a real RS232 channel 3MBit/s works perfect, you can even get it up to 6Mbit or even more with an improved receiver. And this brings in another question. Magnus, Jack, you think it may be possible to use MPSSE mode on 1st channel, but not use the JTAG/BSCAN interface ? My guess is that you would need to instantiate an instance of the BSCAN_SPARTAN6 primitive and hook that up to your logic. Jack did that with the SUMP logic analyzer. BTW, the FT2232H used on DUO can do also do 8 Mbit/sec and 12 Mbit/sec in serial mode. Magnus. Link to comment Share on other sites More sharing options...
Jack Gassett Posted February 25, 2015 Author Report Share Posted February 25, 2015 With the FT2232H both channels are capable of using MPSSE mode and both channel A and B are fully setup for MPSSE communications. So we can bypass using channel A, which is connected to the JTAG pins of the FPGA and therefore more difficult to use, and just use channel B in MPSSE mode which is connected to straight FPGA pins. I'm not sure off the top of my head what speeds we can get with MPSSE on channel B but we should be able to do high speed SPI I would think... Jack. Link to comment Share on other sites More sharing options...
Jack Gassett Posted February 25, 2015 Author Report Share Posted February 25, 2015 Ok, excellent, I just looked it up in the datasheet and it looks like we can do up to 30Mbits/s with MPSSE mode, or like Magnus said, 12Mbits/s with serial uart: Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 I just realised you connected the other two pins with DUO (which can allow for full-duplex synchronous operation). Papilio Pro only connects tx/rx pins, correct? Link to comment Share on other sites More sharing options...
Jack Gassett Posted February 25, 2015 Author Report Share Posted February 25, 2015 I just realised you connected the other two pins with DUO (which can allow for full-duplex synchronous operation). Papilio Pro only connects tx/rx pins, correct? That's right. The Papilio Pro uses a ft2232D which doesn't have MPSSE on channel B so there was not much point in connected more then the rx/tx pins. But with the DUO we use the FT2232H so I fully connected the MPSSE pins on channel B and also added an extra pin, the DTR pin. BD0-BD4 are connected to FPGA: Link to comment Share on other sites More sharing options...
Jack Gassett Posted February 25, 2015 Author Report Share Posted February 25, 2015 It's not quite 480Mbits/s that the FT2232H can do if the full FIFO mode was connected, but 30Mbit/s is much better then the 3Mbits/s we could do with the Pro and One boards. Link to comment Share on other sites More sharing options...
ruzzmon Posted February 25, 2015 Report Share Posted February 25, 2015 Yes, looks like a "detection" issue. Can you do this please:Serial.print("SigmaDelta0 at slot "); Serial.println(SigmaDelta.getSlot());Serial.print("SigmaDelta1 at slot "); Serial.println(SigmaDelta1.getSlot());If any of these looks incorrect, try instantiating them by hand, like this:SigmaDelta_class MySigmaDelta0(0xff);SigmaDelta_class MySigmaDelta1(0xff);void setup(){ MySigmaDelta0.begin(); MySigmaDelta1.begin(); Serial.print("Sigmadelta at slots "); Serial.print(MySigmaDelta0.getSlot()); Serial.print(" and "); Serial.println(MySigmaDelta1.getSlot());}Looks like the library always maps both devices to 1st instance. It's a bug, but can be solved this way for now. Alvie 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? Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 ruzzmon: looks like it's only detecting one SigmaDelta instance.Regarding "begin(pin1, pin2)", this would only work with flexpins, and not with direct connections. In which slots do you have your SigmaDelta ? Can you run the sysinfo sketch, so it can report what is where ? (not sure Jack published it though). Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 Jack: 30Mbit/s is just excellent. Hardest part will be to integrate MPSSE in the application itself. No big deal with HDL. Link to comment Share on other sites More sharing options...
ruzzmon Posted February 25, 2015 Report Share Posted February 25, 2015 ruzzmon: looks like it's only detecting one SigmaDelta instance.Regarding "begin(pin1, pin2)", this would only work with flexpins, and not with direct connections. In which slots do you have your SigmaDelta ? Can you run the sysinfo sketch, so it can report what is where ? (not sure Jack published it though). 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? Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 Dual serial works, and they share the same codebase. May be a bug somewhere, it's true. Can I send you a debugging version of some of the core cpp files, so we can see what might be going on? One of two things may be happening, as you can see from the following code (it assumes the 0xff/256 I asked you to do). So, either there's no device there (but looks like you have it, from you schematic), or it was already "claimed" by another driver. I think Jack had some trouble with the device registry earlier.... we may need to debug that. int BaseDevice::deviceBegin(uint8_t vendor, uint8_t product) { uint8_t slot; if (m_slot==0xff) { slot = DeviceRegistry::scanDevice(vendor,product,m_instance); if (slot==NO_DEVICE) { /* Uuups */ m_slot=0xff; return -1; } } else { slot=m_slot; } if (DeviceRegistry::registerDevice(slot)<0) { m_slot=0xff; return -1; }}Please try this code too, in addition to your code, just after starting all SigmaDelta:int z;for (z=0;z<16;z++) { Serial.print("Device at slot "); Serial.print(z); Serial.println(BaseDevice::isRegistered(z)?" registered":" NOT registered");}Alvie Link to comment Share on other sites More sharing options...
ruzzmon Posted February 25, 2015 Report Share Posted February 25, 2015 Hi Alvie, I'm getting this error when I try to compile your for loop:error: `isRegistered' is not a member of `ZPUino::BaseDevice' Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 Sorry, my bad. Please use this instead:DeviceRegistry::isRegistered(z)I'm writing this from top of my head. Alvie Link to comment Share on other sites More sharing options...
ruzzmon Posted February 25, 2015 Report Share Posted February 25, 2015 Sorry, my bad. Please use this instead:DeviceRegistry::isRegistered(z)I'm writing this from top of my head. Alvie 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 Link to comment Share on other sites More sharing options...
ruzzmon Posted February 25, 2015 Report Share Posted February 25, 2015 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 Link to comment Share on other sites More sharing options...
alvieboy Posted February 25, 2015 Report Share Posted February 25, 2015 Note: registered does not mean there's a device there: just means a "driver" acquired the device for its usage. Can you email me at alvieboy at alvie dot com, so I can send you the systeminfo sketch, which displays what's in the wishbone slots proper ? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.