cattledog:
Serial.println( (String) "DATA,DATE,TIME,TIMER," + i++ + "," + millis() + ",AUTOSCROLL_20" );
Serial.println( (String) "Value of stoplogging/checkbox is: " + stoplogging);
doh! facepalm That explains it. Copy-Paste from the PLX-DAQ example. No wonder I didn't remember typing it.
adwsystems:
When I compile the program, it comes to 22804 and 1961.
We may have different versions of the libraries and the IDE.
Upon implementing... This is the same memory savings.
I'm not sure why you say 20798/1691 is the same as 20316/1468.
/dev:
And you don't need to use a TIMER, since you only set runnable flags in the ISR.Nope. Timer stays... I still need to deal with debouncing the I2C PCF8575 and filtering the remote I2C ADCs.
Then you don't understand interrupt routines.
You cannot do I2C operations inside an interrupt routine. All you do (currently) is set flags in the ISR. Then you check them in loop. This means that you aren't handling timed operations any faster than loop can get to them.
So you might as well simply check the "timer" (aka millis()) in loop and set the same flags... as I showed in the attached file. All I did was convert the ISR into a regular routine and call it from loop.
Any chance of getting some comments on what and how you are [not using sprintf and sscanf]?
...
what is causing the String class to be included?
...
There is too much code in loop().
Did you even look at the attached file? I would suggest using a file-difference utility to compare the two files. I like WinMerge, but Compare++ looks nice.
BTW, I just tried the sscanf replacement code... this line needs "-1":
const size_t baseNameSize = sizeof(FILE_BASE_NAME)-1;
If you have specific questions about that section please ask. Much info here (that goes to strncmp_P, use the search box in the upper-right corner of the page for others).
there are many aspects, including these two, that you didn't notice aren't complete.
Objection, your honour. Requires knowing the poster's state of mind.
Cheers,
/dev
-dev:
We may have different versions of the libraries and the IDE.
That was my first thought.
-dev:
I'm not sure why you say 20798/1691 is the same as 20316/1468.
That is not what I said.
adwsystems:
... it drops to 22714/1725. Upon implementing the replacement for sscanf it drops to 20798/1691. This is the same memory savings.
The absolute numbers are meaningless, as you noted the libraries are likely different plus I implemented them in a different order (relative to posting the numbers from the compiler, not as an overall effect on the program), and I made other changes in the process. Only the relative numbers can be used.
22714-20798=1916 and 1725-1691=34
22316-20362 = 1954 and 1738-1704=34 ... close enough for me. I call it the same.
-dev:
Nope. Timer stays... I still need to deal with debouncing the I2C PCF8575 and filtering the remote I2C ADCs.
Then you don't understand interrupt routines.You cannot do I2C operations inside an interrupt routine. All you do (currently) is set flags in the ISR. Then you check them in
loop. This means that you aren't handling timed operations any faster thanloopcan get to them.
Currently being the operative word. I write very few final programs that are scan based, as you allude to how the development programs were currently written. The final program will be entirely interrupt driven. Loop() will be getting to them pretty fast when all the other stuff is moved out of it. As for memory of millis() vs ISR, 24 byte more program and 7 bytes less RAM. So that's a break even.
-dev:
Did you even look at the attached file? I would suggest using a file-difference utility to compare the two files. I like WinMerge, but Compare++ looks nice.
Obviously I did as I noted the memory savings in the first line. I wasn't looking for something as obvious as (String).
-dev:
Did you even look at the attached file? I BTW, I just tried thesscanfreplacement code... this line needs "-1":
Thank you for the update!
-dev:
Objection, your honour. Requires knowing the poster's state of mind.
adwsystems:
Caveat. ...If something doesn't look complete, it probably isn't. SO don't be surprised if the response to a question about the code is "that isn't done yet". ...