Created Mon, 25 Mar 2013 17:52:58 +0000 by dvjcreep
Mon, 25 Mar 2013 17:52:58 +0000
I'm trying to make this you tube tutorial to work but nothing goes out good https://www.youtube.com/watch?v=FiDaNkuwgQM Main problem is that nothing works MPIDE uploads everything to the board and that's the point where everything stops working.
Can somebody please help with this ? What I'm doing wrong ? And NewSoftSerial is the same as SoftwareSerial ?
I'm begging you HELP :)
Code from video.
#include <SoftwareSerial.h>
SoftwareSerial mySerial(8, 9);//rx tx
int i;
char reader[0];
void setup(){
Serial.begin(9600); //PC
mySerial.begin(9600); //Serial
pinMode(13, OUTPUT); //LED
}
void loop(){
reader[0]=mySerial.read();
if(reader[0]=='A'){
for(i=1; i<100; i++){
reader[10]=mySerial.read();
delay(2);
}//read
}//serial
if(reader[0]=='1'&&reader[1]=='0'&&reader[2]=='N')
digitalWrite(13, HIGH);
if(reader[0]=='1'&&reader[1]=='0'&&reader[2]=='F'&&reader[3]=='F')
digitalWrite(13, LOW);
if(reader[0]=='2'&&reader[1]=='0'&&reader[2]=='N')
mySerial.print("2ON");
if(reader[0]=='2'&&reader[1]=='0'&&reader[2]=='F'&&reader[3]=='F')
mySerial.print("2OFF");
if(reader[0]=='A'&&reader[1]=='0'&&reader[2]=='N')
Serial.println("LED ON ARDUNIO 2 IS ON");
if(reader[0]=='1'&&reader[1]=='0'&&reader[2]=='F'&&reader[3]=='F')
Serial.println("LED ON ARDUNIO 2 IS OFF");
for(i=0; i<10; i++)
reader[i]=0;
}//loop
Mon, 25 Mar 2013 19:50:15 +0000
char reader[0];
That immediately rings alarm bells. You can't have an array of size 0. It makes no sense. That should be a bigger number in there - it looks like 100 is the biggest size you reference...
reader[0]=mySerial.read();
if(reader[0]=='A'){
for(i=1; i<100; i++){
reader[10]=mySerial.read();
delay(2);
}//read
}//serial
You're reading a character into the first element of reader, and if it's "A" then immediately read 99 more characters with a 2ms delay into element 10 of the reader array - whether or not they have been received. So you end up with "A" in element 0, and who knows what in element 10. The rest of the array is still empty at this point.
if(reader[0]=='1'&&reader[1]=='0'&&reader[2]=='N')
digitalWrite(13, HIGH);
It's never going to happen. reader[0] could be anything - whatever was sent. reaser[1] and reader[2] you're not setting to anything, so how can they be "0" and "N"?
Oh, and you need to learn the difference between "0" and "O" - the ChipKit knows the difference, but you don't seem to... You're spelling ON and OFF as 0N and 0FF - that's Zero-N and Zero-F-F
And one other thing. You know that big long button at the bottom of the keyboard? It's called a "Space Bar". I suggest you use it sometimes.
Mon, 25 Mar 2013 19:58:23 +0000
It's not all your fault though - I just took a look at that video, and the person who made it doesn't seem to know much themselves. The program they have written is just plain wrong. I suggest you completely ignore that video and start from scratch, learning the right way of doing it.
Tue, 26 Mar 2013 01:46:03 +0000
This is how I would do a parser (set your Serial Monitor for Carriage Return on line endings)
char buff[0x20];//buffer to hold input
char ctr; //keeps track of position in buffer
char ch; //holds last character received
void setup() {
pinMode(PIN_LED1, OUTPUT);
Serial.begin(115200);
}
void loop() {
if (Serial.available() > 0)
{
ch = Serial.read();
if( ctr < sizeof(buff)) { //don't over run the buffer
buff[ctr++] = ch;
}
if (ch == '\r') // when I get a carriage return
{
buff[ctr-1] = 0; //replace the carriage return in the buffer with 0 which
//terminates strings
ctr = 0; //reset the buffer pointer
if (strcmp(buff, "1on") == 0)
{
digitalWrite(PIN_LED1, HIGH);
}
else if (strcmp(buff, "1off") == 0)
{
digitalWrite(PIN_LED1, LOW);
}
else if (strncmp(buff, "led",3) == 0) //test only the first three characters
{
digitalWrite(PIN_LED1, buff[3]-'0');//use the fourth character
//if '0' then off else on
}
} // end of if I get a carriage return
} //end of serial available
}
Tue, 26 Mar 2013 09:56:36 +0000
See now, that's the right way of doing it.
Only one comment - in this program it's perfectly fine, and nothing to worry about, but I usually tend to empty the serial buffer with each pass - instead of an "if" controlling it, use a "while" - so for each pass through loop() you process everything that's available. It makes it smoother running if you have more things happening in loop. Of course, that's just personal taste ;)
Also, I tend to handle more characters than just a carriage return. I usually have a nice switch structure handling such things as CR, LF, backspace, del, etc and echo the characters back to the user as they're typed. This allows you to use a proper terminal emulator to interact with the system in a way that is much more meaningful. But again, that's juts me ;)
Mon, 08 Apr 2013 19:44:47 +0000
Only one comment - in this program it's perfectly fine, and nothing to worry about, but I usually tend to empty the serial buffer with each pass - instead of an "if" controlling it, use a "while" - so for each pass through loop() you process everything that's available. It makes it smoother running if you have more things happening in loop. Of course, that's just personal taste ;)
The tradeoff of using while() over if() is if you have really heavy serial communications you could starve the rest of the loop(). But this I think this would a case of a trade off decision per application. If you communications is light then while() may be better than if() for above stated reasons.
Jacob
Tue, 09 Apr 2013 08:55:27 +0000
Well, yes it's all a matter of priorities.
Human interaction tends to come in short bursts (especially with the serial monitor sending a line at a time), so "while" is better in that situation.
If it's a constant stream of data then yes, you need to interleave it with your other operations more, so "if", or a limited "while" (process up to X characters in one batch) can be better.
Of course, even better is to use interrupt driven comms, so that as characters become available they are handled, and at all other times the system just gets on with what it's doing. Unfortunately the way the Arduino-esque boards handle the serial, interrupt driven comms is not really very easy. What would be nice would be if we could attach hooks to different parts of the system, like the serial interrupts, so that you can call your own function instead of the system default one. Then you could write your own interrupt handler for the received characters and make a more efficient system than the generalised and abstracted one that is there by default.