ESP8266
The ESP from ByVac is effectively a Wifi to Serial device, just as a USB to Serial uses USB then this device used WiFi
WiFi to Serial adapter
It can now be used directly with a trial IDE, no download needed just connect to the IP address
ByPic
ByPic device that have a built in ESP8266 can normally connect via UART1 or UART2. If UART2 is used, this is the main interface (ok prmpt) and the device can be programmed and used remotely. No library is needed. If used with UART1 then a library is needed, this method is used for a reliable connection to the internet for example getting API or time data or sending data to servers.
ESP Modes of Operation
The new ESP firmware has the following capabilities:
- As a TCP Bridge
- As a HTTP pass through server.
- As a websocket server
Because of the above built in protocols it is possible to use this device with JavaScript and so no external software is needed other than a browser.
TCP Bridge
The ESP has two ends, the wifi end and the UART end just as a USB to serial converter has two ends (USB end and the serial end). In its simplest from the ESP can be used as a WiFi to Serial converter. This involves some extra software at the host (PC) end as a TCP socket needs to be opened in order to communicate. PUTTY and BVserial can do that. Instead of opening a COM port a socket is opened.
A socket is an IP address and port number, for example 192.168.1.1:80. 192.168.1.1 is the IP address and 80 is the port number. The IP address will be the same IP address as the ESP, as that is the device you wish to talk to.
HTTP Pass through Server
One of the problems with a simple bridge as above is that it requires software on the PC side, e.g. telnet, putty etc. Wouldn't it be great if NO extra software were required? This is the purpose of this mode. All browsers use HTTP as a protocol and so in this mode the ESP is able to translate this protocol and turn it into plane text. It will also keep the browser happy by replying in HTTP. All of this takes place transparently within the ESP.
What does this mean in practice?
Here we have a ByPic device connected to an ESP, sending CRLF produces the ok prompt which is what would be expected if connected by a COM port. The ByPic could of course be programmed to respond to commands and carry out tasks, if connected to UART2 as this is a function name can be used.
This function called test, outputs n number of 'hello' as can be seen. Instead of CRLF at the end it outputs <br> which is HTML as so it is formatted correctly. e.g.
function test(n)
dim n
for j = 1 to n
print "hello<br>"
next
endf
All of this is without ANY extra software on the PC OR the ByPic device.
To get the most out of this method, JavaScript can be used in the browser so buttons and the like can be used. It is possible to do this without the need for any intervening servers which is usually the case.
WebSockets
In order to move data to and from a browser, HTTP IS required. For applications other than browsing web pages this has some disadvantages.
- Each time data is sent the browser needs to establish a TCP connection which is time consuming.
- The HTTP protocol requires that a message head is sent and one received back during the communication. The overhead is significant.
- Only the browser can initiate communication
Using WebSockets (an apparently recent innovation) overcomes these problems. The communication starts off as HTTP to keep the browser happy and then a two way communication can take place in a similar fashion to the TCP bridge.
This can all be done within the browser using Javascript and so the concept is quite powerful. For involved applications such as a browser ByPic IDE, it is not much faster than straight HTTP but is is very much easier.
The trial IDE makes use of all of the above modes of operation, mainly web socket for IDE use.
Technical Details
There is no need to read this, it is for information only.
HTTP communication
The browser will initiate the communication with the ESP and if this is recognised as HTTP, by using either GET or POST then the ESP will respond with the response message. This message has two inportant parts:
- Access-Control-Allow-Origin: *
- Transfer-Encoding: chunked
The first item allows the ESP to be used on 'foreign' networks. Without this it would not be possible to do some of the Javascript programming due to browser security.
The second item is more complex. When a HTTP request is made by the browser it expects a response telling it how much data will be sent back. Because of the nature of what's being done (random serial communication) and because there is limited resources for a buffer, this is not really possible so chunked data is used.
It is still required to tell the browser how much data is being sent but only in bits at a time so this is manageable. also the browser will keep the TCP connection open until the ESP closes it with a zero sized chunk. This method does have two drawbacks. The first is that each chunk needs to be preceded by the size creating yet more overhead. This is mitigated in the ESP by having a small 'chunk' buffer. The biggest drawback is when to finish the communication? When to send that zero chunk?
Thinking about this, the ByPic device always sends 'ok' when it has accepted a line of input so a special byte (6) can be added to the end of the 'ok' and this will tell the ESP to send that final chunk to close the TCP connection. Failing that if there is also a timeout so that if there is no response from the UART end (time set by +++restto) then a zero chunk will be sent anyway.
GET / POST
For some extra detail, when a HTTP request is made by the browser for example on the address bar '192.168.11.208/hello; It will in fact make a GET request which to the ESP look like:
GET /hello HTTP/1.1
The ESP will extract the 'hello' and anything else that is there and sent it to the UART. Anything that comes back from the UART will be sent to the TCP end via the chunking process. This data will not normally show up on the browser page until the connection is closed.