XCore Exchange

I have a couple of question I would like answered just to clear my mind.

The Raspberry Pi connector J3, This acts as input to startkit when connected to the pi but output when running separate?

(Just using the I/O to simplyfy the different modes.)

Can other Raspberry Pi devices be used if the correct stacking connector is used?

On the subject of i2C (I'm probably missing the answer to this) What port and pins do I use for connecting i2C devices?

I have read through the Hardware pdf but still feeling a bit confused on this subject hence the question.

The connector J3 pinout is described in section 4 of the startKIT user guide:
https://www.xmos.com/en/download/public ... 1.0%29.pdf

Section 14 of the user guide is a very useful page for port planning. You can see that J3 consists mostly of ports from the port P32A, which are also shared with 3x3 LEDs and button. Multi-bit ports can only be used all as output or input at the same time (unlike most MCUs which can have mixed direction) as standard:

http://www.xcore.com/questions/1777/can ... ome-output

However, the SPI I/O on the RPI is overlaid with 1b ports used for SPI flash boot on XMOS.

The result is that if you wish to use the 1:1 connection of RPI to startKIT without any hardware mods, SPI is the only choice. If you want to connect via UART or I2C, then you can:

- (Recommended) Use flying leads from the RPI I2C or UART to spare 1b ports on the startKIT (J7 has tons of them spare). You'll be able to use standard XMOS xSOFTip if you do this.
- (Not recommended, unless you enjoy a challenge). Implement a bidirectional UART or I2C port using P32A. This will require series resistors and you'd need to develop your own interface IP with some reasonably advance coding techniques such as sampling and port turnaround, and would be quite limited in performance.

We've done a RPI to XMOS (it was actually an L8 USB audio kit board) example using I2C and it working fine. It's an example to interrogate the USB audio board from the RPI to find out what mode and sample rate it is running.. Attached is the slave side code. The master side code test using XMOS is in https://github.com/xcore/sc_i2c and I'll see if I can dig out the python RPI host app.

Haven't tried RPI as slave with XMOS has master yet for SPI/I2C - not sure if the common RPI libraries support RPI as slave anyhow.

We're also working on a SPI example (to transfer a buffer to/from XMOS, initiated by the RPI) and it's looking good for 7.8Mbps, maybe 15.6Mbps...

On the subject of SPI,
in the document (section 14) I see pin/ports allocations for Miso,Mosi and clk but no ss?
Is this a mistake?

You can use any free IO for SS assuming it's port is configured as input. I also seem to recall that the RPi can only act as master not slave however.

regards
Al

Folknology wrote:You can use any free IO for SS assuming it's port is configured as input. I also seem to recall that the RPi can only act as master not slave however.

regards
Al

Ah cool, even after reading through the user guide, I knew it had to be easy, thanks mate.
Looks like I may set the start kit as slave to the pi but then this gives me another question (probably documented somewhere and I'm just being stupid.

using i2c can the startkit act as an i2c master for control of devices but as a slave to the pi?

If you could point me to the correct reference docs for this I would seriously appreciate it as I don't know what to search for.

You *can* have multiple masters on one IIC bus but you
want to avoid that if *at all* possible.

You can of course have more than one bus.

segher wrote:You *can* have multiple masters on one IIC bus but you
want to avoid that if *at all* possible.

You can of course have more than one bus.

Am I reading the documentation correct in that I can set any of the 1bit ports to use as i2c?

Yes - as long as that port is available, you can use it for I2C. Just make sure you pass it to the I2C function and it will use that I/O. That's the nice thing about XMOS ports, as long as you stick to the same type on the same tile (ie. 1b port to 1b port, or 4b port to 4b port), you can move them around at will. This will not affect timing or functionality, and will just work.

infiniteimprobability wrote:Yes - as long as that port is available, you can use it for I2C. Just make sure you pass it to the I2C function and it will use that I/O. That's the nice thing about XMOS ports, as long as you stick to the same type on the same tile (ie. 1b port to 1b port, or 4b port to 4b port), you can move them around at will. This will not affect timing or functionality, and will just work.

Ah, cool, thanks!