@@ -4,12 +4,13 @@ This library provides a means of examining the behaviour of a running
4
4
` uasyncio ` system. The device under test is linked to a Raspberry Pi Pico. The
5
5
latter displays the behaviour of the host by pin changes and/or optional print
6
6
statements. A logic analyser or scope provides an insight into the way an
7
- asynchronous application is working.
7
+ asynchronous application is working, although valuable informtion can be
8
+ gleaned without such tools.
8
9
9
10
Communication with the Pico may be by UART or SPI, and is uni-directional from
10
11
system under test to Pico. If a UART is used only one GPIO pin is used; at last
11
- a use for the ESP8266 transmit-only UART(1). SPI requires three - mosi, sck and
12
- cs/.
12
+ a use for the ESP8266 transmit-only UART(1). SPI requires three - ` mosi ` , ` sck `
13
+ and ` cs/ ` .
13
14
14
15
Where an application runs multiple concurrent tasks it can be difficult to
15
16
locate a task which is hogging CPU time. Long blocking periods can also result
@@ -25,11 +26,14 @@ trigger because another task is hogging the CPU. Lines 01 and 03 show the `foo`
25
26
and ` bar ` tasks.
26
27
![ Image] ( ./monitor.jpg )
27
28
28
- ### Breaking changes to support SPI
29
+ ### Status
29
30
30
- The ` set_uart ` method is replaced by ` set_device ` . Pin mappings on the Pico
31
- have changed. Barring bug fixes or user suggestions I consider this project to
32
- be complete.
31
+ 30th Sep 2021 Pico code has improved hog detection.
32
+
33
+ 27th Sep 2021 SPI support added. The ` set_uart ` method is replaced by
34
+ ` set_device ` . Pin mappings on the Pico changed.
35
+
36
+ 21st Sep 2021 Initial release.
33
37
34
38
## 1.1 Pre-requisites
35
39
@@ -133,10 +137,8 @@ To aid in detecting the gaps in execution, the Pico code implements a timer.
133
137
This is retriggered by activity on ` ident=0 ` . If it times out, a brief high
134
138
going pulse is produced on pin 28, along with the console message "Hog". The
135
139
pulse can be used to trigger a scope or logic analyser. The duration of the
136
- timer may be adjusted - see [ section 4] ( ./README.md~4-the-pico-code ) .
137
-
138
- Note that hog detection will be triggered if the host application terminates.
139
- The Pico cannot determine the reason why the ` hog_detect ` task has stopped.
140
+ timer may be adjusted. Other modes of hog detection are also supported. See
141
+ [ section 4] ( ./README.md~4-the-pico-code ) .
140
142
141
143
# 2. Monitoring synchronous code
142
144
@@ -239,6 +241,38 @@ reported if blocking is for more than 60ms, issue
239
241
from monitor_pico import run
240
242
run(60 , (4 , 7 ))
241
243
```
244
+ Hog reporting is as follows. If ident 0 is inactive for more than the specified
245
+ time, "Timeout" is issued. If ident 0 occurs after this, "Hog Nms" is issued
246
+ where N is the duration of the outage. If the outage is longer than the prior
247
+ maximum, "Max hog Nms" is also issued.
248
+
249
+ This means that if the application under test terminates, throws an exception
250
+ or crashes, "Timeout" will be issued.
251
+
252
+ ## 4.1 Advanced hog detection
253
+
254
+ The detection of rare instances of high latency is a key requirement and other
255
+ modes are available. There are two aims: providing information to users lacking
256
+ test equipment and enhancing the ability to detect infrequent cases. Modes
257
+ affect the timing of the trigger pulse and the frequency of reports.
258
+
259
+ Modes are invoked by passing a 2-tuple as the ` period ` arg.
260
+ * ` period[0] ` The period (ms): outages shorter than this time will be ignored.
261
+ * ` period[1] ` is the mode: constants ` SOON ` , ` LATE ` and ` MAX ` are exported.
262
+
263
+ The mode has the following effect on the trigger pulse:
264
+ * ` SOON ` Default behaviour: pulse occurs early at time ` period[0] ` ms after
265
+ the last trigger.
266
+ * ` LATE ` Pulse occurs when the outage ends.
267
+ * ` MAX ` Pulse occurs when the outage ends and its duration exceeds the prior
268
+ maximum.
269
+
270
+ The mode also affects reporting. The effect of mode is as follows:
271
+ * ` SOON ` Default behaviour as described in section 4.
272
+ * ` LATE ` As above, but no "Timeout" message: reporting occurs at the end of an
273
+ outage only.
274
+ * ` MAX ` Report at end of outage but only when prior maximum exceeded. This
275
+ ensures worst-case is not missed.
242
276
243
277
# 5. Performance and design notes
244
278
0 commit comments