The reason for this port is that I'm using PicoVGA as a VGA terminal for an 8bit retro computer. I'm using USB host mode on the Pico for keyboard and mouse input. I found a Pico W for sale for a reasonable price + shipping so now I can add wifi support.
Can it run a ~GNUscreen text console attached to a serial port attached to pins on the other side of the Pico, and maybe a BLE keyboard/controller? (And how, while I'm at it; Thonny has an AST parse tree menu item)
- TIL electronics.stackexchange has CircuitLab built-in: https://electronics.stackexchange.com/questions/241537/3-3v-... . Autodesk TinkerCAD is a neat, free, web-based circuit simulator, too; though it supports Arduino and bbc:micro but not (yet?) Pi Pico like Wokwi.
There is at least one RP2040 JS simulator:
Wokwi appears to support {MicroPython, CircuitPython,} on {Pi Pico} and also Rust on ESP32:
https://vscode.dev/ is the official hosted copy of VSCode as WASM in a browser tab. YMMV with which extensions work after compilation to WASM and without WASI (node/fs,) in a browser tab.
Why is it always analogue output with these kinds of devices? It seems to me like it should be easier to do some form of digital out, but you never see small micro-controllers implementing any kind of digital video output. Is it just because current video standards are bloated and terrible (HDCP, really complicated spec, etc) or is there some more fundamental reason why analog out is so much easier?
Apparently, there is a digital video output project for the RP2040 already out there [0]! As for why digital video is more rare, it is because the common digital video formats are higher bandwidth and require higher signal integrity.
Analogue output is actually easier that's why it's done. Here, you just have to push out some signals at the right (slow) timing and you get a picture. DVI/HDMI requires pretty decent technology to do effectively.
Maybe it would make sense to have a "framebuffer chip", that handles things at a fairly abstract level-- commands like "set screen dimensions to 640x480x8bpp", "write buffer #12, pixel (203, 122) as colour 0xF3", "toggle buffer #5 to active display".
Let the "framebuffer chip" handle the timing sensitive HDMI/DVI dance, and then you can use the general-purpose controller for things like "map a more well-supported graphics protocol to this language". If the controller fails to meet a timing requirement, the framebuffer chip doesn't cause the monitor to lose synch, you'd just get a torn image because it wasn't fully populated in time for the frame to render.
What I've been waiting for is some sort of "modern MCU as replacement for expensive, clunky, slow old video cards." It seems like if you want to use something like a Pi Pico, it would use almost all of the resources just to maintain synch and timing, so it might not be amenable for the other half of the job-- monitoring the external bus and waiting for inquiries on the framebuffer/firmware/support register address ranges.
Most small LCDs have a controller chip that manages the framebuffer and have a high-level interface like you describe. However, using these interfaces is still very slow. Much slower than this VGA interface.
The Pi Pico has 2 cores so while one core is used entirely to maintain the display the other core can do other things.
I looked at how USB was bit-banged on an arduino and I'm sure some of the problems involved are common with this.
One constraint is VGA is at minimum around 25mhz and HDMI is at minimum 165mhz and a pico is around 133mhz.
It also takes clock cycles to update the data and run algorithms. Some of the algorithms can often be mitigated to the silicon that controls some of the pins as they can have small bit of programmable logic for this purpose or can be re-purposed, but usually not all the pins or all of the algorithms.
There are tricks and such that might be able to get it working in certain lower resolutions and color modes, perhaps like overclocking or taking advantage of some harmonic, or clever use of some existing feature, but the more tricks you do to get things faster,often introduce issues with stability that you have to mitigate or solve. This barely touches physical constraints like cord length, signal integrity, voltages and current, overheating, etc that may or may not be applicable.
A TMDS symbol is 10 bits long so a pixel clock of 25Mhz needs a DVI bitrate of 250Mhz. You can generate DVI with an overclocked RP2040[1], but even then you have to halve the horizontal resolution because the general TMDS encoding algorithm is expensive to perform in software. You could, however, replace the VGA resistor DAC with a dedicated DVI encoder IC like the TFP401.
Not an expert, but with a back of a napkin guess, the minimum for say digital HD, might be something like the following:
X x Y x colour_bytes x frames x 8bits
Eg, 1280x1080x3x60x8=1.99Gbps
So at 133Mhz, each cycle the RP2040 would have to push 15 bits out. It's got 2x cores, can be overclocked at double reliably, and has a bunch of programmable IO machines, so maybe doable, but likely not 4K. (More around 10-20Gbps.)
There are 5 processors on the chip, which you can optionally use as required:
NPU (neural processing unit https://github.com/sipeed/TinyMaix/blob/main/benchmark.md)
H264 video codec
RV64 application processor capable of running linux
RV32 radio processor for the 3 radio protocols it supports - wifi/BT/zigbee
RV32E low power core to manage the chip
The radio and application cores should run fast enough to be able to bitbang digital video signals, there is 32K VRAM which I guess might be used for the bundled touchscreen display.
You mean with parallel address and data bus? That would be a whole lot of pins and quite a large effort to implement, not to speak of getting the timing right, when going beyond a clock rate of 10MHz or so. In the MCU world (quad) SPI RAM is favored, if external RAM is needed. That can be done with the RP2040 (well, you'd have to move the content yourself, there is no hardware support to transparently access external RAM, like in some other MCUs).
But what exactly do you have in mind with the 'instant booting computer experience'? The RP2040 has 264KiB of RAM already (more than the address space of a PDP-11), so surely that qualifies as 'computer'. That should be enough to even emulate a 8 bit Home Computer (well, it has been done for 6502 and Z80 CPUs and whole CP/M machines and ZX Spectrum).
Not that I get this obsession with 'instant on'. My chromebook is ready for me the moment (well, within a blink of an eye) I open the lid. My desktop needs a minute or so, but I reboot it only when there's a kernel update ...
There are countless chips for more dollars with external RAM. RAM IP costs literally dollars, costs silicon area, increases package price, makes pcb design more difficult and would probably canibalize Raspberry Pi Zero sales.
> The PicoVGA library source code and the PicoVGA library sample programs are freely available for further use and
modifications. This does not apply to certain graphics and sounds (such as the sounds in Pac-Man) and scene definitions in Sokoban, as these are subject to third party copyrights and may be subject to different distribution terms.
- rs232
- UART
- USB-TTL w/ configurable (3.3v/5v) voltage levels
- (optional) VGA output
- (optional) WiFi/Bluetooth (RP2040W Pi Pico W)
The OpenWRT hardware/port.serial wiki page explains how to open a serial console with screen and a tty /dev; and about 3.3V/5V bricking a router and/or the cable: https://openwrt.org/docs/techref/hardware/port.serial#use_yo...
PiKVM may have console support but with a Pi 3/4+, not a $4/$6 RP2040 /W with or without low-level WiFi+Bluetooth
"Raspberry Pi Pico Serial Communication Example (MicroPython)" https://electrocredible.com/raspberry-pi-pico-serial-uart-mi...
> The RP2040 microcontroller in Raspberry Pi Pico has two UART peripherals, UART0 and UART1. The UART in RP2040 has the following features: [pinout]