// Read and store Sensor 1 data
Sensor1Data = analogRead(Sensor1Pin);
// Convert integer data to Char array directly
itoa(Sensor1Data,Sensor1CharMsg,10);
How are you going to fit '1', '0', '2', '3' and the trailing NULL in a 4 element array?
Isn't the above a 5 element array (0 1 2 3 4), or have I got it wrong?
No, it is not. The value in the brackets is the number of elements, not the upper index.
Any thoughts on what might actually cause the hangs?
What I like to do is fix the bugs as a become aware of them, and see what effect that has on the program. You have a known bug. Fix it, and let us know what impact that has on your problem.
Thanks for the tip!
So now I've changed both the transitter and receiver code as below and uploaded to both boards. However the change in behaviour seems minimal. If anything I do get a few more lines to run by in Serial Monitor before things hang again.
char Sensor1CharMsg[5];
All parts of the code work if I run them separately so I can't really tell where the problem lies. Is there something I can do to get more info on what causes the crash?
What about the Serial.print lines? If you remove all those, does the program work? I had a problem recently when I started using Serial.print for debugging and it ended up restarting the arduino over and over again while it was trying to run the code. I think it was something to do with a memory issue.
char Sensor1CharMsg[4];
...
void dataRX()
{
...
uint8_t buflen = VW_MAX_MESSAGE_LEN;
// Non-blocking
if (vw_get_message(buf, &buflen))
{
...
// Message with a good checksum received, dump it.
for (i = 0; i < buflen; i++)
{
// Fill Sensor1CharMsg Char array with corresponding
// chars from buffer.
Sensor1CharMsg[i] = char(buf[i]);
}
Classic buffer overflow bug. Even if you have increased Sensor1CharMsg to 5 elements, the version of VirtualWire.h I just looked at (1.9) defines VW_MAX_MESSAGE_LEN as 30. So the above code will write beyond the end of the buffer, if you receive a message more than 4 or 5 bytes long. Never trust input to be in the expected form, even if it is (in theory) under your control.
On my hard disk the version that I have claims to be 1.6 (!) and in that, the vw_get_message function appears to only return the requested number of bytes, at most.
That compiled, as I suspect you already knew. Unfortunately I will have to wait a couple of hours before I can try it live. However as I do like to know what I'm coding could you please tell me or point me in a good direction to find reading material as to what actually is done in that line. Am I just stating that buf is a const char* or does (const char*)buf perform some sort of change?
Am I just stating that buf is a const char* or does (const char*)buf perform some sort of change?
You're just telling the compiler that you want the pointer to "buf" to be treated as though it were a "const char*", even though you know it is a pointer to a different type.
Because it is a pointer to a datatype with the same size, this is normally perfectly OK, particularly as in this case, where the buffer simply contains ASCII data.
Sorry to say I got the same problem as before. A couple of lines fly by in the Serial Monitor before it hangs. Commenting out the Serial.print lines does not help either.
Again if I don't include the colorControl(); function everything seems to work just fine.
Ok, so I've changed the ledpins to use pin 3, 5 and 6.
This actually stops Serial Monitor output from hanging. But it still seems to hang after a while when the Sensor1Data gets stuck with the same number.
Makkan:
But it still seems to hang after a while when the Sensor1Data gets stuck with the same number.
Perhaps the device is no longer receiving data over VirtualWire then? In which case, either receiving has stopped, or the other device has stopped sending data. You need to determine which.