rosserial compilation error related to PROGMEM or PSTR() for Teensy 4.0 but not 3.1

Status
Not open for further replies.

Caleb314

New member
I'm trying to get this rosserial library to work on Teensy 4.0 but I keep getting an error that I can't figure out:

Code:
In file included from C:\Users\Caleb\.platformio\packages\framework-arduinoteensy\cores\teensy4/WProgram.h:41:0,
                 from C:\Users\Caleb\.platformio\packages\framework-arduinoteensy\cores\teensy4/Arduino.h:6,
                 from src\main.cpp:1:
C:\Users\Caleb\.platformio\packages\framework-arduinoteensy\cores\teensy4/avr/pgmspace.h:35:39: error: data causes a section type conflict with rosserial_msgs::REQUESTPARAM
 #define PSTR(str) ({static const char data[] PROGMEM = (str); &data[0];})
                                       ^
.pio\libdeps\teensy40\Rosserial Arduino Library\src/rosserial_msgs/RequestParam.h:213:41: note: in expansion of macro 'PSTR'
         const char * getMD5() { return  PSTR("9f0e98bda65981986ddf53afa7a40e49");};
                                         ^
In file included from .pio\libdeps\teensy40\Rosserial Arduino Library\src/ros/node_handle.h:43:0,
                 from .pio\libdeps\teensy40\Rosserial Arduino Library\src/ros.h:38,
                 from src\main.cpp:3:
.pio\libdeps\teensy40\Rosserial Arduino Library\src/rosserial_msgs/RequestParam.h:15:23: note: 'rosserial_msgs::REQUESTPARAM' was declared here
     static const char REQUESTPARAM[] PROGMEM = "rosserial_msgs/RequestParam";
I don't get this when building for teensy 3.2/3.1. Here are github links to the lines the error mentions: PSTR is defined here and the line with REQUESTPARAM in it is here.

The simplest way to reproduce this is by compiling this program:

Code:
#include <Arduino.h>
#include "ros.h"
ros::NodeHandle node;

void setup() {}
void loop() {}

I tried to isolate it and got this far but I'm not really sure what is going on:

Code:
#include <Arduino.h>
class Msg
{
public:
  virtual const char * getType() = 0;
  virtual const char * getMD5() = 0;
};

static const char REQUESTPARAM[] PROGMEM = "test1";

class RequestParamRequest : public Msg
{
  const char * getType(){ return REQUESTPARAM; };
  const char * getMD5() { return  PSTR("test2");};
};

RequestParamRequest test;
void setup() {}
void loop() {}
The error goes away if I get rid of the Msg class but that is a bit tougher to do in the full code haha.

I'm using PlatformIO to build this and I get the same error in the Arduino IDE. Note that the version of this library in the Arduino library manager is outdated so it has to come from github. Here is my platformio.ini file:
Code:
[env:teensy40]
platform = teensy
board = teensy40
framework = arduino
lib_deps =
  https://github.com/frankjoshua/rosserial_arduino_lib.git
;lib_ignore =
;  Rosserial Arduino Library

[env:teensy31]
platform = teensy
board = teensy31
framework = arduino
lib_deps =
  https://github.com/frankjoshua/rosserial_arduino_lib.git

My rough understanding is that it is trying to put two strings in the same place in flash or something. Anyone have any ideas on how to fix this or have any insight on what the error means?

Thanks!
- Caleb
 
Were you able to solve this issue? I am facing the same problem with Teensy 4.0 and the latest commit from the master branch of the Rosserial_Arduino_lib. Although I just tried with the Arduino IDE.
 
Were you able to solve this issue? I am facing the same problem with Teensy 4.0 and the latest commit from the master branch of the Rosserial_Arduino_lib. Although I just tried with the Arduino IDE.

Yeah I guess the PROGMEM macro is somewhat broken on the teensy 4.0. Just not using it in one spot was enough to get the things I needed working (see this commit). A more complete fix would be to remove it everywhere like someone did for the esp8266. PROGMEM is for lowering ram usage which isn't much of an an issue here so doesn't hurt to remove it.
 
I too just ran into this :)
Apparently there's a VERY tight constraint that GCC is using during the compilation, and marks the sections different if it's global, or not. :-/
 
I too just ran into this :)
Apparently there's a VERY tight constraint that GCC is using during the compilation, and marks the sections different if it's global, or not. :-/

Yes, we've first seen this during the T4 beta test. There is no fix other than modifying the sourcecodes and use both, FLASHMEM (for code) and PROGMEM (for data)
 
Last edited:
Technically, there is a fix, but it has to happen on the teensy4 core side of things.
#‎define‬ PROGMEM __attribute__((section(".progmem.vars")))

**note fixes global variables ONLY, but PSTR() needs something different
 
Last edited:
No we tried that too. Works if used once.
But I don't remember exactly. Too long ago.
Had something todo with different compilation units etc..
 
Macro magic anyone? :-D
all you need to do (yes, I just said that) is have a macro that adds another subsection.
In theory, that's the fix.
 
@Paul
(and everyone else)
I have a working magic set of macros that fix this

Here you guys go!

Code:
#define DMAMEM __attribute__ ((section(".dmabuffers"), used))
#define FASTRUN __attribute__ ((section(".fastrun") ))
// PROGMEM fix for section type conflict
#define QUO(x) #x
#define QLINE(x,y,z) QUO(x) y QUO(z)
#define PFIX QLINE(.progmem., __FILE__, __LINE__)
#define PROGMEM __attribute__((section(PFIX)))
// You are welcome! --AJK
#define FLASHMEM __attribute__((section(".flashmem")))
#define EXTMEM __attribute__((section(".externalram")))

***NOTE Only tested on my own system (Linux) where I don't have evil path characters like : \ or spaces.
 
And now for the universal one...


Code:
// PROGMEM fix for section type conflict
#define QUO(x) #x
#define QLINE(x,y) QUO(x)QUO(y)
#define PFIX QLINE(.progmem.variable, __COUNTER__)
#define PROGMEM __attribute__((section(PFIX)))
// You are welcome! --AJK

:)
 
Doesn't counter start with every new unit again?
At least with every call of gcc.
 
Last edited:
Perhaps with adding the filename without path (by using inbuilt strstr or similar gcc inbuilt funcs) plus adding the counter it would work.. not sure..
But for common names like "config" or similar this would fail too..
 
Status
Not open for further replies.
Back
Top