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.
It's the receiver that stops receiving.
And it seems it is colorControl() that somehow mixes things up. If I just comment that one out, I can go on for ages.
You appear to still have your LEDs connected to pins 9 and 10, which the VirtualWire class uses, unless you tell it to use other pins. Which you don't.
So, it's hardly surprising that as soon as you write to those pins VirtualWire quits working.
PaulS:
You appear to still have your LEDs connected to pins 9 and 10, which the VirtualWire class uses, unless you tell it to use other pins. Which you don't.
So, it's hardly surprising that as soon as you write to those pins VirtualWire quits working.
Nope, dc42 noted this a while back so I've changed to pins 3,5 and 6.
dc42:
What happens if you just comment out the analogWrite calls?
That works, it's up and running hand still works after five minutes of continous running. So it seems to be analogWrite that causes trouble.
well. I am the less qualified here and maybe I should not interfere, but I also had problem with arduino uno hanging when converting integers into arrays of characters and back into integers, and I solved the problem gradually incresing the size of the array [x] untill it worked...