SPI Communication between a Prop and PIC
ypapelis
Posts: 99
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
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
Comments
@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.
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/showthread.php?130093-Propeller-Ardunio-Shilelds&highlight=scorpion.
I'm looking forward to this shield. With it you can use the Propeller with any Ardiuno clone.
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: 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.