Arduino Due and AD725 How-to?

I think you are flogging a dead horse here - the Arduino is nothing like powerful enough to generate video and run a gui - there's a thread here on this topic and the consensus is VERY discouraging.

Color SVideo. Like the AD725 chip except in software? - Arduino Forum

If you want video and a gui you need to start off with a more powerful processor - or offload the task - FTDI make a nice video controller chip which you could use with an Arduino - and they also sell kits with an LCD display included. The FTDI chip is an LCD controller - it doesn't do composite video.

If you explained what you are trying to achieve overall it might be possible to be more helpful.

MK

The Due runs at 84Mhz, which is much faster than the overclocked ATMega used in uzebox, so clearly it is quite possible to achieve.

I have a device that outputs svideo and composite. I will switch the video signals to the GUI and configure the device with it before switching back. An LCD is not an option, it must be both svideo and composite. I was thinking I could just use bitmaps and basically make a photo viewer that uses provided file names.

I don't mind offloading if I can find a device that offers what I need. I even looked into using an actual photo viewer that outputs the signals I need, but none of them allowed me to provide the file name. They are all simple next-previous type.

I chose the AD725 since it is already being successfully used with an Atmel (uzebox).

It may be a lot harder than you think - this kind of precisely timed coding gets more difficult with a complex processor. I haven't looked at the ARM processor in the Due in enough detail to say that it's impossible to replicate the Uzebox but you do need to check the rate at which pins can be toggled.

However, when you said you wanted a GUI I thought you meant somewhat better video than the Uzebox manages.

I don't think I quite understand yet exactly what you are trying to do - is the plan that the Arduino just provides a GUI and the photo bit maps are done by something else or is the Arduino to do it all ? What resolution and number of colours are you looking for.

MK

Thanks, Michael.

The GUI does not at all need to be fancy. I'm not even expecting motion at this point. I didn't want to go with the TVout lib because I desire color and it doesn't provide svideo. The resolution doesn't even need to be great, but if my math is correct, the Due could easily reach full SD resolution - 480i - with 256 colors. This resolution is a little over half of what the Due should be able to provide, which came to a resolution of roughly 800 pixels wide. So, assuming all of this, I assume the toggle speed should be fine. I don't have an oscilloscope to be sure.

The plan is to use the Due to read a bitmap from an sd card and then generate the proper signals used by the AD725. I don't know anything about how to even get started with providing the proper signals using the Due.

are you planning on trying to output / generate the composite color or RGB. RGB of course would be way easier than comp.

Using timers directly to output pins to generate the basic sync HS and VS may also help with a stable display. I also think the ARM has DMA capability, the TI ARM (TIVA C) boards do so this also can off load the CPU from dealing with most of the output work

Thanks, Peter.

The Due does have a DMA controller.

Yes, RGB and the sync signals. How-to?

It was also my understanding that I would be able to have sync signals coming off the Due since it runs fast enough, and this would help provide a more stable picture. How would I generate such a signal? I am still an electronics and duino noob with only a 1.5 years worth of experience, but I take myself where my projects take me and that's how I learn. Unfortunately for me, a lot of this stuff is difficult to research online, with only hints of where to go or what to do. I am a long established programmer, so I have that going for me. I am looking for commented example code or explanation of what I need to do, and glue schematics or wiring guide. That seems to me like a lot for me to ask for, but I don't have any resource to learn this. If you know of any, that is helpful also. If I can get going toward a couple pixels and I can puzzle the rest.

The Atmel ARM processor in the Due does have DMA but as far as I can tell it can't DMA from memory to a GPIO port so it won't help make video signals.

To work out if the processor is fast enough you need to do some experiments and you will need to to do a LOT of work. I don't think you are going to find the kind of examples you want on the web.

On the Uzebox wiki is an explanation document that I expect you have seen but if not its at:

Main Page - Uzebox

"How it works (PDF"

The actual code, like most open source code, is not very well documented and so is very difficult to understand - if it were my project I wouldn't bother attempting a "port" because the ARM processor is so different from the AVR. The How it works doc tells you pretty much how to do it.

You will need an oscilloscope (well it will make things a lot easier) to get it working.

You could start by connecting the resistor network to an IO port on the Due (pick output pins 0-7 if possible) connecting up the converter chip and start writing code snippets. The easiest way to do the hardware would be to take the processor out of a Uzebox board and hook up to that (watch out for 3.3V to 5V issues).

MK

maybe worth looking at the Arm Cortex in the TI Connected Launch pad then (Tiva C Connected Launchpad) Its DMA can interface from ACD to memory IO to mem etc, a very flexible system and no more expensive

Hello Peter, it's no use going to memory - you need to be able to DMA from memory to GPIO. I'm familiar with the STM32F range from ST but I'm not sure that they can do it - certainly no intended way to do so but you might be able to fool it by setting up memory to memory DMA where the destination is a GPIO port. It's this sort of thing which makes me suggest that Kizin needs to start actually playing with the chip - after all I don't think any of them were actually designed with the idea of direct video generation in mind so in all cases he'll be pushing at the limits of the chip.

@kizin - I don't suppose there is any point in me suggesting an FPGA ?

MK