DMA-based SPI on T3.2

Status
Not open for further replies.
G

gfvalvo

Well-known member
Hi all. I'm interested in doing some experiments with DMA SPI on the T3.2. I'm using Arduino 1.85 / Teensyduino 1.40. Looking in SPI.h and SPI.cpp, I see that there is a method that does the job. Its prototype is:
Code: 
bool transfer(const void *txBuffer, void *rxBuffer, size_t count,  EventResponderRef  event_responder);
However, due to conditional compilation, it's not available because the macro 'SPI_HAS_TRANSFER_ASYNC' is not defined. Looking in SPI.h, I see:
Code: 
#if defined(__has_include) && __has_include("EventResponder.h")
// SPI_HAS_TRANSFER_ASYNC - Defined to say that the SPI supports an ASYNC version
// of the SPI_HAS_TRANSFER_BUF
#define SPI_HAS_TRANSFER_ASYNC 1
#include <DMAChannel.h>
#include <EventResponder.h>
#endif
I do have "EventResponder.h" included in my code, and I think "__has_include" is true, but the required sections are still not being compiled. If I change the above conditional to:
Code: 
#if 1
// SPI_HAS_TRANSFER_ASYNC - Defined to say that the SPI supports an ASYNC version
// of the SPI_HAS_TRANSFER_BUF
#define SPI_HAS_TRANSFER_ASYNC 1
#include <DMAChannel.h>
#include <EventResponder.h>
#endif
then the sections compile and my DMA-based SPI experiment seems to work as expected.

I'd appreciate any insight in to this.

Thanks.
 
It should work... That test was put in, to handle the case where someone downloads the SPI library and uses it with an older version of Teensyduino that did not have the eventresponder.

Maybe try 1.41 or latest beta of Teensyduino?
 
My bad, the problem appears to be some weirdness with Eclipse / Sloeber.

The code compiles without complaint in Arduino IDE. However, Sloeber claims that the 'SPI_HAS_TRANSFER_ASYNC' macro is undefined and throws a compiler error when trying to use the method:
Code: 
bool transfer(const void *txBuffer, void *rxBuffer, size_t count,  EventResponderRef  event_responder);
Oddly, Sloeber still loads my DMA / SPI test code into the T3.2 and it runs correctly (just like with the Arduino IDE).

Kind of strange.
 
What I don't remember about Sloeber is does it use the Arduino compiler toolchain, or does it have it's own set of compilers? If it's own, maybe it does not support the __has_include

Which if supported allows you to detect if a header file exists or not, before you try to include it. Which tries to keep you from getting compile errors if you run the library on an older IDE that does not support the event responder.
 
Don’t know anything about Sloeber’s toolchain details. For whatever reason, its compiler (preprocessor?) has a slight “problem” with the version of the ‘__has_include’ macro that takes an argument (i.e. ‘__has_include(<EventResponder.h>)’). The code below runs on the T3.2 when compiled with EITHER Sloeber or Arudino IDE.

However, the Sloeber screen shows the associated ‘#if’ statements as failed (greys them out) and complains that it couldn’t resolve functinos ‘test2()’ and ‘test3()’. But, as I said, the compiled code it produces runs just fine.

Another interesting thing is that ‘__has_include(<EventResponder.h>)’ evaluates to true even if the ‘#include <EventResponder.h>’ line is left out (with either IDE).

Anyway, I’m happy that my DMA SPI experiment worked.

Thanks.
Code: 
#include <Arduino.h>
#include <EventResponder.h>

#if defined (__has_include)
void test1() {
	Serial.println("Conditional Test #1 - PASSED");
}
#if  __has_include(<EventResponder.h>)
void test2() {
	Serial.println("Conditional Test #2 - PASSED");
}
#endif
#endif

#if defined (__has_include) && __has_include(<EventResponder.h>)
void test3() {
	Serial.println("Conditional Test #3 - PASSED");
}
#endif

void setup() {
	Serial.begin(115200);
	delay(2000);
	Serial.println("Compiled in Sloeber");
	test1();
	test2();
	test3();
}

void loop() {
}
 
Sloeber (which is basically Eclipse with an Arduino plugin) is by default set up to use the same toolchain as the Arduino IDE. Thus, if 1) the Teensyduino plugin is correctly installed over Arduino AND 2) the private hardware and private library paths are correctly set is the Eclipse/Sloeber Arduino options settings, the toolchain use and the compile result are theoretically and most times in practice identical. There are only a few rare cases which I could see, where thanks to the underlying Eclipse C/C++ pre-build indexing system, compiling in Sloeber would not work while it would in the Arduino IDE. It seems like Arduino is more forgiving about lenient programming (nested includes, missing forward declarations and non volatile variables which need to be volatile are nice candidates for that) while Sloeber would only compile if the code is 100% correct in terms of C/C++ specifications.
 
Thus I was right suspecting the underlying C/C++ build system in Eclipse.

The Arduino part (Jantje's plugin) works surprisingly well, even the nightly builds.
 
Status
Not open for further replies.
Back
Top