Hi everyone and happy new year!
I would like to use # CS0 on Edison for chip select for a device I am making which will be on a custom made board.
(In /dev I can see: spidev5.1 but not spidev5.0 )
There was a discussion two years ago which can be found here: /message/272815# 272815 Edison spidev for CS0 And I wondered if it is still the case that the current linux builds for Edison do not allow the use of CS0?
I suppose I could always programme CS0 (GP110) as GPIO and bit-bang the CS0 line, but that would be slow compared to using the hardware module to do it.
So, does anyone know how to use CS0 for SPI (using spidev) on Edison?
Thank you for interest in the Intel® Edison Breakout Board.
The CS0 is connected to the ADC module in the Arduino Expansion Board and the image was built for this behavior, this is why it is hard to use the pin.
As you mentioned, most members who face this, choose to program CS0 as GPIO.
I suggest you to check this patch https://gist.github.com/FantomJAC/69c3e963580e939b0615 (community members found that it works for both spidev5.0 and spidev5.1).
Thank you for the helpful reply.
I will check out the patch, although I'm not 100% sure what to do with it.
I do have a machine running Ubuntu 12.04 set up for rebuilding the image so I'll try to figure it out.
GPIO seems to work for me, so thats good enough for now.
I'm glad that programming CS0 as GPIO is working for you.
If you have any other question don't hesitate to contact us.
Thanks for all the help.
I downloaded the patch and put it into the build, but the build now fails on an unrelated issue to do with paho.mqtt
So I found that there is a change you need to make to one of the bb files to account for the fact that mqtt has moved from one repository to another, but after doing that the build still fails with a script error which I don't have time to chase down just now.
I really would like to have CS0 working natively (ie without using manual GPIO bit twiddling) but it seems that the build gets out of date quickly and requires fettling. Unfortunately I don't know quite enough about the image build process to fix it easily.
So for now it's going to have to be GPIO :-)
So I thought GPIO control of GPIO110 would allow me to toggle CS0, but in fact GPIO110 remains stubbornly stuck at "1"
This is what I have tried:
root@MercuryEdison:/sys/class/gpio# echo "110" >export
root@MercuryEdison:/sys/class/gpio# cd gpio110
root@MercuryEdison:/sys/class/gpio/gpio110# cat direction
root@MercuryEdison:/sys/class/gpio/gpio110# cat value
root@MercuryEdison:/sys/class/gpio/gpio110# echo "0" >value
root@MercuryEdison:/sys/class/gpio/gpio110# cat value
...as you can see the 'value' stays stubbornly stuck at '1' so I think something else must have control of this line.
Is there a way to see who else has control of gpio110?
Have I missed a step ?
I'll suggest you to check this couple of threads, they show how to control the CS0 manually:
https://communities.intel.com/message/272815# 272815 https://communities.intel.com/message/272815# 272815
https://communities.intel.com/message/276092# 276092 https://communities.intel.com/message/276092# 276092
Thanks again, Andres
I don't have a problem understanding and using GPIO either from the file system or mraa.
In fact I have tried both.
The issue is that what should be a simple thing (using CS0) is not. Not everyone is using an Arduino solution for this thing, so why is CS0 reserved?
GPIO from file system OR from mraa don't work because something else is controlling GPIO110.
So the solutions are the build a new kernel with a pactch to allow CS0 (spidev5.0) BUT the build instructions are out of date, repositories have moved and no-one seems to be interested in maintaining the build.
I challenge you to find a set of build instructions for re-building the linux kernel, from scratch, which actually work. And why should I have to rebuild the kernel just to allow me to toggle GPIO110 (SPI2_CS0, PIN53 whatever you wish to call it).
There must be a simpler solution to allow me to drive CS0 either properly under spidev control or manually using sysfs or mraa - but none of these work.
Hi AndresI'll suggest you to check this couple of threads, they show how to control the CS0 manually:
I had already seen both of those. One deals with patching the build, but the build is currently broken anyway. The other offers nothing that I haven't already tried.
I feel that there is something "owning" the CS0 line in this build and preventing it's use.
I'll be needing more time to come up with information that you may find relevant. As soon as I find something that may help solve your issue, I'll contact you through this post.
Thank you for your patience.
As I previously mentioned, the use of CS0 is for the on-board ADC and that's how the Yocto image has been built, that's way, in order to change this behavior, you'll need to modify the kernel and re-building the image.
This is not part of our support scope so we cannot provide any other suggestions on this subject. As you saw, there are a couple of threads that discuss this same scenario and the suggestions provided are contributions from other users. When the suggestion provided by another community members don't work (like the patch recommended before), we cannot do anything about it. That's because they are not official suggestions from Intel, I hope you understand that.
What I can tell you is to contact the authors of the previous suggestions to see if they can help you with this, otherwise, modifying the kernel/image is the way to go.
What a completely unhelpful reply!
The Hardware guide states that Edison has two SPI channels available. The hardware guide explicitly states that there are two chip selects available, and even gives the pin numbers:
The current build is configured for a non-existent ADC, and so hides CS0 from the user.
Intel must surely be able to keep their own build up to date.
You talk to me like some child who hasn't done his homework! Whereas in fact I did a large amount of research into this issue and found the two threads you posted, and read them, before posting my own question here.
I believe it's a bit un-professional of Intel to say "Here's our product, sorry it doesn't work as advertised. Try asking around. If that doesn't help, then tough. Sorry"
At considerable personal expense I re-laid my carrier board to work with CS1 instead of CS0.
At least I now have working prototypes for my client, but I'm stuck using bit-banged GPIO for chip selects if I want to add any other SPI devices.
This whole issue raises a few concerns for me....
1. It should be a simple matter to rebuild the image with the new recipes for allowing both chip selects to work, but currently there are NO working build instructions for the Edison image.
2. The Intel provided documentation is out of date and doesn't get updated.
3. The intel provided software download pages don't have some items pointed to by other Intel documents.
4. The support you can get is not great for what will become part of a commercial product.
You may think I am just moaning, but you compare the above to, say, the Raspberry PI and you'll see a marked difference.
The intel product is four times the cost of an R-PI compute module, and I expected a much better support experience from Intel, but you live and learn.