Closed PropGit closed 7 years ago
@dbetz - I'm concerned that wasn't clear enough in the post above as there are many related factors mixed in. I can be more specific and form cases that should result in certain errors in individual issues if that helps.
"Propeller not found" seems pretty clear.
This is done for serial loading. I'm still working on wi-fi loading.
I've verified this update works for wired serial loading (via Windows and Mac platforms; did not test Linux).
I've verified PropLoader v1.0-33 (commit 0d30b50) now works properly for this issue for both wired and wireless serial loading. Tested on Windows platform with Parallax Wi-Fi Module firmware v1.0 (2017-02-13 12:35:45 11-gecbba49).
This relates to Issue #27 but making specific message issue for this one.
[From an email conversation between @dbetz and @PropGit]
Thanks for confirming that
Yes, well... keep the "Handshake failed" (for -v) but that's a fail point that should also emit a "Propeller not found" message (regardless of -v).
More specifically, the "Propeller not found" error message should occur at any fatal moment from the point of receiving the Rx Handshake through just after receiving the version number, unless of course, a valid number of bytes is received for version response but it just equates to a different-than-expected version number, in which case it should be reporting that it found "Propeller 1 version #" but also indicate that it can not program that version of Propeller. If no Rx Handshake, or later, version number, is received, or the received data for Rx Handshake is invalid, it should say "Propeller not found" because either nothing's there, or something's there but we don't know what.
Yes, we'll need to distinguish the "RX handshake timeout" from other errors (is there also a "Bad Rx Handshake" and "Version Timeout" and "Bad Version Response" (i.e.: too little or too many bytes received) error message?) and the PropLoader will need to address at least those specific errors so it can display "Propeller Not Found" if that's the case.
I think we can use 400 as a generic failure error (one we don't specifically process a certain way within the loader) and use 401+ for the other specific errors; rather than try to map each case to an existing 4xx error message commonly use by the Internet since there's unlikely to be any that will really match appropriately.