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

MMcLaren

Joined Feb 14, 2010
861
I don't use simulators. I use a compiler IDE at best. I did all of my University Java assignments in notepad.
I use the simulator built-in to MPLAB and I use the free/lite version of the Sourceboost BoostC compiler, which runs in MPLAB.

I found that my knowledge and understanding increased dramatically after taking the time to learn to use the Simulator and I highly recommend it.
 

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
I use the simulator built-in to MPLAB and I use the free/lite version of the Sourceboost BoostC compiler, which runs in MPLAB.

I found that my knowledge and understanding increased dramatically after taking the time to learn to use the Simulator and I highly recommend it.
It would be nice to see this with some better res. Why don't you write something and upload the hex file and I can test it out on the proto.
 

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
Thanks for the tip with shift out >>

I agree that PORTB configured as a 'shift resgister' would do away with the OR gates and be on par with resolution as is.
 

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
I also agree that doing away with the multi dimensional array in exchange with a single with one less variable index would really speed things up too.

I appreciate all of the advice that I can get.
 

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
I now agree that:
Rich (BB code):
PORTB = cache[0][segmentColumn];
PORTB = PORTB << 1;
PORTB = PORTB << 1;
PORTB = PORTB << 1;
PORTB = PORTB << 1;


Equates to this:

Rich (BB code):
PORTB = cache[0][segmentColumn];
PORTB += PORTB;
PORTB += PORTB;
PORTB += PORTB;
PORTB += PORTB;


2.4uS !!!
 

Attachments

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
Rich (BB code):
PORTB = video[0];
PORTB += PORTB;
PORTB += PORTB;
PORTB += PORTB;
PORTB += PORTB;
2uS !

Decent res is looking like more than possible now. The restriction would be the PIC's RAM.
 

SgtWookie

Joined Jul 17, 2007
22,230
I got things backwards; shift left shifts towards the MSB.
Shift right shifts towards the LSB.
I didn't think about the clear the flag bit before the shift, so use the add instead.
portb += portb;
 

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
So 200 ish bytes of RAM. 8 bytes to a scan line would equate to 64 pixels on the X-axis. Leaving room for 25 traces on the Y-axis.

Throw in a serial interface for the lines that aren't being drawn on. Bytes in the map are sequentially read in. Done and dusted good enough res to use for something practical.

Possibly room remaining in flash memory to store some characters.
 
Last edited:

John P

Joined Oct 14, 2008
2,025
I hate to rain on anyone's parade, but the C line
portb += portb;

is actually a 2-step instruction on a PIC. I did this by tacking it onto the end of another program:
Rich (BB code):
....................   portb += portb; 
02EF:  MOVF   06,W
02F0:  ADDWF  06,F
....................  
....................   portb <<= 1; 
02F1:  BCF    03,0
02F2:  RLF    06,F
....................
Of course you can't just shift Portb 7 times, because after that you have to bring in a new byte, and doing that and incrementing the index would be 2 instructions. So maybe you can do a pixel every 2 instructions, or 2.5 megapixels/sec, which would be about 130 pixels per line in 52 usec. But then, the end of a line is a problem, and anyway the PIC processors I know only have 4 blocks of RAM of 80 bytes each. Could data come in from an external serially-accessed RAM as fast as it's being used?

And as for time to actually prepare data for display (create characters, for instance) forget it.


If speed is vital, then it seems as if it has to be
Rich (BB code):
  #ASM
     RLF    06,F
  #ENDASM
 
Last edited:

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
I hate to rain on anyone's parade, but the C line
portb += portb;

is actually a 2-step instruction on a PIC. I did this by tacking it onto the end of another program:
Yup, 400nS @ 20MHz.

A lot better than what I had before @600nS using external OR gates.
 

joeyd999

Joined Jun 6, 2011
5,234
Ummm...back to my original suggestion many posts ago...

Why not just use the USART and get 1 bit per instruction cycle?
 

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
Ummm...back to my original suggestion many posts ago...

Why not just use the USART and get 1 bit per instruction cycle?
Each scan line only lasts for 64uS. The timing is so critical too that, regardless of program flow, it must always take the same amount of time to execute, otherwise the picture is distorted. The vertical axis is somewhat forgiving, but not the horizontal.

And I had planed on using the UART for serial interface too.
 

joeyd999

Joined Jun 6, 2011
5,234
Each scan line only lasts for 64uS. The timing is so critical too that, regardless of program flow, it must always take the same amount of time to execute, otherwise the picture is distorted. The vertical axis is somewhat forgiving, but not the horizontal.
That's the magic of using hardware....the timing will be perfect.

And I had planed on using the UART for serial interface too.
Fine. For a few cents more, then, get another PIC with an extra usart/spi.
 

Thread Starter

T.Jackson

Joined Nov 22, 2011
328
My horizontal runs on exactly 15.625KHz. Should actually be closer to 15.748KHz according to some specs that I have read. They say that the scan line is actually 63.5uS. My vertical runs close to 60Hz.
 
Top