Closed PropGit closed 7 years ago
What about other reasons for the protocol failing? Currently, the TransmitPacket function can fail if it tries 3 times and each attempt gets a timeout. It can also fail if it gets data but the packet ID or tag is wrong. Do we want errors for each of those cases?
Yes, other reasons for protocol failing at that point were intended to be covered by this issue too. For the timeout cases, they can result in the example I gave "126-ERROR: Communication lost."
Actually, even the case where it gets the wrong packet ID or the tag is wrong... those can also use the same "126-ERROR: ..." result. If we need to know more, we can use the verbose option to see that it did indeed receive something, but it was an unexpected result.
This way, we don't need 10 new error codes (1 to cover each case), but perhaps much fewer (1, 2 or 3 maybe) that nicely covers all cases. Let me know if you question certain error cases and what error to emit.
NOTE: 126 was just the next error code at the time of this issue's creation; it should be set to the proper value when created.
I currently have three errors that could fall into this category:
RX handshake timeout RAM checksum timeout EEPROM checksum timeout
Do you want all of these to produce the "Communication lost" error?
done
Did you implement each of those three with a single "Communication lost" error? That was the intent, yes.
Verified on v1.0-37.
[This request created in response to Issue #27]
In much the same way that the added "Propeller not found" error message clarifies download failures, we need a Communication lost message.
This should apply to both wired and wireless downloads and should appear before the "ERROR: Download failed: -1" message so that instead of something like this:
we see this (assuming no response was received for the RAM checksum and assuming the error code is 126):