SPI Headaches...

[stephb]

Hi everyone...

Ok. I am trying to do SPI between 2 rabbits. Should be easy...Well, this is proving harder than I expected. RCM4110.

Using all SPI defaults: PB0 (clock), PC4/PC5 data, I built my own chip select logic.

So the code looks like this:

------

auto char c[4];

c[0] = 0x55;
c[1] = 0x37;
c[2] = 0xde;
c[3] = 0x41;


SPISelect( ); // this triggers my CS stuff
SPIWrite( c , 4 ) ;
SPIDeSelect(); // cancels the CS stuff...

I hookup my Digiview to the proper pins and I get, clock (perfect), Chip select (perfect), 1 byte transmitted , fine, but the remainder is as follows:
0x13, 0x84, 0x7D.

Shouldn't I be seeing the same output? I have played with DV's internal stuff (clock edge, LSB,MSB,bits,inverting clock, data, etc...). I cannot get the last 3 bytes to show properly. I have isolated the master and still get the same.

I tried changing the way the data is sent, 1 byte at a time, change the clock divisor, etc. No change.

So...any ideas what I must have overlooked?

[bsprouse]

You should look at the value you have written to the SBER register (page 143 in User's Manual). This controls the mode that the port is operating in. Different modes can invert either the clock or the data lines. It is also normal with SPI to transmit bits in LSB to MSB order, although the R4000 will allow you to reverse this as well. It just so happens that the sequence you saw 0x55, 0x13, 0x84, 0x7D is exactly what you would expect if the data was inverted and interpreted in the opposite bit order (MSB to LSB). This of course really throws you by the fact that 0x55 looks the same when inverted and the bits are reversed. Just make sure you write the same mode and bit order on both processors and your communications should work fine.

[stephb]

I just found that after spending some more time in DV and doing exactly what you mentioned.

So I can see what I can send fine. Still cannot receive the proper data in the slave.

I will look into the register and hopefully that's all this turns out to be.

Thanks again.

[stephb]

If you plan on doing Rabbit to rabbit SPI connections, be very careful with the speed at which you are communicating.

In the simplest of designs, I have to RCM4110 talking over SPI and I found that the default transmit speed provided it too fast for the receiver and sender to synch. This causes the slave to lose a bit for every byte and report erroneous results. A clock diviser of 100 solved the problem but renders the whole interface quite slow.

Has anyone seend anything like this?