You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of this Github project, we provide libraries for Bluetooth Low Energy (BLE) for the ESP32 Arduino environment. Support for this capability is still in the process of being cooked (as of August 2017). As such you should not build product based on these functions as changes to the API and implementation are extremely likely over the next couple of months.
2
+
As part of this Github project, we provide libraries for Bluetooth Low Energy (BLE) for the ESP32 Arduino environment. Support for this capability is still in the process of being cooked (as of September 2017). As such you should not build product based on these functions as changes to the API and implementation are extremely likely over the next couple of months.
3
3
4
4
That said, we now have the ability to produce a driver you can use for testing. This will give you early access to the function while give those who choose to build and maintain the code early feedback on what works, what doesn't and what can be improved from a usage perspective.
5
5
6
6
When complete, the BLE support for ESP32 Arduino will be available as a single ZIP file. The file will be called **ESP32_BLE.zip**. It is this file that will be able to be imported into the Arduino IDE from the `Sketch -> Include Library -> Add .ZIP library`. When initial development of the library has been completed, this ZIP will be placed under some form of release control so that an ordinary Arduino IDE user can simply download this as a unit and install.
7
7
8
-
However, today, we are choosing **not** to distribute the BLE support as a downloadable library. The reason for this is that we believe that the code base for the BLE support is too fluid and it is being actively worked upon. Each day there will be changes and that means that for any given instance of the ZIP you get, if it is more than a day old, it is likely out of date.
8
+
We provide sample builds of the `ESP32_BLE.zip` file in the `Arduino` folder found relative to this directory.
9
9
10
-
Instead of giving you a fish (a new ESP32_BLE.zip) we are going to teach you to fish so that you yourself can build the very latest ESP32_BLE.zip yourself. Hopefully you will find this quite easy to accomplish.
11
-
12
-
Here is the recipe.
10
+
The build of the Arduino support will be current as of the date of the ZIP file however should you wish to build your own instance of the ZIP from the source, here is the recipe.
13
11
14
12
1. Create a new directory called `build`
15
13
2. Enter that directory and run `git clone https://github.com/nkolban/esp32-snippets.git`
@@ -24,41 +22,22 @@ And here you will find the `ESP32_BLE.zip` that is build from the latest source.
24
22
If you have previously installed a version of the Arduino BLE Support and need to install a new one, follow the steps above to build yourself a new instance of the `ESP32_BLE.zip` that is ready for installation. I recommend removing the old one before installing the new one. To remove the old one, find the directory where the Arduino IDE stores your libraries (on Linux this is commonly `$HOME/Arduino`). In there you will find a directory called `libraries` and, if you have previously installed the BLE support, you will find a directory called `ESP32_BLE`. Remove that directory.
25
23
26
24
## Switching on debugging
27
-
The BLE support contains extensive internal diagnostics which can be switched on by editing the file called `sdkconfig` and finding the lines which read:
25
+
The BLE support contains extensive internal diagnostics which can be switched on by editing the file called `sdkconfig.h` and finding the lines which read:
28
26
29
27
```
30
-
#
31
-
# Log output
32
-
#
33
-
# CONFIG_LOG_DEFAULT_LEVEL_NONE is not set
34
-
CONFIG_LOG_DEFAULT_LEVEL_ERROR=y
35
-
# CONFIG_LOG_DEFAULT_LEVEL_WARN is not set
36
-
# CONFIG_LOG_DEFAULT_LEVEL_INFO is not set
37
-
# CONFIG_LOG_DEFAULT_LEVEL_DEBUG is not set
38
-
# CONFIG_LOG_DEFAULT_LEVEL_VERBOSE is not set
39
-
CONFIG_LOG_DEFAULT_LEVEL=1
28
+
#define CONFIG_LOG_DEFAULT 1
40
29
```
41
30
42
31
Change this to:
43
32
44
33
```
45
-
#
46
-
# Log output
47
-
#
48
-
# CONFIG_LOG_DEFAULT_LEVEL_NONE is not set
49
-
# CONFIG_LOG_DEFAULT_LEVEL_ERROR=y
50
-
# CONFIG_LOG_DEFAULT_LEVEL_WARN is not set
51
-
# CONFIG_LOG_DEFAULT_LEVEL_INFO is not set
52
-
# CONFIG_LOG_DEFAULT_LEVEL_DEBUG is not set
53
-
CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y
54
-
CONFIG_LOG_DEFAULT_LEVEL=5
55
-
# CONFIG_LOG_COLORS is not set
34
+
#define CONFIG_LOG_DEFAULT 5
56
35
```
57
36
58
37
and rebuild/deploy your project.
59
38
60
39
This file can be found in your Arduino IDE installation directories at:
Copy file name to clipboardExpand all lines: cpp_utils/DesignNotes/WebSockets.md
+37-3
Original file line number
Diff line number
Diff line change
@@ -13,11 +13,11 @@ For example, imagine a WebSocket client wants to send a file of 1MByte to the ES
13
13
14
14
This sounds workable ... so let us now think about how we might go about creating an input stream for a WebSocket message. Each WebSocket message starts with a WebSocket frame which contains, amongst other things, the length of the payload data. This means that we know up front how much of the remaining data is payload. This becomes essential as we can't rely on an "end of file" marker in the input stream to indicate the end of the WebSocket payload. The reason for this is that the WebSocket is a TCP stream that will be used to carry multiple sequential messages.
15
15
16
-
Let us now invent a new class. Let us call it a SocketInputRecordStream.
16
+
Let us now invent a new class. Let us call it a SocketInputRecordStreambuf.
The `socket` is the TCP/IP socket that we are going to read data from. The `dataLength` is the size of the data we wish to read. The class will extend `std::streambuf`. It will internally maintain a data buffer of size `bufferSize`. Initially, the buffer will be empty. When a read is performed on the stream, a call to `underflow()` will be made (this is a `std::streambuf` virtual function).
@@ -27,4 +27,38 @@ Our rules for this class include:
27
27
* We must **not** read more the `dataLength` bytes from the socket.
28
28
* We must **indicate** and `EOF` once we have had `dataLength` bytes consumed by a stream reader.
29
29
* The class must implement a `discard()` method that will discard further bytes from the socket such that the total number of bytes read from the socket will equal `dataLength`.
30
-
* Deleting an instance of the class must invoke `discard()`.
30
+
* Deleting an instance of the class must invoke `discard()`.
31
+
32
+
## File transfer
33
+
WebSockets make a great file transfer technology. While this is more an application utilization of the technology than the design of the framework, we'll capture it here. Let us first set the scene. We have a client application that wishes to transmit a file. We will assume that the file is composed of three logical components:
34
+
35
+
* The file name
36
+
* The file length
37
+
* The content of the file
38
+
39
+
It would be wrong to expect the client to send the file as one continuous unit in one WebSocket message. The reason for this is that the client would have to have loaded the complete file into its memory buffers in order to send it. As such, we should assume that the client will send the files as one or more "parts" where each part represents a piece of the file.
*`transferId` - An Id that is randomly generated by the client. This is used to associate multiple messages for the same file together.
61
+
*`file name` - The name of the file that the client wishes to send. Can include paths. This will be used to determine where on the file system the file will be written.
62
+
*`length` - The size of the file in bytes. Knowing the size will allow us to know when the whole file has been received.
63
+
64
+
We will create an encapsulation class called `WebSocketFileTransfer`.
0 commit comments