We're doing a little testing with the SPI 0 controller on the expansion board. The current environment is Windows 10 IoT Core and Visual Studio 2015 with C++/CX for the application development. If we run the following code:
# define SPI_CS_FLASH 0
# define SPI_FQ_FLASH 25000000
m_pSpiSettingsFlash = ref new Windows::Devices::Spi::SpiConnectionSettings(SPI_CS_FLASH);
m_pSpiSettingsFlash->ClockFrequency = SPI_FQ_FLASH;
m_pSpiSettingsFlash->Mode = Windows::Devices::Spi::SpiMode::Mode0;
Platform::String ^pDeviceSelector = Windows::Devices::Spi::SpiDevice::GetDeviceSelector();
Windows::Devices::Enumeration::DeviceInformationCollection ^pDeviceInformationCollection = concurrency::create_task(Windows::Devices::Enumeration::DeviceInformation::FindAllAsync(pDeviceSelector)).get();
m_pSpiFlash = concurrency::create_task(Windows::Devices::Spi::SpiDevice::FromIdAsync(pDeviceInformationCollection->GetAt(0)->Id, m_pSpiSettingsFlash)).get();
unsigned __int8 ui8 = 0xAA;
unsigned __int16 ui16 = 0xAAAA;
unsigned __int32 ui32 = 0xAAAAAAAA;
Platform::ArrayReference ui8Array(reinterpret_cast(&ui8), sizeof(ui8));
Platform::ArrayReference ui16Array(reinterpret_cast(&ui16), sizeof(ui16));
Platform::ArrayReference ui32Array(reinterpret_cast(&ui32), sizeof(ui32));
we get extremely slow performance. We're looking for roughly 100 times faster than what we're getting. Is the code wrong, the underlying C++/CX code this slow, the driver this slow, or the hardware not capable?
Here is an image from our scope capturing the results of lines 21 and 22 in the above code:
The amount of time between FS0 going low and the first clock (on each write) is baffling. The amount of time after the last clock (on each write) and FS0 going high is baffling. And finally the amount of time between the two writes is potentially baffling (lots of software layers to go through will certainly contribute to this timing). Can this be sped up?
This issue seems to exist on the Linux side as well.
By default, the SPIDEV driver & and spidev_test.c seems to be capped at 1MHz clock rate. Setting the speed below this seems to work fine. Setting clock rates above 1 MHZ are set to 1MHz. This is well short of the 25MHz clock rate listed in the Datasheet.
If the driver is capped at 1MHz, capture and verify the fastest rate you can get with the driver you have installed. And then modify the driver, if possible and or required, to increase the speed.
Create a simple test to transmit only one burst with a couple of Known Diags characters (0xA5, or 0xC3 are goos identifiable patterns).
take the clock speed down to 500KHz for simplicity
use the logic analyzer to capture the Chip select, clock, and data. Zoom in if needed
measure the period for the clock to verify speed is correct.
verify the data in MISO and MOSI are correct (what was expected based on diag test data.
If all looks good increase the clock speed, and perform additional testing.
If you can get a short burst at 25MBits/Second to look good, then multiple transmissions maybe optimized capable and or optimized with the higher level thread priority, system architecture, and or API interface calls (buffer size).
That sounds good in theory. A quick glance into the code, and my immediate reaction is this may be a lot easier if there was some documentation that outlined the configuration registers used to set up the peripheral within the module. Actually, a reference manual for the entire processor that includes detailed description of all the configuration registers would be useful. . From a hardware perspective, some timing diagrams or charts with information such as setup and hold times would also be nice
very true, the documentation is limited.
Is it fair to say that this SPI interface is in the Quark device? And if that is the case, have you been able to locate the source code for the Quark device to access the registers (and analyze the driver code)?
Then "Intel System Studio for Microcontrollers" IDE, may provide the tools to modify and build the SPI interface, and enhance/refine the driver.
To Intel: Where does the Quark software reside to review and use?
Thanks for contacting us!
We are aware of the need to have more documentation of the Joule available soon, also that other users are asking for it as well. We would like to let you know that our team in charge is working on it. Additionally, we would like to thank you for your suggestions, we will pass all of them to our respective team.
Moreover, we would like to let you know that the Joule doesn't have a Quark, however, in case you are interested in the Quark on the Edison, you can find the information available here: https://software.intel.com/en-us/creating-applications-with-mcu-sdk-for-intel-edison-board Creating applications with the MCU SDK for the Intel® Edison board: Overview. For Edison questions, we'd suggest to post them here: /community/tech/edison Intel Edison Community.
Also, we are aware of the new thread opened (/thread/110354 Slow clock rate for SPI peripheral on J12 in Linux) and we will reply soon.