thinger-io / Arduino-Library

IOTMP Arduino Library for connecting devices to thinger.io #IoT
https://thinger.io
MIT License
111 stars 66 forks source link

Using Debug causes compiler errors #6

Closed dhunink closed 6 years ago

dhunink commented 7 years ago

Hi,

while playing around with Thinger.io a lot ore the past few days, I found a possible bug. I've spend several hours googling but I believe my level of knowledge of AVR behaviour is insufficient to really understand what's going on here.

Basically the situation is as follows:

Looking at the Thinger source code I believe some enhancements are possible; after reading a lot of other topics on other platforms the Serial.println(F()) statement comes up a lot. This one could be used differently to play nicer with the PROGMEM function. But again, this may be a complete misinterpretation since my leve of knowledge of deep-level-AVR-behaviour is not sufficient at this time.

For reference: here are the pieces of code and the compiler error. I'm very interested in further thoughts on this issue!

Compiler error one

error: WiFi_Logo_bits causes a section type conflict with __c
 const char WiFi_Logo_bits[] PROGMEM = {

Compiler error two

ThingerWifi.h:66:9: note: in expansion of macro 'THINGER_DEBUG_VALUE'
         THINGER_DEBUG_VALUE("NETWORK", "Got IP Address: ", WiFi.localIP());
         ^

Code added that causes the compiler errors, when Debug is enabled:

#define WiFi_Logo_width 60
#define WiFi_Logo_height 36

const char WiFi_Logo_bits[] PROGMEM = {
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0xFF, 0x07, 0x00, 0x00, 0x00,
  0x00, 0x00, 0xE0, 0xFF, 0x1F, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0xFF,
  0x7F, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFC, 0xFF, 0xFF, 0x00, 0x00, 0x00,
  0x00, 0x00, 0xFE, 0xFF, 0xFF, 0x01, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF,
  0xFF, 0x03, 0x00, 0x00, 0x00, 0xFC, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00,
  0x00, 0xFF, 0xFF, 0xFF, 0x07, 0xC0, 0x83, 0x01, 0x80, 0xFF, 0xFF, 0xFF,
  0x01, 0x00, 0x07, 0x00, 0xC0, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x0C, 0x00,
  0xC0, 0xFF, 0xFF, 0x7C, 0x00, 0x60, 0x0C, 0x00, 0xC0, 0x31, 0x46, 0x7C,
  0xFC, 0x77, 0x08, 0x00, 0xE0, 0x23, 0xC6, 0x3C, 0xFC, 0x67, 0x18, 0x00,
  0xE0, 0x23, 0xE4, 0x3F, 0x1C, 0x00, 0x18, 0x00, 0xE0, 0x23, 0x60, 0x3C,
  0x1C, 0x70, 0x18, 0x00, 0xE0, 0x03, 0x60, 0x3C, 0x1C, 0x70, 0x18, 0x00,
  0xE0, 0x07, 0x60, 0x3C, 0xFC, 0x73, 0x18, 0x00, 0xE0, 0x87, 0x70, 0x3C,
  0xFC, 0x73, 0x18, 0x00, 0xE0, 0x87, 0x70, 0x3C, 0x1C, 0x70, 0x18, 0x00,
  0xE0, 0x87, 0x70, 0x3C, 0x1C, 0x70, 0x18, 0x00, 0xE0, 0x8F, 0x71, 0x3C,
  0x1C, 0x70, 0x18, 0x00, 0xC0, 0xFF, 0xFF, 0x3F, 0x00, 0x00, 0x08, 0x00,
  0xC0, 0xFF, 0xFF, 0x1F, 0x00, 0x00, 0x0C, 0x00, 0x80, 0xFF, 0xFF, 0x1F,
  0x00, 0x00, 0x06, 0x00, 0x80, 0xFF, 0xFF, 0x0F, 0x00, 0x00, 0x07, 0x00,
  0x00, 0xFE, 0xFF, 0xFF, 0xFF, 0xFF, 0x01, 0x00, 0x00, 0xF8, 0xFF, 0xFF,
  0xFF, 0x7F, 0x00, 0x00, 0x00, 0x00, 0xFE, 0xFF, 0xFF, 0x01, 0x00, 0x00,
  0x00, 0x00, 0xFC, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0xFF,
  0x7F, 0x00, 0x00, 0x00, 0x00, 0x00, 0xE0, 0xFF, 0x1F, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x80, 0xFF, 0x07, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFC,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  };
alvarolb commented 7 years ago

Hi, sorry for the late response! The debug only uses the F macro for storing the strings int he flash instead of the memory, so it can save some RAM, similar to PROGMEM you defined for your icon, so it should no cause any issue, except it takes space for your sketch.

What hardware are you using? I have tested to compile a similar example for an Arduino and ESP8266 board, and both seems to compile fine. Do you have an isolated example to test what is happening?