Which file to include: > The header is a subset of the header |------------------------------------------|-----------------------------------|--------------------------------| | C INTS | | | | `{CHAR,SHRT,INT,LONG,LLONG}_{MIN,MAX}` | `` | | | `U{CHAR,SHRT,INT,LONG,LLONG}_MAX` | `` | | |------------------------------------------|-----------------------------------|--------------------------------| | C SIZED INTS | | | | `(u)int{n}_t` (and `_{MIN,MAX,C}`) | `` | exact | | `(u)int_least{n}_t` (and `_{MIN,MAX,C}`) | `` | type may be more than `n` bits | | `(u)int_fast{n}_t` (and `_{MIN,MAX,C}`) | `` | type may be more than `n` bits | | `(u)intptr_t` (and `_{MIN,MAX,C}`) | `` | | | `(u)intmax_t` (and `_{MIN,MAX,C}`) | `` | | | `PRI*` | `` | | | `SCN*` | `` | | |------------------------------------------|-----------------------------------|--------------------------------| | C ADDRESS INTS | | | | `ptrdiff_t` | `` | | | `PTRDIFF_{MIN,MAX}` | `` | | | `size_t` | `` (or ``) | | | `SIZE_MAX` | `` | | |------------------------------------------|-----------------------------------|--------------------------------| | C WCHAR INTS | | | | `wchar_t` | `` | | | `WCHAR_{MIN,MAX}` | `` | | | `wint_t` | `` | | | `WINT_{MIN,MAX}` | `` | | |------------------------------------------|-----------------------------------|--------------------------------| | POSIX INTS | | | | `sig_atomic_t` | `` | | | `SIG_ATOMIC_{MIN,MAX}` | `` | | | `mode_t` | `` | unsigned | | `dev_t` | `` | unsigned | | `nlink_t` | `` | unsigned | | `{u,g,}id_t` | `` | unsigned | | `blkcnt_t` | `` | signed | | `off_t` | `` | signed | | `fsblkcnt_t` | `` | unsigned | | `fsfilecnt_t` | `` | unsigned | | `ino_t` | `` | unsigned | | `blksize_t` | `` | signed | | `pid_t` | `` | signed | | `ssize_t` | `` | signed | | `SSIZE_MAX` | `` | not in newlib | | `suseconds_t` | `` | signed | | `clock_t` | `` | could be float | | `time_t` | `` | 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.