[HN Gopher] RP2350 PicoDVI Preview
___________________________________________________________________
RP2350 PicoDVI Preview
Author : fidotron
Score : 184 points
Date : 2024-08-15 21:42 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tony-allan wrote:
| The RP2040 discussion -- https://github.com/Wren6991/PicoDVI
| typeiierror wrote:
| The new HSTX interface on the RP2350 seems to be squarely
| targeted at this use case (video output) and doesn't require the
| use of PIO or consuming a ton of CPU cycles. There's a nice write
| up on the capability here: https://www.cnx-
| software.com/2024/08/15/raspberry-pi-rp2350-...
| phire wrote:
| The main advantage of the SIO TMDS encoder, is that it allows
| you to output TMDS on any GPIO, instead of the eight that the
| HSTX is restricted to.
|
| And they allow an easy upgrade path for projects that were
| already bit-banging DVI on the rp2040. Other than those two
| advantages, I don't think there is any advantage to the SIO
| TMDS encoder over the HSTX TMDS encoder.
|
| I get the impression that the SIO TMDS encoder was added to the
| design first, and there wasn't a good reason to remove them
| after the introduction of HSTX.
| jauntywundrkind wrote:
| Isn't hstx mainly good for streaming out? My naive guess would
| be that it wouldn't have as much transceiver offload
| capabilities, like what the SIO I naively guess would be good
| for.
|
| The nice part about using SIO seems to be that you can do the
| tdms encoding there. With hstx you need the output bitstream in
| the right format already which seems like you might be back to
| needing the CPU to do the encoding.
| phire wrote:
| HSTX has a built in TMDS encoder, and as far as I can tell,
| it has all the functionality of the SIO TMDS encoder.
|
| You can configure it to directly consume any line buffer with
| any pixel format, from 1 to 8 bits per color channel. It even
| supports formats with different numbers of bits per channel
| like 8-bit RGB322 and 16-bit RGB565.
| onetom wrote:
| what's the fun in that though?
|
| i have the impression, that the main motivation for this
| project was learning the intricacies of TMDS encoding and
| providing an open implementation as reference for other
| ppl, who want to learn too.
|
| there are too many black box electronics these days, so
| it's very much welcome to virtually open them up, by
| providing software equivalents of their operation.
| szundi wrote:
| Fun is to proceed to the next fun faster
| Palomides wrote:
| can the RP2350 do a higher resolution? it would be a neat option
| for some retrocomputing stuff if so
| raphlinus wrote:
| My understanding is that the HSTX can do twice the bit clock as
| the frequency of the CPU, as opposed to 1x for RP2040. So
| 800x480 (60Hz) is possible with no overclocking (295MHz bit
| clock) and Luke said [1] he got 1280x720 50Hz with overclocking
| (530MHz using CVT-R according to the video timings calculator
| [2]).
|
| [1]:
| https://mastodon.online/@wren6991@types.pl/11292855122145752...
|
| [2]: https://tomverbeure.github.io/video_timings_calculator
| jauntywundrkind wrote:
| I wonder what res/refresh Display Stream Compression (DSC)
| would bring this up to, if this were DisplayPort (instead of
| DVI)?
| tverbeure wrote:
| The lowest you can go with DSC 1.2 is 8 bits per pixel.
| phire wrote:
| Probably.
|
| Especially with the HSTX block which can apparently output at
| double the system clock (while the rp2040 was limited to 1/10th
| of the system)
|
| If my rough math is correct, it should be possible to do output
| 720p 60hz video with an overclock to ~320Mhz. Though, actually
| generating that many pixels might be hard when you have nowhere
| near enough memory.
|
| I would love to see some solid infomation about how well the
| rp2350 overclocks, apparently 300mhz is easy. 60hz 1080p is
| almost certainly out of reach, it would require something like
| a 700mhz overclock, but 30hz 1080p is probably viable.
| jsheard wrote:
| > Though, actually generating that many pixels might be hard
| when you have nowhere near enough memory.
|
| Even if you don't have enough memory or CPU time to render
| true 720p, it's nice to be able to output 360p or 240p inside
| a 720p container with each pixel and line duplicated two or
| three times. Doing it that way gives you nice crisp pixels
| rather than the blurry mess the displays internal upscaler
| would probably produce. You can even insert blank lines to
| get a faux-CRT-scanline effect.
| phire wrote:
| And HSTX is actually pretty flexible. Nowhere near as
| flexible as PIO, but it can repeat pixels by itself
| (though, it uses the shift, so you can either pack multiple
| pixels per 32-bit word, or repeat pixels, not both).
|
| Scanline doubling/tripping and blank line inserting can be
| done with nothing more than DMA chaining.
| vardump wrote:
| > while the rp2040 was limited to 1/10th of the system
|
| Isn't RP2040 capable of outputting at system clock rate?
| phire wrote:
| Oh... yes. I had a total brainfart there and started
| thinking about the time for a pixel (which is 10 bits).
| dmitrygr wrote:
| The two chips I have will both run at 350MHz with Vcore at
| 1.3V. No glitches seen. I am not sure how safe it is to run
| with that Vcore for long though. Probably fine. Stock Vcore
| will take you to 300 seemingly on all instances of rp2350
| ironhaven wrote:
| What kind of retro computing are you doing that would work well
| with high definition (720p). Standard definition I believe only
| started to be limited around 2007 when Xbox games like Dead
| Rising had captions that where too small to be legible on SD
| tvs
| MBCook wrote:
| I think a link to the repo instead of the change set might be
| better.
| kelnos wrote:
| I had no idea what this was, ended up clicking around to the
| README, and found it quite the enjoyable read.
| sitkack wrote:
| This is amazing, not only did they port from the 2040 to the
| 2350, but they also ported all the functionality they could
| support over to the RV32 cores as well. PicoDVI is usable no
| matter what cores one chooses to use on the RP2350. Well done!
| jsheard wrote:
| The author is also the creator of the RISC-V core found in the
| RP2350, you don't get your own core design taped out as an ASIC
| and then not show it off :p
|
| https://github.com/Wren6991/Hazard3
| jakobson14 wrote:
| Guy is an employee of raspi, so of course he's going to write
| code that ships chips.
| transpute wrote:
| Is it theoretically possible to have 2-way HID (keyboard, mouse)
| and 1-way video output on a single USB-c cable? It would simplify
| connection to a KVM or software-emulated display/keyboard/mouse.
| Low FPS would be enough for dashboards and CLI.
| jauntywundrkind wrote:
| There's no current specs for dual directional USB over any
| cable, afaik. There very well should be.
|
| You could present as a device and offer networking and have
| usb-ip advertised over multicast on that port. Easy, weekend
| project at most, would be dead obvious to any practitioner.
|
| USB4 as a packetized protocol really should offer something. I
| do wish there were like a half speed 2.5Gbit usb4 option, that
| microcontrollers could have some hope of accelerated bit
| banging.
| FlyingAvatar wrote:
| Haven't USB hubs done this since USB 1.1?
| yonatan8070 wrote:
| I believe that the author is talking about plugging in a
| USB-C cable between your laptop and some headless system,
| and having your laptop send HID data, while also capturing
| a display output from the headless system
| bonzini wrote:
| Isn't that exactly what a USB-C docking station does? It
| receives display and audio data, and acts as a USB device
| (keyboard, mouse, webcam). You'd need hardware that can
| receive DisplayPort, but it's doable.
| numpad0 wrote:
| Looks like an Alt Mode host with DP sink capability is
| technically allowed...? But it also looks like USB host
| controllers with Alt Mode support exposes internal DP
| source driver inputs, rather than handing you bunch of
| bare copper wires in Alt Mode, so I doubt it
| realistically has an implementation.
|
| ref: https://vesa.org/wp-content/uploads/2019/10/USB-
| DevDays-2019...
| BenjiWiebe wrote:
| Afaik this is 100% allowed by the spec. Flash drives are
| bidirectional (in and out). Hubs present multiple devices to
| the host through one cable.
|
| IDK why it isn't done more often in one device though.
| transpute wrote:
| Looks like Belkin has a USB-C cable for VR headsets, which
| breaks out to DisplayPort (video) and USB-A (data)
| connectors, https://www.belkin.com/support-
| article/?articleNum=316883
| numpad0 wrote:
| But neither USB nor DP(or DVI, VGA...) are symmetrical
| interfaces. They don't work like RS232C or Ethernet ports,
| a product that use these standards must be designed from
| beginning as a host or as a peripheral(or as a special
| 2-in-1 gadget that can exclusively switch roles). I think
| that's what GP meant by dual directional.
| transpute wrote:
| According to Wikipedia, DisplayPort 2.0+ can coexist with USB
| data on the same cable,
| https://en.wikipedia.org/wiki/DisplayPort
|
| [2.0] .. using only two lanes on the USB-C connector via DP
| Alt Mode to allow for simultaneous SuperSpeed USB data and
| video
|
| [2.1] .. tightened its alignment with the USB Type-C
| specification as well as the USB4 PHY specification to
| facilitate a common PHY servicing both DisplayPort and USB4.
| In addition, DisplayPort 2.1 has added a new DisplayPort
| bandwidth management feature to enable DisplayPort tunnelling
| to coexist with other I/O data traffic more efficiently over
| the USB4 link.
| jauntywundrkind wrote:
| I thought the comment was talking about both sides of the
| USB cable exposing devices to the other, when they said:
|
| > _Is it theoretically possible to have 2-way HID_
| tomcam wrote:
| Can someone explain the downvotes?
| yonatan8070 wrote:
| I don't think you can do it direcly.
|
| I recently found the Openterface Mini-KVM [1], which is
| supposed to allow you plug it into your laptop over USB-C, and
| some arbitrary system with USB+HDMI. Then, using their host
| software, view the HDMI display output and send mouse and
| keyboard inputs with ease.
|
| I haven't tried it, so I can't speak to how well it works, but
| it sounds promising.
|
| It is a crowdfunded project, so the usual caveats apply
|
| [1] https://openterface.com/
| transpute wrote:
| This thread has gone from: could exist?
| not possible specs imply yes? exists as open
| hw/sw
|
| Thanks so much for the pointer!
| https://www.crowdsupply.com/techxartisan/openterface-mini-
| kv...
|
| _> KVM-over-USB .. macOS, Windows, and Linux [clients], with
| Android support in development.. HDMI and emulated keyboard
| /mouse (HID) input.. video up to 1920x1080@30Hz with under
| 140ms latency.. play target device's audio directly on the
| host computer.. [send text] from the host to the target
| device, ideal for copying usernames, passwords.. Switchable
| USB-A Port.. for transferring files.. or sharing other USB
| devices._
|
| With USB storage emulation, this approaches BMC remote mgmt,
| minus network attack surface.
| numpad0 wrote:
| I think most people just weren't sure what you're talking
| about.
|
| Communications between such a thingamajig capture card and
| a laptop has nothing to do with DP Alt mode or USB HID,
| it's whatever custom USB packet types that capture card
| manufacturer comes up with. That technically wouldn't be an
| answer to your original comment in strict sense.
|
| The most likely heuristic paraphrasing for your original
| query is something like "are there ways to multiplex DP
| _source_ and HID _peripheral_ on a single USB3+DP Alt
| connection". That made no sense at multiple levels on top
| of being unlikely to be possible. That lead to people
| hallucinating wildly.
|
| The alternate question "are there ways to plug an SBC into
| laptop somehow for remote control, over a single USB-C
| cable" has that dongle as an answer as we now know in
| hindsight. But that is not a straightforward interpretation
| and response for your original comment, especially with
| your follow-up replies about DP Alt mode specs that would
| not be used by such a device.
| transpute wrote:
| Thanks for the feedback.
|
| As mentioned by others, there are USB-C docking
| stations/monitors where a single cable provides power to
| the device, takes video from the device, and sends
| keyboard/mouse events to the device. I should have asked
| whether software on a laptop could emulate a USB-C
| docking station, i.e. DP display sink + keyboard + mouse,
| since docking stations already exist.
|
| _> Communications between such a thingamajig capture
| card and a laptop has nothing to do with DP Alt mode or
| USB HID, it 's whatever custom USB packet types that
| capture card manufacturer comes up with._
|
| I was surprised to learn that Windows/Linux/Mac/Android
| userspace software can encode/decode custom USB packets
| from a USB-C cable, without a custom kernel driver. Could
| RP2350 implement a similar custom protocol at the other
| end of the cable, removing the need for a hardware
| capture device?
| rcarmo wrote:
| You can get the RP2XX0 PIO to control an extra USB host port.
| I've been keeping tabs on RP2040 resources:
| https://taoofmac.com/space/hw/rp2040
| u8080 wrote:
| Yes, this theoretically could be done using DP Alt-mode for
| type-c. It allows up to 4 lanes(commonly 2 lanes) DP signal
| over typically USB3 assigned lanes. USB2 data lanes are still
| functional in this mode. https://newnex.com/technology-
| articles-dp-alt-mode-over-usb-...
| g15jv2dp wrote:
| This already exists, right now...? I've seen tons of USB hubs
| with an hdmi output and several USB ports that can be used
| concurrently. Hell I'm using one right now. Are you asking
| about something else?
| transpute wrote:
| This is for connecting an SBC to a laptop via one USB-c
| cable. The laptop emulates a display and sends kb/mouse
| events to the SBC.
|
| Another comment pointed out a $100 board that can tunnel USB
| data + video on one cable.
| silon42 wrote:
| You can easily have PD+DP+USB (but limited to 2.0).
| wrycoder wrote:
| _Bitbanged DVI on the RP2040 Microcontroller_
| sylware wrote:
| I wish the RP2350 would include a fuse to disable for good the
| ARM cores for those who want only the risc-v cores (and maybe not
| pay ARM royalties on those chips).
| jsheard wrote:
| See pg.1259 in the datasheet, the ARM_DISABLE fuse does exactly
| that. Putting that in was a smart move because it means they
| can always make a RISC-V-only variant of the chip without
| having to tape out new silicon - they just have to blow that
| fuse at the factory.
| londons_explore wrote:
| I'm not sure "arm-core-disabled-by-fuse" is gonna be
| sufficient to persuade arms legal department to stop charging
| royalties...
| axoltl wrote:
| That's actually a super common way to handle licensing in
| hard IP. You don't want to spin different revisions of a
| chip with and without the IP, that's expensive. So you
| build in fuses to permanently disable the IP. This happens
| a lot with hardware video encoder/decoder blocks.
| mschuster91 wrote:
| Or you do it the other way around in software - remember
| the Pi 1/2 era where you had to buy separate licenses for
| MPEG/h264 HW decoders, tied to the Pi's serial number?
| sylware wrote:
| That's why the fuse, with proper sales accounting, is so
| much important.
| sylware wrote:
| Good!
|
| Upon buying a board with a RP2350, do you know of a reseller
| who burns the fuse before shipping it to you (and don't pay
| ARM royalies on that sale)?
| _Microft wrote:
| Maybe this is just not the microcontroller you are looking
| for?
| TaylorAlexander wrote:
| One imagines that at some point they will release a pure risc-v
| chip, once community adoption of the new RP2350 cores is
| widespread.
| sylware wrote:
| It means the chip CPU cores won't be tied to ARM PI
| enforcement, and won't have to pay for the license to
| implement ARM ISA (or implement ARM core design).
| numpad0 wrote:
| So no words about Cadence-Synopsys duopoly? ARM bad lazy,
| that's it?
| sylware wrote:
| Rome was not built in one day.
| TaylorAlexander wrote:
| Yes, correct.
| kristianp wrote:
| In case anyone missed the blog post about the Raspberry Pi Pico
| 2, here it is:
|
| https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...
|
| It has quite a list of products already created by their
| partners.
| peterburkimsher wrote:
| If anyone wants a PicoDVI sock or 4, I had 5 PCBs manufactured
| and am only using one.
|
| I wanted to put the HDMI connector onto the PCB itself, so I
| could avoid soldering the very small pin pitch. So I took some
| measurements and did my first KiCad project!
|
| https://forum.kicad.info/t/hdmi-pcb-edge-connector/48358/9
|
| Just send me an email if you're interested in having one, and I'd
| be happy to post it to you. The resistors are already populated,
| too, you just need to solder on the Pico using the through-hole
| connections.
| amelius wrote:
| Is there any way to select between two HDMI signals?
|
| I have an nVidia Jetson but its boot sequence turns off the HDMI
| output at some point. It would be nice if I could show a
| placeholder screen while the Jetson is booting. Would something
| like that be possible by using this RP2350 board?
| ale42 wrote:
| Not directly because it can't handle retransmitting the
| existing HDMI signal. You probably need to add a HDMI/DVI
| switch IC like this one:
| https://www.analog.com/en/products/ad8196.html
| psd1 wrote:
| I've tried a few commercial hdmi switches, to share a monitor
| between machines. The switch time is long and the monitor
| doesn't reliably wake up. Perhaps it's related to eDID?
|
| Do you know how that chip is for real-world usability?
| kees99 wrote:
| > switch time is long and the monitor doesn't reliably wake
| up
|
| In my personal experience, obtuse monitor's firmware is
| often to blame.
|
| Using a switch with one extra input port, where all data
| pins are connected to ground (via series resistors), and
| switching to that port for a brief moment, before switching
| again to the real intended input, usually helps some.
| amelius wrote:
| Isn't it possible to create a valid and stable HDMI
| signal based on two inputs? I can imagine that some
| memory is required to synchronize both signals. Is there
| an IC that can do that?
| dezgeg wrote:
| I'd be surprised if that was not fixable in the Jetson with
| pure software changes.
| amelius wrote:
| Perhaps but I don't have time to familiarize myself with
| their boot architecture. Also it might be different in their
| next version.
| phkahler wrote:
| It says 60 percent of CPU cycles on one core with the other core
| free. What does the available 40 percent of the one core look
| like? I'm assuming its got some high frequency interrupts going
| that can't be disturbed? What restrictions are on using the
| remaining capacity of the one core?
___________________________________________________________________
(page generated 2024-08-16 23:01 UTC)