Hacker News Reader

Comment by canucklady | Hacker News Reader

I think dunking on the rpi is harsh - if it allows you to prototype and get your small-volume product out the door quickly, there's lots of other areas you could optimize the BOM first. Better to make a product with 75% gross margins as a single dev in 6 months than a product with 80% gross margins with a team of 6 in a year. Of course, they also overhired and wasted money on other BOM components

View on HN

The problem with rPi is storage and filesystem. You need to issue a shutdown command and wait for it to complete before removing power in order to help ensure that it will come up without problems. This will literally never happen with a consumer IoT device. Also, SD media is extremely prone to failure.

It's fine for prototype at a very early stage, absolutely not fine for something you ship to a user.

On the other hand, see https://news.ycombinator.com/item?id=33892009, https://www.raspberrypi.com/success-stories/korg-synthesizer... for example on how some companies use Raspberry Pi compute modules in their products.

Am assuming here that they're adopting strategies to minimize/work around the problems you mention.

The computer module instead of the standard Pi is the first step of those strategies. It doesn't use the SD card (in fact the data sheet gives details on how to configure the OS if you won't be shutting it down before removing power) and the device as a whole requires smaller electrical current that the standard device.

Ironically today, for embedded hardware projects, it would be a perfectly fine idea to use a Raspberry Pi... Pico microcontroller.

You would typically use a read-only filesystem in an embedded system, not the default raspbian style distro. This allows you to a) not require a clean shutdown and b) saves your physical media from writes.

This. Check out https://balena.io as one example.

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)

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.

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)

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.

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.

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.

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.

Reply on news.ycombinator.com