SPI master to PIC18F4550 slave synchronization (C18) using NETMF
A .NET Micro Framework device (ChipworkX in this case) sends a byte through the SPI interface to a PIC18F. Having PIE1bits.SSPIE
enabled, the following code is executed on interrrupt:
void high_isr (void)
{
PIE1bits.SSPIE = 0;
P开发者_Python百科IR1bits.SSPIF = 0; //Clear interrupt flag.
LATDbits.LATD5 = 1; //Enables LED for high interrupt activity.
while ( !SSPSTATbits.BF ); //Wait until cycle complete
red_byte_array[1] = SSPBUF;
SSPBUF = 0x00;
LATDbits.LATD5 = 0;
PIE1bits.SSPIE = 1;
}
When sending the same byte a few times, the data does not seem to be read consistently. Both master and slave are setup for clock idle low level, and data clocking on rising edge. I don't use the chip select line, because it's direct communictation. Finally, the master sends data at 100 kHz, while the PIC is operating at 8 MHz.
How do I improve and/or fix this code?
On the PIC16F886/7:
If you are not using the /SS
, then the data changes on the rising edge and is sampled on the falling edge, for a SCK
idling at 0: CKE = 0
, CKP = 0
(or 1
), SMP = 0
.
The byte moving from the shift register to the buffer register causes BF
bit and SSPIF
the interrupt, so you don't normally loop about in the interrupt waiting for BF
.
There should not be any need to disable SSP
interrupts (SSPIE = 0
), but you probably need to clear the SSPIF
before returning from interrupt.
I would guess you should, on SSP
interrupt (SSPIF = 1
):
red_byte_array[x] = SSPBUF
SSPIF = 0
You may need to check WCOL
and SSPOV
for errors.
Given that your PIC only has ( 8 MHz / 100 kHz ) 80 cycles to respond, that Delay1KTCYx() seems rather long.
精彩评论