Compilation error: "wiring_private.h: No such file or directory"

Official Hardware Classic UNO R4 Minima
1

More compile problems with R4 MINIMA
Here's the compiler message for a sketch that includes a TFT SPI display and a couple of I2C devices. I won't give the code here because it's kind of long, but it compiles and runs perfectly well on an UNO R3. I've never seen this message before! What/where is "wiring_private"?? and what is the R4 looking for that R3 isn't??

1884×209 10.9 KB

1 Like
2

This one is expected rather than a glitch in the build system as was the case with your previous compilation error.

It is a file that happens to be present in certain Arduino cores. For example:

As the "private" in the name indicates, it was not intended to be part of the public API of the core, but unfortunately an #include directive for the file was added to the "Adafruit ILI9341" library anyway. The "Arduino UNO R4 Boards" platform does not contain a file of this name, so any code that contains an #include directive for the file will fail to compile.

You could probably fix the library by doing the following:

  1. Use any text editor to open the Adafruit_ILI9341.cpp file at the path shown in the error message.
  2. Change lines 52-54 from this:
    #ifndef RASPI
#include "wiring_private.h"
#endif
    to this:
    #if defined(__has_include)
#if __has_include("wiring_private.h")
#include "wiring_private.h"
#endif  // __has_include("wiring_private.h")
#else  //defined(__has_include)
#include "wiring_private.h"
#endif  //defined(__has_include)
  3. Save the file.

I don't have an ILI9341 display on hand so I didn't test the runtime functionality of the library with that change, but it does at least compile now so it's worth a try.

2 Likes
3

Once again you have solved what was for me an unsolvable problem! Out of all the hundreds of UNO R3 sketches I have written, to test my new R4 MINIMA I just happened to pick one using the ILI9341! I'm on the Adafruit forum, so I will pass along this fix. I think it would be naive to think that similar problems won't occur with some of their other software libraries, too. If so, I will let you (and them) know. Thanks again!

1 Like
4

Note: this will probably happen with many other libraries.

For example, I fixed one in the Adafruit ST7735/89 library last week:
Support the new Arduino UNO-R4 boards by KurtE · Pull Request #187 · adafruit/Adafruit-ST7735-Library (github.com)
Although they still have not merged it in.

Personally, I believe Arduino should simply add that file to the core, even if it is empty, as to avoid having to fix a lot of different libraries.

But...

1 Like
5

Does this work? I know I tried something similar with a sketch and it would never include that file, unless some other file included it.
Wish there was a way to optionally include a library in a sketch if I have it installed · Issue #1650 · arduino/arduino-cli (github.com)

6

Yes, this fix worked with my sketch that uses Adafruit's 2.2" TFT display. Probably there will be similar problems with other Adafruit libraries.

7

If there is a fix on Arduino's end, to avoid these problems with other libraries, I certainly hope that they do what you have suggested!

8

This is just a question rather than a problem. :slight_smile: Here's some of the devices used in the code with the problem you recently fixed:
#include <Wire.h>
#include "U8x8lib.h"
U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8(/* reset=*/ U8X8_PIN_NONE);
#include <Adafruit_GFX.h> // core graphics library
#include <Adafruit_AS7341.h>
Adafruit_AS7341 as7341;
uint16_t readings[12]; // raw data
#include <Adafruit_ILI9341.h>

Here are the compile results. I was surprised to see the huge difference between the compiled code size for an R3 as opposed to an R4 MININA. Can you explain why?
R3:

R4 MINIMA

9

You are welcome. I'm glad it is working now.

There is a nice explanation here:

10

It does work to skip the #include if the file is not present in the core. However, it might be that in some cases the fix is not so easy as simply skipping the #include directive and instead some changes to the code/alternative #include directive is needed to replace whatever the library was depending on from wiring_private.h.

There is a possible corner case:

  • The core of the board being compiled for does not contain wiring_private.h
  • The toolchain for the board being compiled for does not support __has_include

In the fallback for compilers that don't support __has_include (which is tested for with #if defined(__has_include)), I chose to unconditionally #include wiring_private.h. I'm not aware of such a board but I didn't do a comprehensive survey. I only checked that it works as expected when compiling for UNO R4 Minima and AVR boards. It was intended as more of a quick patch for @brooksdr rather than a something that ready to ship to all users of the library. The patch could have even been as simple as removing the #include directive entirely, but I thought I'd make at least some effort to retain compatibility with other boards @brooksdr might be using the library with.

__has_include will work if the path where the file is expected to be is already in the the compiler's "search path". The path of the core is always in the search path so this does work for wiring_private.h. The situation is different with files from libraries because the library source folder path is only added to the search path after the library is discovered by the Arduino build system through the first #include directive for a header file from the library. So you have a "catch 22" situation with libraries. It is possible to use it with additional header files present in a library if a previous #include directive already triggered the discovery of the library.

For example, if you have a library with header file FooLib.h, the conditional in this sketch will never evaluate as true:

#if __has_include(<FooLib.h>)
#include <FooLib.h>
#endif
void setup() {}
void loop() {}

but if the library has an additional header file FooLibAdditional.h, the conditional in this sketch will work as expected:

#include <FooLib.h>
#if __has_include(<FooLibAdditional.h>)
#include <FooLibAdditional.h>
#endif
void setup() {}
void loop() {}
1 Like
11

Hi @ptillisch - thank you for this fix.
My project is based on an Adafruit 2.8" TFT Touch Shield with Capacitive Touch (Product ID: 1947) using their Adafruit_ILI9341 library which has the same wiring_private.h error.

After manually making your change sketches now compile and work, although graphics functions have become painfully slower.

Their example graphicstest benchmark on the Uno R4 WiFi results:

  • ILI9341 Test!
  • Display Power Mode: 0xCA
  • MADCTL Mode: 0x24
  • Pixel Format: 0x2
  • Image Format: 0xC0
  • Self Diagnostic: 0xE0
  • Benchmark Time (microseconds)
    -- Screen fill 9287327
    -- Text 375059
    -- Lines 3616244
    -- Horiz/Vert Lines 752839
    -- Rectangles (outline) 479038
    -- Rectangles (filled) 19277057
    -- Circles (filled) 2049134
    -- Circles (outline) 1582727
    -- Triangles (outline) 837282
    -- Triangles (filled) 6189230
    -- Rounded rects (outline) 899737
    -- Rounded rects (filled) 19156685
  • Done!

Versus ~3x to ~6x faster on an R3:

  • ILI9341 Test!
  • Display Power Mode: 0x94
  • MADCTL Mode: 0x48
  • Pixel Format: 0x5
  • Image Format: 0x80
  • Self Diagnostic: 0xC0
  • Benchmark Time (microseconds)
    -- Screen fill 1496764
    -- Text 154492
    -- Lines 1268800
    -- Horiz/Vert Lines 125416
    -- Rectangles (outline) 82808
    -- Rectangles (filled) 3107200
    -- Circles (filled) 465852
    -- Circles (outline) 541564
    -- Triangles (outline) 281660
    -- Triangles (filled) 1339908
    -- Rounded rects (outline) 243748
    -- Rounded rects (filled) 3132652
  • Done!

I can only guess the speed difference is an SPI issue, but not sure where or how to report that.

The touchscreen is working fine over I2C though, so one step close.

12

The subject is discussed here:

And work to improve the performance is in the final stages here:

You could test it out by copying the SPI library from the pull request staging branch here:

to a libraries/SPI subfolder under your sketchbook folder and then uploading the sketch once again. Or you can wait for the next release of the "Arduino UNO R4 Boards" platform, which will probably include that improvement to the SPI library.

1 Like
13

Hi @ptillisch - please keep in mind I have very little knowledge of this stuff, but I followed your great instructions for the SPI library and it increased performance beyond the old UNO...

  • ILI9341 Test!
  • Display Power Mode: 0xCA
  • MADCTL Mode: 0x24
  • Pixel Format: 0x2
  • Image Format: 0xC0
  • Self Diagnostic: 0xE0
  • Benchmark Time (microseconds)
    -- Screen fill 1234857
    -- Text 77562
    -- Lines 743642
    -- Horiz/Vert Lines 101676
    -- Rectangles (outline) 65668
    -- Rectangles (filled) 2564033
    -- Circles (filled) 317852
    -- Circles (outline) 323277
    -- Triangles (outline) 167711
    -- Triangles (filled) 858330
    -- Rounded rects (outline) 158716
    -- Rounded rects (filled) 2563049
  • Done!
14

Good news! I'm glad you were able to install the beta version of the SPI library and that the results were good.

1 Like
15

I've the same Problem with Adafruit TFT ILI 9341 and Arduino R4 Wifi.

Arduino IDE 2.3.2, all libraries up to date
I am using the Sketch Graphic Test and get the following error messages:

..\Adafruit_TFTLCD_Library\pin_magic.h:467:2: error: #error "Board type unsupported / not recognized"

..\Adafruit_TFTLCD_Library\Adafruit_TFTLCD.cpp:19:10: fatal error: wiring_private.h: No such file or directory
#include "wiring_private.h"

Despite many attempts and changes to the .cpp, this error remains

16

Hi @mark_xo.

As indicated by that error, this library has a fundamental lack of support for the UNO R4 WiFi board, so it is not something that can be fixed easily.

A library that only uses the high level Arduino core API can work with most any Arduino board without the need to add code specific to a given target. However, other libraries contain lower level code that is specific to the architecture of the boards the library author was targeting. That low level code needs to be written for each board that the library supports, so if the library author didn't add code for the board you are using, then it is simply impossible to use the library. That is the case with "Adafruit TFTLCD Library". The library author only added the low level code for the AVR architecture of the classic Arduino UNO R3 (and the rest of the AVR boards), and the Arduino Due.

The library was written long before the introduction of the UNO R4 WiFi board so no low level code was added for that target, and the library has been unmaintained for the last four years so I don't think there is any hope that support will be added to it. You should find another library.

Why are you using the Adafruit TFTLCD Library? If you read this forum thread then surely you are aware that there is a "Adafruit ILI9341" library that can be used with the UNO R4 boards after a minor modification. So why aren't you using the "Adafruit ILI9341" library?

17

Why are you using the Adafruit TFTLCD Library ? If you read this forum thread then surely you are aware that there is a "Adafruit ILI9341 " library that can be used with the UNO R4 boards after a minor modification. So why aren't you using the "Adafruit ILI9341 " library?

I went to the Adafruit site, tried the tutorial and it didn't work.
It's because I've been programming with the Arduino for many years, but I'm too stupid to reprogramme any drivers.
Not even this example worked for me:

Sorry

18

After looking at the two libraries, I see now that each is for a distinct type of display hardware. The "Adafruit ILI9341" library is for displays that are connected to the Arduino board via the SPI bus (like this one), while the "Adafruit TFTLCD Library" is for displays that use an 8-bit parallel connection to the Arduino board (like this one).

So I understand now that the two libraries are not interchangeable.

Which exact display hardware are you using? You can post a link to the product page on the website you bought it from. That will give the forum helpers some valuable information that could be used to provide you with more effective assistance.

19

I am guessing it is for the WHADDA one?

The posting above has link in it to product page:

Aargh - I really wish Arduino would do like some other board manufactures have done, and do simple things (even if it is a kludge), that help improve the ease of adoption.
And for example include a dummy wiring_private.h file in their cores...
Maybe have it output a #warning or the like, but...

20

This is breathtaking, What an amazing fix to my problems. Will be making a pull request for this library that I'm using so that others don't face the problems we faced.