I have a strange problem.
A few months back I wrote a piece of code that used the ILI9341_due library to draw on a classic Ebay 2.4″ SPI TFT.
It compiled without problem on the compatible Arduino IDE of the time (1.6.5 or something like that) and ran on a blue pill.
Here is my code’s first few lines:
#include "Arduino.h"
#include <SPI.h>
//#include <ILI_SdSpi.h>
//#include <ILI_SdFatConfig.h>
#include <ILI9341_due_gText.h>
#include <ILI9341_due.h>
#include "fonts\MS_Sans_Serif_25.h"
#define TFT_DC PA15
#define TFT_CS PB4
#define rst PB3
// Use hardware SPI (on Uno, #13, #12, #11) and the above for CS/DC
ILI9341_due tft = ILI9341_due(TFT_CS, TFT_DC, rst);
ILI9341_due_gText t1(&tft);
char textBuff[20];
// Color set
#define BLACK 0x0000
#define RED 0xF800
#define GREEN 0x07E0
//#define BLUE 0x001F
#define BLUE 0x102E
#define CYAN 0x07FF
#define MAGENTA 0xF81F
#define YELLOW 0xFFE0
#define ORANGE 0xFD20
#define GREENYELLOW 0xAFE5
#define DARKGREEN 0x03E0
#define WHITE 0xFFFF
uint16_t color;
uint16_t colorFONDO=BLACK;
String serialin;
String pch;
char str[600];
char tmp[40];
#define MAX_STRING_LEN 600
<snip .... snip>
#include "pins_arduino.h"use the one with _STM in its name, I think that one still compiles and works.
We should really test the older examples and remove any that no longer work with our current codebase
Anyway, thank you all for your help. Everything compiles just fine now. 
It looks like the issue is that both the Touch library and also the Due ILI9341 library are both including pins_arduino.h
The issue is mainly the lib its self and not all the examples use the Touch library
Anyway. I’ve commented out the offending lines, and I’ve pushed an update to to github
utftDemo on IDE 1.6.12 with current Arduino_STM32 (master branch) compiles with no errors but the code doesn’t run (or the TFT doesn’t initialize properly – I’m not sure). I just get a static pattern of alternating black & white vertical lines.
utftDemo on IDE 1.6.5-r2 with Arduino_STM32 downloaded from github at April 11, 2016 works just fine.
Everything else is the same (same PC, same blue pill & TFT).
There definitely was an issue with the pins_arduino stuff, but I’m not sure why we even bother keeping the Due code in the example as its not really relevant now the other examples for ILI9341 are working
They all compile just fine but do not run.
Looking at my serial port, when I ran Adafruit_ILI9341_STM/stm32_graphicstest all I got was:
ILI9341 Test!
Display Power Mode: 0x0
MADCTL Mode: 0xDE
&
I also encountered the same crashes but could debug the ELF file with Rowley Crossworks.
The problem is with the F() macro that is used by the Arduino to access strings in Flash.
C:\Users\David\Documents\Arduino\hardware\Arduino_STM32-master\STM32F1\cores\maple\WString.h
class __FlashStringHelper;
#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))
On ARM processors you use the normal C language principals like const to achieve the same thing in a more oortable manner
void setup()
{
char message[40];
delay(5000);
Serial.begin(9600);
Serial.println("Hello Serial");
delay(5000);
strcpy(message, (const char*)F("Flash Message copied to SRAM"));
Serial.println(message);
delay(5000);
Serial.println(F("Flash Message"));
delay(5000);
Serial.println("Are we still alive?");
}
void loop()
{
}
OK. i thought our print.cpp was the same as the Arduino SAM version, but it looks like this is not the case?
like
tft.print(F(“test”));
after I download and install new version Arduino_STM32
———————————–
#undef F
#define F(x) x
return print(reinterpret_cast<const char *>(ifsh));![[SOLVED] Discovery STM32F100RB — Trouble with timers and library structure](https://sparklogic.ru/wp-content/uploads/2019/11/st-stm32vl-discovery-90x90.jpg)
