rp-cvideo 0.1.1

Generate composite video on the Raspberry Pi microcontrollers
Documentation
# RP-CVideo

[![pipeline-badge](https://gitlab.com/kasper256/rust-rp-cvideo/badges/main/pipeline.svg)](https://gitlab.com/kasper256/rust-rp-cvideo)
[![docsrs-badge](https://docs.rs/rp-cvideo/badge.svg)](https://docs.rs/rp-cvideo)
[![cratesio-badge](https://img.shields.io/crates/v/rp-cvideo)](https://crates.io/crates/rp-cvideo)

<!-- The following section is generated with cargo rdme. Do not edit manually --> 
<!-- cargo-rdme start -->

Generate a binary/monochrome composite video signal on the RP2040 and RP235x MCUs

### Features
- Clock cycle consistent timing
- Supports progressive and interlaced video
- Supports single and double buffering
- Supports non-standard stuff like:
  - Different number of display lines
  - Bigger or smaller front/back porch (horizontal margins)
  - Fewer or more blank lines on top and bottom
  - Non-square pixels
  - Different frame-rates
  - And more
  - These options can be useful when you're using one of those old 80's CRT monitors with adjustment knobs, which allows
    you - for example - to trade a bit of framerate for vertical resolution or the other way around.
- Uses one only one PIO state-machine (and 13 instructions)
- Supports non-standard system clock frequencies
- Optional [embedded_graphics]https://crates.io/crates/embedded-graphics driver, which allows you
  to draw common shapes and text.
- Stores pixel data efficiently using 1 bit per pixel. To give an idea, in single-buffer / progressive mode,
  with a resolution of 400x250 you need about 21kb. There is some overhead for all the non visible
  portions of the composite signal.
- Const time configuration. Allows for perfectly sized static buffer allocation and catching
  many configuration mistakes at compile time.

### Limitations
 (PR's welcome)
- No colors
- Currently only supports 2 level black/white level monochrome. More levels might be possible with some modifications
- No per line-buffering, it has to keep at least one whole frame/field in memory
- No feedback on being too late with commiting the next frame, other than seeing glitches on your monitor
- No async support

### Known issues
 - The (optional) embedded graphics driver doesn't draw correctly in combination with
   the semi-double buffering mode. See example `semi_double_buffered.rs`

### Examples
You can find some examples in the directory
[rp-cvideo-examples](https://gitlab.com/kasper256/rust-rp-cvideo/-/tree/main/rp-cvideo-examples)
in the root of the repository.

### Hardware
Two digital pins of the MCU are used to generate an analog signal containing 3 discrete voltage levels:
0.0, 0.3 and 1.0 volt, respectively meaning *sync*, *black* and *white*. The easiest way to make this work is
with the following example schematic:
```text
┌─────────────────┐ ┌──────┐
│        GP0(sync)├─┤ 560Ω ├───┐
│ RP              │ └──────┘   │
│ Pico            │ ┌──────┐   │
│       GP1(video)├─┤ 220Ω ├───┴──► composite
│                 │ └──────┘        video
│                 │                 plug
│              GND├───────────────►
└─────────────────┘
```
*Note* These resistor values are for 3.2v digital pins!

### Thanks
* Thanks to the [rp-rs]https://github.com/rp-rs team for their excellent work that makes this library possible
* Thanks for [batsocks]https://www.batsocks.co.uk/readme/video_timing.htm for his/hers great reference on the composite video signal

<!-- cargo-rdme end -->

### Demo video
A video of the matrix example running on an old green phosphor monitor

![demo video](https://gitlab.com/kasper256/rust-rp-cvideo/-/raw/main/rp-cvideo-examples/examples/matrix.mp4)