RTEMS | libtest: Add packet processor (#5057)

[Gedare Bloom (@gedare)]

Gedare Bloom commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5057#note_108974


As this is a protocol, it would help to describe it in terms of a grammar and/or a state machine. In addition, the rationale for the field sizes should be explained, and what that means. The reasoning for using variable versus fixed framing would be helpful. The simplicity of this protocol seems to lend itself well to having a few well-defined packet formats. Here there are 6 different kinds of messages, with 5 different formats. It seems this could be made more regular to simplify processing.

It's not intuitive to me what a 12-bit base64url encoded value even is, are you truncating/compressing them somehow? Or, is it the 12-bit number gets base64url encoded (into 3 UTF-8 characters ==> 24 bits in the bitstream)? It would be helpful to see the description of the packets in terms of their actual contents (e.g., 3 ASCII characters in base64url encoded, 11 ASCII characters, etc.) instead of their underlying data types (12-bit number, 64-bit signal value).

Do signals and channels have semantic meaning in the protocol? If so, please explain what those are. If not, why not just define a generic way of passing data?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5057#note_108974
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240710/38a7b78e/attachment.htm>