Skip to content

Commit cde822c

Browse files
author
Paul Sokolovsky
committed
README: Add "Technical details" sections.
1 parent 754c1a5 commit cde822c

File tree

1 file changed

+82
-0
lines changed

1 file changed

+82
-0
lines changed

README.md

Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -29,3 +29,85 @@ via webrepl.html client). Run
2929
to see usage information. Note that there can be only one active
3030
WebREPL connection, so while webrepl.html is connected to device,
3131
webrepl_cli.py can't transfer files, and vice versa.
32+
33+
34+
Technical details
35+
-----------------
36+
37+
WebREPL is the latest standard (in the sense of an Internet RFC) for
38+
communicating and controlling a MicroPython-based board. Following
39+
were the requirements for the protocol design:
40+
41+
1. Single connection/channel, multiplexing terminal access, filesystem
42+
access, and board control.
43+
44+
2. Network ready and Web technologies ready (allowing access directly
45+
from a browser with an HTML-based client).
46+
47+
Based on these requirements, WebREPL uses single connection over
48+
[WebSocket](https://en.wikipedia.org/wiki/WebSocket) as a transport
49+
protocol. Note that while WebREPL is primarily intended for network
50+
(usually, wireless) connection, due to its single-connection,
51+
multiplexed nature, the same protocol can be used over a lower-level,
52+
wired connection like UART, SPI, I2C, etc.
53+
54+
Few other traits of WebREPL:
55+
56+
1. It is intended (whenever possible) to work in background, i.e.
57+
while WebREPL operations are executed (like a file transfer), normal
58+
REPL/user application should continue to run and be responsive
59+
(though perhaps with higher latency, as WebREPL operations may
60+
take its share of CPU time and other system resources). (Some
61+
systems may not allow such background operation, and then WebREPL
62+
access/operations will be blocking).
63+
64+
2. While it's intended to run in background, like a Unix daemon,
65+
it's not intended to support multiple, per-connection sessions.
66+
There's a single REPL session, and this same session is accessible
67+
via different media, like UART or WebREPL. This also means that
68+
there's usually no point in having more than one WenREPL connection
69+
(multiple connections would access the same session), and a
70+
particular system may actually limit number of concurrent
71+
connections to ease implementation and save system resources.
72+
73+
WebREPL protocol consists of 2 sub-protocols:
74+
75+
* Terminal protocol
76+
77+
This protocol is finalized and is very simple in its nature, akin
78+
to Telnet protocol. WebSocket "text"-flagged messages are used to
79+
communicate terminal input and output between a client and a WebREPL-
80+
enabled device (server). There's a guaranteed password prompt, which
81+
can be detected by the appearance of characters ':', ' ' (at this
82+
point, server expected a password ending with '\n' from client).
83+
If you're interested to develop a 3rd-party application to communicate
84+
using WebREPL terminal protocol, the information above should be enough
85+
to implement it (or feel free to study implementation of the official
86+
clients in this repository).
87+
88+
* File transfer/board control protocol
89+
90+
This protocol uses WebSocket "binary"-flagged messages. At this point,
91+
this protocol is in early research/design/proof-of-concept phase. The
92+
only available specification of it is the reference code implementation,
93+
and the protocol is subject to frequent and incompatible changes.
94+
The `webrepl_cli.py` module mentioned above intended to be both a
95+
command-line tool and a library for 3rd-party projects to use, though
96+
it may not be there yet. If you're interested in integrating WebREPL
97+
transfer/control capabilities into your application, please submit
98+
a ticket to Github with information about your project and how it is
99+
useful to MicroPython community, to help us prioritize this work.
100+
101+
While the protocol is (eventually) intended to provide full-fledged
102+
filesystem access and means to control a board (all subject to
103+
resource constraints of a deeply embedded boards it's intended to
104+
run on), currently, only "get file" and "put file" operations are
105+
supported. As above, sharing information with us on features you
106+
miss and how they can be helpful to the general MicroPython
107+
community will help us prioritize our plans. If you're interested
108+
in reducing wait time for new features, you're also welcome to
109+
contribute to their implementation. Please start with discussing
110+
the design first, and with small changes and improvements. Please
111+
keep in mind that WebREPL is just one of the many features on which
112+
MicroPython developers work, so having sustainable (vs revolutionary)
113+
development process is a must to have long-term success.

0 commit comments

Comments
 (0)