[sokoloff]

If your product needs to output HDMI, I can easily see an argument for using a Pi. If your product needs a couple GPIOs to drive an LED matrix? Using an RPi is pretty difficult to justify. You're likely going to spend more on the SD card for the Pi than you would on more suitable microcontroller (which can still be easily programmed and, in my experience, has a better [or at least no worse] story for GPIOs than the Pi)

[tyingq]

It's difficult to drive these LED matrix devices from a typical MCU, especially with chained panels, lots of LEDS, etc. Either due to the ~10Mhz+ output needed, or the memory to hold all the pixel data. Consider, for example, that each of the two panels in this sign has 32x64X3 (6144) leds. You have to send on/off for all of those, and then control brightness for each color by using PWM...meaning half-red brightness would be changing that pixel so it's on/off/on/off fast enough to beat persistence of vision.

It's more common in the pre-built devices to have a controller that's using a main CPU plus a FPGA or CPLD. The better hobbyist drivers use things like a beaglebone black and it's onboard "PRU" that can drive real time from memory it shares with the ARM cpu and Linux.

Also, since it's pulling train data, you need more smarts or cycles than a typical MCU to pull via WiFi/https, transform text into pixmaps, etc. Though there are examples of beefy MCUs doing all this well, like an ESP32. Or examples of small MCUs driving a small single color matrix.

[kjagiello]

RP2040 is a pretty fitting MCU for this use case thanks to its PIOs coupled with DMA. It got me some impressive refresh rates on a 64x32 HUB75 display – over 2 kHz in 24 bit color mode. The lack of networking capabilities out of the box is a bit of shame though.

[dom96]

ESP32 is perfect for this application. RPI is far too beefy, unless you really want to do everything locally (without relying on an external server to package up the train data for you)

[tyingq]

Sure, though 240Mhz, 32bit, optional gobs of PSRAM, etc, aren't usually what comes to mind when you hear MCU.

Edit: Yes, you could even use an ESP8266, though 32x128x3 plus X bits of PWM brightness would mean being limited to drawing from storage rather than in-memory manipulation. I'd jump right to the WROOM type devices with PSRAM.

[sokoloff]

If you need a microcontroller with networking (such as the train sign would), I think the ESP32 (or older/cheaper/less capable ESP8266) is one of the first that comes to mind for most engineers, especially those who aren't full-time firmware engineers.

[anigbrowl]

You are quite right that the ESP is way over-specified for many tasks, but it's not like the uC is gonna quit and take a more fulfilling job elsewhere. You can get tiny boards for close to $5/ea, or under $5 if you don't need the USB connector. - and that's in single-digit quantities. The hardware configuration is very flexible, eg if power consumption matters you can run it a lot slower, switch off subsystems you don't need, use a watchdog timer to simplify exception handling etc.. There's a rich and constantly expanding SW ecosystem so you can get to a working prototype very fast.