HDMI is rather high-frequency (faster than our typical CPU clocks … so no bit banging ), and not something any Cortex-M or smaller has peripherals for.
Something the beaglebone does is to use an HDMI framer – seems quite elegant: produce video at a parallel interface (down to 2.5MHz pixel clock through pixel stretching for … probably 64x480?) and audio in I2S, then send through a TDA19988 that goes for 5€ in single pieces (3.50 in quantity).
This might be enough to get at least a monochrome screen plus I2S audio signal from any chip; chips with parallel video output (we don’t support LPC1788 right now) or an external engine could do even actual graphics.
Are there other options?
Does it matter? (I’d say ‘weak yes’; anything with actual graphics is probably overkill, but a static text for a remote audio player that goes through home entertainment systems could be nice).
Well, I was thinking about using composite and a composite to HDMI IC.
Like the ms1858.
HDMI has 5V with 50mA. Not sure how much the IC uses.
Having a small HDMI dongle you can program and run some simple apps on it, sounds pretty nice. You can program some API for it and display whatever you need.
Nothing too crazy. Just some simple more or less static applications or whatever people come up with.
I don’t know any other product like that. It would be nice, if you can display on any HDMI display data from other 802.15.4 devices.
There is also the Commander X16 project: Commander X16™ About & FAQ - Commander X16™ Community
A C64 with 512K flash, 2M ram (all bank switched to hell…) and VGA output via some converter chip.
(I thought a revision had HDMI, I was wrong!)
HDMI attaching things is not the thing I’d care about. Trivial interfacing to some off-the-shelf 4-line LCD display… that would be good.
VGA is also fine. Actually even better. There are also VGA2HDMI ICs. The benefit of HDMI is though that you can even package it into some kind of product. And everyone has a HDMI Monitor or Display.
So, you can just plug it into the Monitor/Display and have your sensor data or whatever you want to display.
Going through VGA would be a bit weird as it’s an analog signal; doable, but worth the hassle? (Compsite / CVBS is even worse as it contains modulated signals).
(In 8-color mode, VGA can probably be thought of as digital, but then, the same can be achieved with a parallel-to-HDMI converter (like the linked one) by soldering all pins to a single rail.)
All bit-banging etc is nice and good fun, but ultimately limits what the device can do (or asks the programmer to be very smart, and while it’s good to have tools for smart people, I’m more interested in software that’s maintainable, and as a rule of thumb you gotta be twice as smart to maintain as you were when you wrote, so don’t write on a smart streak ).
Without live generation, parallel output (or DAC to VGA or GPIO via DMA if that works / maybe through SPI peripheral?) necessitates an uncompressed video buffer; 640x480 in non-paletted RGB is about 1MB; we have few devices with even that much, let alone space left for the application. (Black-and-white single-bit would be 38k, that’s somewhat managable).
So, do we have alternatives?
Live generation per row: That’d be a high-priority interrupt, can we afford that when we also do 6LoWPAN on the same system? (Whatever runs in that interrupt would define our graphics engine; does it do color palettes? sprites? revive the ghost of long gone generations of consoles?).
External video memory? A classic; I don’t know a chip off my head. (IIUC these work by exposing a parallel writable memory extension, and allow you to clock out data as configured through a double buffer).
It’s HDMI, and we’re a long way from cathode ray tubes any more. We shouldn’t really have to send the image 60 times per second any more, and the outputs have video buffers anyway.
Unfortunately, depending on “ignore MSA” / “adaptive sync” makes the range of usable devices limited; plus the easy options to generate HDMI are unlikely to support it.
Still probably requires the display to be updated in full.
There’s of course always the option to use very custom HDMI drivers: This upcoming board has HDMI attached to an FPGA attached to an MCU
(Note that not all FPGA do have the TMDS outputs to do this. The iCE40 need some tricks to get such a signal; the Cyclone on the Vidor board “just” goes through AC coupling.)
I’d find a suitable MCU (stmf7?) with usb host mode (for mouse/keyboard), ethernet and hdmi out quite interesting. At least for educational stuff that’s more bare-metal than e.g., a Raspi…
Let’s get back to <10ms from keypress to doing something on screen!
ad Nintendo: Driving a like 256x240 LCD is easier than driving HDMI – it’s probably using a parallel video output, and RAM requirements for that resolution are manageable on a Cortex-M7. It’s a good reference point but won’t get us to HDMI.
ad host mode / educational / more bare-metal: That takes us into the direction of retrocomputing (which may be misnomer), or reinvention of computing – monotron, betrusted and starting over. Is that an area in which we can even go without losing the low end of devices?
), and not something any Cortex-M or smaller has peripherals for.