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
Copy file name to clipboardExpand all lines: doc/libraries.rst
+9-1
Original file line number
Diff line number
Diff line change
@@ -71,7 +71,7 @@ ESP-specific APIs
71
71
72
72
Some ESP-specific APIs related to deep sleep, RTC and flash memories are available in the ``ESP`` object.
73
73
74
-
``ESP.deepSleep(microseconds, mode)`` will put the chip into deep sleep. ``mode`` is one of ``WAKE_RF_DEFAULT``, ``WAKE_RFCAL``, ``WAKE_NO_RFCAL``, ``WAKE_RF_DISABLED``. (GPIO16 needs to be tied to RST to wake from deepSleep.)
74
+
``ESP.deepSleep(microseconds, mode)`` will put the chip into deep sleep. ``mode`` is one of ``WAKE_RF_DEFAULT``, ``WAKE_RFCAL``, ``WAKE_NO_RFCAL``, ``WAKE_RF_DISABLED``. (GPIO16 needs to be tied to RST to wake from deepSleep.) The chip can sleep for at most ``ESP.deepSleepMax()`` microseconds.
75
75
76
76
``ESP.rtcUserMemoryWrite(offset, &data, sizeof(data))`` and ``ESP.rtcUserMemoryRead(offset, &data, sizeof(data))`` allow data to be stored in and retrieved from the RTC user memory of the chip respectively. Total size of RTC user memory is 512 bytes, so ``offset + sizeof(data)`` shouldn't exceed 512. Data should be 4-byte aligned. The stored data can be retained between deep sleep cycles. However, the data might be lost after power cycling the chip.
77
77
@@ -135,6 +135,14 @@ Servo
135
135
136
136
This library exposes the ability to control RC (hobby) servo motors. It will support up to 24 servos on any available output pin. By default the first 12 servos will use Timer0 and currently this will not interfere with any other support. Servo counts above 12 will use Timer1 and features that use it will be affected. While many RC servo motors will accept the 3.3V IO data pin from a ESP8266, most will not be able to run off 3.3v and will require another power source that matches their specifications. Make sure to connect the grounds between the ESP8266 and the servo motor power supply.
137
137
138
+
Improved EEPROM library for ESP (ESP_EEPROM)
139
+
--------------------------------------------
140
+
141
+
An improved EEPROM library for ESPxxxx. Uses flash memory as per the standard ESP EEPROM library but reduces reflash - so reducing wear and improving commit() performance.
142
+
143
+
As actions on the flash need to stop the interrupts, an EEPROM reflash could noticably affect anything using PWM, etc.
Copy file name to clipboardExpand all lines: tests/README.md
+35-2
Original file line number
Diff line number
Diff line change
@@ -106,7 +106,14 @@ BSTest library also contains a Python script which can "talk" to the ESP8266 boa
106
106
107
107
### Test configuration
108
108
109
-
Some tests need to connect to WiFi AP or to the PC running the tests. This configuration should be set in tests/device/libraries/test_config/test_config.h. This file is not tracked in Git. Create it by copying from tests/device/libraries/test_config/test_config.h.template, and modifying settings in that file.
109
+
Some tests need to connect to WiFi AP or to the PC running the tests. In the test code, this configuration is read from environment variables (the ones set using C `getenv`/`setenv` functions). There are two ways environment variables can be set.
110
+
111
+
- Environment variables which apply to all or most of the tests can be defined in `tests/device/test_env.cfg` file. This file is not present in Git by default. Make a copy of `tests/device/test_env.cfg.template` and change the values to suit your environment.
112
+
113
+
- Environment variables which apply to a specific test can be set dynamically by the `setup` host side helper (see section below). This is done using `setenv` function defined in `mock_decorators`.
114
+
115
+
Environment variables can also be used to pass some information from the test code to the host side helper. To do that, test code can set an environment variable using `setenv` C function. Then the `teardown` host side helper can obtain the value of that variable using `request_env` function defined in `mock_decorators`.
116
+
110
117
111
118
### Building and running the tests
112
119
@@ -135,15 +142,41 @@ Here are some of the supported targets:
135
142
Some tests running on the device need a matching part running on the host. For example, HTTP client test might need a web server running on the host to connect to. TCP server test might need to be connected to by TCP client running on the host. To support such use cases, for each test file, an optional Python test file can be provided. This Python file defines setup and teardown functions which have to be run before and after the test is run on the device. `setup` and `teardown` decorators bind setup/teardown functions to the test with specified name:
136
143
137
144
```python
138
-
from mock_decorators import setup, teardown
145
+
from mock_decorators import setup, teardown, setenv, request_env
139
146
140
147
@setup('WiFiClient test')
141
148
def setup_wificlient_test(e):
142
149
# create a TCP server
150
+
# pass environment variable to the test
151
+
setenv(e, 'SERVER_PORT', '10000')
152
+
setenv(e, 'SERVER_IP', repr(server_ip))
143
153
144
154
@teardown('WiFiClient test')
145
155
def teardown_wificlient_test(e):
146
156
# delete TCP server
157
+
# request environment variable from the test, compare to the expected value
158
+
read_bytes = request_env(e, 'READ_BYTES')
159
+
assert(read_bytes == '4096')
160
+
```
161
+
162
+
Corresponding test code might look like this:
163
+
164
+
```c++
165
+
166
+
TEST_CASE("WiFiClient test", "[wificlient]")
167
+
{
168
+
const char* server_ip = getenv("SERVER_IP");
169
+
int server_port = (int) strtol(getenv("SERVER_PORT"), NULL, 0);
170
+
171
+
WiFiClient client;
172
+
REQUIRE(client.connect(server_ip, server_port));
173
+
174
+
// read data from server
175
+
// ...
176
+
177
+
// Save the result back so that host side helper can read it
0 commit comments