Sun Aug 10 09:43:44 BST 2008
Revising boot monitor
To prepare for proper routing of the monitor protocol, all commands
should be self-delimiting. Note that the protocol remains RPC: each
request receives a reply.
Q: Should the interpreter ignore messages it doesn't understand? If
so, what should be the reply?
Probably not. This is a debugging protocol where the slave gives full
access to the host. Limiting access by checking if some messages are
legal or not makes no sense in this setting: it's the host's
responsability to properly drive the target in this mode.
Q: Should the monitor protocol be explicitly specified?
No. It is the responsability of the application developper to use the
proper protocol since it might be extended for specific applications.
Q: What with PING? I'm starting to run out of boot monitor space.
Maybe it's best to take this out. It's not essential. And
identification data can always be added to block 0, which is
essentially unused: the host knows what kind of target it is, and for
each target type, a storage area can be assigned.
Next: clean up live/tethered.ss so there is a clear delimited message
send/receive part in the protocol, instead of the current "send header
then send body" approach.
Q: Should we send "write at address" or "set address pointer" +
Opting for the latter. It seems to be easiest when sending multiple
So, rewrite is done. All messages in 2 directions are now
length-prefixed byte strings that do not require interpretation to be
repeated or routed. The tethered.ss code is refactored into async
send/receive for messages and rpc functions. 'ping is removed and
replaced with a simple target-sync ack = OK mechanism, which enabled
the monitor code to fit into the 256 words again, after interpreter
changes for delimited messages.