Well, IBM owns a lot of Java, so it's pretty safe for them to use it. I just wouldn't use it for a new project because the future of Java is still murky.
If you're talking about Oracle's stewardship of it, then yeah, I see your point. I hope it doesn't die off completely since some programs I rely on personally are written (partly or in full) in Java.
I still can't get it to work. It won't respond to me sending "go". #include <Servo.h> #define STRING_LENGTH 2 // how many bytes is the string, in this case five Servo tilt; int pos = 0; const int gledPin = 13; const int rledPin = 12; const int lazrPin = 11; void setup() { pinMode(rledPin, OUTPUT); pinMode(gledPin, OUTPUT); pinMode(lazrPin, OUTPUT); tilt.attach(10); digitalWrite(gledPin, HIGH); Serial.begin(9600); // start serial port at 9600 bps: } void loop(){ char buffer[STRING_LENGTH]; // a place to store the string // if there are enough bytes available on the serial port if( Serial.available() >= STRING_LENGTH) { // put them in the buffer int i = 0; for(i=0; i < STRING_LENGTH; i++) { buffer[i] = Serial.read(); } } if (buffer == "go") { digitalWrite(rledPin, HIGH); digitalWrite(lazrPin, HIGH); int max = 5; int i = 0; for(i = 0; i < max;i++){ for(pos = 32; pos < 169; pos += 1) // goes from 32 degrees to 169 degrees { // in steps of 1 degree tilt.write(pos); // tell servo to go to position in variable 'pos' delay(15); // waits 15ms for the servo to reach the position } for(pos = 169; pos>=32; pos-=1) // goes from 169 degrees to 32 degrees { tilt.write(pos); // tell servo to go to position in variable 'pos' delay(15); // waits 15ms for the servo to reach the position } } digitalWrite(rledPin, LOW); digitalWrite(lazrPin, LOW); } }
In C and C++ you can't compare strings with ==. You have to use strcmp(). http://www.cplusplus.com/reference/clibrary/cstring/strcmp/. In fact, for almost everything you do involving a string, you want to use a function from string.h. For example, if you want to add two strings together, you use strcat().
Using operators to work with strings is strictly something you should only do when using higher level dynamically typed languages like Python, PHP, Ruby, etc.
Only use == when you're dealing with fundamental data types - ints, chars, etc. Otherwise, == tends to check if two objects are pointing to the same location in memory, which tends to not work so well.
okay, so I added a line in Void loop char start[] = "go"; and replaced the if statement with if (strcmp (start,buffer) != 0) but then it just bypassed the if statement entirely. THEN I actually read the whole page Scott linked to and had a "duh" moment. So, taking into account what linkigi said about ==, I looked up C++ operators... but that pretty much said to USE ==. So I tried using if (strcmp (start,buffer) == 0) but now nothing happened at all when I sent "go" through the serial monitor.
Java is dying, so I try to avoid it.
In terms of it's ownership by Oracle?
Yeah, I wouldn't build anything on such an unstable foundation.
That's the sentiment floating around the comp sci department these days.
In C and C++ you can't compare strings with ==. You have to use strcmp(). http://www.cplusplus.com/reference/clibrary/cstring/strcmp/. In fact, for almost everything you do involving a string, you want to use a function from string.h. For example, if you want to add two strings together, you use strcat().
strcmp() won't work here, or at least it won't work predictably. You'll probably have a buffer overflow with it because your buffer is exactly 2 bytes long, doesn't have room for a zero-terminator, and probably won't be zero-terminated even if it was big enough to hold one. strcmp() only works with zero-terminated strings. What strcmp() will probably do in this case is just keep going on past STRING_LENGTH, touching whatever memory it stumbles upon past the end of your buffer until it either crashes your program or happens to stumble upon a zero character somewhere in memory.
What you probably want to do is use memcmp() or strncmp() like this: if (strncmp(buffer, "go", STRING_LENGTH) == 0) { // etc... etc... }
memcmp() would be the same arguments and argument order, but you may prefer to use strncmp() here as it preserves the idea that you're comparing strings as opposed to raw memory buffers. strncmp() does differ from memcmp() in that it will stop if it encounters a zero-terminater whereas memcmp() keeps going for the entire length you specify, but both should be equivalent in this scenario.
Alternately, you could also do something like this if you want to use strcmp(): const int STRING_LENGTH = 2; // There is no need to use #define for constants anymore.
// Code here... yadda yadda...
char buffer[STRING_LENGTH + 1]; // Desired buffer size plus zero-terminator space
// More code here...
for(i=0; i < STRING_LENGTH; i++) { buffer[i] = Serial.read(); } buffer[STRING_LENGTH] = '\0'; // This is where you zero-terminate it for strcmp()
// More code, etc...
if (strcmp(buffer, "go") == 0) { // etc... etc... }
This second solution is probably more flexible as then you can treat it just like any regular C string as opposed to a raw memory buffer/unterminated string that you have to handle slightly differently.
Using operators to work with strings is strictly something you should only do when using higher level dynamically typed languages like Python, PHP, Ruby, etc.
Actually, if you're using std::string in C++ (#include <string>), you can use ==. It's part of the C++ standard library and what you should be using for general purpose strings (as opposed to character buffers like what you have here) in any/all C++ code. Yay operator overloading (and a bunch of other nice benefits that std::string brings you).
Actually, if you're using std::string in C++ (#include ), you can use ==. It's part of the C++ standard library and what you should be using for general purpose strings (as opposed to character buffers like what you have here) in any/all C++ code. Yay operator overloading (and a bunch of other nice benefits that std::string brings you).
Thanks for reminding me why I hate C++. You can keep your :: and your to yourself, thanks.
okay, so I added a line in Void loop char start[] = "go"; and replaced the if statement with if (strcmp (start,buffer) != 0) but then it just bypassed the if statement entirely. THEN I actually read the whole page Scott linked to and had a "duh" moment. So, taking into account what linkigi said about ==, I looked up C++ operators... but that pretty much said to USE ==. So I tried using if (strcmp (start,buffer) == 0) but now nothing happened at all when I sent "go" through the serial monitor.
Sounds like the issue I mentioned about unterminated strings. It's not crashing, but it's not comparing properly since strcmp() doesn't know where your buffer, 'buffer', ends due to not being terminated.
Actually, if you're using std::string in C++ (#include ), you can use ==. It's part of the C++ standard library and what you should be using for general purpose strings (as opposed to character buffers like what you have here) in any/all C++ code. Yay operator overloading (and a bunch of other nice benefits that std::string brings you).
Thanks for reminding me why I hate C++. You can keep your :: and your to yourself, thanks.
I never said C++ was syntactically pretty... Personally, I prefer straight C for low-level coding myself, but there are a handful of things I do like about C++. std::string is one of them, though I do hate having to use that :: specifier all the time (or having to do a 'using namespace whatever' if I want to avoid it).
Not really "Weekend Coding" as it's part of my job, but...
This is my implementation of SLAM using an Extended Kalman Filter. Blue Stars are landmarks in the environment. Blue Path is the robots actual path and location. Green is the robot's belief using just dead reckoning. Red is the SLAM estimation with the red pluses being the approximated location of the landmarks, the path being the robot's belief of it's location using SLAM and the red ellipse being it's covariance ellipse of it's uncertainty.
What you probably want to do is use memcmp() or strncmp() like this: if (strncmp(buffer, "go", STRING_LENGTH) == 0) { // etc... etc... }
That worked perfectly! Thanks Lou. Now, if I'm reading the code correctly, the buffer should autoclear after the "if" ends as it goes back from the top of the loop and the serial buffer code starts back up. But Arduinos are my first real foray into programming, so please correct me if I'm wrong. I probably am, because I re-sending "go" after the first go around and it does nothing (like my goggles). Still, I'll venture out and look for how to clear a string.
I started playing around with PHP and MySQL yesterday and I'm definitely liking them. So far I've made a simple "address book" and a file uploader/deleter; I plan on adding search functionality to both of them tomorrow.
Is there a reason you are programming the Arduino with C++ instead of Processing?
Isn't the arduino language a subset of c/c++?
Well, Processing is actually it's own language, that is Java-ish. It's designed to be really easy so artists and other non-programmers can use it. At that, it succeeds very well. For what you are doing, there's really no reason you shouldn't just use Processing. It will be easier in every conceivable way. Stick with the defaults.
That worked perfectly! Thanks Lou. Now, if I'm reading the code correctly, the buffer should autoclear after the "if" ends as it goes back from the top of the loop and the serial buffer code starts back up. But Arduinos are my first real foray into programming, so please correct me if I'm wrong. I probably am, because I re-sending "go" after the first go around and it does nothing (like my goggles). Still, I'll venture out and look for how to clear a string.
No problem. However, I'm not sure what you mean by "autoclear." When you reach the top of the loop, what's in the buffer already will remain in the buffer, but it should be overwritten by the calls to Serial.read(), so I don't think this will be an issue in this case. If you really need to make an "empty" string for some reason, the best way would probably be to just overwrite the whole string with zero characters. You can do that by calling memset(buffer, 0, STRING_LENGTH)
Oh, and like Apreche said, if you can get what you want done with Processing, you're probably better off doing it that way. I don't know enough about Processing myself, but based on what I've heard, I agree with him that it should be much easier to use with many fewer gotchas than C++ (and I'm saying this as someone who works with C++ every day).
The thing with switching to processing is I'm like "Great. I'm just getting used to C++ and now I gotta learn THIS new thing."
I'm not sure how prosessing work with what you are doing but making graphics with that is just too easy. Making box is just box(size);. How it can get easier?
The thing with switching to processing is I'm like "Great. I'm just getting used to C++ and now I gotta learn THIS new thing."
Fair enough, though it looks like Processing is at least somewhat syntactically similar to C++, which means the learning curve wouldn't be that bad -- especially if you don't have to worry about C/C++ buffer handling and other little nasty bits that can cross you up like what you've been facing here.
The thing with switching to processing is I'm like "Great. I'm just getting used to C++ and now I gotta learn THIS new thing."
It's not much different. People who say they know X language are generally people who are no good at programming. If you tell me tomorrow to make something in F#, Clojure, Erlang, or Scala, I could do it. I've never used any of those languages ever. I would have a slow start looking things up in books, but I would be rolling after a few days. If you know how to program, you can use any language. Also, Processing is so easy and similar to what you are doing, you'll be done so fast. Just get the official Arduino software, a tutorial, and gogogo.
You didn't think I was writing this in Visual Studio, did you? The reason I said I was programming in C++ was because that's what the Arduino site says.
In fact, you already are; the Arduino language is merely a set of C/C++ functions that can be called from your code. Your sketch undergoes minor changes (e.g. automatic generation of function prototypes) and then is passed directly to a C/C++ compiler (avr-g++). All standard C and C++ constructs supported by avr-g++ should work in Arduino. For more details, see the page on the Arduino build process.
See, I've seen that, but I thought that was just the name of the IDE until you started talking about it. Even then I thought that maybe they made the IDE with processing.
Comments
#include <Servo.h>#define STRING_LENGTH 2
// how many bytes is the string, in this case five
Servo tilt;
int pos = 0;
const int gledPin = 13;
const int rledPin = 12;
const int lazrPin = 11;
void setup()
{
pinMode(rledPin, OUTPUT);
pinMode(gledPin, OUTPUT);
pinMode(lazrPin, OUTPUT);
tilt.attach(10);
digitalWrite(gledPin, HIGH);
Serial.begin(9600); // start serial port at 9600 bps:
}
void loop(){
char buffer[STRING_LENGTH]; // a place to store the string
// if there are enough bytes available on the serial port
if( Serial.available() >= STRING_LENGTH)
{
// put them in the buffer
int i = 0;
for(i=0; i < STRING_LENGTH; i++)
{
buffer[i] = Serial.read();
}
}
if (buffer == "go")
{
digitalWrite(rledPin, HIGH);
digitalWrite(lazrPin, HIGH);
int max = 5;
int i = 0;
for(i = 0; i < max;i++){
for(pos = 32; pos < 169; pos += 1) // goes from 32 degrees to 169 degrees
{ // in steps of 1 degree
tilt.write(pos); // tell servo to go to position in variable 'pos'
delay(15); // waits 15ms for the servo to reach the position
}
for(pos = 169; pos>=32; pos-=1) // goes from 169 degrees to 32 degrees
{
tilt.write(pos); // tell servo to go to position in variable 'pos'
delay(15); // waits 15ms for the servo to reach the position
}
}
digitalWrite(rledPin, LOW);
digitalWrite(lazrPin, LOW);
}
}
buffer == "go"
is correct?
If the language is essentially C, which it definitely seems to be, that won't work the way you want it to.
Using operators to work with strings is strictly something you should only do when using higher level dynamically typed languages like Python, PHP, Ruby, etc.
char start[] = "go";and replaced the if statement with
if (strcmp (start,buffer) != 0)but then it just bypassed the if statement entirely. THEN I actually read the whole page Scott linked to and had a "duh" moment. So, taking into account what linkigi said about ==, I looked up C++ operators... but that pretty much said to USE ==. So I tried using
if (strcmp (start,buffer) == 0)but now nothing happened at all when I sent "go" through the serial monitor.That's the sentiment floating around the comp sci department these days.
What you probably want to do is use memcmp() or strncmp() like this:
if (strncmp(buffer, "go", STRING_LENGTH) == 0)
{
// etc... etc...
}
memcmp() would be the same arguments and argument order, but you may prefer to use strncmp() here as it preserves the idea that you're comparing strings as opposed to raw memory buffers. strncmp() does differ from memcmp() in that it will stop if it encounters a zero-terminater whereas memcmp() keeps going for the entire length you specify, but both should be equivalent in this scenario.
Alternately, you could also do something like this if you want to use strcmp():
const int STRING_LENGTH = 2; // There is no need to use #define for constants anymore.
// Code here... yadda yadda...
char buffer[STRING_LENGTH + 1]; // Desired buffer size plus zero-terminator space
// More code here...
for(i=0; i < STRING_LENGTH; i++)
{
buffer[i] = Serial.read();
}
buffer[STRING_LENGTH] = '\0'; // This is where you zero-terminate it for strcmp()
// More code, etc...
if (strcmp(buffer, "go") == 0)
{
// etc... etc...
}
This second solution is probably more flexible as then you can treat it just like any regular C string as opposed to a raw memory buffer/unterminated string that you have to handle slightly differently. Actually, if you're using std::string in C++ (#include <string>), you can use ==. It's part of the C++ standard library and what you should be using for general purpose strings (as opposed to character buffers like what you have here) in any/all C++ code. Yay operator overloading (and a bunch of other nice benefits that std::string brings you).
This is my implementation of SLAM using an Extended Kalman Filter. Blue Stars are landmarks in the environment. Blue Path is the robots actual path and location. Green is the robot's belief using just dead reckoning. Red is the SLAM estimation with the red pluses being the approximated location of the landmarks, the path being the robot's belief of it's location using SLAM and the red ellipse being it's covariance ellipse of it's uncertainty.
http://processing.org/
Oh, and like Apreche said, if you can get what you want done with Processing, you're probably better off doing it that way. I don't know enough about Processing myself, but based on what I've heard, I agree with him that it should be much easier to use with many fewer gotchas than C++ (and I'm saying this as someone who works with C++ every day).
http://arduino.cc/en/Main/Software
You didn't think I was writing this in Visual Studio, did you? The reason I said I was programming in C++ was because that's what the Arduino site says.
Based on processing...