SPI Communication between a Prop and PIC

[ypapelis]

I am trying to connect a Prop to a PIC MCPU through SPI but have not managed to make it work.

The PIC cpu is on the Digilent UNO32 board, and the programming environment is around the Arduino framework, where timing for SPI is provided through a clock divider (the main clock is 80 MHz).

On the prop side, I am using Beau's SPI_Asm object, although have tried the Spin version as well.

To start, I was trying to get one way communication so I connected the MOSI/CLK lines on the PIC side directly to the pins on the Prop side. The PIC is the master and the prop is the slave, which only really affects which pins connect to which. I have confirmed through a scope that the PIC is putting out a clock and data on the respective pins. Problem is that on the PIC side I do not receive anything, in fact the ShiftIn command never returns.

To start, what is the easiest way to map the clock divider on the PIC to the clockdelay on the Prop?

-- Thanks

[blittled]

This isn't the answer to your question but I recently bought an UNO32 too and was thinking of doing the same thing. You may want to check out http://www.chameleon-dev.com/ since that has documentation on a PIC24 interfacing to a Propeller using SPI. This may be similar to what you are thinking about. (BTW I also have the Chameleon-PIC which is a great product).

[Leon]

I find it useful to use a 74HC595 when getting SPI to work. It uses hardware SPI.

[ypapelis]

@blittled: thanks, I'll take a look and may even look at the Chameleon PIC, the Uno32 is attractive due to price but the software and support is greatly lacking - then again, maybe I have been spoiled by parallax -

@Leon: part of the attractiveness of the Prop is that by assigning cogs to comm tasks you don't have to add intermediate hardware, so I am trying to avoiding adding a hardware shift register.

[Leon]

I use it for testing that the SPI software works. It can then be replaced by the Propeller or PIC. Otherwise you don't really know where the problem is, although a loop-back test can often help.

[Cluso99]

Curious by your statement "so I connected the MOSI/CLK lines on the PIC side directly to the pins on the Prop side". You do have MISO connected too don't you???

[K2]

iirc, Beau's code combined MISO and MOSI on one pin. This is outside my realm of experience. MISO and MOSI are separate lines in my world.

[blittled]

I agree the Arduino compatible libraries need work. I bought the Uno32 to use with Microchip's libraries. I also wanted a PIC based Arduino Clone to use with shields.

The creator of the Chameleon, Andre LaMothe is currently working on the Scorpion which is a shield with a Propeller with media capabilities http://forums.parallax.com/showthrea...light=scorpion.

I'm looking forward to this shield. With it you can use the Propeller with any Ardiuno clone.

[ypapelis]

Curious by your statement "so I connected the MOSI/CLK lines on the PIC side directly to the pins on the Prop side". You do have MISO connected too don't you???

Actually I didn't initially because I was going to try one sided communication; I connected both lines but same result. I am trying to debug the PIC side first, I have successfully used SPI on the Prop to access accelerometers, rate gyros etc., so I know that side works. It is unclear to me if on the PIC side I have to monitor the chip select before issuing the 'transfer' call or if that is done inside the library.

When I started on this, I never thought it would be some complicated, I guess everything is a lesson ...

[Cluso99]

ypapelis: SPI is a two-way protocol, not a one sided communication. Since the pic is the master, is the code you are using on the prop setup for slave use? I haven't looked at the code, so just a suggestion.

[ypapelis]

ypapelis: SPI is a two-way protocol, not a one sided communication. Since the pic is the master, is the code you are using on the prop setup for slave use? I haven't looked at the code, so just a suggestion.

Cluso99: I was trying to use Beau's code (in SPIN and ASM) but after going through both of the versions I realized that neither would work because the code is designed under the assumption that the sender is the Master and thus owns the clock line. I need a 'slave' implementation, where the slave waits on the SS line and then data transfers simultaneously on both sides, but the master maintains control of the clock. So effectively, if the master wants to receive data, it has to send something at the same time.

In retrospect, my initial question was a bit naive; I had never looked into the details and assumed that SPI is a buffered protocol, and didn't realize that I also need to develop a high level protocol to logically synchronize the master and slave.

I ended up developing my own 'slave-side' SPI implementation in assembly; it works fine for my application and I can define my own high level protocol between the master and the slave to support transfers that are longer than 8 bits and thus have higher bandwidth. The PIC always initiates a transfer (sending a command) and depending on the command it then pauses (to allow the Prop to do what was asked) and then initiates another transfer whose length is the expected length answer. All of this while the master (PIC) maintains control of SS, CLK, and MOSI and the prop maintains control of MISO. Now I am running in trouble on the PIC side, but that's a whole other story.

Thanks to everyone for the pointers and comments, it may not be apparent but all were helpful.