Go Down

Topic: Arduino video shield design requirements (Read 4969 times) previous topic - next topic



I am a great fan of Arduino...

I would like to design an arduino video shield. Is there some one who has designed so that I don't want to redesign it ?

If not please give me suggestion of designing the board. That means what should it mainly contain...

I have an idea in my mind that has to be included in the shield
1) NTSC Composite and S-Video using AD725
2) Small ADC circuit for AD725

I am planning to design it using free software circuit and pcb designer gEDA http://www.gpleda.org/

Jeffrey Antony



A video shield could be a popular item. However to be really Arduino useful and friendly it would nice to have a lots of on-board non-volatile memory so that screens could be preloaded and the Arduino application sketch would only have to update data fields or other low memory intensive items.


I also think it must offload most of the video work to an external chip (CPLD, FPGA or a more powerful MCU) and add SRAM for video memory.  Some sort of an Arduino friendly, low-cost Picaso chip.

Mark Bramwell

I hate to suggest another micro but have you guys checked out the propeller chip?

It is cheap and has video capabilities.  You could load up the VT100 emulator on the propeller and send it serial commands to display text.

I think real graphics will be tough because the little atmel doesn't have enough memory to fill a real graphics buffer.

It would make a really cheap video shield.


Thanks for the reply

My idea is to use the IC AD725 as implemented in http://belogic.com/uzebox/

Any way I will also try with http://avga.prometheus4.com/


I hate to suggest another micro but have you guys checked out the propeller chip?

We've had a couple of robotics teams look at it.  Based on their observations and reports, I think it's crap.  The thing doesn't even have a UART - everything has to be bit-banged.



I tried it when I built one YBOX2... the propeller chip can generate composite video, communicate using TCP/IP via Ethernet (you need an additional chip).  It seems a very capable chip for multimedia projects and it has 8 cores


Mar 18, 2009, 06:19 pm Last Edit: Mar 18, 2009, 07:06 pm by condemned Reason: 1
I've got a shield version of my TellyMate project currently on the drawing-board.

It does 38x25 characters over PAL/NTSC composite video.
It uses a subset of VT52 and H19 control codes.

Might that be useful?

[edit: added link + picture]


condemned, that looks awesome.  I look forward to the shield version.  Don't suppose there's any chance of compositing the output onto an incoming signal, right?  Or at least getting a vertical blank clock to help synchronize?


Overlaying the text onto an existing signal is beyond its capabilities, but there is a chance I could get some sync signals out... What sort of thing might be needed?

It should be simple to generate a suitable field/v-sync pulse onto a spare pin, and then out (via a jumper?) to maybe Digital pin 2 of the shield.
An H-Sync pulse might be a little more tricky, but I'd have a stab at getting it out if needed.

Would you need a true interlaced signal? The TellyMate uses a technique copied from early games consoles and 'home computers' - it outputs a single TV field over and over again (rather than pairs of odd and even fields) - I've got a page of notes on composite video timing that shows this trick.


condemned, for compositing, it's more of a need to get a sync signal INTO your board, and you base your frame or field timing on that signal.  I forget the vsync specifics now, but it's something like, on the falling edge of the input vsync, start drawing a field.  When you're done drawing a field, the vsync should be high again, so wait for the falling edge to start the next field.  It seems fine to draw two identical fields rather than interlacing... it's not a high-res device.


@halley: I was wondering how much use just sync output would have been!

I've since had a good look at what's needed for overlaying/compsiting, and it would need a sync separator (LM1881), some sort of analog switch (HCF4053 or similar) and a re-write of the code to sync to external V-sync and H-sync signals. I'm not yet clear on how I'd cleanly handle sync generation when there isn't an incoming video signal to overlay onto, but I believe it's all possible to do [even for a software guy like me].

Unfortunately, these changes wander significantly away from TellyMate's "very simple hardware" remit, so I'll put them onto the wish-list for TellyMate 2.

Other things on the wish-list for TellyMate 2 include colour output, but there don't seem to be any cheap RGB to composite chips around. MC1337's are hard to source now, and AD722-725's are expensive (certainly for the quantity I'd use). I was at least hoping for a chip that's cheaper than an AVR... I think I might have to settle for greyscale 'colours'.

As it stands, I should be getting some parts this weekend to put together a prototype TellyMate Shield. Hopefully I'll post some pictures next week...


OK, here's a picture of the TellyMate Shield prototype...

It's an offset stacking design - all the components sit well below the sockets.
I had to use a low-profile 3.5mm jack socket for the video output, as PCB mounted RCA/Phono connectors are just too tall.

Go Up