Help porting code - * not declared in this scope

[antman]

Hi,
I am quite new with some of the syntax I am seeing from third parties, such as E-ink libraries from Waveshare - which I would like to integrate with my Electron. I will also say that my knowledge of C++ is still quite limited too - so please excuse my ignorance.

For example; if I create a project and add in the code provided by Waveshare, such as this:

https://github.com/waveshare/e-Paper/tree/master/Arduino/epd1in54_V2

I run into all sorts of issues attempting to compile code in the particle wed IDE. After adding in the *.h and *.cpp files - the first issue to note, its referring to “arduino” includes - which I’ve commented out to try to progress things.

The first error scenario which I don’t know how to solve seems to be related to some of the “baked in” functions of the particle OS.

Within the epdif.cpp file, it complains “‘digitalWrite’ was not declared in this scope”.

The Waveshare example code seems to be attempting to wrap-up low level functions into a method in the EpdIf class. The code I am referring to is as follows:

void EpdIf::DigitalWrite(int pin, int value){
digitalWrite(pin, value);
}

I don’t see from the documentation how to add includes to allow the “digitalWrite” function to be recognised (i.e. you don’t need to use any includes etc if you were to use the digitalRead/digitalWrite functions in a new project - you can call it directly in the “main” loop of the code, as is the basis of many LED blinking starter code).

When creating additional .cpp/.h files in the wed IDE - is there something that needs to be done to make those files “aware” of (what I understand to be) baked-in OS functions in particle world? Programming microcontrollers in the past (many years ago, and just in C) - this was always a case of ensuring the appropriate include libraries were defined.

Am I missing something here?

Any advice would be greatly appreciated.

[ScruffR]

I don't know whether your display is supported by this library but it seems well written and supporting loads of different displays

GitHub - ZinggJM/GxEPD2: Arduino Display Library for SPI E-Paper Displays

About your porting issues:
You can keep #include <Arduino.h> as Particle has added this as a compatibility layer.
However, when you remove Arudino.h you must replace it with Particle.h to avoid errors like this

@antman

it complains “‘digitalWrite’ was not declared in this scope”.

The reason why you don't need to (explicitly) include Particle.h in a "normal" project is that the main project file is a .ino file which will undergo some preprocessing which will add #include <Particle.h> when it finds it missing.
The same happens for function prototypes.
C/C++ usually requires you to have forward declarations for functions that are referenced in code before their respective implementation. When the preprocessor finds a function that is implemented but not prototyped it will add that prototype.
.h and .cpp files will not undergo such convenience treatment but it's up to the coder to do it manually.

BTW, Particle.h is the intermediate header file that includes application.h (its own predecessor) which - in turn - adds a load of #include statements for all the standard stuff that is provided by the Particle framework.

[antman]

Thanks ScruffR, that’s a great explanation. I’ve been able to progress things further on this advice.

I’ve wrestled with the web IDE for a few hours now at different times; I’m a little frustrated with adding the libraries. When I attempt to add some libraries (e.g. “GxEPD2_PP”), the interface just hangs while loading.

I’ve read others have resolved this by clearing cache which hasn’t worked for me. Any further advice on how to efficiently use other libraries would be great.

I started to go down the path of manually adding in libraries (attempting to copy paste all the files from git over into the web ide). However - it’s not apparently how I’d create sub folders to recreate with the same folder structure.

My frustration is compounded at the moment by poor cellular comms to the Electron I’m using - so debugging is painfully slow/unreliable. Often the board says its flashing the code but fails. Perhaps I could use local wifi instead - I’m not sure?

My preference is probably to switch to a local iDE (which I can flash over serial reliably - and ideally do some additional debugging through breakpoints and the serial port etc).

Would you recommend I make a switch to local IDE to resolve these issues? Is there any advantage to this development cycle.

If you’ve got any advice, I’m all ears…

[ScruffR]

@antman

I’ve read others have resolved this by clearing cache which hasn’t worked for me. Any further advice on how to efficiently use other libraries would be great.

Unfortunately not - it is a known issue that seems to be part of the 3rd party editor that is used by Particle for Web IDE.

The easiest way to get around this - particularly for bigger libraries with multiple files - would be using Particle Workbench (VS Code) instead.
This way it's also much simpler to flash your code via USB and when using a non-AUTOMATIC system mode you can cut out the reconnection time while debugging too.