11 Replies Latest reply on Apr 26, 2016 2:17 AM by nsrb

    Some questions about Edison's SPI

    cer1991

      Hi,everyone,

      When I use Edison's spi,I found some problems.


      1.SPI's CLK SPEED

         The guide says the Edison's SPI CLK can be up to 25MHZ,however when I set my spi_device's MAX_SPEED_HZ to 10MHZ,the real speed of the clk is just about 6MHZ.It is very odd.But when I set it to 4MHZ,the clk is really 4MHZ.

           Can anyone test it?


      2.The problem of SPI's CS

          When I use FS0 as CS,I meet problem as below,

      IMG_20150702_152732.jpg

      Between every byte of one SPI_transfer,the CS(Blue Line) will be "1" automatically.That is inacceptable.


      However,when I use FS1 as CS,there is not this problem.But the time of one SPI_message is very long.

      For example,I set SPI clk to 4MHZ,the cost time of one SPI_message is about 25us(the right time should be about 6us).That is inacceptable.

      IMG_20150703_074725.jpg


      Does anyone kown how to fix these problems?


      Thank you!!!

        • 1. Re: Some questions about Edison's SPI
          KurtE

          Simple answer is nope, still waiting..

           

          There have been quite a few threads talking about SPI issues including: New Kernel - SPI fixes

           

          Yes there are several speed issues with SPI (let alone hangs and idle issues)

           

          Clock Speed: I think the last versions had some stuff that may allow some stuff to run faster than 6 mhz, but then I think it added delays in...

           

          Does not support DMA nor FIFO queue: so code waits for interrupt (or spins) until a character is done, then puts the next one in.... So there is a delay between characters.

           

          There is a real long delay between requests... That is if you make multiple calls to spidev (whichever way you get there, MRAA, Arduino, direct), There is a lot of overhead per call... So you are better off if you can call once with multiple bytes...

           

          CS: Yes there appears to be issues with you not having control with CS that you think you should...  Before I put my Edison stuff on hold, I was controlling the CS myself instead of either using hardware one or having MRAAs SPI library control it...   Would be nice to know if Intel will be (or maybe already has) implemented the SPIDEV CS support that i think I read in the websites.  That is if i understand correctly, Each call to SPIDEV will keep the CS asserted afterwords for some period of time, such that if you call multiple times in your code it stays asserted.  After a timeout it will unassert.   There are fields that you can control that sets the timeout and gives you an override to deassert CS...

           

          Again I don't know of any fixes for current release... I keep hoping they will release some fixes, but...

          • 2. Re: Some questions about Edison's SPI
            cer1991

            Thank you very much.

            • 3. Re: Some questions about Edison's SPI
              LeonY

              i really wish i had looked through this forum before i purchased my Edison....I had so many issues using the Galileo Gen1 and Gen 2 i though they had ironed all this stuff out for the Edison...What a disappointment.

              • 4. Re: Some questions about Edison's SPI
                mikemoy

                I just pulled out my edison to see what changes have been done. I figured for sure SPI would be working correctly by now. Ran some of my SPI code and jaw dropped when I saw that there are still huge delays with SPI writes. Then searched on the forum and found this post. I just cannot believe even after all this time its still the same.

                 

                What is wrong with Intel!

                • 5. Re: Some questions about Edison's SPI
                  KurtE

                  Hi Mike,

                   

                  Yep - the unfortunate thing is, they have an external github project with sources for some of the Edison stuff.  These sources include some deltas that have been made since the last image was made and some of these changes include some SPI stuff, which looks promising.  Things like DMA... But so far no public releases have been made.  It may be possible to figure out how to do a build using these sources.  There have been a few clues on this in a couple other threads, which I keep meaning to try again.  But I keep getting distracted doing stuff with other processors (Odroid C1 and U4 as well as playing with Teensy 3.1/ and 3.2 and some with Raspberry Pi 2).

                   

                  Intel: As I have mentioned a few times, I wish you had a way in place for those of us who are interested to pick up Intermediate builds.  Example: maybe when ever the public github project is updated, there is a alpha/beta build available.  Or could be like Arduino which have their daily builds...

                   

                  Also it would be great if you were a little more open and would give us a rough estimate of when releases were about to be released and some mechanism to track the status of different issues. ... 

                  • 6. Re: Some questions about Edison's SPI
                    Frederick Blais

                    KurtE, do you think it would be a good idea to start a new thread on the matter? It would be nice to know what are Intel plans on the future of the Edison.

                    • 7. Re: Some questions about Edison's SPI
                      LeonY

                      Can i please refer everyone to this thread MRAA SPI - kernel panic when writing buffers at >25KHz Intel has stated that "They are aware of the problem...." That is all! They are not planning on fixing it, or at the very least not telling us that they are planning on fixing it.

                      I logged a support case with Intel, and after 2 weeks their response was:


                      Edison uses the SPI driver available with the Yocto embedded Linux. Like most embedded devices the SPI driver is emulating SPI interface protocol use bitbang technique therefore the speed on the SPI is limited. By increasing the SPI speed the SPI driver provided by Yocto Linux get overwhelmed with the data and crashes and cause the kernel panic.

                       

                      Regards,
                      JPMontero_Intel

                      • 8. Re: Some questions about Edison's SPI
                        mikemoy

                        So is this a Yocto issue?  In other words how about the Debian port, does it still suffer there ?

                         

                        • 9. Re: Some questions about Edison's SPI
                          LeonY

                          From my experience, the previous version of firmware V2, does not have any issues with SPI

                          • 10. Re: Some questions about Edison's SPI
                            TCGreen

                            Does anyone know what version of the firmware LeonY would of been using that didn't have issues with the SPI?

                            • 11. Re: Some questions about Edison's SPI
                              nsrb

                              I asked guys from MRAA and they said that last version that does not have SPI Kernal Panic issue is edison-image-ww05-15. Yes, it looks very very odd that Intel published several releases after that and they all have Kernal Panic! Now I use ww05-15 but with very low SPI bandwidth - I measured SPI transactions with logic analyser and result are the same as in this post. With bulks of 2048 bytes and speed 10 MHz in infinite while loop I have only 200-300 kBps throughput, it is not acceptable on my project and it also CPU payload depended. This was bad idea to use Intel Edison in my project.