At times I wonder if anyone has made a kernel image that does not have any of the Arduino specific stuff installed.
Example wonder if SPI is semi-crippled to support the Analog to digital converter. If that was not installed could SPI run faster without delays.
No SD Card?
I can't say I've tried to build an image like the one you are describing. I guess you would need to modify some recipes so that the image doesn't contain the Arduino files. You can try it and post your results in the community.
As I learn more about how to build stuff for yocto, maybe at some point I will try.
But there is some underlying stuff, that in the system to support the Arduino board. Things like the SPI support to the A2D converter. So assuming I can find which driver that is, probably can change to remove this driver. Then maybe can modify somewhere else to now make the CS pin associated with that device available, maybe to SPIDEV.
The harder questions are, if for example if the slowness in SPI, example the gaps between bytes and the real big gaps between requests can were put in because of issues associated with the A2D...
Likewise are there capabilities of I2C that are not available on the mini board (or sparkfun boards or the Trossen Robotics board) because of how it is used to support the Arduino board. Again I have no idea which other drivers or settings that might be. SDCard? ...
Again I unfortunately I don't know enough to know. It may turn out, that the one built kernel is smart enough, that when it detects something is not available those resources that would have been used to support that device and makes it available for other devices...
Yes, I guess the only way to answer those questions would be to make the image and testing all the different cases and see how spi and i2c for example would behave if the changes to the Arduino were made. If you are using Yocto I believe it can be done because it is very flexible in certain aspects and will probably let you create the image you are describing.
I haven't used or looked at any of the Arduino stuff, but I was looking at adding an SPI Ethernet bridge. Because of the way the spi drivers are setup I had to remove the existing SPI devices from the board.c file in the kernel. Looking at the kernel board.c, platform_ads7955.c and platform_spidev.c files, it looks like any slowness would be in the spi drivers themselves. So removing the Arduino specific stuff from the build probably won't help.
The ads7955 drivers uses automated chipselect and spidev uses gpio chipselects. I wonder how much difference this makes?
I have not spent any time looking into the spi drivers @ intel_mid_ssp_spi.c (yet) other than to note there were no Arduino related ifdefs.
Have you tried to build an image with your requests? Are you getting improves in the features? Or mweal was right about removing the Arduino specs?
No, I have not tried anything yet. Right now I am trying to understand why SPI is busted on Arduino board with newer release. Like 1 byte gets swallowed at start of section after a lull of output.
guessing maybe autosuspend code added?
I believe the "1 byte gets swallowed at start of section after a lull of output" is a delay caused by an unresolved issue. Take a look at http://www.intel.com/support/edison/sb/CS-035253.htm http://www.intel.com/support/edison/sb/CS-035253.htm and let me know if your issue can be described as "issue 2033"
i am pretty sure that error mentioned in release notes is about how slow spi is. Most likely talking about the very large time delay between calls to do the transfer. Could also be about delay between bytes. No fifo or dma buffering?
The new issue has to do that power management calls were added to driver and I believe that the image will suspend spi device if no calls for some time, which I think is 50ms. When the next transfer happens it resumes the device, and during the resume it loses at least the first character. I have hacked the driver to change timeout to several seconds, which appears to get my test apps to work. More details in thread . Note I no very very little about pm system, but I think there should be some mechanism, that when device resumed the system, can delay some time for device to resume...