Re: Arduino question?
Hi Paul, Based on both your suggestion and a few of Bill Freeman's, I found the problem. It basically was a problem with the scope of the #ifndef statement. The problem was that if moreutils was compiled prior to RunningMedian, then RunningMedian_h was defined. Due to an error in placement of the #endif statement in RunningMedian.h, the whole body of the header file was not read in. I changed the location of the #endif statement in RunningMedian.h so that the body of the header would be read. Problem solved. So, it was simple... once it was pointed out. Thanks to you both. I'll still be coming up to the MakerSpace on Monday. I'd like to check out the setup. There is one in Nashua, just wondering how the Manchester one compares. Regards, Bruce On 5/3/19 7:34 PM, Bruce Labitt wrote: Hi Paul, It seems this is a variant of header hell that I am stewing in... At the moment the project is not up on github, as I was under some sort of delusion that this might eventually have some commercial value. I'm not so sure about that, but I have put a lot of effort into it so far... Arduino, does indeed do some funky stuff. If I could figure it out, I'd probably just write my own scripts to have things compile in the order I want. A makefile isn't hard. I just don't know all the crazy locations where Arduino stuff is stashed. Suppose I could poke about. Thanks for the tip on going through the #ifndef's. It's got to be in that neighborhood. I put in the #ifndef stuff to prevent multiple inclusions, which Arduino 1.8.9 IDE does not seem to like, the compiler squawked at me when I tried to do that. What is puzzling me is that even if I put the include #include "RunningMedian.h" in the file, I get "nearly" the same error, if I comment out the include. WITH include: #include "moreutils.h" *#include "RunningMedian.h"* home/bruce/Arduino/adcdmafftM4bruce/adcdmafft/adcdmafftm4/moreutils.ino: In function 'void doMedian(float*, float*, int)': moreutils:14:3: error: 'RunningMedian' was not declared in this scope RunningMedian samples = RunningMedian(medianlength); ^ moreutils:14:17: error: expected ';' before 'samples' RunningMedian samples = RunningMedian(medianlength); ^ moreutils:16:5: error: 'samples' was not declared in this scope samples.add(abuf[i]); ^ exit status 1 'RunningMedian' was not declared in this scope WITHOUT include: #include "moreutils.h" /home/bruce/Arduino/adcdmafftM4bruce/adcdmafft/adcdmafftm4/moreutils.ino: In function 'void doMedian(float*, float*, int)': moreutils:14:3: error: 'RunningMedian' was not declared in this scope RunningMedian samples = RunningMedian(medianlength); ^ moreutils:14:17: error: expected ';' before 'samples' RunningMedian samples = RunningMedian(medianlength); ^ moreutils:16:5: error: 'samples' was not declared in this scope samples.add(abuf[i]); ^ exit status 1 'RunningMedian' was not declared in this scope In both cases, the top of the file states #include moreutils.h. And inside of moreutils.h there is: #ifndef RunningMedian_h #define RunningMedian_h #include "RunningMedian.h" ... #endif It's got to be simple, it's got to be simple,... Wish I could see it what it was... I think, I'll come up on Monday. I haven't been to the Manchester Maker Space before. -Bruce On 5/3/19 6:50 PM, Paul Beaudet wrote: The compiler is basically telling you the library is not imported or has yet to be imported for whatever reason. The Arduinoy parts of the compilation process do some weird things behind the scenes to reorder the code before compiling so that it actually makes sense. Done with extra .ino files not named the same as the project and functions after the main loop in said project_name.ino file. Its possible for an Arduino developer/tinkerer to declare a function after the two primary loops that use those exact functions before actual deceleration because of this behavior. Which breaks some expectations of hardened engineers I think. All in the interest of catering to new people that would probably be frustrated by a strict order of operation. If this behaviour rearranges library functions before the "#include ", that might give an unexpected result, but that doesn't seem to be what's going on here. Under the hood strict order of operations still exist. Arduino does ultimately use the gcc compiler, though maybe its configured for that switcharoo magic, I didn't write the code, I've just fallen into the traps. Extra .ino files in the same folder will be arranged before your main .ino file, but it could be right before setup. Not sure, its been a while since I've been regularly working with the Arduino, I could be wrong. The .h file should be a bit more obvious as to where its included. Bit more explicit Do you have a github link to your current project state Bruce? I'm looking back at an older project of mine, it looks like
Re: Arduino question?
Hi Paul, It seems this is a variant of header hell that I am stewing in... At the moment the project is not up on github, as I was under some sort of delusion that this might eventually have some commercial value. I'm not so sure about that, but I have put a lot of effort into it so far... Arduino, does indeed do some funky stuff. If I could figure it out, I'd probably just write my own scripts to have things compile in the order I want. A makefile isn't hard. I just don't know all the crazy locations where Arduino stuff is stashed. Suppose I could poke about. Thanks for the tip on going through the #ifndef's. It's got to be in that neighborhood. I put in the #ifndef stuff to prevent multiple inclusions, which Arduino 1.8.9 IDE does not seem to like, the compiler squawked at me when I tried to do that. What is puzzling me is that even if I put the include #include "RunningMedian.h" in the file, I get "nearly" the same error, if I comment out the include. WITH include: #include "moreutils.h" *#include "RunningMedian.h"* home/bruce/Arduino/adcdmafftM4bruce/adcdmafft/adcdmafftm4/moreutils.ino: In function 'void doMedian(float*, float*, int)': moreutils:14:3: error: 'RunningMedian' was not declared in this scope RunningMedian samples = RunningMedian(medianlength); ^ moreutils:14:17: error: expected ';' before 'samples' RunningMedian samples = RunningMedian(medianlength); ^ moreutils:16:5: error: 'samples' was not declared in this scope samples.add(abuf[i]); ^ exit status 1 'RunningMedian' was not declared in this scope WITHOUT include: #include "moreutils.h" /home/bruce/Arduino/adcdmafftM4bruce/adcdmafft/adcdmafftm4/moreutils.ino: In function 'void doMedian(float*, float*, int)': moreutils:14:3: error: 'RunningMedian' was not declared in this scope RunningMedian samples = RunningMedian(medianlength); ^ moreutils:14:17: error: expected ';' before 'samples' RunningMedian samples = RunningMedian(medianlength); ^ moreutils:16:5: error: 'samples' was not declared in this scope samples.add(abuf[i]); ^ exit status 1 'RunningMedian' was not declared in this scope In both cases, the top of the file states #include moreutils.h. And inside of moreutils.h there is: #ifndef RunningMedian_h #define RunningMedian_h #include "RunningMedian.h" ... #endif It's got to be simple, it's got to be simple,... Wish I could see it what it was... I think, I'll come up on Monday. I haven't been to the Manchester Maker Space before. -Bruce On 5/3/19 6:50 PM, Paul Beaudet wrote: The compiler is basically telling you the library is not imported or has yet to be imported for whatever reason. The Arduinoy parts of the compilation process do some weird things behind the scenes to reorder the code before compiling so that it actually makes sense. Done with extra .ino files not named the same as the project and functions after the main loop in said project_name.ino file. Its possible for an Arduino developer/tinkerer to declare a function after the two primary loops that use those exact functions before actual deceleration because of this behavior. Which breaks some expectations of hardened engineers I think. All in the interest of catering to new people that would probably be frustrated by a strict order of operation. If this behaviour rearranges library functions before the "#include ", that might give an unexpected result, but that doesn't seem to be what's going on here. Under the hood strict order of operations still exist. Arduino does ultimately use the gcc compiler, though maybe its configured for that switcharoo magic, I didn't write the code, I've just fallen into the traps. Extra .ino files in the same folder will be arranged before your main .ino file, but it could be right before setup. Not sure, its been a while since I've been regularly working with the Arduino, I could be wrong. The .h file should be a bit more obvious as to where its included. Bit more explicit Do you have a github link to your current project state Bruce? I'm looking back at an older project of mine, it looks like I was doing something similar in this one https://github.com/PaulBeaudet/SimpleBotSocketIo/blob/master/SimpleBotSocketIo.ino I declared a timer library in a .h file then declared and instance of it in the .ino fille. We demoed that bot at the mini makerfaire in dover, I'm assuming it compiled and that should be something that's doable I think you may want to inspect your #ifndef statement a bit more closely to be sure the RunningMedian data type (library import) is actually being instantiated after that pre-compilation logic runs its course. Why do you need to prevent multiple instances from being called? #import should only call one instance, right? Also, spelling, that's normally my issue.. haha If you are still having trouble after spending more time with it, feel free to stop by the
Re: Arduino question?
The compiler is basically telling you the library is not imported or has
yet to be imported for whatever reason.
The Arduinoy parts of the compilation process do some weird things behind
the scenes to reorder the code before compiling so that it actually makes
sense. Done with extra .ino files not named the same as the project and
functions after the main loop in said project_name.ino file. Its possible
for an Arduino developer/tinkerer to declare a function after the two
primary loops that use those exact functions before actual deceleration
because of this behavior. Which breaks some expectations of hardened
engineers I think. All in the interest of catering to new people that would
probably be frustrated by a strict order of operation. If this behaviour
rearranges library functions before the "#include ", that
might give an unexpected result, but that doesn't seem to be what's going
on here. Under the hood strict order of operations still exist. Arduino
does ultimately use the gcc compiler, though maybe its configured for that
switcharoo magic, I didn't write the code, I've just fallen into the traps.
Extra .ino files in the same folder will be arranged before your main .ino
file, but it could be right before setup. Not sure, its been a while since
I've been regularly working with the Arduino, I could be wrong. The .h file
should be a bit more obvious as to where its included. Bit more explicit
Do you have a github link to your current project state Bruce?
I'm looking back at an older project of mine, it looks like I was doing
something similar in this one
https://github.com/PaulBeaudet/SimpleBotSocketIo/blob/master/SimpleBotSocketIo.ino
I declared a timer library in a .h file then declared and instance of it in
the .ino fille. We demoed that bot at the mini makerfaire in dover, I'm
assuming it compiled and that should be something that's doable
I think you may want to inspect your #ifndef statement a bit more closely
to be sure the RunningMedian data type (library import) is actually being
instantiated after that pre-compilation logic runs its course. Why do you
need to prevent multiple instances from being called? #import should only
call one instance, right? Also, spelling, that's normally my issue.. haha
If you are still having trouble after spending more time with it, feel free
to stop by the Manchester Makerspace Monday during open house (6pm-8pm).
I'll likely be in giving tours, I can take a look with you when tours
simmer down.
Cheers,
Paul Beaudet
On Fri, May 3, 2019 at 4:57 PM Bruce Labitt
wrote:
> Can I ask an Arduino/C/C++ question here? If not, where is a decent
> place to ask? Full code is just under 50KB (unzipped).
>
> It's a "Variable was not declared in this scope" problem. Basically, I'm
> in over my head at the moment. I'm not a good structured programmer -
> so let's get that out of the way. I'm a hack, in the worst sense...
>
> Everything was working... when I had a huge file. I then decided, wow,
> this is a mess, lets break this up a bit into modules, so that it is
> more supportable and debug-able (for myself). If anyone is remotely
> interested, it is a homebrew radar based chronograph. I've got most of
> the pieces working (or at least it worked before I recently busted
> things). The 100KHz sampling using DMA, the ping pong floating point 1K
> FFT's running in 'real' time, and some display stuff. Separately, I
> have a live update of a tft screen (320x240) running with the FFT
> output. I'm running on an ARM M4F processor, but using the Arduino
> IDE. The Arduino way of doing things is a little confusing to me, to be
> honest. It hides a lot of things.
>
> Ok, here is the error.
>
> /home/bruce/Arduino/adcdmafftM4bruce/adcdmafft/adcdmafftm4/moreutils.ino:
> In function 'void doMedian(float*, float*, int)':
> moreutils:14:3: error: 'RunningMedian' was not declared in this scope
> RunningMedian samples = RunningMedian(medianlength);
> ^
> moreutils:14:17: error: expected ';' before 'samples'
> RunningMedian samples = RunningMedian(medianlength);
> ^
> moreutils:16:5: error: 'samples' was not declared in this scope
> samples.add(abuf[i]);
> ^
> exit status 1
> 'RunningMedian' was not declared in this scope
>
> The code in moreutils.ino is:
>
> // additional processing
> #include "moreutils.h"
>
> void doMedian( float abuf[], float runmed[], int medianlength) { //
> needs work!
>
>RunningMedian samples = RunningMedian(medianlength);
>for (int i=0; i< FFT_SIZE/2; i++) {
> samples.add(abuf[i]);
> if (i>medianlength-1) {
>runmed[i-medianlength] = samples.getMedian();
>// don't put value until the circ buffer is filled
> }
>}
>for (int i= (FFT_SIZE/2 -medianlength-7); i< (FFT_SIZE/2); i++) {
> runmed[i] = runmed[FFT_SIZE/4]; // hack for now
> // at tail end of median there are some bizarre numbers. root
> cause has not been
> // determined, so we just fill
