AceRoutine with SPI communications

[andrewspeirs]

Great library and easy to use.
However I encountered a problem trying to use the coroutine to communicate with LS7366R chip (quadrature encoder counter) that uses SPI communication. I wonder if you've every tried SPI communications with AceRoutine?
I've created a class for my sensor and it works fine when it is not a coroutine i.e. I can get the count. However when I created a CoroutineEncoder class derived from Coroutine I always get a return value of 0. The basic procedure to get the count is to send a command via (simplified, see full code below):

SPI.transfer(0xE8)
// brief delay required by LS7366r (minimum is 120 ns)
COROUTINE_DELAY_MICROS(1)
//then receive the count
count = SPI.transfer(0x00) //repeat a few times, then combine with bit-shift and OR'ing; input argument here is ignored

This is used with another coroutine that makes use of COROUTINE_DELAY() to control the speed of a stepper motor (which works really well), so I don't want any of these delays to be blocking.

Here is the header file:

#include <Arduino.h>

#include <AceRoutine.h>

using namespace ace_routine; 

class CoroutineEncoder: public Coroutine {
  public:
  CoroutineEncoder(uint16_t CSPIN);

  void ClearCount();

  void Configure();

  int runCoroutine() override;

  //return displacement in mm
  float GetDisplacement() {return count * 0.003125;}

  //return the current count
  long GetCount() {return count;}

private:
  uint16_t m_csPin;
  unsigned int count0, count1, count2, count3;
  long count;

}; //class CoroutineEncoder

#endif

And the coroutine in the .cpp file:

#include "CoroutineEncoder.h"
#include <SPI.h> //standard arduino library

SPISettings settings(5000000,MSBFIRST,SPI_MODE0);

using namespace ace_routine;

/* some config routines omitted */

int CoroutineEncoder::runCoroutine() {

  COROUTINE_BEGIN();
  SPI.beginTransaction(settings);
  digitalWrite(m_csPin, LOW);
  
  SPI.transfer(0xE8); //load count into OTR
  digitalWrite(m_csPin,HIGH);
  
  COROUTINE_DELAY_MICROS(1); //120 ns minimum before pulling chip select LOW again
  
  //read the OTR
  digitalWrite(m_csPin, LOW);
  SPI.transfer(0x68);
/*****Next four lines all return 0 when inside the runCoroutine, but work normally when not inside*********/
  count0=SPI.transfer(0x00);
  count1=SPI.transfer(0x00);
  count2=SPI.transfer(0x00);
  count3=SPI.transfer(0x00);
  digitalWrite(m_csPin,HIGH);

  SPI.endTransaction();

 // Calculate encoder count
  count = (count0 << 8) + count1;
  count = (count << 8) + count2;
  count = (count << 8) + count3;
  
  COROUTINE_END();
    
} //runCoroutine()

Execution leaves the runCoroutine and later returns at the COROUTINE_DELAY_MICROS, and this is between the SPI.beginTransaction() and SPI.endTransaction(). Does this somehow interfere with SPI functionality? Currently there are no other SPI communications in my system. Have you (or anybody else) had any success using SPI with AceRoutine? The coroutine may not be necessary for such a short delay time, but I'm trying to understand why SPI isn't working within the runCoroutine? Any ideas would be appreciated. In case it matters, I'm using the the Metro M4 Grand Central (SAMD51) and the Arduino IDE. Thanks.

[bxparks]

Hi, I've never tested AceRoutine on a SAMD51, so I'm just guessing, but here are some thoughts:

1. Have you tried actually benchmarking the speed of digitalWrite() on the SAMD51? On most (all?) Arduino platforms, digitalWrite() is incredibly inefficient. On a 120MHz Cortex-M4, I'm going to guess that it takes about 1 us. So if you need only a 120 ns delay, you shouldn't need any delay at all.
2. The context switch time of COROUTINE_DELAY_MICROS() is between 0.4 microseconds to 1 microsecond. So a COROUTINE_DELAY_MICROS() of 1 microseconds will be very inaccurate.
3. I assume that you understand that AceRoutine is a cooperative multi-tasking library. Calling COROUTINE_DELAY_MICROS(N) does not guarantee that the delay will be exactly N microseconds, as I tried to explain in USER_GUIDE.md#Delay. The execution flow transfers to your other coroutines, and if they take 1000 microseconds, then the COROUTINE_DELAY_MICROS() will not return for 1000 microseconds.

So to answer your question about using AceRoutine inside an SPI transaction, I have never done that because AceRoutine cannot guarantee the timing delays due to the interaction with other coroutines. I have always used delayMicroseconds() directly inside such time sensitive loops. If you only need a delay of 120 ns, it seems like you should just use delayMicroseconds(1).

I scanned your code to see if there are any other interaction between AceRoutine and the SPI transactions. Nothing obvious stood out for me. My guess is that the COROUTINE_DELAY_MICROS(1) is just taking too long and your peripheral is timing out. But it's possible there's something else..

[andrewspeirs]

Thanks for the response and the timing explanations, and yes I understand with the cooperative part that timing is not guaranteed. I was just trying to understand why the count0=SPI.transfer(0x00) etc always return 0 when used inside the coroutine but work correctly outside it. The datasheet for the peripheral indicates a minimum time for the chip select pulse widths, but not maximum so I don't think the chip times out (I admit this is not my area of expertise). Once I have time I'll investigate whether the SPI library has any timeout. For now I'm using this peripheral without the coroutine. Thanks again.

[bxparks]

You might consider hooking up a logic analyzer to see exactly what is being sent or received, and the timing of those signals. I once spent 4 hours tracking down an SPI problem on the ESP32. The code worked on all other microcontrollers, except for the EPS32. I spent 3.5 hours blindly recompiling different things in an attempt to narrow down the problem. Once I hooked up the logic analyzer, I could see that I was sending nothing out through the SPI pins. That quickly allowed me to figure out the relevant code wasn't even being compiled, which led me to find the one-character typo that conditionally disabled that entire section of the code.

[andrewspeirs]

I tried out the logic analyzer and discovered I was just missing the SPI transaction. I was using the one-shot form of coroutine (_BEGIN() and _END() ). I switched to a COROUTINE_LOOP() and it works as expected. I don't really need this part to be a coroutine, but it's nice to know I could get it to work. The library is still useful for other parts of my project though i.e. controlling the step timing of a stepper motor without blocking everything else, although I suppose I could use a timer interrupt instead.
I also tested the timing of digitalWrite on this board: 0.4 us (400 ns), for anyone who is interested. Thanks for your input.