Hi,
Im using the Seeeduiono XIAO and im working with the SPI bus. I’m getting incorrect behaviour on the Bus when doing an Transaction wich causes the SPI com to not work.
Here ist the code I use to read a register
uint8_t reg = 0x00; //WHO AM I
digitalWrite(PIN_SPI_CS, LOW);
SPI.beginTransaction(SPISettings(SPI_FREQ, MSBFIRST, SPI_MODE0));
SPI.transfer(((reg & 0x7F) | 0x80));
uint8_t val = SPI.transfer(0x00);
SPI.endTransaction();
digitalWrite(PIN_SPI_CS, HIGH);
This code does not work because the SPI Hardware seems to get reinitialized on call of beginTransaction. That leaves the SCK (blue in picture) pin floating for a while and together with the Pull up it raised to HIGH level. Chip Select yellow in picture
the following code on the other hand works but is not clean nor correct according to the arduino SPI convention
SPI.beginTransaction(SPISettings(SPI_FREQ, MSBFIRST, SPI_MODE0));
digitalWrite(PIN_SPI_CS, LOW);
SPI.transfer(((reg & 0x7F) | 0x80));
uint8_t val = SPI.transfer(0x00);
SPI.endTransaction();
digitalWrite(PIN_SPI_CS, HIGH);
The code at the beginning is working fine with for example an ESP32.
Hi save_jeff,
If you don’t need to change the SPI configuration, why not write beginTransaction() only once in setup()?
Hi msfujino.
For once I use multiple SPI Slaves on the same but with different configurations and second, it does not solve the general problem that the SPI implementation of the XIAO has unexpected behavior. This causes many SPI-based sensor libraries written for general Arduino not to work. For example, the Sparkfun Library for the ICM-20948 does not work with the XIAO despite using the general beginTransfer -> transfer endTransaction convention defined by Arduino.
Other Platforms like ESP32 work with the Library no problem.
In my case, i have a project that compiles for multiple Arduino-based processors. Here it result in extra #ifdef PLATFORM code to change the SPI interaction based on the used platform despite having the same functions.
Lastly, it causes young programmers getting into microcontroller programming to be needlessly discouraged because it does not work as defined and without an oscilloscope, they are just left frustrated. I can speed from personal experience here.
Hi save_jeff,
The problem is that the description has to be changed to suit the platform. I understand very well. I read XIAO’s SPI library and thought it might have something to do with being implemented using SERCOM.
On the other hand, using an oscilloscope and editor, I enjoy to analyze projects that don’t work and get them to work.