For compilation Using RadioLib, I have managed to resolve many errors in #include calls, by fixing the path.
But this following line eludes me. It is using a syntax, with which I am not familiar.
(in file: ModuleTemplate.cpp)
#include "<module_name>.h"
I have tried relative paths of various kinds. I suspect this <module_name> is a string variable, which was not properly set somewhere.
Anyone know what is going on, and how to fix it?
Kind regards and gratitude.
You don't know #include syntax? Really? 
And what is "ModuleTemplate.cpp"? And what library you're trying to use? How? Is THIS the library or what?
Please post your entire code here, and let us see what you're talking about.
ModuleTemplate is a template for writing your own module. It isn't compilable by itself you have to write your own code and change the name accordingly. No clue what you're trying to do but you didn't tell us, so it's up to you to inform us.
Thanks, docdoc, pylon.
A day ago, I would welcome any insights as to where I have gone wrong.
Today, things are much better, much different.
Today's steps at replicating my problem, with new project starts, shows no anomolous behaviour.
My suspicion, just a suspicion, is that with all libraries properly downloaded under previous efforts, the launch of a new project (sketch) is happily well-behaved.
Details below my Signature
One more thing ...
==> @docdoc, Yes, I do recognize the #include directive. The particular one I was questioning is distinguished by the location of the right-hand arrow bracket.
<module_name>.h
You will see it is located to the left of the filetype extension.
This is not a call to a library file.
It appears this way in other places of the code, so it is not a typo either.
It was a module name assertion, made somewhere in the labyrinth of supporting files, but no longer an issue.
Summary: In preparing a substantive reply, I stumbled across a resolution. More down below.
Sincerest thanks,
Michael A. Banak
For those who might learn from my pain ...
The problems I experienced occurred under 3 setups, that is 3 attempts to get started.
I started over a 4th time, in order to replicate my steps to precisely document them for this forum.
On this fourth occasion, everything remained well-behaved, as mentioned above.
So, looking back, here is what happened.
For a SparkFun nRF52840 Board ...
First Step: Confirm that the hardware can programmed.
Loaded, tested, modified an LED Blink program.
- Download install sample code in a suitable directory
- Compiled and Uploaded to Board, OK.
- Modified code to change blink rate, OK.
-Added and verified serial display utility to verify the terminal view works,
and serve as a debug tool: OK.
- No issues with preprocessing directives, nor with the libraries
Procedural finding to this point:
Though I started opening and programing in a directory of my choosing. When I try to rename the file, the Arduino IDE keeps moving and continuing everything in a sub-directpry of C:....\Documents\Arduino. This appears to happen whenever I do a save-as. I just kept working under the new directory location.
Next: Download and install the sample code for the nRF52840 + SEMTECH
"MicroMod_LoRa_Function_Board-Basic_Examples.zip"
It's just one .ino file
Add a few comments and re-save, and, once again, it is moved to a subdirectory under
C:....\Documents\Arduino
OK. I keep working
Re-Open the one sketch file and it launches a massive tar file download, and further loads (opens) every file under RadioLib into some directory associated with my new one.
This happened at least two more sessions.
I saw something similar in an IDE from ATMEL, and though the overhead looked strange, I figured it would take care of itself.
The Arduino IDE, as I understand it, cannot close just one file. "Close" means "Close the Project". They all kind of tagged along, with the project I was working.
With all these files open ...
Code Verification cycles revealed path errors to header files in the library.
I painfully fixed them and moved on.
The only repair eluding me, was that unusual syntax
<module_name>.h
And that took care of itself when I started all over.
Looking ahead, If I want to change a project name, as if to up-rev the version, I must be careful to make sure the .ino file name matches the new folder name, in which must be created.
I must also get used to the Arduino IDE creating and caching many copies of the library through the day's work.
Cheers!
Michael A. Banak
Yes, but <module_name> is clearly an example placeholder , to be entirely replaced by the real module name, angle brackets included. It's a common representation for portions to be replaced with some other string.
Just in case we need to clarify, as example if you have a module named "dothat" (like a *.cpp module) with its header "dothat.h" you should replace that line with:
#include "dothat.h"
where the quotes indicate the file is stored in the same folder of your sketch.
Or use the angle brackets if the module has been installed under global Arduino libraries paths:
#include <dothat.h>
Yep, but that's how Arduino IDE works. And that's why I never use version numbers as file name (I put it inside a specific "configuration" header file, if for some reason I need to track the running release down).
Thank you for your generous response, docdoc.
On the first item, I agree with your assessment.
Looking back, I should have asked more clearly ... "Where is this thing getting set?"
Once I blew past the compiler management issues, the compiler errors (leading me to discover that line of code) all went away. I never got to chase it down any further. The sample code bundle is taking care of it for me somewhere, but at this level, board verification, I must wait awhile before I have time to scratch that itch. Everything is working now.
On the second item ... YOU GOT THAT RIGHT!!
Enourmously grateful, I remain ...
Yours truly,
MABanak
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.