Hi. I have a question about the pyocd remote protocol. (tcp_probe_server.py and tcp_probe_client.py)
What would be needed to be able to implement pyocd remote protocol in a microcontroller?
At this moment, the length of write_block32 and write_block8 is unlimited. That is a problem if memory is limited, as in microcontrollers.
There are two possibilities to process json:
- the server reads the whole json request in a buffer before processing.
- the server does not wait until the end of the json request to start processing, but processes the json request as it is received.
If the server reads the whole json request in a buffer before processing there ought to be a way for the server to tell the client the maximum json request length.
If the server processes the json request as it comes in, then the receiving buffer can be quite small, but then the order of the attribute-value pairs in the json request is no longer arbitrary. To process json as it comes in, "request" has to come before "arguments"; "address" has to come before "data", etc. The order as specified in remote_probe_protocol is fine; the only thing that needs to be added to the protocol spec is that the client has to send the attribute-value pairs in the order specified.
The most general solution would be to do both - server tells client maximum json length, and order of attribute-value pairs is specified.
Opinion?
koen
Hi. I have a question about the pyocd remote protocol. (tcp_probe_server.py and tcp_probe_client.py)
What would be needed to be able to implement pyocd remote protocol in a microcontroller?
At this moment, the length of write_block32 and write_block8 is unlimited. That is a problem if memory is limited, as in microcontrollers.
There are two possibilities to process json:
If the server reads the whole json request in a buffer before processing there ought to be a way for the server to tell the client the maximum json request length.
If the server processes the json request as it comes in, then the receiving buffer can be quite small, but then the order of the attribute-value pairs in the json request is no longer arbitrary. To process json as it comes in, "request" has to come before "arguments"; "address" has to come before "data", etc. The order as specified in remote_probe_protocol is fine; the only thing that needs to be added to the protocol spec is that the client has to send the attribute-value pairs in the order specified.
The most general solution would be to do both - server tells client maximum json length, and order of attribute-value pairs is specified.
Opinion?
koen