1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
|
<!--
notes.md - Misc notes
Copyright (C) 2024-2025 Luke T. Shumaker <lukeshu@lukeshu.com>
SPDX-License-Identifier: AGPL-3.0-or-later
-->
Which file to include:
> The <stdint.h> header is a subset of the <inttypes.h> header
|------------------------------------------|-----------------------------------|--------------------------------|
| C INTS | | |
| `{CHAR,SHRT,INT,LONG,LLONG}_{MIN,MAX}` | `<limits.h>` | |
| `U{CHAR,SHRT,INT,LONG,LLONG}_MAX` | `<limits.h>` | |
|------------------------------------------|-----------------------------------|--------------------------------|
| C SIZED INTS | | |
| `(u)int{n}_t` (and `_{MIN,MAX,C}`) | `<stdint.h>` | exact |
| `(u)int_least{n}_t` (and `_{MIN,MAX,C}`) | `<stdint.h>` | type may be more than `n` bits |
| `(u)int_fast{n}_t` (and `_{MIN,MAX,C}`) | `<stdint.h>` | type may be more than `n` bits |
| `(u)intptr_t` (and `_{MIN,MAX,C}`) | `<stdint.h>` | |
| `(u)intmax_t` (and `_{MIN,MAX,C}`) | `<stdint.h>` | |
| `PRI*` | `<inttypes.h>` | |
| `SCN*` | `<inttypes.h>` | |
|------------------------------------------|-----------------------------------|--------------------------------|
| C ADDRESS INTS | | |
| `ptrdiff_t` | `<stddef.h>` | |
| `PTRDIFF_{MIN,MAX}` | `<stdint.h>` | |
| `size_t` | `<stddef.h>` (or `<sys/types.h>`) | |
| `SIZE_MAX` | `<stdint.h>` | |
|------------------------------------------|-----------------------------------|--------------------------------|
| C WCHAR INTS | | |
| `wchar_t` | `<stddef.h>` | |
| `WCHAR_{MIN,MAX}` | `<stdint.h>` | |
| `wint_t` | `<wchar.h>` | |
| `WINT_{MIN,MAX}` | `<stdint.h>` | |
|------------------------------------------|-----------------------------------|--------------------------------|
| POSIX INTS | | |
| `sig_atomic_t` | `<signal.h>` | |
| `SIG_ATOMIC_{MIN,MAX}` | `<stdint.h>` | |
| `mode_t` | `<sys/types.h>` | unsigned |
| `dev_t` | `<sys/types.h>` | unsigned |
| `nlink_t` | `<sys/types.h>` | unsigned |
| `{u,g,}id_t` | `<sys/types.h>` | unsigned |
| `blkcnt_t` | `<sys/types.h>` | signed |
| `off_t` | `<sys/types.h>` | signed |
| `fsblkcnt_t` | `<sys/types.h>` | unsigned |
| `fsfilecnt_t` | `<sys/types.h>` | unsigned |
| `ino_t` | `<sys/types.h>` | unsigned |
| `blksize_t` | `<sys/types.h>` | signed |
| `pid_t` | `<sys/types.h>` | signed |
| `ssize_t` | `<sys/types.h>` | signed |
| `SSIZE_MAX` | `<limits.h>` | not in newlib |
| `suseconds_t` | `<sys/types.h>` | signed |
| `clock_t` | `<sys/types.h>` | could be float |
| `time_t` | `<sys/types.h>` | signed |
Here's my reading of the lowest-bitrate possible for our HDMI sink:
HDMI v1.4 (2009/06/05) § 6.2.1 "Format Support Requirements"
> - An HDMI Source shall support at least one of the following video
> format timings:
> + 640x480p @ 59.94/60Hz
> + 720x480p @ 59.94/60Hz
> + 720x576p @ 50Hz
> …
>
> - An HDMI Sink that accepts 60Hz video formats shall support the
> 640x480p @ 59.94/60Hz and 720x480p @ 59.94/60Hz video format
> timings
>
> - An HDMI Sink that accepts 50Hz video formats shall support the
> 640x480p @ 59.94/60Hz and 720x576p @ 50Hz video format timings.
These latter 2 requirements match what is in CEI-861-D §3.1 "General
Video Format requirements" Table 1.
I'm a little confused about the 50Hz systems requirement; if it
needs to support 640x480@60Hz, does that mean that it's *also* a 60Hz
system and must therefore also support 720x480@60Hz?
Anyway, I need to support at least 640x480p@60Hz and 720x480@60Hz, and
it would be nice to support 720x576p@50Hz. Note that PicoDVI supports
these first two, but not the @50Hz one.
| format | bitrate | CEA-861 pixel freq |
|---------------|-----------------------|--------------------|
| 640x480p@60Hz | 18,432,000 pixels/sec | 25.200 MHz |
| 720x480p@60Hz | 20,736,000 pixels/sec | 27.027 MHz |
| 720x576p@50Hz | 20,736,000 pixels/sec | 27.000 MHz |
https://forums.parallax.com/discussion/download/128730/Hdmi-1.4-1000008562-6364143185282736974850538.pdf
https://archive.org/details/CEA-861-D
https://glenwing.github.io/docs/DVI-1.0.pdf
https://www.cs.unc.edu/Research/stc/FAQs/Video/dvi_spec-V1_0.pdf
https://glenwing.github.io/docs/HDMI-1.0.pdf
The RP2040 has several clocks:
Sources:
- GPCLK0 (GPIO-based clock 0)
- GPCLK1 (GPIO-based clock 1)
- XOSC (External (Crystal) Oscillator)
+ System PLL
+ USB PLL
- ROSC (Ring Oscillator)
These can be muxed onto several clocks which each have dividers (and
most of them enable/disable too):
- clk_gpout0 (GPIO Muxing)
- clk_gpout1 (GPIO Muxing)
- clk_gpout2 (GPIO Muxing)
- clk_gpout3 (GPIO Muxing)
- clk_adc (ADC)
- clk_usb (USB)
- clk_RTC (RTC)
- clk_peri (UART and SPI)
- clk_sys (CPU, bus, RAM)
- clk_ref (watchdog and timers)
```
SSP = ARM Primecell Synchronous Serial Port
^ ^ ^
```
- SPI (Serial Peripheral Interface - Motorola)
- SSI (Synchronous Serial Interface - Texas Instruments)
- Microwire (National Semiconductor)
| `sclk` | `SSPCLKOUT` | `SSP_CLK_OUT` | SSP clock output |
| `ss_n` | `SSPFSSOUT` | `SSP_FSS_OUT` | SSP frame/slave select output |
| `tx` | `SSPTXD` | `SSP_TX_D` | SSP transmit data |
| `rd` | `SSPRXD` | `SSP_RX_D` | SSP receive data |
"The SPI uses `clk_peri` as its reference clock for SPI timing, and is
referred to as `SSPCLK` in the following sections. `clk_sys` is used
as the bus clock, and is referred to as `PCLK` in the following
sections" wut does that mean
8 16-bit values in both the TX buffer and the RX buffer
| Ver. 1.0.0 | 2013-08-01 | https://www.alldatasheet.com/datasheet-pdf/view/554784/ETC2/W5500.html https://www.alldatasheet.com/pdfjsview/web/viewer.html?file=//www.alldatasheet.com/datasheet-pdf/view/554784/ETC2/W5500/+_44J97VwSw9bZYvAB+/datasheet.pdf |
| Ver. 1.0.1 | 2013-09-13 | |
| Ver. 1.0.2 | 2013-11-14 | https://cdn.sparkfun.com/datasheets/Dev/Arduino/Shields/W5500_datasheet_v1.0.2_1.pdf |
| Ver. 1.0.3 | 2014-05-29 | |
| Ver. 1.0.4 | 2014-06-13 | |
| Ver. 1.0.5 | 2014-11-10 | |
| Ver. 1.0.6 | 2014-12-30 | |
| Ver. 1.0.7 | 2016-02-24 | |
| Ver. 1.0.8 | 2017-05-19 | https://docs.wiznet.io/img/products/w5500/w5500_ds_v108e.pdf (on-page version and date are wrong) |
| Ver. 1.0.9 | 2019-05-22 | https://docs.wiznet.io/img/products/w5500/w5500_ds_v109e.pdf |
| Ver. 1.1.0 | 2022-12-17 | https://docs.wiznet.io/img/products/w5500/W5500_ds_v110e.pdf |
https://github.com/Bodmer/TFT_eSPI/discussions/2432
----
The theoretical max rate of the the W5500 is just shy of 80 Mb/s = 10 MB/s
IDK about HDMI compression yet, but naively uncompressed we're looking
at wanting to shove ~60 MB/s (480 Mb/s).
Compression is an optional feature introduced in HDMI 2.1 :(
----
PIO-based USB needs the system clock to be a multiple of 120mhz
----
https://electronics.stackexchange.com/questions/684221/usb-c-on-off-switch-design-that-is-pd-compatible-off-similar-to-cold-plugging
----
OpenBMC
~$300 price range:
- Motherboards with a BMC
- Old proprietary IP-KVM
- TinyPilot KVM
- PiKVM
~$60 price range:
- DIY PiKVM
- JetKVM
~$30 price range
- Sipeed NanoKVM
- https://github.com/stefanklug/picoKVM (~$20 Arduino, ~$5 HDMI
capture), non-IP
----
https://hackaday.com/2022/08/26/bit-banged-ethernet-on-the-raspberry-pi-pico/
---
rough pricepoints
| HDMI socket | $0.85 |
| microHDMI socket | $1.36 |
| miniHDMI socket | $1.89 |
| DVI socket | $3.68 |
---
- "USB" is a trademark of the USB Implementers Forum (USB-IF)
- "HDMI" is a trademark of HDMI Licensing Administrator, Inc. (HDMI LA)
- "DVI" was once a trademark of someone, but in the USA all relevant
trademarks have been canceled.
---
The video-in socket is single-link DVI-D using an HDMI-style physical
receptacle. This makes it able to receive video from both
DVI-D-compliant sources and from HDMI-compliant sources; though it is
itself **not** HDMI-compliant. It supports the following resolutions:
- 640x480p @ 59.94/60Hz
- 720x480p @ 59.94/60Hz
- 720x576p @ 50Hz
:explainer:
> HDMI is perhaps easiest thought of as an extension to single-link
> DVI-D. There are 17 used pins on a single-link DVI-D connector; 17
> of the 19 pins on an HDMI connector correspond 1:1 with these, and
> the additional 2 pins are optional "CEC" and "Utility" pins. HDMI
> starts talking as DVI-D, and enables additional non-DVI
> functionality based on the exchanged E-EDID device descriptors.
> That is: Compliant HDMI devices must work with DVI devices as long
> as they have an overlapping set of supported resolutions.
>
> Additionally, compliant HDMI sources are required to support at
> least one of the above resolutions, while compliant DVI sources are
> required to support 640x480p @ 60Hz.
:rationale:
> If it's DVI, why use an HDMI-style connector instead of a "more
> honest" DVI connector?
>
> Two reasons:
>
> - We anticipate that most DUTs that our users will want to plug
> into it have HDMI ports, and that our users are more likely to
> already have an HDMI cable than an HDMI←→DVI cable or HDMI←→DVI
> adapters. We also anticipate that users who actually do have
> DUTs with DVI ports already have DVI←→HDMI adapters.
>
> - HDMI-style sockets are much cheaper than DVI sockets; using a DVI
> socket would have increased the cost of the harness by several
> dollars.
|
