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.
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.
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.
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.
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.
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.
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.
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 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.
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
sudo systemctl stop rsyslog
sudo systemctl disable rsyslog
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.
Set up everything how I like it, set root read-only and mount tmpfs in various areas such as /var/log etc..
I haven't tried them myself, though.
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.
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!
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.
Obviously 4GB is not a lot, so I use tmpfs and USB storage as appropriate.
: https://www.raspberrypi.org/forums/viewtopic.php?p=1257129 (2nd to last comment in the thread)
Also, the Zymbit works nicely with its eMMC.
 From what I understand it still has all codecs unlocked by default which you'd have to do manually with the new CM3+.
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.
"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.
I recently saw this project for processing 3d 'vr180' stereoscopic vision with a Pi Compute module, called StereoPi. http://stereopi.com/
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.
I've sometimes had the same question, and have also wondered what industrial applications the compute module is being used for?
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...).
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.
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.
Though, documentation is likely sparse.
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...