Stimmer,
I downloaded the library, but running into issues when also using the SDFat library to read my graphics off the SD Card. Any thoughts why these libraries conflict? Is there any potential for making them able to work together? It was possible previously with the PWM version.
I'd really like to use the VGA library because it's so convienient, but reading the graphics data off the SD card is absolutely needed (ie: I can't load the bitmap into the VGA library framebuffer without the SDFat library being initialized at the same time). I was hoping to take advantage of the speed increases you mentioned before, as well as the image stabilization using the additional timer.
If it worked before I'd say there's a good chance that it will work again. I'll take a look at it later today.
Could you tell me a few things: which VGA screen mode are you using (mono, colour, PAL or NTSC), and which exact version of the SDFat library are you using and how is it wired up?
Thanks - could you please try the following as a temporary workaround.
In the SdFat library, in file Sd2Card.cpp on line 85:
change "#define USE_SAM3X_DMAC 1" to "#define USE_SAM3X_DMAC 0"
Tell me if it works, and if it does work is the SdFat library now too slow or at an acceptable speed?
It looks like there is a DMA clash between the VGA and SdFat libraries. It should be possible to sort it out properly somehow - there should be a way to use DMA for both at the same time.
Thanks for letting me know. I think I have found out what the actual problem is (basically in DMA mode SdFat gets SPI overruns if anything else is using DMA at the same time) but I'll bring it up in the SdFat thread where fat16lib is more likely to see it.
OK, after a lot of testing and debugging it turns out that using the #define USE_SAM3X_DMAC 0 workaround posted above is the fastest and best solution I can find to the problem of running DueVGA and SdFat together.
No, even at SPI_SIXTEENTH_SPEED they still wouldn't work together in DMA mode.
I'm happy with the speed in non-DMA mode. It's fast enough for uncompressed full-screen animation at about 15fps. The code just loads each frame directly into the colour buffer:
#include <VGA.h>
#include <SdFat.h>
const int chipSelect = SS; // you may need to change this to the pin you connected SS to
SdFat sd;
SdFile file;
void setup() {
VGA.begin(320,240,VGA_COLOUR);
sd.begin(chipSelect, SPI_FULL_SPEED);
file.open("anim.dat", O_READ);
}
void loop() {
file.rewind();
while(file.available()){
file.read(VGA.cb,320*240);
}
}
I've attached a video of the output (though being a highly compressed shaky video of a shaky video it doesn't look as good as it does in real life!)
I've made a new release of the library. Get it here: DueVGA-0.512.zip This release fixes a few bugs and clashes between DueVGA and the Serial and Audio libraries.
It also includes three longer demos - the GPS demo and the Animation demos have been posted above already, the other one is a demo of a waterfall plot. This takes an audio signal as inout, samples it and performs a FFT, and shows the result on a scrolling display. See the video and screenshot below for an example of what it does.
What about UNO board support? It makes sense to have light version of lib...
DueVGA is too dependent on hardware features only available in the SAM3X chip in the Due (particularly DMA) so it would be impossible to port it to the Uno.
Not to mention going from 96k of ram to 2k..
Great work on this library. I've been looking for something cool to do with my Due, now I may have found it.
I have been working on drawing bitmapped graphics with this library using a couple of techniques:
8-bit, 256 colour PNG images converted to unsigned char arrays of pixels
I have written a utility in Ruby that I'm finalising, which will convert 8-bit PNGs for display using Due VGA. It references a colour-palette PNG image that contains all the displayable colours on the Due, re-ordered so that they are correctly converted to their binary value.
I have written a utility which, when given a 16-colour index palette, will produce an image at half the storage size. You will only have access to 15 actual colours, as index 0 is reserved for transparency.
I have also produce an 8-bit palette which can be used with Adobe products (and possibly others) for compressing images for optimal display, see Tools/8bit-truecolor-palette.act
And, finally, a couple of photos to show what you can achieve with these tools:
Hi,
I'd like to know what is the real reason to use the MOSI pin (A26).
Isn't it possible to use another pin, allowing to obtain a simpler connector ?
Thanks in advance for the reply,
gadgetoid: Wow, impressive work! Thanks for the HSV code, I may well add it to the library because it would simplify my fractal demos (which use an ugly look up table at the moment)
fog44: Monochrome mode uses the SPI hardware to generate pixels. Therefore the output has to be on the MOSI pin. I am experimenting if it is possible to use the SSC hardware (in which case output would be on port A.16 / Arduino pin A0) but I don't know if it will work yet.
Stimmer,
Is there a similar library for VGA input? I want to convert a VGA signal from my computer to a composite RCA output to a TV.
I figure the problem with this is the processor speed and not being able to both read the incoming signal and generate the outgoing signal quickly enough. Is that the limiting factor here?
I suppose I could write a PC application that would capture the screen and send it over serial to the Arduino and fill the frame buffer, and then simply have the Arduino generate the composite video signal. That may be doable, as long as I can cram that much video data over serial quickly enough to get it to appear to be video instead of stop-motion.
At 320x240 at 8-bit color, that'd be 76800 bytes of data for the frame buffer, at a baud rate of 115200 (bits per second) or 14400 Bytes/sec. By my calculation, it'd take 5.3 seconds to transfer one frame, which is far too slow.
I do have a wifi shield. I wonder if I can get better throughput using that. It looks like the wifi benchmarks are pretty good for throughput (can range from 0.7 Mbps to 3.4 Mbps reasonably). Although, that won't overcome the memory constraint.
From what I understand, the 480i (interlaced) TV format is equivalent to 640x480 resolution. Does the fact that the TV format is interlaced mean that that the frame is actually half the size (half-line or every-other line)? Or will I have to downsample my video to fit the memory of the microcontroller?
You're right about the limiting factor of processing and I/O speed. Also, grabbing a VGA signal would need 3 A/D converters running at 12.5Msps each just for 320x240
In composite mode there still isn't much processing capacity left for input. The closest thing to what you are doing that I have tried is the SD card animation demo, which loads uncompressed animations from an SD card straight into the framebuffer ram. In VGA mode the frame rate is acceptable but in composite mode it slows to a few frames per second (I can't remember exactly how slow it was, but it was unwatchable)
I created a shield to utilize this awesome library you made. I need to order a few more components before I can be sure I got it right, but I suspect it will work fine. I used jumpers to isolate the composite video resistors from the VGA resistors, and I went ahead and tossed in an LM386 amplifier hooked to the DAC0 and DAC1 pins with an audio out jack (may have accidentally selected the very small size audio jack, oops). Oh, and VGA has i2c data, I went ahead and broke out those pins. I left out support for monochrome mode, it just made things more manageable in the PCB layout.
I made a whole bunch of the boards, so once I confirm they actually work, I'll have them up on my Tindie store as DIY kits..
