What's the best video output for 8 bit AVR micros

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the best peripheral for displaying things on a display/TV for a AVR micro. VGA, Component video or composite video. Please explain why too. 

This topic has a solution.
Last Edited: Wed. Dec 26, 2018 - 01:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look at this long thread https://www.avrfreaks.net/forum/...

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also Google "lucid science avr video" then read and enjoy.

 

EDIT as it's Christmas I googled it for you... http://www.lucidscience.com/pro-...

Last Edited: Tue. Dec 25, 2018 - 05:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

microcapacitor wrote:

What is the best peripheral for displaying things on a display/TV for a AVR micro. VGA, Component video or composite video. Please explain why too. 

 

Depends on the 'things' you want to display, and how important the number of pins used are to you, and if you need colour.

Composite video can be done in the least-pins, and is suited to smallest displays.

Component Video avoids needing the carrier modulation of Composite (if you need colour), at the cost of more pins and fading availability.

VGA is more suited to larger displays and I think most? monitors can sync on green, if you need to reduce pins.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are talking "Peripheral" as being external hardware then the first thing that comes to mind is the VS23S010

 

http://www.vlsi.fi/fileadmin/dat...

 

If you are looking for a software/bit-banged solution then as pointed out earlier AtomicZombie/Brad has both VGA and NTSC solutions.

 

CNLohr has an NTSC solution than creates the colour burst with no external hardware.

 

https://www.youtube.com/watch?v=...

 

Or the Uzebox has the most user friendly to get into and arguably the most impressive NTSC video output software but requires an external colour encoder if you want composite rather than SCART/RGB

 

http://belogic.com/uzebox/index.asp

 

Myself and others are still getting the Uzebox to push the envelope of what video output on an AVR can be :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the best peripheral

The USART in SPI mode, because you can output multiple bytes serially without a gap between them.

Alternately, a Raspberry Pi Zero, because it's cheap and drives modern (HDMI) displays at high res...

 

(these are meant to be slightly un-useful answers to an overly vague question...)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It really depends on what you want to do with this video.

 

First, you need to be aware that direct video generation takes a LOT  of "horse-power". If you manage to do it on an AVR, it is left with very little time to do anything else. So, if you want to load a fixed image or something with minimal detail (think "pong" game, maybe?), you can pull it off, as AtomicZombie has demonstrated.

 

So, that first big question: What do you want to display?

 

1. Fixed or minimal moving image? OR

 

2. Something more like a "terminal"? OR

 

3. Full image display? OR

 

4. Complex (and changeable) graphics?

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I don't agree with

 

ka7ehk wrote:
something with minimal detail (think "pong" game, maybe?)

 

This is done on an ATMega644.

 

https://youtu.be/UnpNuFsHPSs?t=76

 

It is running overclocked at 28Mhz for NTSC colour reasons, but even at 20Mhz it would have plenty of horses for doing video and complex gameplay or moving images.

 

The blue lines are relying on external flash memory, but the yellow, green and red pixels are all inside the 4K of RAM on the Mega644 and everything is calculated in the HSync/VSync time.

 

The only other chip apart from the AVR is an NTSC colour encoder to go from component to composite for a standard TV.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My point is/was that there is a lot more to it than just the video output port.

 

If you need to display a dynamic image that originates from outside the MCU, then you also have to deal the flow of the data to be displayed. If it is to emulate a terminal, for example, that is different ball game than displaying an mp4. And a terminal, with fairly low level data flow, is, itself, a different ball game than something like pong where (almost) everything is generated inside but is constantly changing. And, that, in turn, is a different ball game than a single static image.

 

It is also not clear if the OP is asking for an encoder of some sort or if the OP wants to generate raw video at the MCU  port pins.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes - OP was very light on detail.   Maybe even a troll.  Still quite a few of us have posted links to things that may be useful to OP.

 

With the link to the T2K video I was pointing out that there a still QUITE A FEW HORSES left after bit banging out the video.

 

In fact enough horses to decode a 256x224 2 BPP image map, overlay a 1BPP image read from SD card, take user input, play some music (including sampled speech) do the usual game play things like movement and collision detection, throw in some trivial NPC AI as well as rotate, scale and draw up to 60 sprites on screen. 

 

That is a fair bit more than what you need for pong.  Pong is something people aspired to do on a PIC 16C84 quarter a century ago.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Here you can see 3D real-time graphics, polyphonic(??) synth music & video generation, all directly simultaneously generated from a mega88 with 1K of ram.

 

https://www.youtube.com/watch?v=sNCqrylNY-0

 

What is the best peripheral for displaying things on a display

I'm sure it would be easy to include the word "things" on the display in the demo video.

When in the dark remember-the future looks brighter than ever.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

Here you can see 3D real-time graphics, polyphonic(??) synth music & video generation, all directly simultaneously generated from a mega88 with 1K of ram.

 

Well - its a bit over 10 years since lft did his 3D thing shown above and things have moved on a bit.

 

I just released a demo of my latest video mode on the Mega644.  The chip has 4K of RAM but I am using slightly less than 512 bytes for this 3D spinny Cobra MKIII.

 

Here is a browser runnable emulator of the Uzebox with the new 3D spinny demo thing

 

https://nicksen782.net/UAM5/emu....

 

You can select most of the other Uzebox games apart from Tornado2000 which sadly the broswer emulator can't handle.

 

The NTSC resolution on the 3D polygon demo is the same 256x224 as T2K so is 5 clocks per pixel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andrewm1973 wrote:
3D polygon demo
I don't see that one listed under DB.  Or are you referring to RLE_Demo.uze?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah - Sorry - the file name is RLE_Demo.uze.  It is a demo of the RLE video mode I made.

 

The pixels being rendered to the screen are run length encoded into a 256 byte circular buffer.  There is another 2 kilobytes reserved for two linked lists that share a common memory pool.  In that 3D spinning Cobra MKIII less than 256 bytes of the link list are used.

 

A normal Uzebox "video mode" takes control of the AVR CPU from TV line 12 till TV line 237.  The "User code" gets to run between H_Syncs on the remaining 27 video lines (V_Blank).  That gives about 40K CPU clocks to do any "User Mode" stuff like control game logic or draw things to screen in a normal video mode.  If you take into account things like 1 clock per instruction, 2 clock multiply and 32 registers, the Uzebox has about much User Mode CPU left as a 1.5Mhz 6502 did on the Commodore 64.

 

This RLE Video mode is somewhat different to a normal mode.  No "Drawing to screen" has to be done by user code.  It just has to fill a linked list with lines.  The video code then starts at TV line 26 to pre fill the 256 byte RLE buffer from that linked list.  Then starting at line 27 it writes from the RLE buffer to screen.

 

If the Run Length of pixels it has to display is 9 or less the RLE decoder just sits there reading RAM, decoding and writing pixels to the screen (OUT PORTC).  If a run length of >9 pixels happens then there is enough CPU clocks to set up a timer interrupt to come back to the pixel writing routine at the correct time for the next pixel, and go off and run the code that refills the 256 byte circular buffer.

 

The RLE filling code has to scan one linked list (lines not visible yet) and if they have become visible move them to the visible lines linked list.  It then has to traverse the 2nd linked list and use a line drawing algo (not Bresenham) to fill up the 256 byte RLE buffer.

 

The online emulator linked above shows all sorts of interesting DEBUG info in the borders of the screen.  Those 17 squares at the bottom of the screen are the AVR memory map showing the I/O REGS and RAM.  Each sqaure is 16 pixels high and 16 wide for 256 pixels or RAM addresses.  Each pixel can be red, yellow, green or blue depending on the read write activity.  The fifth square from the right is the RLE buffer (address 0x0C00) and it is totally full.  The eight squares to the left of that are 2 kilobytes of the linked list RAM (Address 0x0400 to 0x0C00).  You can see in the spinning cobra demo that less than 256 bytes of Linked List RAM are used.  This screen capture here with three ships shows a little bit over 512 bytes used for the lines linked list.

 

One of the other interesting things about the video mode is that I had run out of timer interrupts at this stage.  So the real timer interrupt was used for the internal 9 pixel wide thing described above.  The main timer interrupt to end the scan line was a ghetto timer interrupt repurposing the USART TX complete interrupt.

 

Three Cobra MKIII on the UzeBox

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who else saw that picture with the first thought "Elite" ?

 

(you are going to have to be quite old for that to make any sense!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't see an old Lotus there, except maybe after a crash.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Who else saw that picture with the first thought "Elite" ?
Very nearly bought (a wreck of) one 30 years ago.  Had I done so, I would still be rebuilding it ;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Who else saw that picture with the first thought "Elite" ?

(you are going to have to be quite old for that to make any sense!)

 

The young-ens still know what a Cobra MKIII is from the modern game "Elite - Dangerous".  They would just be expecting it to be texture map surfaces and alpha channel effects for lens flare and dust clouds.

 

The 3D model I used was from the source code for the Archemedies version of Elite from Ian Bells web site.  That site has most of the old versions including the source code for the original BBC micro version.

 

joeymorin wrote:

Very nearly bought (a wreck of) one 30 years ago.  Had I done so, I would still be rebuilding it ;-)

 

At the very least you would still be working on the electrics and trying to get the pop up headlights to stay up.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since the original poster seems to have disappeared, I can only assume that he has access to the last composite video CRT in Northern Europe and North America.  He asks what is the best peripheral for displaying  "things" on a "TV" using an AVR.   There are three suggestions: VGA, component or composite video.  I've never heard of component video.   I assume that is understood that the AVR will be generating the video signal for the composite monitor or bit sequence for a VGA display.

 

While the respondents link and showcase the various impressive AVR-VGA interfaces and demos, I must suggest a different approach for 2019.  The best AVR peripheral for display is the TFT telephone screen.  It has a low cost {$5-$15 USD}, a reasonable resolution (reasonable for an AVR at 320 x 240 pixels, each one of 64K colors), and a well-reviewed and maintained set of Arduino-based software libraries.  The parallel-port based unit (as opposed to the SPI-based TFTs) is extremely fast as well.  Moving an 8x8 pixel sprite by erasing the old sprite image and writing a new one takes about 500 microseconds.   Here is an eBay example unit: https://www.ebay.com/itm/2-4-TFT...

 

This unit has an embedded touch screen for user input and an SD card cage for storing photographic imagery.   In my humble opinion, it has every advantage over composite video except for its tiny size.  The time spent learning TFT programming and screen/touch user-interface design results in a set of embedded-system developer skills that prepares the learner for prosperous middle-class employment in a way that the same time spent learning composite video animation assembler language programming doesn't.   Because composite video displays are rarely used in modern times.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I assumed OP new what he was asking for.

 

Component video is pretty common and even more common in Europe (via SCART) where OP comes from.  I just bought a brand new fancy TV on the 26th of December.  It has composite video.  I don't see composite going away any time soon in the low end of the market.

 

I personally feel that the learning skills like bit banging composite video in ASM are excellent for employability.  Not because you know about some dead/defunct video standard, but because you know that it is possible for you to do things that many other people are incapable of.  Knowing about "stuff" even lets you hack and use those cheap eBay LCD displays better than the commoner that only knows how to import an Arduino library and hit compile.

 

https://www.instructables.com/id...

 

Shows how a little bit of hardware knowledge, a little bit of ASM knowledge and some history of TV makes those LCD displays even faster and smoother for the task of a full screen vector display.  Though more sellers of LCDs these days are breaking out the VSync pin so that hack is less needed.  It still leaves the other two hacks the average person would not have thought of.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:

I've never heard of component video.

 

Component video is the Red/Green/Blue triple of RCA plugs.

 

Though superior to Composite video (one yellow plug), the

content companies apparently don't like the high quality

analog outputs since you can make decent pirated copies

of movies from them.  So expect component video and

S-video (S-VHS) to disappear, while you'll still get the low

grade composite output.

 

The high-quality digital HDMI can have encryption, thus

preventing piracy.  In theory, has anyone broken it yet?

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Split of to a different thread another cool thing to see in the Uzebox online emulator

 

https://www.avrfreaks.net/forum/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That bad apple demo is quite terrible video output at 128x176 1BPP.

 

The project overall is impressive - but that is due to the RLE+LZ77 video compression not the actual video output.