Project du jour is turning out to be a headache, it requires multiple tasks where the frequency is too high for RTCC method (interrupt overhead (6 cycles) would throw everything off). Anyways my solution is manually multithreaded modules which are strung together in order of need. Jmp + setting up jump value approaches the problem with ISR overhead. Can I do a "mov pc,w" to cause execution to jump to that location? What does jmp do that needs those 3 cycles (I know one additional is for the pipeline, but where is the other one)? Do I need to place a nop after the command because of the instruction pipeline? What Im trying to implement is a jmp ind.

Paul,
Yes, provided that W contains the address of the jump target, you can use mov pc, w to jump to that target. jmp pc+w (or add pc, w) is another method which allows for relative jumps with w holding the offset.

Actually, all three cycles are caused due the instruction pipeline. This 4-level pipeline usually holds four instructions read from four consecutive locations in program memory. On a  jmp (or call), three instructions in the pipeline must be discarded, and it takes three cycles until the first instruction of the code sequence at the jmp target reaches the end of the pipeline.

hmm it was late last night when I posted, I forgot that the pipeline has a depth of 4. So does this mean "mov pc, w" will take 3 cycles before the code at that location is executed? What is done with the three intructions in the pipeline after "mov pc, w"? IE is it six one way, half a dozen the other when comparing jmp w vs. mov pc, w?

Hi Paul;
When your destination address is in w, and that destination is on the same page, the the mov pc,w executes the same as a jmp addr, timeings and all. It is 3 cycles for either one. By the way, this makes a great state machine:

Thanks Peter, I had a feeling that was the case.

I think I've got the module switching code down to 5 cycles (+1 if fsr needs to be set), I should be able to squeeze that in, the fast process is 3.57 MHz or a state transistion every 7 cycles, leaving 6 cycles between the trailing edge of the clock to the leading edge of the clock. Man I thought calculating the timing of NTSC was tricky, thats childs play compared to organizing a 3.57 MHz process, a 450 kHz process (1/8th speed of the faster process) and stuffing a bunch of support functions to perform data manipulations during the "dead space" while keeping the fast proccess a rock steady frequency.

As I hinted, Im tackling it by writing the support functions, then lacing them with the fast and slow processes by hand, then stringing them in a fashion that the leading edge of the clock in the next module happens exactly 7 cycles after the previous module's last trailing edge of the clock. Ive thought about using a preprocessing framework to do the merging of the processes but I think that would take longer than doing it by hand. Does anyone know of a free generic, flexible preprocessor that is also easy to use?

Hi Paul;
Yes, that interleaved code writing (stuffing "dead" space) can get pretty tricky, but hey, once it's done and running, who cares. Years ago I had the need for that when I was doing 10 Mbit/sec bit-bang UARTing, and presently I'm doing it with 5 Mbit/sec UARTing interleaved with reading/writing serial memory at 12.5 MHz.

Could you descibe in more detail what your exact high speed requirements are??  I'm kinda interested in seeing what others are able to squeeze out of 50 Mips.

I am attempting to construct an LCD controller with a SHIFTOUT compatible serial interface (synchrounous serial comm is faster than async (less overhead and no need for oversampling)). The LCD requires 8 bit values pumped into it at a speed of 3.57 MHz, I have chosen to support serial data at a rate upto 446 kbps (3.57/8). There will be a fast SRAM for the video buffer and EEPROM (or FRAM) to store fonts and user defined 8x8 blocks (tiles). Tiles can also be sent over the serial link. The first stage is to get the interface working, after that comes the sprite engine and graphics manipulation functions, and if there is space maybe some primative graphics routines (line, rectangle, ellipse etc). During each row, serial data is collected in a fifo and tasks on the task fifo are executed. At the end of each row and before the next, the comm fifo is processed and tasks are generated and placed on the task fifo. Since the tasks are dynamic in nature, I had to come up with this framework to achieve the 3.57 MHz refresh rate of the LCD while being able to perform any subfunction. This will be an interesting project since I have not had to perform RT multitasking with process requiring this speed.