Help request getting library to compile on esp32 micrcontrollers

[paulhayes]

Hi, I want to see if it's possible to get ink to run on esp32 and similar microcontrollers. Specifically this e-Paper device
https://docs.m5stack.com/en/core/m5paper

I wanted to know if anyone from this project might be able to help me with the some issues.

I've opted for using the platformio IDE which I've had a lot of experience with.

So I've forked this repo, and got quite far getting it to compile on the esp32. I'm down to 3 compiler issues.

The platformio project is here
https://github.com/paulhayes/M5paper-ink-runner

My fork of this library is here:
https://github.com/paulhayes/inkcpp-platformio

To test it,

• Install Microsoft Visual Studio Code
• Install the Platformio extension
• checkout the repo git clone https://github.com/paulhayes/M5paper-ink-runner
• Instanciate the submodule git submodule init and git submodule update
• Open the project folder in VSCode

[JBenda]

That is a cool idea. I will try to compile this weekend.
Currently I have no real clue why it does not find these functions.

[paulhayes]

omg that would be amazing.

fyi In platformio.ini configuration file I've set the compiler flag to use c++17, as that seemed to be the correct c++ standard to use.
build_flags = -std=c++17

[JBenda]

C++20 is the version we use to compile normally, it seems to work with the C++17 flag, but if it possibly try to use 20.

I added a missing import and now (at least inkcpp) seems to compile with PlatformIO (VSCode)
patch for your inkcpp fork
git am 0001-fixes-include-and-template-for-platformio-compiler.patch

I still get errors in PlatformIO code, but this is about some HTTPS library, so I would give the ball back to you.
If you have your demo project up and running, feel free to create a PR for inkcpp.

Anyhow, if you need further assistance, please let me know.

I would recommand changing your .gitmodules to

[submodule "lib/inkcpp"]
	path = lib/inkcpp
	url = https://github.com/paulhayes/inkcpp-platformio.git
[submodule "inkcpp"]
	path = inkcpp
	url = https://github.com/paulhayes/inkcpp-platformio.git

Using HTTPS instead of ssh allows cloning the project without ssh setup
Also, the relative path for the second project did not work for me well with git submodule update --init --recursive. If this is a error on my side, please teach me ;)

[paulhayes]

You absolute legend! Thanks for taking a look so quickly. Can't wait to give this a go.

Regarding the submodule url I'll switch it to a http url. I've done that so many times to others by accident, especially games artists who rairly have ssh.

My heads a big foggy because I've got a cold. So I'm not sure if I'm understanding the submodule issue you had, and it's probably not neccessary for us to resolve it yet. But I am curious what did you do do get round the problem?

I'll try to take a look at this once my crainium isn't filly with a malevolent virus.

Oh and a huge thank you for creating and maintaining this library.

[paulhayes]

I was feeling a touch better, and thought I'd quickly fiddle with the final problem, and what do you know I solved not one but 2 issues.

https://github.com/paulhayes/M5paper-ink-runner is compiling now.

Thanks so much for your help. I'm going to crack on with my demo. I'll let you know when it works and we can discuss PR.

Oh and I solved the submodule stuff, there was a bad entry in .gitmodules.

[paulhayes]

I've tripped over another hurdle. This time a runtime issue. I'm investigating myself, but I'm wondering if you might have some idea what might be going on @JBenda .

I'm always getting NULL pointer strings from thread->getline();

The following code in https://github.com/paulhayes/M5paper-ink-runner/blob/main/src/main.cpp

    
    Serial.println("Testing...");
    story* myInk = story::from_binary(test_story_bin,test_story_bin_len);
    
    // Create a new thread
    runner thread = myInk->new_runner();
    if(!thread.is_valid()){ 
        Serial.println("Invalid binary story file");
    }

    std::string line = std::string("unpopulated");
    
    if(thread.is_valid() && thread->can_continue()){
        Serial.print("Free heap size ");
        Serial.println(ESP.getFreeHeap());
        std::string line2 = thread->getline();
        Serial.print("pointer ");
        Serial.println((int)(line2.c_str()), 16); //line2 pointer is NULL
        Serial.print("Free heap size ");
        Serial.println(ESP.getFreeHeap());
        Serial.println(line2.c_str()); //this is the same as before running getline. Surely some memmory allocation should happen?
    }

is outputting

Free heap size 311128
pointer 0
Free heap size 311128

As you can see there doesn't seem to be an memory allocation from the call to getline(). I'm wondering, is there some place I'm meant to provide the library with a tmp buffer or something?

[JBenda]

This is wired, you could try setting INK_ENABLE_CSTD (as define) and use getline_alloc and check if this also returns a nullptr
To my mental model, the getline method should return a valid string every time, maybe an empty string, but not a nullptr.
Also, I did not know, that c_str can return a nullptr ...

[paulhayes]

Funnily enough I just got it to work using getline_alloc.

I think something really strange is happening when using the STL library as I added a few lines to getline that injected test output and it didn't appear, which was worrying.

[JBenda]

#96 touches the getline logic and output, maybe there is a fix in there

[paulhayes]

Ooof that pull request write up #96 is the stuff of nightmares. Computational look ahead, just to have tags perform to spec. Makes me wonder if that's just a bad idea. I imagine that's a Pandora's box.

[JBenda]

The feature causing all this trouble is called glue, without it we would not need to look ahead but it is how it is.
PR #96 cleans some rough edges

It will be merged soon, after this I would investigate a non working getline

Until then I hope getline_alloc works for you