WEBVTT

1
00:00:00.000 --> 00:00:03.669
The constraints table tells us
which facts the documents support.

2
00:00:04.110 --> 00:00:06.850
Now we will turn those
facts into a small interface

3
00:00:06.896 --> 00:00:09.462
plan and a software acquisition contract.

4
00:00:09.973 --> 00:00:13.189
Stay in checkpoint four and
keep your reviewed table open.

5
00:00:13.630 --> 00:00:17.519
This is a documentation exercise
for an optional physical extension.

6
00:00:17.903 --> 00:00:20.956
The required project will
still use synthetic input,

7
00:00:21.200 --> 00:00:24.752
so no wiring or upload is
needed to complete the lesson.

8
00:00:25.077 --> 00:00:28.665
Start the drawing with two
separate boxes. Name the exact

9
00:00:28.723 --> 00:00:32.519
host board above one and the separate
sensor breakout above the other.

10
00:00:32.844 --> 00:00:35.607
Do not replace those
identities with a broad family

11
00:00:35.677 --> 00:00:38.382
name after doing the
work to establish them.

12
00:00:38.765 --> 00:00:42.121
The drawing should describe
the same example as the README,

13
00:00:42.295 --> 00:00:45.104
hardware reference,
and dependency manifest.

14
00:00:45.708 --> 00:00:50.073
A correct connection attached to the
wrong variant is still misleading context.

15
00:00:50.514 --> 00:00:53.707
Use the named connector signals
from the applicable references.

16
00:00:54.090 --> 00:00:58.919
At this level, we need clock, data, the
documented connector supply, and ground.

17
00:00:59.303 --> 00:01:01.822
Trace the corresponding
endpoint on the breakout.

18
00:01:02.101 --> 00:01:05.108
The intended connection uses
a compatible keyed cable.

19
00:01:05.433 --> 00:01:09.519
Do not insert remembered GPIO
numbers, unsupported wire colors,

20
00:01:09.635 --> 00:01:12.248
or assumptions from a
photograph of a similar board.

21
00:01:12.526 --> 00:01:16.358
Every added detail becomes
another factual claim to review.

22
00:01:16.683 --> 00:01:20.375
Place a clear label on the
plan: documentation based,

23
00:01:20.549 --> 00:01:24.822
physical assembly unverified. This
is not a decorative disclaimer.

24
00:01:25.031 --> 00:01:28.676
It tells the next person what kind
of evidence the drawing represents.

25
00:01:28.955 --> 00:01:33.100
The source can support an intended
connection, while actual orientation,

26
00:01:33.169 --> 00:01:37.523
cable condition, board revision, and
physical operation remain unobserved.

27
00:01:38.127 --> 00:01:41.807
A diagram does not become a bench
result because it is carefully drawn.

28
00:01:42.318 --> 00:01:44.269
Check one connection at a time.

29
00:01:44.594 --> 00:01:47.810
Follow clock from the host
endpoint to the sensor endpoint,

30
00:01:47.961 --> 00:01:49.354
then do the same for data.

31
00:01:49.679 --> 00:01:52.570
Check the supply connection
and return path separately.

32
00:01:52.895 --> 00:01:56.784
Keep the source section beside each
check so a reviewer can repeat it.

33
00:01:57.109 --> 00:02:00.337
Reading all four lines as a
group makes it easier to miss

34
00:02:00.384 --> 00:02:03.983
a swapped endpoint or an assumption
copied from another interface.

35
00:02:04.494 --> 00:02:06.885
When a schematic label
is too small to read,

36
00:02:07.129 --> 00:02:11.018
enlarge the actual source or
locate a readable pinout companion.

37
00:02:11.529 --> 00:02:13.956
An assistant may help find
the relevant material,

38
00:02:14.200 --> 00:02:18.147
but guessing the label from a blurred
image does not resolve the uncertainty.

39
00:02:18.658 --> 00:02:22.222
If the endpoint is not
established, mark it unresolved.

40
00:02:22.826 --> 00:02:25.403
A clearly identified
gap is more useful than

41
00:02:25.438 --> 00:02:28.167
a confident line drawn to an invented pin.

42
00:02:28.863 --> 00:02:33.379
A bare-wire variation would need more
evidence than this connector-level plan.

43
00:02:33.821 --> 00:02:36.874
You would need exact pin
positions, orientation,

44
00:02:36.909 --> 00:02:40.113
supply assumptions, and
relevant interface conditions.

45
00:02:40.554 --> 00:02:44.838
Do not silently expand the keyed-cable
example into that variation.

46
00:02:45.349 --> 00:02:48.240
A changed connection method
is a changed engineering

47
00:02:48.298 --> 00:02:50.864
task, and the source
checks should grow with it.

48
00:02:51.247 --> 00:02:54.521
The core course does not require
you to perform that extension.

49
00:02:54.905 --> 00:02:57.888
Now describe what the input
adapter gives the application.

50
00:02:58.213 --> 00:03:02.068
It should produce a timestamped
temperature when acquisition succeeds,

51
00:03:02.312 --> 00:03:06.108
or an explicit indication that
a reading is missing or invalid.

52
00:03:06.433 --> 00:03:10.137
The adapter handles the acquisition
environment. The policy decides

53
00:03:10.172 --> 00:03:13.747
whether the input is current and
whether the application has recovered.

54
00:03:14.130 --> 00:03:16.998
Keeping that boundary
clear lets host replay

55
00:03:17.079 --> 00:03:20.434
exercise the same policy
without a physical sensor.

56
00:03:20.817 --> 00:03:22.954
Write down what a timestamp means.

57
00:03:23.337 --> 00:03:27.180
A fresh acquisition can carry the
time associated with that reading.

58
00:03:27.621 --> 00:03:32.857
A failed attempt must not take an old
cached value and give it a new timestamp.

59
00:03:33.298 --> 00:03:35.597
That would make stale data appear current.

60
00:03:35.841 --> 00:03:39.382
The value, its validity,
and its age belong together.

61
00:03:39.765 --> 00:03:42.191
If an assistant proposes
a fallback number,

62
00:03:42.400 --> 00:03:46.359
ask which requirement gives that invented
measurement a legitimate meaning.

63
00:03:46.684 --> 00:03:49.830
Initialization is part
of the contract as well.

64
00:03:50.155 --> 00:03:52.965
A future physical adapter
needs to establish

65
00:03:53.046 --> 00:03:56.529
a usable interface or report
initialization failure.

66
00:03:56.854 --> 00:04:00.709
It should not proceed as though
input exists when setup failed.

67
00:04:01.034 --> 00:04:05.980
The current synthetic implementation
avoids a sensor driver entirely,

68
00:04:06.154 --> 00:04:09.080
which keeps the shared
behavior small and testable.

69
00:04:09.683 --> 00:04:12.214
You can define the future
boundary now without

70
00:04:12.273 --> 00:04:14.989
claiming the future driver
has been implemented.

71
00:04:15.430 --> 00:04:19.227
The board guide also describes
switchable peripheral power.

72
00:04:19.831 --> 00:04:23.209
Before adopting a control
symbol in a physical adapter,

73
00:04:23.418 --> 00:04:27.540
inspect the selected board variant
and its pinned initialization source.

74
00:04:27.923 --> 00:04:31.499
An alias from another example
is not automatically applicable.

75
00:04:31.882 --> 00:04:34.367
If the guide and code use different names,

76
00:04:34.610 --> 00:04:38.094
record the exact question and the
evidence needed to resolve it.

77
00:04:38.372 --> 00:04:42.598
Do not hide that mismatch behind
a generic ESP32 pin number.

78
00:04:42.923 --> 00:04:46.569
Ask a separate timing question:
how long can acquisition take?

79
00:04:46.847 --> 00:04:50.923
Calling an adapter once a second does
not guarantee that its internal driver

80
00:04:51.039 --> 00:04:55.300
returns within one second. Scheduling
controls when work is requested.

81
00:04:55.683 --> 00:04:59.502
Driver timeout behavior controls
what happens inside the request.

82
00:04:59.886 --> 00:05:03.577
A physical extension needs appropriate
source and implementation evidence

83
00:05:03.601 --> 00:05:07.746
for that behavior before you
describe its acquisition as bounded.

84
00:05:08.187 --> 00:05:11.414
These unanswered
physical-driver questions do not

85
00:05:11.472 --> 00:05:14.642
prevent the required synthetic
project from moving forward.

86
00:05:14.967 --> 00:05:18.659
The host adapter can supply
controlled values and timestamps

87
00:05:18.938 --> 00:05:22.363
while the optional implementation
remains a separate task.

88
00:05:22.642 --> 00:05:26.148
The important boundary is
visible: software policy checks

89
00:05:26.194 --> 00:05:30.223
will establish behavior for supplied
inputs, while electrical operation,

90
00:05:30.374 --> 00:05:34.762
bus behavior, and measured response
timing remain outside those checks.

91
00:05:35.088 --> 00:05:38.733
In the exercise, review a
proposal that confuses scheduling

92
00:05:38.768 --> 00:05:42.541
with duration and refreshes
cached data after failed reads.

93
00:05:42.983 --> 00:05:45.920
Correct both claims in the
plan before any coding.

94
00:05:46.303 --> 00:05:50.424
The first needs an independent
acquisition-duration or timeout check.

95
00:05:50.750 --> 00:05:53.431
The second needs the
original sample age to remain

96
00:05:53.501 --> 00:05:56.078
visible or an explicit missing result.

97
00:05:56.775 --> 00:06:01.024
Neither problem is solved by making
the output look continuously normal.

98
00:06:01.349 --> 00:06:04.519
Your completed plan contains
the documented connections,

99
00:06:04.844 --> 00:06:08.652
a short adapter contract, and
specific unresolved questions.

100
00:06:09.093 --> 00:06:11.972
Each unknown names what
evidence would resolve it.

101
00:06:12.355 --> 00:06:16.616
Physical revision, jumper state,
pinned power initialization,

102
00:06:16.860 --> 00:06:20.784
selected driver version, and
actual upload or serial operation

103
00:06:21.109 --> 00:06:24.290
are useful examples when they
affect the planned extension.

104
00:06:25.103 --> 00:06:28.772
Avoid an indiscriminate list
of every conceivable risk;

105
00:06:29.213 --> 00:06:31.813
keep the questions tied to this interface.

106
00:06:32.138 --> 00:06:35.633
Finally compare the plan with the
constraints table one more time.

107
00:06:36.016 --> 00:06:38.733
Confirm that no variant,
address assumption,

108
00:06:38.791 --> 00:06:42.657
or source condition changed while
the drawing became more polished.

109
00:06:43.168 --> 00:06:45.966
Ask the assistant for a
bounded review if it helps,

110
00:06:46.210 --> 00:06:48.334
then inspect the source evidence yourself.

111
00:06:48.717 --> 00:06:52.467
In the next lesson we will implement
and run synthetic input handling,

112
00:06:52.793 --> 00:06:55.765
using this clear acquisition
boundary to keep the firmware

113
00:06:55.799 --> 00:06:58.655
change small and its
results easy to explain.