Hacker News new | comments | ask | show | jobs | submit login
New Raspberry Pi Compute Module 3+ (raspberrypi.org)
187 points by schappim 19 days ago | hide | past | web | favorite | 74 comments

This looks delectable for the eMMC storage alone. I wish there were a Raspberry Pi model that came with it... I'm tired of SD cards causing problems and eating my data or (more frequently) causing the Pi not to boot.

I also wish Raspbian had an option to mount all the write-heavy directories (logs, etc) on tmpfs, so they wouldn't wear the card out so quickly.

Well it's just Linux so you definitely can and that's what I do. As a result I've been running my pi 2 on the same card for nearly 4 years now with no issues. But if your point is that it should do it out of the box for you, I agree it shouldn't require manual setup.

Yeah, that's what I meant. It's not hard to do, but it's one more thing and it would be nice if it were done automatically.

I believe recent versions of Raspbian (at least the ones available on raspberrypi.org) mount all of /var as tmpfs. That's a RAM filesystem.

That's great! I'll need to rebuild my Raspberry Pi if that's the case, maybe make everything run in some repeatable way so I can reprovision quickly if I need to, thank you.

When done properly, SD cards are reliable enough. For my digital signage product the custom OS is highly optimized around avoiding IO as much as possible. There are thousands of devices, some running more than 4 years now, without any SD related problems.

I also really like the fact that the Pi is pretty much stateless. So switch SD cards and you can be mostly sure everything still works. If storage is bundled, that's a lot more difficult.

For most use cases, SD cards on Raspberry Pi's are not reliable enough.

I realize you may be successful in running signage devices, but most people want to simply be able to run common class 10 card (e.g. from Verbatim, Kingston, Sandisk), using a standard OS setup and leave the Pi running without having it corrupting your files. This simply isn't possible, in my experience. Also look at the OpenHAB forums as a reference.

The more regular disk activity, the worse it gets.

We went this route in our office and every 3-6 months we had corruption on each of many dozen Pi's. Once we switched to using USB drives (spinning or SSD) the issues were sorted out.

> but most people want to simply be able to run common class 10 card (e.g. from Verbatim, Kingston, Sandisk), using a standard OS setup and leave the Pi running without having it corrupting your file

To be fair: try the same with cellphones. I have a shitload of micro-SD cards gone bad on me, and yes genuine SanDisk not cheap fakes off of Amazon.

microSD cards are the cheapest crappy flash chips you can get with a microcontroller strapped in front for error correction.

I don't even put SD cards in my phones anymore due to corruption. I always got the best SanDisk's I could find. Luckily my Pi that runs probably 8 hours/week hasn't failed, but I have the drive imaged just in case.

Cheap SD cards are going to return less than desirable results. Higher quality cards such as SanDisk Ultra Mobile or Samsung Pro series should last quite a while when used as a normal "disk" on a system like this. As an added benefit, using a card like a Samsung Pro will also get you MUCH better file system speed for both reads and writes on common Linux file systems like ext4. The controller inside a Samsung Pro series card is much more advanced than run of the mill cheap Kingston cards.

If you really need durability, there's also a handful of SLC (single level cell) SD cards on the market which will last an order of magnitude longer in terms of writes as compared to consumer level MLC/TLC cards. SLC cards aren't cheap but you get what you pay for.

> Higher quality cards such as SanDisk Ultra Mobile or Samsung Pro series should last quite a while when used as a normal "disk" on a system like this.

Nope, it's mainly marketing. Cards from those brands are fundamentally not great for sub million unit purchases. We tried to use some for the root fs for a fairly high availability appliance. If you don't want one in twenty going out in a month (and we figured out a way to make them go out after 8kb/s for 8 hours with a specific access pattern without power drops), then you need 'industrial SD cards'. They'll treat you like adults when it comes to support, will have lot codes that actually map to internal changes, etc. Trying to sell a product with consumer SD cards (yes, even the ones that call themselves 'Pro') is basically a futile exercise.

Sure, but I don't have the time to highly optimize a custom OS just to put up an MQTT server in my parents' house. I want to do the work once and have it Just Work after that.

Out of interest, how did you approach disk encryption? That would be my concern with removable storage. The other thing I'm keeping an eye on is Arm's LittleFS for storage longevity.

It's possible to write 256 bit of user data to the Pis internal OTP memory. You can store a non-changeable key there. Of course that's then easily readable if you can run execute commands on the Pi.

LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out

1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that.

2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.

Oh, there's an OTP in the MPU? I didn't know that.

Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity.

With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable.

I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design.

[0] https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md

I posted it (though I'll freely admit hackaday was the source that I discovered it through)

Personally I want to use it as an internal filesystem for various projects (like games - instead of zip/pak files, which are really read only)

even littlefs over https might be an interesting naval gazing project :D

I store the data in encrypted USB flash drives & store the key in eCryptfs on the SD card.

You can (should) disable logging on raspbian:

  sudo systemctl stop rsyslog

  sudo systemctl disable rsyslog
It also makes sense to create a temporary directory in memory, if you don't need much space.

That's not a great solution because I do need logging sometimes, especially to see what processes are doing, I just don't need it persisted.

Unless you set the option in journald.conf systemd/journald will retain logs in an auto-rotated tmpfs.

It does this whether or not a syslog daemon is running. (All messages it captures goes through the journal and then are forwarded along)

You'll still be able to look @ recent logs with journalctl commands.

This is what I do for an IR camera project.

Set up everything how I like it, set root read-only and mount tmpfs in various areas such as /var/log etc..

Oh really? That's awesome then, thanks!

I've heard that these are better: https://www.digikey.com/product-detail/en/atp-electronics-in...

I haven't tried them myself, though.

Oh yeah, I recommended these in the past and just mentioned them again in another comment on this thread :)

4GB is enough for most Pi projects, and <$20 premium is worth never needing to worry about SD reliability to me. My understanding is they use multi-level cells, which are far less expensive than true industrial grade single level cells, but they only write a single value to each cell, increasing the reliability significantly.

Industrial grade AMLC, for example from this reseller and brand, haven't let me down yet. Other HN users have a similar experience. The downside is the price. Delivery was one day from Springfield to The Netherlands but had to pay duties. Which is like a total opposite of China: bad quality, cheap, slow delivery, but no duties

Oof, pretty pricy, huh.

EDIT: I see in other comments that they're worth it, so they're a great option for when I need reliability at a premium, thanks!

Check out: https://github.com/azlux/log2ram

Explanations: The script creates a /var/log mount point in RAM. So any writing of the log to the /var/log folder will not actually be written to disk (in this case to the sd card for a raspberry card) but directly to RAM. By default, every hour, the CRON will launch a synchronization of the RAM to the folder located on the physical disk. The script will also make this copy of RAM to disk in case of machine shutdown (but cannot do it in case of power failure). This way you avoid excessive writing on the SD card.

This is the best of both worlds, thanks!

I had problems with Samsung and SanDisk cards, which worked fine in a GoPro, and troubleshooting the weird Pi symptoms was aggravating. So I tried aMLC cards from ATP and have had zero issues. They cost significantly more (~$20/ea for 4GB @ qty 10 from Digikey w/shipping) but it’s worth avoiding the hassle to me.

Obviously 4GB is not a lot, so I use tmpfs and USB storage as appropriate.

According to SanDisk support[0] they only support the High Endurance line of SD Cards[1] for Raspberry Pi.

[0]: https://www.raspberrypi.org/forums/viewtopic.php?p=1257129 (2nd to last comment in the thread)

[1]: https://www.amazon.de/gp/product/B00V5Q1K3O/

Interesting, I definitely have not tried those yet. The Sandisk cards performed consistently worse in my experience, but I figured that could be anecdotal, and I had plenty of issues with Samsung as well.

Check out the NanoPI[0]. I've had really good luck with it.

Also, the Zymbit[1] works nicely with its eMMC.

0: http://nanopi.org/ 1: https://www.zymbit.com/zymkey/

That's interesting, thanks! Although, aren't AllWinner the devil? I think I recall someone saying that.

Maybe once upon a time, but with blobless mainline Linux kernel support for almost all features on almost all SOCs[1], including video codecs on many parts[2], anyone claiming Allwinner to be "the devil" or variants on a theme is unambiguously incorrect. Broadcomm and the raspi foundation are evil. [3][4]

[1] https://linux-sunxi.org/Linux_mainlining_effort

[2] https://www.kickstarter.com/projects/bootlin/allwinner-vpu-s...

[3] https://twitter.com/marcan42/status/1088472549715918848

[4] https://github.com/raspberrypi/firmware/blob/master/boot/LIC...

Of course, IO performance remains terrible.

Previously the only official way to get a 16GB variant of the Compute Module was to use the NEC edition[1][2]. Looks like that got a lot easier now.

[1] https://www.nec-display-solutions.com/p/eeme/en/products/acc...

[2] From what I understand it still has all codecs unlocked by default which you'd have to do manually with the new CM3+.

"CM3+ will be available until at least January 2026" - That's an impressive commitment. I'm pleasantly surprised to see them stick their necks out that long into the tech future.

It’s not consumer electronics, they’re targeting industrial applications. Is it that long a timeframe in that world?

It's not horrible but it's not remarkable either. 8 years is a decent but it's nothing compared to other SoM (system on module) vendors like Toradex. Toradex generally offer 12+ year commitment on their SoMs.

Consider that if you start a design now using a SoM that you probably won't get to market for at least 1 year. Then in the industrial/commercial space it'll take at least another year for your sales to ramp up. If you started today designing with a CM3+ then you'd get 6 more years of sales out of the product after sales ramp, but since the above timeline is going to hold for your replacement of the current product, you're going to have to start engineering on the replacement 6 years from now. For some industries this will sound amazing, for others it'll sound like a deal breaker.

If you look at SoC (system on chip, the processor) vendors, generally they're offering 20+ years of sales from release for SoC which target the industrial/commercial embedded markets. Vendors like TI or NXP don't generally end of life their silicon for a very very long time.

Oh sure. My point was precisely that the commitment wasn’t that impressive once you consider the application

If you need 15/20 years, you get a separate contract. 7 years as a baseline is not too bad, for that kind of device, but likely not sufficient on its own. Automotive test-beds etc. would require longer timeframes.

7 years availability seemed impressive to me, but I don't know, may be it's common in industrial embedded.

The other thing that impresses me is that the modules have remained electrically compatible, so (at least in theory) you could slot out a CM1 for a CM3+ and still expect it to work.

Perhaps, the CM3 (and I assume CM3+) have significantly higher power requirements.

From the PR:

"Note that due to power-supply limitations the maximum processor speed remains at 1.2GHz, compared to 1.4GHz for Raspberry Pi 3B+."

So I guess they're doing what they can to keep the power envelope consistent.

Very tempting.

I recently saw this project for processing 3d 'vr180' stereoscopic vision with a Pi Compute module, called StereoPi. http://stereopi.com/

Excuse the ignorance, but how does one use it? What would be some applications for this?

I saw an example of someone making a gameboy-like pcb on which you could plug in this module as a brain.


I remain surprised that there don't seem to be any of the shelf "blade centers" for raspberry pi compute modules. It seems like they're the ideal hobbyist and small business expandable computing resource.

Someone did make this at one point: https://hackaday.com/2016/01/25/raspberry-pi-zero-cluster-pa...

But it was never commercialized as far as I know.

miniNodes makes a 5 socket Raspberry Pi compute module "cluster" board which seems decent:


Hey, neat. Looks like they're still in pre-order mode, but I'll def keep an eye on them.

We're actually about to run a production batch. Should take about 3 to 4 weeks to turn them around from manufacture to shipping.

You mean the BitScope Cluster? http://cluster.bitscope.com/solutions

Those use the regular raspberry pi rather than the compute module, though, don't they?

Yeah, those are for the regular pi's and are very large as a result.

Outside of hobby purposes of "I made a cluster, that's cool!", I'm not sure why many people would want such a thing compared to bigger machines.

Right, I'm sure even using the AWS ARM instances would be faster/cheaper for its performance.

There's the cluster hat which supports 4 Pi Zeros on a Pi Hat. Good for hobbyist tinkering anyway.


The board that you are pointing to is a cluster of Pi Zeros.

I've sometimes had the same question, and have also wondered what industrial applications the compute module is being used for?

I use the sopine cluster modules and a clusterboard for my docker swarm. The sopine modules have a quad core and 2GB of ram and a sd card slot. It is a cheaper way of having a docker swarm (you could run kubernetes, but that is overkill).

As for the Raspberry pi module, it is the same price as the sopine module and half the RAM. One could argue the pi is better supported, but the sopine modules support armbian (and are actually in stock).

So is it worth it, well not right now. If you buy the module and the base board it is just cheaper and better to by a pi 3+. I saw a pi compute module backplace to hold 5 (i think it was 5) modules for like $250 (a pine64 clusterboard for 7 modules and a built in Gb switch is $100).

There are probably uses for it, maybe custom embedded devices, but i am not 100% convinced. I was a lot more excited about the Raspberry Pi 3+ Model A. That is nice for the price, but even then nano pi's have comperable devices for simliar cost (and are actually in stock).

I still love Raspberry Pi's though and can't wait until the 4 comes out. But as my Rock54 screams with a quad core and 4GB of emmory and usb3 for $45, i am questioning what a raspberry Pi 4 could bring to the table for the same price (M.2, 8GB of ram, etc...).

Slightly off-topic but does anyone known any good similar modules with support for LVDS and/or eDP displays (15"+ ideally)?

I've been wanting to assemble a sort of tablet device but I am having a really hard time finding a display/compute combo that will work with any confidence. I would ideally like to avoid having to get a separate A/D board.

I've done this on Olimex A20 boards (random laptop LCD had LVDS, A20 had LVDS output).

Recently I've used NanoPC-T4's eDP output. Unfortunately, their eDP pinout does not match VESA standard pinout, so I had to make an adapter board.

The UP board has eDP support. It's a fair bit more expensive, but it does have the benefit of an Intel chip: https://up-board.org/up/specifications/

The OrangePi Win supports LVDS: http://www.orangepi.org/OrangePiWin_WinPlus/

Though, documentation is likely sparse.

It would be really cool if someone created an updated RaSCSI for the Compute Module https://github.com/fran-cap/RASCSI-68kmlaver

Doesn’t seem to have 802.11 WiFi on board. Would have been nice for diy iot projects on the raspberry ecosystem.

Not quite DIY prices, but companies like Balena make RPi Compute Module carrier boards w/ WiFi https://www.balena.io/fin

Well, at least it wont shit the bed (i.e. SD card corruption) on a power fluctuation?

Is there something with similar hardware? Basically something with built-in, actual SSD flash.

I love the size and low-power use of the RPi 3+, but I hate having it's SD card die on me...

You can use flash drives over USB on RPi 2 and up. Boot from them and everything. Requires a tiny bit of setup.

If you go this route, be forewarned: not all SSD enclosures work. Do a bit of research on Raspberry forums before making any purchases. Also, Pi 2/3/B+ sadly don't support USB 3.0 devices, so much for backwards compatibility. I bought a handful of cheap SSDs and USB 3.0 enclosures for this exact purpose, but still haven't got any of them to boot, even though I did research and supposedly bought several from Sabrent that should work. In retrospect I should have looked closer, Sabrent makes a bunch of very similarly named drives with slightly different specs, some of which apparently aren't compatible. I found a forum comment suggesting to try the enclosure with USB 2.0 cables, but that avenue has been fruitless thus far. I will probably have to order some USB 2.0 enclosures.

Requires a SD card containing an updated bootrom on Pi 2. Pi 3 has the update bootrom but needs a bit flipped in OTP to enable the feature. Pi 3B+ has network and USB booting enabled out of the box.

Thanks to other commenters for the Balena and miniNodes links. I would be interested in something neatly packaged so it would look nice on my desk that had about a dozen computer boards with local networking set up.

The other option for that use case is the Pi Zero W, which is probably a bit friendlier for most use-cases. It has the older BCM2835 from the Pi 1 (but at 1GHz) – it's quite a bit cheaper, though does require the additional SD card.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact