Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

usb support? #1

Open
cleverca22 opened this issue Jan 21, 2021 · 7 comments
Open

usb support? #1

cleverca22 opened this issue Jan 21, 2021 · 7 comments
Labels
enhancement New feature or request

Comments

@cleverca22
Copy link

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Generic-USB-Display

this is a fully open spec on how to drive a display over usb, given that the 2nd core is entirely unused, i'm guessing it has enough processing power to be a usb gadget, and implement that protocol, which would then expose the framebuffer to a host over usb!

linux already has drivers to act as either end of that protocol, and there are examples of running it on a pi0 in gadget mode

@Wren6991
Copy link
Owner

Note the second core is idle when displaying a static pixel-doubled image, but many of the examples use both cores. See here. I'll put up some YouTube videos at some point.

This would be a neat example, though pretty limited in resolution. I'd rather work on getting the DVI code imported into the scanvideo stack (currently experimental), so that you can use the same example with e.g. VGA, DBI. It wouldn't be developed in this repo. Note we are all quite busy around launch, so this isn't going to happen for a while.

@Wren6991
Copy link
Owner

Sorry I was a bit terse and forgot to preface this with: yes this is absolutely a thing that should exist :) and we have talked internally about that very driver in the context of the VGA code

@raszpl
Copy link

raszpl commented Jan 23, 2021

USB 1.1 =12Mbit = ~1MB/s

@cleverca22
Copy link
Author

@raszpl the protocol supports things like RGB565 (16bpp) and LZ4 compression of the stream, along with partial updates of the framebuffer

usb1 will definitely harm the fullscreen refresh rate, but it still looks feasible, but obviously not a high priority

@fanoush
Copy link

fanoush commented Jan 25, 2021

Slightly related, could PIO do additional USB in software? Even AVR ATtiny could bitbang it.
Too bad there is nothing in USB between fullspeed (12Mbps) and high speed 480Mbps (as the high speed mode is probably too high).

@cleverca22
Copy link
Author

@fanoush if you use a high-speed usb phy, with an 8bit bus driven at 60mhz (well within pio reach), then you can definitely get highspeed usb on an rp2040

but you would have to re-implement the entire usb controller in software

@fanoush
Copy link

fanoush commented Jan 29, 2021

@cleverca22 yes, but then it may be easier to use the idea I mentioned in the forum - use cheap small microsd reader and emulate sd card to that reader. mmcplus/emmc even has 8 data pins but even plain SD 4 bits@100MHz would be pretty fast. Then you could do similar protocol like uf2 to communicate with it over usb storage.

But even another full speed (12MBits) USB in software could be interesting so it could be usb host and client at the same time.

@Wren6991 Wren6991 added the enhancement New feature or request label Feb 8, 2021
kbeckmann referenced this issue in kbeckmann/PicoDVI-N64 Jun 4, 2023
commit f3e095c182331f1ebcf6258ca6c027ad8845e5dd
Author: Konrad Beckmann <[email protected]>
Date:   Sun Jun 4 00:47:13 2023 +0200

    Revert pinout change

commit 06af523
Author: Marcelo Lorenzati <[email protected]>
Date:   Mon Mar 27 23:59:45 2023 -0300

    audio_buffer: required optimizations to run a faster DVI irq

commit 321cbca
Author: Marcelo Lorenzati <[email protected]>
Date:   Mon Mar 27 22:56:46 2023 -0300

    audio_buffer: since TMDS_SYNC_LANE is 0 remove it from loop and simplify inner loop logic

commit 6155988
Author: Marcelo Lorenzati <[email protected]>
Date:   Mon Mar 27 22:18:39 2023 -0300

    audio_buffer: remove from loop  audio option

commit 961a38a
Author: Marcelo Lorenzati <[email protected]>
Date:   Mon Mar 27 21:56:19 2023 -0300

    audio_buffer: optimization, only one call to _dvi_load_dma_op since it's inline. Use ptr assigment

commit d47d004
Author: Marcelo Lorenzati <[email protected]>
Date:   Mon Mar 27 21:06:46 2023 -0300

    audio_buffer: adding a color terminal demo with a audio table, works in doubled vertical line

commit 75441f0
Author: Marcelo Lorenzati <[email protected]>
Date:   Tue Mar 21 23:51:53 2023 -0300

    Update Readme.md

commit 4643434
Author: Marcelo Lorenzati <[email protected]>
Date:   Mon Mar 20 10:24:34 2023 -0300

    Update Readme.md

commit 1088cdb
Merge: 752dafb 428554d
Author: Shuichi Takano <[email protected]>
Date:   Mon Mar 20 11:28:33 2023 +0900

    Merge pull request #1 from mlorenzati/fix/overrun

    fixed to work

commit 428554d
Author: Shuichi Takano <[email protected]>
Date:   Sun Mar 19 01:01:08 2023 +0900

    Fixed to work for now

commit 752dafb
Author: Marcelo Lorenzati <[email protected]>
Date:   Sat Mar 11 15:14:47 2023 -0300

    Update Readme.md

commit ee5ea85
Author: Marcelo Lorenzati <[email protected]>
Date:   Sat Mar 11 15:11:57 2023 -0300

    audio test: added a sprite bounce audio to show the flow, does not work

commit f1f1300
Author: Marcelo Lorenzati <[email protected]>
Date:   Sat Mar 11 14:48:11 2023 -0300

    audio: Taken pico_lib C++ implementation from Shuichi Takano and shifted to C, not working if dataislands are enabled

commit 579eecc
Author: Marcelo Lorenzati <[email protected]>
Date:   Sat Mar 11 14:42:48 2023 -0300

    support for display start/stop,  fix for 332 mode without line pixel doubling
zx64 pushed a commit to zx64/PicoDVI that referenced this issue Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants