subroutines to save time in main loop ?

I have my video text overlay working at last, nicely synchronised with the incoming video signals.
I have just some fixed text and number displayed at the moment, from a temporary table in the main loop

As soon as I try to get the loop to do extra coding, I start losing the sync, and the overlaid graphics start jittering.

I need to look up patterns depending on what number has to be displayed, ( depending which radio linked push button is pressed) and was thinking that perhaps I could either have:-

the look up table in a subroutine that is looked up as soon as the valid transmission and ID is received- perhaps in interrupt on the valid transmission rising?
The data could then update the temp table that is working OK now.
The fairly lengthy look-up table would then be excluded from the main loop.

Alternatively perhaps I could have the actual writing of the SPI data to the shift registers in a subroutine, and make it repeat for n frames - I just need about 4 seconds - and then return to the main loop to await the next valid transmission.
Any recommendations?

I am not going to try to get the same micro to do the audio announce too, I will have a separate one for that, which can also handle the wireless decoding, thats all working fine.

Boffin, if you're running out of time a subroutine makes things slower. If in general you have enough time just one task takes to long, perhaps splitting up things might help. Or do time critical things with interrupts. Or optimising the long task to make it quicker. Without the code it's hard to say where you can reshuffle things to prevent your loss of frame.


Thanks, when I have tried using interrupts I have kept the routine as brief as possible ( and volatile variables ) as per the tutorials.
I am not using any timing so would it be ok to run a whole look-up table once off from the interrupt routine?
I was suggesting a subroutine to run once before the main loop runs, while its setting up the number.

As soon as I try to get the loop to do extra coding, I start losing the sync, and the overlaid graphics start jittering.

Then you must be right on the edge, adding anything might not be possible without a code rethink.

Can you post what you have, we might be able to suggest some optimisation.


I will post it when its not so embarrasing - I must master arrays!
It might help just by tidying it all up, but I was just wondering about the idea of setting the variables ( a,ax,b etc.) up for various numbers using a subroutine first.
The loop must then ignore the subroutine and run the part that is working now, as below (part of )
(Each pair of bytes goes out in less than 4 microsecs.)

Rather like the bits of code that run in setup, but in my case I must get back there when another button is pressed.......


      case 0: 
      case 1:  
      case 2:  
      case 3:  

I agree with your instinct to do the heavy computation in the main loop. You should be able to compute all of the overlay data in a non-time-constrained context and have the interrupt just spit out the data according to the timing requirements. You may be able to take over one or more of the hardware timers to facilitate the fine-grained timing.

I wish I had a clearer idea how your project works in detail. Is there a past thread with more info somewhere?

Thanks guys, I have had some sleep since posting, and I think I know what the problem is, I will try an idea when I get into work.

( the jitter is vertical, not horizontal which is rock solid )

I have got very good horizontal resolution, I can even repeat my 16 bit wide graphic more than 6 times across the screen and the edges are crystal clear !

and I am running at 1280p x 720 pixel resolution on the LCD screen.

I will post the idea when if its all working.

Hi Richard
the code represents two 8 bit words that are sent out binary fashion to make the video signal, Its these pairs of bytes that I want to set to the incoming data before starting the SPI transfer of the video to the shift registers.
The video data is repeated for 16 lines to make one vertical pixel ( case 0 , 1 etc) then the next and so on for 18 vertical pixels.
So my graphic window is 16 pixels wide and 18 high, in the top right hand corner of the screen, the rest of which shows the normal incoming vga picture from the satellite/computer or whatever

Just trying to get my head around this, I may not have any answers but so far I'm not necesarily understanding the problem.

You have a method of syncing with the scan lines? How?

At the start of each scan line you have to put a byte into the SPI data reg.

The SPI hardware is clocked by the LCD dot clock.

8 pixels later you stick another byte in.

These bytes come from a pattern generator table.

You repeat 18 times.

Then you have 702 scan lines to organise your data for the next run.

Is that correct?

I'm working from previous experience with CRTs, may be totally off for LCDs.


thanks for the input guys, I found I had left a temporary test routine in the code, and when I rectified that, voila ! tons of time to do the whole lookup table in the main loop with no problems, I even put the BCD address decoder in too.
I feed the 4 data bits from a Holtek HT12 rf link in to 4 pins, and the valid transmission pin to another.

I am only using 2 of the SPI pins, the MOSI and the srclck , the latching is done externally to the micro which is how I sync everything.
I just have to make sure the data is all clocked into the SIPO before the end of each 15th line.

I want to integrate the HT12 decoder into the project too, but can’t get the library to run, ( ) so I use an external HT12 chip, I would like to try and get it on the micro…

The trick to get the nice horizontal resolution synced to the HD video, is to load 16 bits into a SIPO ( 2 x 595 I am using ) during 15 lines of the video data, and then to latch at the next horiz flyback time, with the parallel outputs feeding a high speed 16 bit PISO , which is loaded and read every line ( clocked by a 4 Mhz oscillator )

This gives basically 16 times the horiz resolution than trying to generate the video real time. I even made some nice fonts as opposed to the 7segment type numbers I had on the 74HC prototype.

Its similar to the teletext used on TV broadcasts ( do they still do that ? )

Its a big rats nest :-/ on a protoboard at the moment, but I will post some details and pics when I get it done.