Composite (complex) Video 100% Straight C on a One-Dollar MCU!

T.Jackson

Joined Nov 22, 2011
328
How much extra time do you have to do any kind of data transfer and preparation?
Rich (BB code):
Delay_us(43);
asm nop;
asm nop;
43uS and change on lines that are not rendered.

This could be improved possibly. Never get anymore than 52uS though. At this point the TV expects horizontal sync, or it is a total no goer.

joeyd999

Joined Jun 6, 2011
4,477
In theory you're right, but I don't feel this to be practical. It needs to some how 'blend' in exact time with software algorithms.
I think you are going to discover, as soon as you start trying to do something other than displaying a static test pattern, that hardware timing is the only way to ultimately make this work.

I will be man enough to congratulate you when you prove me wrong.

MrChips

Joined Oct 2, 2009
25,053
I can do VGA, SVGA and XGA. Anyone interested? Early orders get discount prices.

T.Jackson

Joined Nov 22, 2011
328
I will be man enough to congratulate you when you prove me wrong.
Nothing to prove here mate. Just trying to get a project done that could be attractive for some. Saves money not having buy dedicated output devices all the time. Most cars have LCDs in them now too. A project like this could be of interest, especially on a one-dollar MCU.

T.Jackson

Joined Nov 22, 2011
328
I can do VGA, SVGA and XGA. Anyone interested? Early orders get discount prices.
Car screens don't have these interfaces. Gotta be composite.

MrChips

Joined Oct 2, 2009
25,053
You want composite. I give you composite... in 256 colors.

T.Jackson

Joined Nov 22, 2011
328
You want composite. I give you composite... in 256 colors.
Well if you can do that for a dollar, then I am wasting my time aren't I? Not saying that I can get colour on ANY MCU, let alone a one-dollar part, but usable monochrome to display information using an MCU that is abundant and dirt cheap, is of interest.

T.Jackson

Joined Nov 22, 2011
328
I think you are going to discover, as soon as you start trying to do something other than displaying a static test pattern, that hardware timing is the only way to ultimately make this work.
You are right, this project is out of my league. I don't know asm and have no plans on learning it.

I cannot properly time this in my IDE when I start to use functions such as: UART1_Read();

Rich (BB code):
     {
Delay_us(43);
asm nop;
asm nop;

}
Can anyone tell me how long i = UART1_Read(); in uS takes to execute?

Last edited:

T.Jackson

Joined Nov 22, 2011
328
I will be forced into creating a parallel interface. PORTB changed to inputs during the free scan lines. One bit on PORTA as a data enable. It would be as fast as the "project" MCU at the other end telling it which segments to blit.

The other problem for me with the UART would be that it is on PORTB. It takes time to initialize it.

Doesn't look like there will be a simple serial interface on this, at least not on my version.

Last edited:

T.Jackson

Joined Nov 22, 2011
328
I didn't think about the clear the flag bit before the shift, so use the add instead.
portb += portb;
Yeah me too. A lot that I didn't think about as well. God dam PORTB as a shift register. A shift register is one thing in electronics that I have never used. I thought that the portb += portb; was a joke at first. Like as in you were having a 'lend' of me. As I said at the start -- I know 2% of it.

I feel like a bit of an idiot right now actually. Not only did you manage to get rid of the OR gates, you guys also managed to speed the protocol up by 50% if my maths is right. (600nS / 400nS) x 100

1.5 x faster!

Last edited:

joeyd999

Joined Jun 6, 2011
4,477
Can anyone tell me how long i = UART1_Read(); in uS takes to execute?
No. Because ASYNCHRONOUS serial comunications is, by definition, asynchronous!

Yes, the bit rates are defined, *but* you don't know when to expect the data.

Additionally, this is one of the troubles with C. You are dependent upon the developer's libraries* (if you choose to use them). And you must carry all his baggage around with you.

*EDIT: You are also dependent on the compiler's implementation *and* the code optimization. IMHO, more trouble than its worth!

Last edited:

joeyd999

Joined Jun 6, 2011
4,477
ASM isn't so bad? I think that most of its users are bananas. They're making video games by counting clock cycles with the source code so 'scattered' around the place it is unbelievable.
Can anyone tell me how long i = UART1_Read(); in uS takes to execute?
I feel vindicated!

Last edited:

joeyd999

Joined Jun 6, 2011
4,477
Can anyone tell me how long i = UART1_Read(); in uS takes to execute?
Sorry for three messages in a row, but I want to elaborate a little here. There are at least two possible implementations of the UART1_Read() function, and I don't know which approach your compiler is using.

The first is a "blocking" implementation, where the function waits until a character is available in the receive buffer. This will *never* work in your project, as instruction execution will stall until data is available. This will throw off your timing *every* time you make the call.

The second is a "non-blocking" implementation, where the software USART driver is implemented as an interrupt, and the incoming data is queued. In this case, you would need to test first if data is available in the queue, and then read it. Execution will not stall, but timing is still a pain, because there is receiver code executing in the background stealing instruction cycles from you. Again, I don't think this will ever work.

You are *severely* limited by the hardware you have chosen. IMHO, the only way to get acceptable results would be to have priority interrupts available (like on the 18F parts). The pixel clock (say driven by SPI or synchronous USART) would have high priority, as this is where you need timing precision. A non-blocking serial comm routine would have low-priority, and buffer the data into a queue. The main program would test the receive queue, capture data as necessary (while the other stuff runs in the background), and update the pixel buffer.

Hope this helps.

T.Jackson

Joined Nov 22, 2011
328
You are *severely* limited by the hardware you have chosen. IMHO, the only way to get acceptable results would be to have priority interrupts available (like on the 18F parts). The pixel clock (say driven by SPI or synchronous USART) would have high priority, as this is where you need timing precision. A non-blocking serial comm routine would have low-priority, and buffer the data into a queue. The main program would test the receive queue, capture data as necessary (while the other stuff runs in the background), and update the pixel buffer.
18F parts expensive, 16F parts cheap today expensive tomorrow. There are off-the-shelf products already existing for around 50-dollars (as mentioned earlier) -- to do what I am trying to do, and in color! So, I would not have attempted to do this on anything other than a 16F part that is of plentiful quantity in the market place.

More over, a parallel data interface could possibly be more appealing, because it means that another MCU doesn't necessarily have to be at the controlling realm of it all. Other, more cheaper obsolete parts could be used to create video projects.

The goal is just to get this done as quickly as possible on the chosen one-dollar part. Document it, publish it, and it will attract attention because of how cheap it can be to interface to monochrome composite video. It won't be as simple as with a serial interface, and some may argue that this is a blessing in disguise!

joeyd999

Joined Jun 6, 2011
4,477
18F parts expensive, 16F parts cheap today expensive tomorrow. There are off-the-shelf products already existing for around 50-dollars (as mentioned earlier) -- to do what I am trying to do, and in color! So, I would not have attempted to do this on anything other than a 16F part that is of plentiful quantity in the market place.

More over, a parallel data interface could possibly be more appealing, because it means that another MCU doesn't necessarily have to be at the controlling realm of it all. Other, more cheaper obsolete parts could be used to create video projects.

The goal is just to get this done as quickly as possible on the chosen one-dollar part. Document it, publish it, and it will attract attention because of how cheap it can be to interface to monochrome composite video. It won't be as simple as with a serial interface, and some may argue that this is a blessing in disguise!
Good luck. IMHO, this will an exercise in futility for you. I would like to know how things pan out in the end.

T.Jackson

Joined Nov 22, 2011
328
Good luck. IMHO, this will an exercise in futility for you. I would like to know how things pan out in the end.
It's already like almost all there in the first post of the thread. The only thing(s) that are going to change will be:

• Improved resolution
• Improved source code
• No OR gates
• Data interface
• Documentation with interfacing examples

T.Jackson

Joined Nov 22, 2011
328
The abstract is done. The skeleton code is all there with accurate NTSC timings that almost sent me crazy trying to figure out.

I don't have a decent scope either.

joeyd999

Joined Jun 6, 2011
4,477
It's already like almost all there in the first post of the thread.
Jeeze, I said good luck. And I meant it. I hope you do succeed.

T.Jackson

Joined Nov 22, 2011
328
The biggest hurdle for me now is that, because I only have the evaluation version of mikroC, I can only use around 40% of the pic's ram. I need to take full advantage of the ram to get higher res. I have downloaded BoostC which will allow me to use the full bandwidth of memory, but I don't know this compiler at all.

Days to learn? weeks? months? years?

Can I even time things in it that will tell me how long a routine takes to execute in uS?

Last edited:

tom66

Joined May 9, 2009
2,595
I've been working on an OSD capable of 256x192 pixels bilevel transparent graphics. Not quite $1 though; the OSD part costs are around$10.

I use a dsPIC33FJ128GP804 with a few other components (74LVC1G125, LMH1980, some passives). It uses an incoming video signal, strips the sync out, and embeds the graphics each pixel of which can be black or white or transparent. There are plans for self syncing, if the input signal is lost, but that hasn't yet been developed.

It's an all SMD layout: 0603 and TQFP44. Nothing too difficult to do by hand.

Getting smooth ~25 fps head up display on a processor clocked at 36.85 MHz is tricky but not impossible. There's room for improvement. It's for my model aircraft, so I can see the flight parameters whilst looking at the video monitor. No need to see the aircraft.

Video:

It's also open source - http://code.google.com/p/super-osd/

So the design is pretty simple, but there are some hacks to give such a high resolution at a low cost:
- Input video signal goes into sync separator which gives us CSYNC, VSYNC and ODD/EVEN. (You could use a LM1881 or an LMH1980.)
- A CSYNC event triggers an interrupt.
- Scanline is chosen and loaded into memory.
- A timer interrupt is set to trigger in about 10µs.
- SPI is set up to queue first word. SPI interrupt is set up.
- Interrupt fires when word is finished; new word loaded (in just 10 cycles - a challenge!)
- When VSYNC fires, new field starts; reset line counter.

Drawing graphics is more difficult. You can clear the screen immediately, but you will get flickering. So the HUD updates each bit one bit at a time, to reduce the flicker. Also, accelerated instructions, such as draw_hline, take advantage of the data storage and can draw 16 pixel horizontal lines in less than 30 cycles.

Last edited: