I am making a project that involves a RTC and a servo motor so that it only turns on at a certain time. A snippet from the loop is:
void loop() {
DateTime now = rtc.now();
if (DateTime == 19:10) {
//Some stuff
} else {
return();
}
}
and my error is:
Arduino: 1.6.8 (Windows 10), Board: "Arduino/Genuino Uno"
C:\Users\User\Documents\Arduino\Servo_motor\Servo_motor.ino: In function 'void loop()':
Servo_motor:36: error: expected primary-expression before '==' token
if (DateTime == 19:10) {
^
Servo_motor:36: error: expected ')' before ':' token
if (DateTime == 19:10) {
^
Servo_motor:45: error: expected primary-expression before '}' token
}
^
Servo_motor:45: error: return-statement with a value, in function returning 'void' [-fpermissive]
Servo_motor:45: error: expected ';' before '}' token
Multiple libraries were found for "RTClib.h"
Used: C:\Program Files (x86)\Arduino\libraries\RTClib
Not used: C:\Users\User\Documents\Arduino\libraries\arduino_786051
exit status 1
expected primary-expression before '==' token
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
I am really confused. Can someone please help?
I'm going to assume you're using the Adafruit RTClib located here, as this is likely the one accessible from the IDE, or that a tutorial will use. It's also a fork of the other available RTClib, so this answer is likely to pertain to both.
If you check RTClib.h, you will find the publicly available methods for DateTime and all the RTC classes. If you do so, you'll notice that there is no operator== method, and in general this means that you can't use that as a form of comparison.
In order to do what you want, you need to use DateTime.minute() and DateTime.hour() and compare them separately. In your loop block it would look as follows:
void loop() {
DateTime now = rtc.now();
if (now.hour() == 19 && now.minute() == 10) {
//Some stuff
} else {
return;
}
}
However, this has the possibility of running the code in question quite a few times, as this check will succeed every time the loop runs during the minute following the RTC ticking over to 19:10.
It seems you're comparing the the type with a constant (time without quotes).
Dont you mean something like this?
if (now == "19:10") {
Related
i want to upload a Script to read out a Lightsensor i have bought. The Sensor is a Grove - Sunlightsensor and the libary for it can be found on GitHub.
The Board i am going to use is a WeMos D1 Mini using a ESP8266, but since many Pins are taken i want to use GPIO2 as SDA and 13 as SCL which can be achieved with: Wire.begin(2,13);
But the Pins are not relavant for compiling.
I want to try the example-script found in the libary from the producer:
#include "Si115X.h"
Si115X si1151;
/**
* Setup for configuration
*/
void setup()
{
uint8_t conf[4];
Wire.begin(2,13);
Serial.begin(115200);
if (!si1151.Begin())
Serial.println("Si1151 is not ready!");
else
Serial.println("Si1151 is ready!");
}
/**
* Loops and reads data from registers
*/
void loop()
{
Serial.print("IR: ");
Serial.println(si1151.ReadHalfWord());
Serial.print("VISIBLE: ");
Serial.println(si1151.ReadHalfWord_VISIBLE());
Serial.print("UV: ");
Serial.println(si1151.ReadHalfWord_UV());
delay(100);
}
But i get the following error massage:
c:\Users\nikol\Documents\Mechatronik_Projekte\Arduino_Sketches\libraries\Grove_Sunlight_Sensor-Si1151\Si115X.cpp: In member function 'int Si115X::read_register(uint8_t, uint8_t, int)':
c:\Users\nikol\Documents\Mechatronik_Projekte\Arduino_Sketches\libraries\Grove_Sunlight_Sensor-Si1151\Si115X.cpp:42:39: warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
42 | Wire.requestFrom(addr, bytesOfData);
| ^
In file included from c:\Users\nikol\Documents\Mechatronik_Projekte\Arduino_Sketches\libraries\Grove_Sunlight_Sensor-Si1151\Si115X.h:5,
from c:\Users\nikol\Documents\Mechatronik_Projekte\Arduino_Sketches\libraries\Grove_Sunlight_Sensor-Si1151\Si115X.cpp:2:
C:\Users\nikol\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.1\libraries\Wire/Wire.h:73:13: note: candidate 1: 'uint8_t TwoWire::requestFrom(int, int)'
73 | uint8_t requestFrom(int, int);
| ^~~~~~~~~~~
C:\Users\nikol\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.1.1\libraries\Wire/Wire.h:71:13: note: candidate 2: 'uint8_t TwoWire::requestFrom(uint8_t, uint8_t)'
71 | uint8_t requestFrom(uint8_t, uint8_t);
| ^~~~~~~~~~~
c:/users/nikol/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/../lib/gcc/xtensa-lx106-elf/10.3.0/../../../../xtensa-lx106-elf/bin/ld.exe: C:\Users\nikol\AppData\Local\Temp\arduino-sketch-5BFDDB9EDB939386E5CB1A13D5CC3F69\sketch\Si1151.ino.cpp.o: in function `setup':
C:\Users\nikol\AppData\Local\Temp\.arduinoIDE-unsaved2023112-24360-28iud3.owxco\Si1151/Si1151.ino:18: undefined reference to `_ZN6Si115X12ReadHalfWordEv'
c:/users/nikol/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/../lib/gcc/xtensa-lx106-elf/10.3.0/../../../../xtensa-lx106-elf/bin/ld.exe: C:\Users\nikol\AppData\Local\Temp\.arduinoIDE-unsaved2023112-24360-28iud3.owxco\Si1151/Si1151.ino:18: undefined reference to `_ZN6Si115X20ReadHalfWord_VISIBLEEv'
c:/users/nikol/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/../lib/gcc/xtensa-lx106-elf/10.3.0/../../../../xtensa-lx106-elf/bin/ld.exe: C:\Users\nikol\AppData\Local\Temp\arduino-sketch-5BFDDB9EDB939386E5CB1A13D5CC3F69\sketch\Si1151.ino.cpp.o:(.text.loop+0x14): undefined reference to `_ZN6Si115X15ReadHalfWord_UVEv'
c:/users/nikol/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/../lib/gcc/xtensa-lx106-elf/10.3.0/../../../../xtensa-lx106-elf/bin/ld.exe: C:\Users\nikol\AppData\Local\Temp\arduino-sketch-5BFDDB9EDB939386E5CB1A13D5CC3F69\sketch\Si1151.ino.cpp.o:(.text.loop+0x3a): undefined reference to `_ZN6Si115X12ReadHalfWordEv'
c:/users/nikol/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/../lib/gcc/xtensa-lx106-elf/10.3.0/../../../../xtensa-lx106-elf/bin/ld.exe: C:\Users\nikol\AppData\Local\Temp\arduino-sketch-5BFDDB9EDB939386E5CB1A13D5CC3F69\sketch\Si1151.ino.cpp.o: in function `loop':
C:\Users\nikol\AppData\Local\Temp\.arduinoIDE-unsaved2023112-24360-28iud3.owxco\Si1151/Si1151.ino:27: undefined reference to `_ZN6Si115X20ReadHalfWord_VISIBLEEv'
c:/users/nikol/appdata/local/arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.1.0-gcc10.3-e5f9fec/bin/../lib/gcc/xtensa-lx106-elf/10.3.0/../../../../xtensa-lx106-elf/bin/ld.exe: C:\Users\nikol\AppData\Local\Temp\.arduinoIDE-unsaved2023112-24360-28iud3.owxco\Si1151/Si1151.ino:28: undefined reference to `_ZN6Si115X15ReadHalfWord_UVEv'
collect2.exe: error: ld returned 1 exit status
exit status 1
Compilation error: exit status 1
I already tried using a different compilerversion (2.7.4) but the same error accured.
I might be wrong and not expirienced but the error output seems that something is messed up in the libary itselfe?
Thanks for any help. If further information is needed i am happy to give it to you.
I'm trying to compile the sitmo prng under C++11 within an R package. The problematic code has been packaged and is available here. The objective of this R package is to make available the sitmo header file so that other packages are able to use the LinkTo field within description. As an added bonus, the package is scheduled to ship with an Armadillo + OpenMP example. There is one other package, mvnfast, that uses sitmo, but only under c++98 and boost headers.
I believe that the error which I am receiving is specific to OS X and clang. I haven't been able to replicate it on Windows via win-build. With that being said, the error is:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3641:44: error: non-type template argument is not a constant expression
const size_t __logR = __log2<uint64_t, _URNG::max() - _URNG::min() + uint64_t(1)>::value;
The error has only popped up on the Rcpp dev list. The resolution in this case was to compile under C++98 and use boost.
The above error is followed by the following notes:
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3773:18: note: in instantiation of function template specialization 'std::__1::generate_canonical<double, 53, sitmo::prng_engine>' requested here
* _VSTD::generate_canonical<_RealType, numeric_limits<_RealType>::digits>(__g)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3737:17: note: in instantiation of function template specialization 'std::__1::uniform_real_distribution<double>::operator()<sitmo::prng_engine>' requested here
{return (*this)(__g, __p_);}
^
sitmo_test.cpp:77:26: note: in instantiation of function template specialization 'std::__1::uniform_real_distribution<double>::operator()<sitmo::prng_engine>' requested here
double u = distunif(engine);
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/random:3641:44: note: non-constexpr function 'max' cannot be used in a constant expression
const size_t __logR = __log2<uint64_t, _URNG::max() - _URNG::min() + uint64_t(1)>::value;
^
../inst/include/prng_engine.hpp:100:23: note: declared here
static result_type (max)() { return 0xFFFFFFFF; }
The version of clang being used is:
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
Looking into the code, there is a bug in the sitmo prng_engine.h. min() and max() were declared as
static result_type (min)() { return 0; }
static result_type (max)() { return 0xFFFFFFFF; }
If you take a look at, say, standard LCG max from here, you could see that it is declared constexpr, ditto for min.
As soon as you make those methods constexpr in the sitmo header file, I believe you could use them in template expression.
UPDATE
I've looked into GCC 5 headers, methods indeed are declared constexpr
If I press Ctrl+C, this throws an exception (always in thread 0?). You can catch this if you want - or, more likely, run some cleanup and then rethrow it. But the usual result is to bring the program to a halt, one way or another.
Now suppose I use the Unix kill command. As I understand it, kill basically sends a (configurable) Unix signal to the specified process.
How does the Haskell RTS respond to this? Is it documented somewhere? I would imagine that sending SIGTERM would have the same effect as pressing Ctrl+C, but I don't know that for a fact...
(And, of course, you can use kill to send signals that have nothing to do with killing at all. Again, I would imagine that the RTS would ignore, say, SIGHUP or SIGPWR, but I don't know for sure.)
Googling "haskell catch sigterm" led me to System.Posix.Signals of the unix package, which has a rather nice looking system for catching and handling these signals. Just scroll down to the "Handling Signals" section.
EDIT: A trivial example:
import System.Posix.Signals
import Control.Concurrent (threadDelay)
import Control.Concurrent.MVar
termHandler :: MVar () -> Handler
termHandler v = CatchOnce $ do
putStrLn "Caught SIGTERM"
putMVar v ()
loop :: MVar () -> IO ()
loop v = do
putStrLn "Still running"
threadDelay 1000000
val <- tryTakeMVar v
case val of
Just _ -> putStrLn "Quitting" >> return ()
Nothing -> loop v
main = do
v <- newEmptyMVar
installHandler sigTERM (termHandler v) Nothing
loop v
Notice that I had to use an MVar to inform loop that it was time to quit. I tried using exitSuccess from System.Exit, but since termHandler executes in a thread that isn't the main one, it can't cause the program to exit. There might be an easier way to do it, but I've never used this module before so I don't know of one. I tested this on Ubuntu 12.10.
Searching for "signal" in the ghc source code on github revealed the installDefaultSignals function:
void
initDefaultHandlers(void)
{
struct sigaction action,oact;
// install the SIGINT handler
action.sa_handler = shutdown_handler;
sigemptyset(&action.sa_mask);
action.sa_flags = 0;
if (sigaction(SIGINT, &action, &oact) != 0) {
sysErrorBelch("warning: failed to install SIGINT handler");
}
#if defined(HAVE_SIGINTERRUPT)
siginterrupt(SIGINT, 1); // isn't this the default? --SDM
#endif
// install the SIGFPE handler
// In addition to handling SIGINT, also handle SIGFPE by ignoring it.
// Apparently IEEE requires floating-point exceptions to be ignored by
// default, but alpha-dec-osf3 doesn't seem to do so.
// Commented out by SDM 2/7/2002: this causes an infinite loop on
// some architectures when an integer division by zero occurs: we
// don't recover from the floating point exception, and the
// program just generates another one immediately.
#if 0
action.sa_handler = SIG_IGN;
sigemptyset(&action.sa_mask);
action.sa_flags = 0;
if (sigaction(SIGFPE, &action, &oact) != 0) {
sysErrorBelch("warning: failed to install SIGFPE handler");
}
#endif
#ifdef alpha_HOST_ARCH
ieee_set_fp_control(0);
#endif
// ignore SIGPIPE; see #1619
// actually, we use an empty signal handler rather than SIG_IGN,
// so that SIGPIPE gets reset to its default behaviour on exec.
action.sa_handler = empty_handler;
sigemptyset(&action.sa_mask);
action.sa_flags = 0;
if (sigaction(SIGPIPE, &action, &oact) != 0) {
sysErrorBelch("warning: failed to install SIGPIPE handler");
}
set_sigtstp_action(rtsTrue);
}
From that, you can see that GHC installs at least SIGINT and SIGPIPE handlers. I don't know if there are any other signal handlers hidden in the source code.
I would like to change a program to automatically detect whether a terminal is color-capable or not, so when I run said program from within a non-color capable terminal (say M-x shell in (X)Emacs), color is automatically turned off.
I don't want to hardcode the program to detect TERM={emacs,dumb}.
I am thinking that termcap/terminfo should be able to help with this, but so far I've only managed to cobble together this (n)curses-using snippet of code, which fails badly when it can't find the terminal:
#include <stdlib.h>
#include <curses.h>
int main(void) {
int colors=0;
initscr();
start_color();
colors=has_colors() ? 1 : 0;
endwin();
printf(colors ? "YES\n" : "NO\n");
exit(0);
}
I.e. I get this:
$ gcc -Wall -lncurses -o hep hep.c
$ echo $TERM
xterm
$ ./hep
YES
$ export TERM=dumb
$ ./hep
NO
$ export TERM=emacs
$ ./hep
Error opening terminal: emacs.
$
which is... suboptimal.
A friend pointed me towards tput(1), and I cooked up this solution:
#!/bin/sh
# ack-wrapper - use tput to try and detect whether the terminal is
# color-capable, and call ack-grep accordingly.
OPTION='--nocolor'
COLORS=$(tput colors 2> /dev/null)
if [ $? = 0 ] && [ $COLORS -gt 2 ]; then
OPTION=''
fi
exec ack-grep $OPTION "$#"
which works for me. It would be great if I had a way to integrate it into ack, though.
You almost had it, except that you need to use the lower-level curses function setupterm instead of initscr. setupterm just performs enough initialization to read terminfo data, and if you pass in a pointer to an error result value (the last argument) it will return an error value instead of emitting error messages and exiting (the default behavior for initscr).
#include <stdlib.h>
#include <curses.h>
int main(void) {
char *term = getenv("TERM");
int erret = 0;
if (setupterm(NULL, 1, &erret) == ERR) {
char *errmsg = "unknown error";
switch (erret) {
case 1: errmsg = "terminal is hardcopy, cannot be used for curses applications"; break;
case 0: errmsg = "terminal could not be found, or not enough information for curses applications"; break;
case -1: errmsg = "terminfo entry could not be found"; break;
}
printf("Color support for terminal \"%s\" unknown (error %d: %s).\n", term, erret, errmsg);
exit(1);
}
bool colors = has_colors();
printf("Terminal \"%s\" %s colors.\n", term, colors ? "has" : "does not have");
return 0;
}
Additional information about using setupterm is available in the curs_terminfo(3X) man page (x-man-page://3x/curs_terminfo) and Writing Programs with NCURSES.
Look up the terminfo(5) entry for the terminal type and check the Co (max_colors) entry. That's how many colors the terminal supports.
Currently I have some code like (condensed and removed a bunch of error checking):
dp = readdir(dir);
if (dp->d_type == DT_DIR) {
}
This works swimmingly on my Linux machine. However on another machine (looks like SunOS, sparc):
SunOS HOST 5.10 Generic_127127-11 sun4u sparc SUNW,Ultra-5_10
I get the following error at compile time:
error: structure has no member named `d_type'
error: `DT_DIR' undeclared (first use in this function)
I thought the dirent.h header was crossplatform (for POSIX machines). Any suggestions.
Ref http://www.nexenta.org/os/Porting_Codefixes:
The struct dirent definition in solaris does not contain the d_type field. You would need to make the changes as follows
if (de->d_type == DT_DIR)
{
return 0;
}
changes to
struct stat s; /*include sys/stat.h if necessary */
..
..
stat(de->d_name, &s);
if (s.st_mode & S_IFDIR)
{
return 0;
}
Since stat is also POSIX standard it should be more cross-platform. But you may want to use if ((s.st_mode & S_IFMT) == S_IFDIR) to follow the standard.