Generating Video with LPC1111

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Generating Video with LPC1111

599 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Danjovic on Sun Sep 01 21:11:39 MST 2013
Following the experiments on my previous post, I have managed to obtain some successful results on generating a video display with LPC1111.

Here it is possible to see a 30x24 display. Notice sharp edges of the characters (no noticeable jitter).

It took me a long time to figure out how to remove the jitter, and I can say that I was lucky, since I haven't understood very well what I discovered incidentally. Let me explain.

I am using the Systick interrupt to generate the horizontal interval, and using the SPI port to serialize the patterns from whose the characters on screen are composed.
Initially I was generating a 64x25 display, and since the characters are very narrow on the 5" B&W TV, I didn't realized that there was jitter each 4 horizontal lines. But when I reduced the SPI frequency to the half such jitter become noticeable.

While experimenting with a variable for modulating the value of the Systick Reload Register of Systick Interrupt, in order to compensate the jitter, I have discovered that if I simply reload the register(i.e. no modulation), the jitter dissappears!

My code looks like:

...
void SysTick_Handler(void)
{
   ... 
   do sync
   send characters for SPI port
   ...
   SysTick->LOAD=H_LINE_TICKS;
   ...
}


I don't know exactly what happens. Maybe when the Reload Register is rewritten a prescaler is cleared or something similar.

PS: I am using the MSX character set.
Labels (1)
0 Kudos
4 Replies

590 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Danjovic on Sun Sep 29 20:55:45 MST 2013
Hi Paul

I am experimenting now on synchronizing with external video signal for generating OSD.

The first tests have been done using an interrupt that changed the state of a pin after entering an interrupt caused by a falling edge of HSYNC signal. That resulted in a crisp border [1] (no jitter)

But when I stated using the SPI port, I got some jitter [2]. This time I still couldn't figure out what is the cause, or how to get rid of it. Unfortunately, the parameter IRQLATENCY did not helped.




Best Regards,
Daniel
0 Kudos

590 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by NXP_Paul on Sun Sep 08 08:41:34 MST 2013
I am not sure why rewriting the value of the Systick LOAD register cancelled the jitter.
There is no restriction for the number of ticks to be a multiple of 2, that I am aware of.
0 Kudos

590 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Danjovic on Sat Sep 07 04:22:11 MST 2013
Thanks Paul,
I'll perform some experiments on changing the IRQLATENCY register.

Do you have a any guess why do the rewrite of the Systick->LOAD register have cancelled the jitter? Can it be related to the number of ticks (2727) not being a multiple of 2 (or 8)?

Best Regards, 
0 Kudos

590 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by NXP_Paul on Fri Sep 06 07:22:06 MST 2013
Have you tried using the IRQLATENCY register to improve the jitter?
From the UM10398 User Manual:
The IRQLATENCY register is an eight-bit register which specifies the minimum number of
cycles (0-255) permitted for the system to respond to an interrupt request. The intent of
this register is to allow the user to select a trade-off between interrupt response time and
determinism.
Setting this parameter to a very low value (e.g. zero) will guarantee the best possible
interrupt performance but will also introduce a significant degree of uncertainty and jitter.
Requiring the system to always take a larger number of cycles (whether it needs it or not)
will reduce the amount of uncertainty but may not necessarily eliminate it.
Theoretically, the ARM Cortex-M0 core should always be able to service an interrupt
request within 15 cycles. System factors external to the cpu, however, bus latencies,
peripheral response times, etc. can increase the time required to complete a previous
instruction before an interrupt can be serviced. Therefore, accurately specifying a
minimum number of cycles that will ensure determinism will depend on the application.
0 Kudos