Notifications
Clear all
C++
108
Posts
5
Users
9
Likes
24.6 K
Views
2020-02-18 11:36 am
Or did you mean wrapping the code section in a namespace, like this?
Yes!
Which does compile without errors!
If YES, what is namespace actually doing?
Technically, a namespace introduces a new SCOPE, which is how it is able to avoid clashes with global symbols... make sense?
By the way... speaking of scope, the pause function logically expects to return a Boolean statement right at the end, just in case the conditional statement do not return, because every time you use curly braces as in a conditional statement, that in itself introduces a new scope.
Cheers!
2020-02-18 11:56 am
Topic starter
2020-02-18 12:25 pm
Got it!! But I was already aware of the scope issue!!
Some serious handclapping going on here ?️ ?️
2020-02-18 12:37 pm
Some serious handclapping going on here
LOL!
OK, it was for others too, but the main point is that you now have a nice(er) and clean(er) method of applying those pauses in your programs - Shorter and more descriptive code is good code!
Whats next?
Cheers!
Topic starter
2020-02-18 12:40 pm
Have implemented the new library in my receiver sketch and all is well!
Thanks for your patience!
Whats next?
Oh, I'll find something, no worries about that ?
Topic starter
2020-02-18 12:43 pm
But I didn't know you could assign values to variables using parentheses! That's new to me!!
2020-02-18 12:45 pm
Thanks for your patience!
Whats next?
Oh, I'll find something, no worries about that
No problem... I have thought about some different approaches for your weather station, a bit more technical, but far more elegant! 😉
Cheers!
2020-02-18 12:49 pm
But I didn't know you could assign values to variables using parentheses! That's new to me!!
I often use that method of initialising my variables, as you would have seen me do before, for example in for loops, etc. I think I have mentioned it before, but just in case not... in C++, everything is an object, so using the parenthesis is what you already know... a constructor initialisation call.
Cheers!
Topic starter
2020-02-21 10:11 am
What we have forgotten in the .cpp file is, how to deal with the unsigned long overflowing and resetting to zero every 49.7 days(milliseconds) and every 1.19 hours (microseconds).
I was thinking about checking whether the next "currentTime" plus "delay_time" exceeds 4,294,967,295, calculating the remaining time, then carrying the remainder to the function call and subtracting it from the "delay_time" and resetting remainder to zero, if the remainder does not equal zero.
If that makes any sense!
#include <multiTimer.h>
namespace tim {
bool Timer::interval(DELAY_MODE delay_mode, unsigned long delay_time){
if(delay_mode == MILLIS && isRunning){
_current_time = millis();
if(_current_time >= _previous_time + delay_time) {
_previous_time = _current_time;
return true;
}
}
if(delay_mode == MICROS && isRunning){
_current_time = micros();
if(_current_time >= _previous_time + delay_time) {
_previous_time = _current_time;
return true;
}
}
return false;
}
}
I have changed "pause" to "interval", much sexier IMHO!
Topic starter
2020-02-21 1:12 pm
This is my solution to the rollover problem:
#include <multiTimer.h>
namespace tim {
bool Timer::interval(DELAY_MODE delay_mode, unsigned long delay_time){
if(delay_mode == MILLIS && isRunning){
unsigned long start = millis();
while (millis() - start < delay_time) ;
return true;
}
if(delay_mode == MICROS && isRunning){
unsigned long start = micros();
while (micros() - start < delay_time) ;
return true;
}
return false;
}
}
And this is what happened at the rollover time, after 1 hour and 11 minutes monitoring the microseconds:
4276347440
4279647932
4282948424
4286248912
4289549408
4292849896
1183084
4483432
7783780
11084124
14384516
17684912
20985308
24285700
That proves it works properly. This method compares time durations rather than timestamps!
2020-02-21 2:53 pm
What we have forgotten in the .cpp file is, how to deal with the unsigned long overflowing and resetting to zero every 49.7 days(milliseconds) and every 1.19 hours (microseconds).
I'm not sure that's a problem really, because "_current_time" will always be ">=" to "_previous_time + delay_time"?
This is my solution to the rollover problem:
Again, not sure if it really was a problem, but I like this one better... in fact, I have an almost identical one in my bag of C++ snippets, but written using a continue statement instead, as it's not in a function.
Also, not sure why you need a class with a private label anymore, you may as well just use a struct which is as stated previously, public by default 🙂
Also not a big deal, but self documenting code is easier to understand, so and instead of &&:
if(delay_mode == MILLIS and isRunning) {
Good job!
Topic starter
2020-03-05 11:14 am
Have finally conceded and will log all the data to an SD read/write card. Furthermore, I have also just ordered a 2.4" TFT touchscreen to replace the 20 by 4 LCD.
So, as both of those addons and the nrf24l01 are fighting to use the SPI bus all at the same time, it will take a while to get full control of this sketch!
2020-03-05 11:33 am
Have finally conceded and will log all the data to an SD read/write card. Furthermore, I have also just ordered a 2.4" TFT touchscreen to replace the 20 by 4 LCD.
Sounds like a good move to me 🙂
This will open the door to greater control over your data, and aid in a more versatile design of your weather station.
You will then be able to calculate from the raw data: min, max, avg, and any other data you record, and even present it in a graphical form over time.
Topic starter
2020-03-05 11:49 am
It looks like there is going to be a bit of pin conflict here, especially the SPI slave select pin (SS/CS).
The rf24 library is given control over the SS pin directly at initialisation, I know you are not a hardware guy, but I was wondering if the state of this pin can be changed for the short periods when required by the SD and TFT units. Basically overriding the library temporarily. This looks like a "trial or error" experiment to me!
2020-03-05 11:56 am
It looks like there is going to be a bit of pin conflict here, especially the SPI slave select pin (SS/CS).
The rf24 library is given control over the SS pin directly at initialisation, I know you are not a hardware guy, but I was wondering if the state of this pin can be changed for the short periods when required by the SD and TFT units. Basically overriding the library temporarily.
Indeed, I am not a hardware person (still have a lot to learn in that space!), but... I am a thinker! 😉
Remembering that we can hook up a number of these nrf24l01 modules, how about chucking in another UNO and nrf24l01 into the mix just for remote display?
Does the TFT touchscreen plug into an UNO as a shield?