- Like Paul said, seems as though Serial and Serial1 are not really independent at all, as some of the literature suggests.
My attempts at debugging by sending back information from Serial.print to the Serial Monitor were part of the problem!
Deleting all my Serial.print "debugging" calls, apart from at the end of the main loop, and allowing Serial1 to get on with reading the data without interruption made a big difference.
They ARE completely independent. But, there is a limited amount of memory and serial data receiving and sending takes time. That time takes away from doing other things. By removing the serial output statements, you sped up the input data processing and reduced the amount of memory needed.
Since Serial is only for debugging, there is no reason to not operate it at its maximum speed (115200).
- Putting a "delay(1)" before every "Serial1.read()" statement also seems to be essential.
Not sure why this is the case - maybe someone can explain?
(It does not seem to be necessary before "if (Serial1.available())" statements).
The key there is "seems". There should be no need to wait after you've determined that there is something available to read.
- Using a different USB cable sorted out the problem with the 'SERIAL_8E1 was not declared in this scope' error, and other bizarre errors on trying to upload the code.
The compiler knows nothing about the USB cable you will use. You changed something else.
while (Serial1.available() < 0){ // keep looping until data available
The range of values that the available() method returns ranges from 0 (nothing in the buffer) to 64 (the buffer is full). The available method never returns a negative value. So, this statement never evaluates to true, and, therefore, never does execute the body. Not that there is anything to do if it did evaluate to true.
if (Serial1.available() > 0 ){
// If 7E is followed by more data, this must be a start flag
data[n] = d;
n++;
state = 2; // change state to "Read"
Having just read the one character in the buffer, the 0x7E, it is nearly certain that the buffer will now be empty, so this statement will not evaluate to true. Or, rather, it wouldn't if time wasn't spend sending serial data between the last read and this test.
Building in timing dependencies is really not a good idea.
while (Serial1.available() < 0){ // keep looping until data available
}
Another incorrect assumption/test.
if ((d != 0x7E) && (d != 0x7D)){
data[n] = d;
n++;
}
Assuming that there is room in the buffer is not a good idea.