Status of libraries that include libraries
38 views
Skip to first unread message
Rick Anderson
Sep 7, 2015, 11:13:11 AM9/7/15
to Arduino Developer's List
Hi All,
I've started poking at this issue again. I've been trying to convert several libraries to use hardware SPI for displays. Everyone seems to implement their own version of SPI inside of a library because they can't include SPI.h from inside a library. Has this been resolved?
```example
Documents/Arduino/libraries/Adafruit_SHARP_Memory_Display/Adafruit_SharpMem.cpp:21:17: fatal error: SPI.h: No such file or directory
#include <SPI.h>
^
```
I just went back a looked at the issue and couldn't find the status. I'm willing to help it's still on the todo list.
Pontus Oldberg
Sep 7, 2015, 11:18:44 AM9/7/15
to devel...@arduino.cc
Isn't the solution to that problem simply including spi.h in the sketch as well!?
> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
Rick Anderson
Sep 7, 2015, 11:30:27 AM9/7/15
to Arduino Developer's List
Not for this problem, because the problem I'm trying to fix is that library authors have created a software implementation of SPI and did not use the Arduino hardware SPI or an SPI object that could be software or hardware. This usually means writing non portable AVR code based SPI implementations. Because you can't include SPI.h in a library directly.
Matthijs Kooijman
Sep 7, 2015, 12:13:35 PM9/7/15
to devel...@arduino.cc
Hi Rick,
> Not for this problem, because the problem I'm trying to fix is that library
> authors have created a software implementation of SPI and did not use the
> Arduino hardware SPI or an SPI object that could be software or hardware.
> This usually means writing non portable AVR code based SPI implementations.
> Because you can't include SPI.h in a library directly.
My suspicion is that these libraries have their custom implementation
for other reasons, such as performance or atomicity.
As mentioned, if a library wants, it can use the regular SPI library
just fine, they just have instruct their users to include SPI.h in the
main sketch. Since this isn't entirely unreasonable (needs to be fixed,
though), I suspect this is not the reason why libraries implement their
own. I might be wrong though - perhaps you should ask the library
authors for their reasoning?
Gr.
Matthijs
> Not for this problem, because the problem I'm trying to fix is that library
> authors have created a software implementation of SPI and did not use the
> Arduino hardware SPI or an SPI object that could be software or hardware.
> This usually means writing non portable AVR code based SPI implementations.
> Because you can't include SPI.h in a library directly.
for other reasons, such as performance or atomicity.
As mentioned, if a library wants, it can use the regular SPI library
just fine, they just have instruct their users to include SPI.h in the
main sketch. Since this isn't entirely unreasonable (needs to be fixed,
though), I suspect this is not the reason why libraries implement their
own. I might be wrong though - perhaps you should ask the library
authors for their reasoning?
Gr.
Matthijs
Rick Anderson
Sep 7, 2015, 1:14:16 PM9/7/15
to devel...@arduino.cc
I figured the developer list would be a good place to ask. Anyone working with the DUE or an alternative platform should be familiar with the problem.
Since SPI and similar libraries are a communication protocol I usually encapsulate the protocol and expose specific features to the user. Including it in the main sketch breaks that encapsulation.
--Rick
Paul Stoffregen
Sep 8, 2015, 11:05:13 AM9/8/15
to devel...@arduino.cc
On 09/07/2015 10:14 AM, Rick Anderson
wrote:
I figured the developer list would be a good place to ask. Anyone working with the DUE or an alternative platform should be familiar with the problem.
Yes, I'm very familiar with these problems. I've spent a *lot* of
time crafting workarounds and compatibility layers and some
downright ugly hacks to make ARM-based Teensy work with many poorly
designed libraries.
Much of the 3rd party library code out there is very old, pre-dating SPI transactions, or even the SPI library at all. Today many of the commonly used libraries are written with the narrow focus of support sales of a specific peripheral. There's a strong tendency to minimize development cost by copying old code (for each new peripheral), even if it's known to have limitations. Dozens or even hundreds of copies of similar but not-quite-identical old code creates a high barrier to updating to the newer APIs. Slow sales on older products really drains enthusiasm for updating older library code, but not for copying it to develop support for newer products!
Unfortunately, migrating to newer APIs and hardware neutral techniques takes a very long time. This is true not only for 3rd party libraries, but for Arduino itself. We collectively spent over a year discussing and then delaying SPI improvements. The website was only very recently updated to recommend actually using the new API. It's hard to fault 3rd party library authors for not adopting it yet.
Much of the 3rd party library code out there is very old, pre-dating SPI transactions, or even the SPI library at all. Today many of the commonly used libraries are written with the narrow focus of support sales of a specific peripheral. There's a strong tendency to minimize development cost by copying old code (for each new peripheral), even if it's known to have limitations. Dozens or even hundreds of copies of similar but not-quite-identical old code creates a high barrier to updating to the newer APIs. Slow sales on older products really drains enthusiasm for updating older library code, but not for copying it to develop support for newer products!
Unfortunately, migrating to newer APIs and hardware neutral techniques takes a very long time. This is true not only for 3rd party libraries, but for Arduino itself. We collectively spent over a year discussing and then delaying SPI improvements. The website was only very recently updated to recommend actually using the new API. It's hard to fault 3rd party library authors for not adopting it yet.
Since SPI and similar libraries are a communication protocol I usually encapsulate the protocol and expose specific features to the user. Including it in the main sketch breaks that encapsulation.
Yes, it's still very difficult to make non-AVR boards work for
nearly all Arduino compatible products. I'm sure Arduino must be
feeling this pain with Zero and Due. The closer you interact with
real users trying to get their projects working, the more evident
the many problems are.
Many times I've argued here for improving and adding APIs for hardware independence. That too is a very long and slow and difficult process, with only limited success over the last few years. I wish it were easier.
Many times I've argued here for improving and adding APIs for hardware independence. That too is a very long and slow and difficult process, with only limited success over the last few years. I wish it were easier.
Rick Anderson
Sep 8, 2015, 6:46:53 PM9/8/15
to Arduino Developer's List
By allowing libraries to include libraries there would less need to place files like:
wiring_*
Udp.h
IPAddress.cpp
IPAddress.h
IPAddress.cpp
IPAddress.h
In the Arduino Core. This would be really helpful for code portability. Currently, many objects are stuffed into the core just so there is access to libraries.
Paul Stoffregen
Sep 8, 2015, 7:42:17 PM9/8/15
to devel...@arduino.cc
Yes, header files are an issue.
Headers are serious long-term issue brewing for Arduino as a platform. I doubt there's much will to tackle this now, with all the legal distractions and new stuff in still-private development.
A proactive, forward-thinking plan for Arduino as a microcontroller platform should involve an attempt to standardize the header file names published by core libraries. Ideally, a way for core library developers to use headers inside the core library, without exposing them to sketches and other libraries would also be good design.
A *really* proactive approach would involve code in the IDE to enforce the core library header names, to give a warning or error when any core library publishes header files it shouldn't.
A reactionary approach would be to ignore the many differences between Arduino's own cores, not to mention the many 3rd party ones, until problems become widespread. For example, if a random library or even a complex sketch happens to have "RingBuffer.h" in its own code, it will be conflict-free when used with the common AVR boards like Arduino Uno & Leonardo. But when another user tries to compile that code for Arduino Zero or Due, they'll get an unpleasant surprise when RingBuffer.h from those cores is used, instead of the one from their sketch or some 3rd party library that's only ever been tested on AVR-based boards.
These types of long-term platform planning issues are really tough to invest engineering effort *before* they become ugly problems. But if anyone reads this and cares, hopefully you'll at least know this issue is lurking and likely to eventually come up as more official and 3rd party core libraries and regular libraries are published.
Headers are serious long-term issue brewing for Arduino as a platform. I doubt there's much will to tackle this now, with all the legal distractions and new stuff in still-private development.
A proactive, forward-thinking plan for Arduino as a microcontroller platform should involve an attempt to standardize the header file names published by core libraries. Ideally, a way for core library developers to use headers inside the core library, without exposing them to sketches and other libraries would also be good design.
A *really* proactive approach would involve code in the IDE to enforce the core library header names, to give a warning or error when any core library publishes header files it shouldn't.
A reactionary approach would be to ignore the many differences between Arduino's own cores, not to mention the many 3rd party ones, until problems become widespread. For example, if a random library or even a complex sketch happens to have "RingBuffer.h" in its own code, it will be conflict-free when used with the common AVR boards like Arduino Uno & Leonardo. But when another user tries to compile that code for Arduino Zero or Due, they'll get an unpleasant surprise when RingBuffer.h from those cores is used, instead of the one from their sketch or some 3rd party library that's only ever been tested on AVR-based boards.
These types of long-term platform planning issues are really tough to invest engineering effort *before* they become ugly problems. But if anyone reads this and cares, hopefully you'll at least know this issue is lurking and likely to eventually come up as more official and 3rd party core libraries and regular libraries are published.
Andrew Kroll
Sep 8, 2015, 8:33:55 PM9/8/15
to devel...@arduino.cc
This whole mess is why UHS 3.0 code just inlines in header files. By doing this ugly hack, compile-time options become possible, but it is at the expense of readability.
Reply all
Reply to author
Forward
0 new messages