Working on DesignLab 1.0.3 release.


Jack Gassett

Recommended Posts

  • Replies 104
  • Created
  • Last Reply

Kris,

 

Alvie just checked in the new code and I got it working last night. The new VGA adapter lets you change resolutions on the fly from 640x480 - 1280x768, depending on how much memory you have. The Papilio DUO 2MB has enough memory for 1024x768 so all the people who ordered 2MB finally have a good justification for the more memory. :)

 

I tested everything last night and it works, I have to finish up a Powerpoint presentation for this weekend which has been sucking up my time. But I hope to have another beta release by Friday...

 

BTW, I figured out what was wrong with the VGA_640_480 in the previous release, but have not looked at ZXSpectrum yet. That one I think might be a clock issue that we might have to rethink, it might have just worked on my monitor which is pretty forgiving... The VGA_640_480 issue is a moot point since it is replaced by the new VGA_ZPUino adapter.

 

Jack.

Link to comment
Share on other sites

Hi Jack - I'm back again with another question on the SigmaDelta and hopefully not a silly question this time:  What I see using your example which steps through full swing (65535), middle, and zero results in measured max = 2.5V, middle = 1.65V, and zero = 850mV through an RC filter.

 

I've tested some old code I had that still works at the expected voltage - I set it to 700mV and it goes to very close 700mV with a slight offset. Zero is zero V which is exactly what I expect. Have you been able to measure the voltage on your DAC example? Can you confirm you are getting the expected (full-range of 3.3V and zero is in fact zero volts?)

 

Thanks!

Link to comment
Share on other sites

The new SigmaDelta library allows for different format of datatypes. Plus, it has two channels so you should set both values using the 2-parameter interface.

 

From top of my head:

include "SigmaDelta.h"void setup(){  //SigmaDelta    SigmaDelta.begin(WING_AL4, WING_AL5);  SigmaDelta.setEndianness(BIG_ENDIAN);  SigmaDelta.setSignedness(false);}void loop(){  //SigmaDelta  SigmaDelta.setValues(65535, 65535);}
Link to comment
Share on other sites

Hi Alvie,

 

Thanks for your input. Looking at the SigmaDelta library code, setEndianness(BIG_ENDIAN) would clear bit SDLE and setSignedness(false) would clear bit 5 of Register 0. I had assumed that the registers startup in the zero state but I did try your additional code and unfortunately nothing changes, I still get the same results.

 

Is it possible that there's some sort of bit shift going on? Or maybe not all the bits are getting set correctly? I'm thinking bit 16 corresponds to bit 17 for example. What's strange is both channels exhibit the same exact behavior.

 

Anyhow, the DAC is not going to zero when set to zero. I don't think that is normal. It is reading equivalent to 16383 (assuming 3.3V full scale) which I don't think corresponds to an MSB or signdedness issue.

 

Thanks!

Link to comment
Share on other sites

Ok. Let me try to understand....

 

The current DAC is implemented on top of OpenCores library, which is 16-bit signed, so it goes from -32768 to 32767. Applying zero would cause a square wave to be output, at maximum frequency, and hence read 1/2 VCC after low-pass filter.

 

Do you have a scope ? Can I give you a sketch that generates a waveform which we can use to see what is going on.

Link to comment
Share on other sites

Some more news regarding VGA: We are now able to load PNG and JPEG files :) Code overhead is about 100KB for PNG, and 90KB for JPEG. Images can load from SD card or from any other medium (smallfs, so on). They're awfully slow to load, so don't expect anything real-time (a 640x480 JPEG takes a few seconds to load and decode).

 

Maybe Jack can post some pics.

Link to comment
Share on other sites

Thanks Alvie, yes I have scoped the output after filtering. I've attached a photo of the example Jack posted earlier. The DAC output is referenced to ground. post-38473-0-32127900-1424455064_thumb.p

 

I understand what you're saying about signed values. However, setting Signedness to false should allow me to set full-scale to 3.3V no? That doesn't seem to work. I am quite sure I had this working exactly as I described before with the version where we typed in the wishbone connections directly into the zpuino hdl file (not the schematic/symbol library versions). Hope that makes sense.

 

Thanks. I will test this out further.

 

 

 

Link to comment
Share on other sites

Thanks Alvie, yes I have scoped the output after filtering. I've attached a photo of the example Jack posted earlier. The DAC output is referenced to ground. attachicon.gifoscilliscope.png

 

I understand what you're saying about signed values. However, setting Signedness to false should allow me to set full-scale to 3.3V no? That doesn't seem to work. I am quite sure I had this working exactly as I described before with the version where we typed in the wishbone connections directly into the zpuino hdl file (not the schematic/symbol library versions). Hope that makes sense.

 

Thanks. I will test this out further.

 

Alvie and I looked at this all morning and we are seeing the same thing. Alvie is going to put the DAC in the simulator over the weekend to see what is happening, something is off.

 

Jack.

Link to comment
Share on other sites

I just uploaded DesignLab 1.0.3 Beta 2.

http://forum.gadgetfactory.net/index.php?/files/file/234-designlab-beta/

 

It includes Alvie's new VGA controller that can change modes up to 1024x768 - there are still a couple glitches at the higher resolutions. Right now there is examples for the Papilio Pro with Arcade MegaWing and Papilio DUO 2MB with Computing Shield. 

 

The VGA example can be found under File/Examples/ZPUino_GFX/gfxdemo

 

This beta also has:

 

  • Detects if your schematic is updated but no bit file generated.
  • Automatically comments out #define circuit statement when saving a library to a project.
  • Better handling of #define circuit statements
  • We merged to Arduino 1.5.8 code.
  • Board labels show up next to serial ports.
  • SD card library should be working better now.

Jack.

Link to comment
Share on other sites

Back when I was doing audio with SigmaDelta, I had a lot of noise - sigmadelta looked like a logarithmic amplifier (quiet parts of music exhibit a lot of noise), and I decided to try out OpenCores library. Truth is, I never saw any difference in quality (noise was still there), but I kept it anyway - note that for audio, you need AC, not DC; so I never actually checked out if the voltages (absolute) were correct.

 

It now looks like they are not.

 

I'll try switching back to old, 1-stage SigmaDelta, and simulating the design again. The main difference is that opencores uses signed, and we use unsigned. A bug may lie somewhere in the signed<->unsigned conversion...

 

I'll keep you posted.

Link to comment
Share on other sites

This should get you a triangle wave swinging from 0V to 3.3V (or around it). But does not with the current implementation:

#include "SigmaDelta.h"#include "Timer.h"static int32_t rv = 0;static int32_t delta=1024;bool update(void*data){    SigmaDelta.setValues(rv,rv);    rv+=delta;    if (rv>=32767 || rv<=-32768)        delta=-delta;    if (rv>=32767)        rv=32767;    if (rv<=-32768)        rv=-32768;    return true;}void setup(){    Serial.begin(115200);    SigmaDelta.begin(WING_C_0, WING_C_1);    SigmaDelta.setEndianness(BIG_ENDIAN);    SigmaDelta.setSignedness(1);    Timers.begin();    Timers.periodicHz( 80000, &update, NULL);}void loop(){}

I'll use this for testing.

Link to comment
Share on other sites

Back when I was doing audio with SigmaDelta, I had a lot of noise - sigmadelta looked like a logarithmic amplifier (quiet parts of music exhibit a lot of noise), and I decided to try out OpenCores library. Truth is, I never saw any difference in quality (noise was still there), but I kept it anyway - note that for audio, you need AC, not DC; so I never actually checked out if the voltages (absolute) were correct.

 

It now looks like they are not.

 

I'll try switching back to old, 1-stage SigmaDelta, and simulating the design again. The main difference is that opencores uses signed, and we use unsigned. A bug may lie somewhere in the signed<->unsigned conversion...

 

I'll keep you posted.

 

I have not looked at your code but a properly designed SigmaDelta DAC with a proper filter should hardly have any noise at all if clocked at a reasonably high frequency (~100 MHz).  However, if I recall correctly the original Arcade Megawing had the filter components the wrong way around so there was no filter at all, but hopefully Jack has fixed that in later versions.

 

When I did the waveplayer demo for Pipistrello I could not really hear any difference between the wave-format version of a song played on Pipistrello vs. playing a mp3 version of the song on a mp3 player.  See http://forum.gadgetfactory.net/index.php?/topic/1775-wave-file-player-using-sigma-delta-dac/

 

Here is the 11-line code for the dac used in that project (verilog):

 

module dac(clock, DACin, DACout);

input clock;

input [11:0] DACin;

output DACout;

  reg [12:0] accumulator;

  always @(posedge clock)

    accumulator <= accumulator[11:0] + DACin;

  assign DACout = accumulator[12];

endmodule

 

 

As for signed-to-unsigned conversion, that's just xor 0x8000.

 

Magnus

Link to comment
Share on other sites

A big "THANK YOU" to Alvie & Jack for their continued efforts they put in this !

I got the VGA sample "up and running" (jippie), so I can now start designing an interface to control my large LED RGB LED matrix.

(which is already grown to 160x96 pixels (I got 24bit colors instead of 16bit, 24 fps, 120 Hz refresh for the moment), and will continue "growing" till I have 320x192 pixels)

Time to buy a few more Papilio boards :-)

 

best regards from Belgium,

Kris

Link to comment
Share on other sites

Hi Alvie :-)

I'm also using panels with HUB75 interface. 32x32 pixels per panel. I now have 18 of these panels, but I'm only using 15 of them, in a 5x3 configuration. (so 160x96 pixels)

Next month is my birthday, my wife is going to order another 18 of these panels. After that, I will buy another 6 panels each month, until I have 60 of them.

(ooh well, this will be the "eye-catcher" at our next Christmas event, so I still have some time left :-)

 

I'm playing my animations from SD cards. (yup, multiple cards, because I can't get the read-speed above 2 Mbyte/sec, it's just a proof of concept, maybe I will interface with a SATA or IDE drive later on)

Currently also using a Teensy 3.1+ for every 6 panels. I hope to soon port the whole thing over to Papilio, maybe I can do more panels with one Papilio ?
I assume the RGB LED panel wing for the Papilio, is designed for these HUB75 panels ?
Today I connected the whole thing to my macbook, currently writing some stuff to get the videostream of my internal webcam onto the LED matrix :-)

Ooh well, any capture device would work, so a video2usb device would give me the possibility to watch live TV on this matrix, maybe I switch this "processing-thingy" to a RaspBerry Pi, or I start using my Atlys FPGA board :-)

Link to comment
Share on other sites

 

Currently also using a Teensy 3.1+ for every 6 panels

 

I'm using a Papilio for every 16 panels, but decreased color (21-bit), including CIE color correction and per-panel color correction too, all with a linear framebuffer. But this design is not open-source, I need to monetize my investment first (although panels are cheap in China (I have quotes around $12/panel), they are quite expensive in Europe.

 

And yes, the wing is for HUB75. The controller I have (the open-source one) can drive 3x2 with only 2 channels, and 24-bit color. Note however, that due to CIE luma correction, you get less than that.

 

For video streaming (I done it in the past), just do some calculations. We can get 3MBit/s through the serial port, eventually mode with some MPSSE mode (like SPI).

 

Alvie

Link to comment
Share on other sites

3mbit trough serial port ? Thats weird, where is that comming from ? That will only give about 21 fps for 6 panels.

USB1.1 is 12mbit (teensy can do 12mbit) en USB2.0 is 480 mbit. (USB1.0 is only 1.5mbit)

One question that I still need to investigate, if you connect multiple 1.1 devices to a 2.0 host,

Would the total speed of all connected devices be 12 mbit, or could i use the 480 mbit divided over 40 1.1 devices ?

Maybe i should read a bit more about usb protocols and standards ...

Link to comment
Share on other sites

Just curious, since you mentioned noise before, how many bits to you have in the DAC?

 

It might not be obvious but the frequency components generated by the DAC depends on the clocking frequency and the number of bits in the DAC.  The most-significant bit will generate f/2, the next bit f/4 etc.  If you want to play audio then the lowest frequency component should be above 20 kHz so you can't have too many bits in the DAC unless you clock it at very high clock rate. 

 

In the waveplayer case I mentioned before I used a 12-bit DAC and 120 MHz DAC clock which means that the lowest frequency component is 120 MHz/4096 or about 30 KHz, and above the low-pass filter cut-off frequency.  (if you feed the 12-bit DAC the value 0x001 then it will generate carry once every 4096 clocks, i.e. about 30 kHz).

 

It's tempting to put in a 16-bit DAC but with a 120 MHz clock that would generate frequency components in the audio range (down to 1800 Hz) and since the low-pass filter has the cut off much higher this will pass right through as noise.

 

Magnus

Link to comment
Share on other sites

Magnus, I will send you a wave file offline so you can hear it.

 

Regarding SD: we are clocking it at 96MHz, with 16-bit. Noise shows up when the input signal ls low, and artifacts are perfectly heard. Note that I have improved the Low-Pass filter, with a RLC, but you can still hear artifacts. The use-case is actually not MP3, but a raw WAV file converted from a lossless source (FLAC). I have more than one use case actually.

 

Not all "musics" exhibit this behaviour.

 

My first suspiction was aliasing: it's not easy to filter such high frequencies. Adding a 10uH series inductor helped a lot, but did not elimitate the issue. Note that I am feeding the output directly to headphones, so current is higher, but I experienced same issue with an amplifier with high impedance. Perhaps lower-ESR caps would help too, but I don't have time to test right now.

Link to comment
Share on other sites

The DAC clock rate, the number of bits in the DAC and the low-pass filter all have to be designed together.

 

A 16-bit DAC clocked at 96 MHz will generate frequencies down to 1500 Hz so you need a low-pass filter with a cut-off at about 1 KHz to filter out that.  But that will not work for audio....

 

Magnus

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.