Go Down

Topic: Using SPI in a custom class (Read 1 time) previous topic - next topic


Jul 01, 2014, 12:49 am Last Edit: Jul 01, 2014, 12:55 am by Poofjunior Reason: 1
Hi everyone,

I have a follow-up question to writing custom libraries that use the SPI library, originally started in this (read-only) topic:

It seems that the line
Code: [Select]
#include <SPI.h>
must be included if you're importing a custom library that also uses the SPI library.

Why isn't it sufficient to put that line in the header file of the custom library?  (Tried it already, but I still needed to import it from the ino file also...)
From a design perspective, why is this the case?
If I'm writing MyCustomLibrary, shouldn't the end-user of that custom library not need to know that it's using the SPI library?

I'm thinking of a scenario where a class might need to use SPI member functions, but not always, depending on how they use the library. Perhaps one situation needs an SPI interface, but another situation doesn't. Either way, to actually get the library to compile even when the SPI functions aren't used, you'd still need to import the SPI library in the .ino file.

Thanks for the input!


Hackscribble.  Writing about making things.
arduino@hackscribble.com | www.hackscribble.com


Ah, thanks Ray!

Ok, I've got a hack, but not a clean solution:

According to the link,
...the IDE scans the sketch for all headers that match files residing in the libraries folder, then it simply copies the library source files into the temporary location along with the sketch.

It looks like the IDE dumps everything in the custom library's directory though into the temporary folder.

Ok, so here's the hack: In my case, to include the SPI library in a sketch, I copy/pasted SPI.h  (header only) from Arduino's Github repo and put it in the same directory as my custom library.

Then, in my custom library header, I added
Code: [Select]
#include <SPI.h>, and the IDE went and found the real SPI source and included it.

I'm not completely sure why this works, if the library only scans for headers in the sketch, according to the link above....

So, this won't hold up against time if new functions are added to the SPI library, or if the names are changed.
Is there a better way to work around this?


I am not sure the hack is good if you use two libraries that both use spi. Will they occupy twice space on arduino? Take out calculator and watch compiled sizes. :)
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter


One quick update: I need to actually dump both the header and the CPP file into the same directory as my custom library. (Intuitively, this makes more sense, too.) The reason it was compiling earlier was because the only function I added from the SPI library into my custom library was SPI.transfer(byte), which is actually defined in-line in the header file.

Good call, liudr,

I tried to do some double-includes, but it seems ok. If I
Code: [Select]
#include <SPI.h>
and add a function call to
Code: [Select]
SPI.begin(), the code size only increases by 4 bytes, which seems to be enough for just a couple register writes. I think I also remember reading in the Arduino Build Process page on the main website that the compiler only adds in functions from a library that are actually used in the source.


Yes, only functions used are included. What if you did a more in depth test that has the standard spi library in use, and the hack version included and being used?

I suspect that whichever gets compiled later replaces the earlier one. Peek into temp folder with buildxxxxxxxxxxx folder, xxxxxxx for a very long number.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter

Go Up