Compile problem with ILI9341_due

Dimdim
Fri Oct 28, 2016 3:59 pm
Hi guys,

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>


Manny
Fri Oct 28, 2016 7:18 pm
Far from an expert but try and comment out
#include "pins_arduino.h"

RogerClark
Fri Oct 28, 2016 8:15 pm
That example may no longer compile.

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


martinayotte
Fri Oct 28, 2016 8:23 pm
The problem is as @Manny mentioned, I remember that was the issue last summer :

http://www.stm32duino.com/viewtopic.php … =30#p16026


Dimdim
Sat Oct 29, 2016 9:30 pm
Funny, I actually read through that thread and saw that post but didn’t realize that that fixed the problem. My bad!

Anyway, thank you all for your help. Everything compiles just fine now. :)


RogerClark
Sat Oct 29, 2016 10:43 pm
Guys

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


Dimdim
Sun Oct 30, 2016 1:41 am
I may have spoken too soon.

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).


RogerClark
Sun Oct 30, 2016 7:47 am
Which example is that ?

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


Dimdim
Sun Oct 30, 2016 1:27 pm
I’ve tried examples Adafruit_ILI9341_STM/graphicstest, ILI9341_due_STM/graphicstest, ILI9341_due_STM/utftDemo, Adafruit_ILI9341_STM/stm32_graphicstest, etc.

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
&


david.prentice
Wed Nov 16, 2016 9:15 am
I have just installed the current stm32duino to my v1.6.12 IDE and am running a NUCLEO-F103 board.

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)))


RogerClark
Wed Nov 16, 2016 7:35 pm
The F macro is just a shortcut for the progmem stuff required because of the AVR archteicture.

On ARM processors you use the normal C language principals like const to achieve the same thing in a more oortable manner


david.prentice
Thu Nov 17, 2016 6:58 pm
I wrote a little test sketch:
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()
{
}


RogerClark
Thu Nov 17, 2016 9:37 pm
David

OK. i thought our print.cpp was the same as the Arduino SAM version, but it looks like this is not the case?


VadimEL
Tue Nov 29, 2016 12:01 pm
same problem, program freez on F()

like

tft.print(F(“test”));

after I download and install new version Arduino_STM32
———————————–
#undef F
#define F(x) x


danieleff
Tue Nov 29, 2016 12:12 pm
Changing line 46 in Print.cpp from
return print(reinterpret_cast<const char *>(ifsh));

stevestrong
Tue Nov 29, 2016 12:33 pm
I made an issue on github, check it out here.

Leave a Reply

Your email address will not be published. Required fields are marked *