transferring data b/w two PICs at fast rate

[engg_sajjad]

dear,
There is a master device PIC18F4520 and a slave device PIC16F690. The slave has to take data from ADC at 32K-sample/sec through SPI, and send this to master device. Each sample consist of 3 byte. There are four bit connected b/w two PIC and a sample_ready_interrupt and a nibble_ready_interrupt, connected to INTR2 and INTR0 of master PIC. So, 3 bytes are transferred using 6 interrupts at INTR0 and single interrupt at INTR2. The master has to dump all the received data to memory through SPI. Master Crystal= 40M and Slave = 20M.
Problem: In the master code, i am just buffering the received data. but still missing the data. any ideas?
_________________
sajjad

[Ttelmah]

Big change.

Use the interrupt flag, not the interrupt.

Problem is that calling an interrupt handler in the PIC takes a lot of time. Typically about 30 instructions to get into and out of the handler. Even if you don't use CCS's code and go DIY, perhaps half of this is necessary/inherent....

If instead you poll the interrupt bit, you can respond in a couple of instructions. You can also preload the table pointers, and do a direct byte write to the indf register, and just increment the pointer.

[temtronic]

If I'm reading this post right you're 'breaking' up the 3 bytes of data in 6 nibbles to transfer.

Have you 'done the math' to see if a simpler serial interface might be faster? While only one wire, it would eliminate the 'breaking up'
of the data in the Slave PIC AND the 'reconstruction' of the data in the Master PIC. You should be able to get 1Megabaud PIC to PIC,maybe faster depending on clocks and wiring.

just a thought

jay

[Ttelmah]

Agreed. The extra lines are just adding complexity.
The PIC SPI hardware 'knows' when a byte arrives. So just have the CS line triggering the jump to the receive code (one interrupt only), and then pump three bytes one after the other to the slave. All the slave does, is polls the SPI receive interrupt. Then either preload the array indexes as already mentioned, or (fastest way), use fixed indexes for the three bytes. So array[0], array[1], array[2]. With a fixed index, the code can do a single byte transfer to the location in only a couple of machine cycles. As soon as you use a 'variable' to do the access, this rises massively....

I have a couple of old systems that have been running for years, using PIC's at only 8MHz, and merrily 'burst transfer' 16 byte data blocks between the PIC's at 2Mbps, taking just on 1/10000th second to transfer the whole block. Key to the whole thing though is a single signal from the master to say 'block coming', a pause just long enough for the worst case interrupt latency on the slave, and then the direct transfer of 16bytes through the SPI hardware. The master uses an array and index, which slows it enough for the slave using fixed indexes (state machine), to save the data as it comes. Just fractionally over 160KBps, through processors at 2MIPS, versus the 5MIPS for the slowest processor here.

It is a matter of understanding the limitations, and also the capabilities of the hardware.