pic 18f252 spi clock problem

[regall]

i am using 18f252 for spi comminication with a chip. but i am not getting good responses . for example i must get 3ch for an ACK but i am getting 7f and followed by 9e. it is happening at all commands when i want ACK.
and another responses are also different. cristal is 8MHz. what is the problem?

#fuses HS,NOWDT
#use delay (clock=8000000)

setup_spi(SPI_MASTER | SPI_H_TO_L)

spi_write(0x00); //reset command
delay_ms(1);
data=spi_read();
printf("The response=%x\n\r",data);

[EdWaugh]

I'm not clear exactly what your problem is or what you mean by good responses? Do you mean your device isn't telling you what you expect?

I think also with spi_read(0xff) you need to pass a FF value as this is the clocks or something.

You might also need to poll your device and continually send the reset command until it starts to respond.

I've had a problem with the spi on a 18f252 where if I try div_64 the clock goes completely wrong and much too slow! It doesn't seem to matter what my crystal is and code that works fine at lower divisions gets broken. Anyone have an experience of that?

cheers

ed

[Ttelmah]

This is down to how SPI works. When you send a byte with SPI, a byte is _simultaneously_ clocked in the other direction. Your code at present, clocks a byte in the 'transmit' direction, and reads the byte that was returned in _this_ transaction, not the following byte (which would be the acknowledge).
If you 'send' a byte with the 'read' command (as another poster has suggested), _this_ byte is clocked out, and the byte that is then received is returned (which is what you want), or you can 'write' a second dummy value, and then read the return.

[regall]

that is clear now. i am gettin only one ACK code now. and the unwanted data before ACK is clocked out. in addition the problem of wrong ACK code is solved by changing the protocol.

[Guest]