Jack Gassett

Working on DesignLab 1.0.3 release.

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 devices

in 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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 working
over a network connection fast enough :-)

 

 
 

Share this post


Link to post
Share on other sites

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?

 

Thanks

SigmaDelta_DAC_twoDACs.zip

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 working
over 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 ?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

 

post-29509-0-45914800-1424887261_thumb.p

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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:

duousb-schematic.png

 

duofpga_schematic.png

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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 255

I then instantiated two new DACs like you showed (0xff) and this is the output I get:

Sigmadelta at slots 12 and 255

I 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 255

There'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?

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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:

 

post-38473-0-23271000-1424889694.png

 

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 protected

EDIT: 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

Share this post


Link to post
Share on other sites

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 registered

And here's the circuit:

post-38473-0-24179200-1424895317_thumb.p

 

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

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now