Use the sync type flag in SPWF04SA
Arke64 opened this issue · 5 comments
Apparently the WIND field has meaning in responses as well. We could just skip anything 0xFE to simplify the response reading in the higher level commands. Especially since things like cert loading may or may not happen.
Y == 0x03 appears to mean payload, not AT-S.ERROR.
Moved from ghi-electronics/TinyCLR-Libraries#180
https://community.st.com/s/question/0D50X00009XkXCySAN/how-to-use-the-sockdw-command-correctly-over-spi-on-spwf04sa updated link
Relevant post:
I assume you are still using old FW1.0.0 (CrLf inside the packet...)
'02 1* X other' means +WIND ASync messages number X
'02
2
*
X
other
' means critical
+WIND ASync messages number X (module will reboot)
'02 3* Y
other
' means
Sync messages (AT-S.something)
About Sync messages:
'Y == 0xFF' means AT-S.something that cannot be masked (your 'On')
'Y == 0xFE' means AT-S.something that can be masked by console_verbose variable (your 'Reading')
'Y == 0x00
' means AT-S.OK
'Y == Z
' means AT-S.ERROR number Z ( where: 0 < Z < 120 )
So for KindOfEvent == 0x03, payload data, the manual doesn't assign any meaning to the Indication Number field. According to the above post and our tests, it does appear to have a meaning.
0x00: AT-S.OK without payload
0x03: AT-S.OK with payload
0xFF: AT-S.x not maskable
0xFE: AT-S.x maskable
Right now we don't actually do anything based on that. In the future we may be able to just ignore 0xFE events, like cert loading as mentioned in the op. 0x00 could be used to signify this is the last chunk of data in a response, which could force any threads expecting more data to return regardless instead of blocking forever. 0xFF could be used to signal a response parameter and not the actual payload we care about, like the HTTP response code before the payload.
Could be signaled like so:
0x00: this.activeCommand.Done();
0x03: this.activeCommand.ReadPayload();
0xFE: this.activeCommand.AddOptionalResponseMessage(…);
0xFF: this.activeCommand.AddResponseMessage(…);
This would allow the command impls to just read the payload and not have to worry about what exact optional messages are received (since they're not documented in the manual) and only extract the response messages that they need, like IP address or HTTP code.
We could also use the Y == Z case to signal errors back to the command and its reader, poisoning it in the same way mentioned in #21, not just raising an error received event.
No longer support this wifi.