XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1

RE: XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1

igorlopez — Sun, 26 Apr 2015 13:59:34 GMT

Hi Shabaz,

Nicely written documentation.

I had some questions (but google and reading your oscilloscope project gave answers to the first ones)

1) Why do you use ribbon cable instead of flying leads for the communication lines?

With flying leads you could have connected to 1 bit ports instead of modifying the SPI lib. (You fixed that in the OSC project)

2) Why did you choose SPI over I2C? (My guess is you needed high speed for data transfer)

3) Powering of the Startkit.

Is it possible to power the Startkit without going through the USB connector?

I was thinking about having the Startkit up and running and only connect the USB for debug and reflash SW.

B.R

/Igor

RE: XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1

Former Member — Wed, 25 Feb 2015 07:58:26 GMT

Hello Shabaz,

I am new to the XMOS and admittedly fairly new to the Raspberry Pi so I am quite enthused about your tutorials. I am currently attempting to get the servos working on the Raspberry Pi with the "./xmos_servo 1500 1500" command but I keep getting an error "Error performing SPI exchange: Invalid argument"

On the xmos side everything appears to be okay. I am running and the console reports :

slave_init..

...done

high event

I'm pretty sure that the wiring is correct to. I've found a loopback test for the Raspberry Pi to make sure it is setup for SPI and that all works okay. Is there anything that jumps out and says "you've not done that"?

Many thanks.

RE: XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1

fixstuff — Wed, 04 Feb 2015 20:46:02 GMT

@shabaz,

Great article! I had a question though - and it relates to mere mortals that aren't yet very familiar with the Xmos programming environment.

You utilized a TLV protocol to communicate with the RPi. You had mentioned hard coding as being inflexible, but there is a good reason for this (at least in my case). When debugging the connection between the Pi and the StartKit, it would be helpful to use perhaps hard coded input and output registers, say 2 of each, to get things up and running, and then perhaps switch over to the TLV protocol method. As it stands, I am unable to get the Pi communicating to the Startkit, and I don't know if its a configuration issue with the SPI ports, or just a dumb mistake in the code. I used the code straight off the GIT repository, as well as the sample XMOS.c code (compiled and ran SUDO), but I was unable to get it communicating, and I got stuck trying to figure out whether it was hardware or software. Could you perhaps post a quick code snipet showing just the to and from pi connection, without the servo or anything to confuse matters. Just a dirt simple XMOS program and dirt simple Pi program would be super helpful, then I could switch over to the others, and at least be able to eliminate one or the other.

Thanks!

RE: XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1

Former Member — Mon, 26 May 2014 16:35:14 GMT

Very interesting project,

I would like to introduce to you RobotOps - DevOps For Robots and the Internet Of Things, There I have seen one Rule that catches my attention.

"Writing entirely different code to incorporate similar devices is inefficient, and makes it hard to add new developers to projects, or even for existing developers to understand their own work."

I am not sure on the code that was written, but I would suggest taking a look at existing robotic frameworks (cylon.js some based over Node.js like) that could help the re-usability and like this we could all collaborate in the same direction :-)

Kudos on the Hardware integraton :-)

RE: XMOS startKIT: Building an XMOS and Raspberry Pi Robot XMP-1

Problemchild — Thu, 22 May 2014 21:46:15 GMT

Excellent article Shabaz lots of information, maybe a bit of overload for those not familiar with the XMOS device in particular.

I see you customised the stock SPI Slave there, can you also have an SPI master riding on that thread (on different I/O of course) or have they written it to consume the entire thread resources