Live data from Hacker News

I've now played with a Raspberry Pi 400 for a week and here are my conclusions

news.ycombinator.com

71–80 of 222 posts

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#71

Earlier quoted context omitted.

Why is that more useful than a removable SD card?

I think the comment was a bit tongue-in-cheek. The underlying storage tech between is the same, but eMMCs have a controller that handles the actual layout of the data. In a removable SD card setup, this is handled by the CPU, which of course has many other things to worry about. Having its own controller makes eMMCs more reliable.

"eMMCs have a controller that handles the actual layout of the data"

Maybe there is some part that eMMCs have that SD cards don't, but SD cards absolutely do have a controller that does layout (wear levelling). It doesn't do the filesystem layer, but IIRC eMMC's don't either.

AFAIK the only reason SDs are less reliable, is because they're cheap and the socket can be loose, causing corruption during a write (or wear level). It would be interesting if you know of something logically different that also makes them less reliable.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#72
post #15

I learnt to program on the ZXSpectrum with "Write Your Own Adventure Programs for Your Microcomputer" [0] The RPi400 with Pico-8 seems to tick the same boxes, so I got one for my 10yr old. He's loving it. Perfect use case. [0] https://colorcomputerarchive.com/repo/Documents/Books/Write%...

one of my colleagues uses that as an assignment for his students, they have to port one of the listings to c++

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#73

I understand why the Raspberry Pi uses SD cards (cost, simplicity, ease of use) but the entire line would be so much more useful with onboard eMMC storage. SD cards are great for keeping cost down and getting started quickly by flashing OS images from a PC. However, enthusiasts spend so much time fiddling with external storage options and cobbling together messes of powered USB hubs, cables, external enclosures, and…

It would be better if it had a built in fast flash of about 8GB. That’s enough to run the OS and do basics and if you want more, add it via one of the external ports.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#74

I understand why the Raspberry Pi uses SD cards (cost, simplicity, ease of use) but the entire line would be so much more useful with onboard eMMC storage. SD cards are great for keeping cost down and getting started quickly by flashing OS images from a PC. However, enthusiasts spend so much time fiddling with external storage options and cobbling together messes of powered USB hubs, cables, external enclosures, and…

I browsed the datasheet [1] for the BCM2711 processor and did not see an eMMC controller on this part. Assuming the SD card is connected by SPI which would explain why it's so slow. Also rules out eMMC. [1] https://datasheets.raspberrypi.org/bcm2711/bcm2711-periphera...

The physical layer for eMMC is SDIO- the same is used for SD cards, at least if you want more than ~ a megabyte/s of interface bandwidth.

IIRC the layers above SDIO are slightly different for eMMC and SD(HC), but generally SoCs that have SDIO interface support both types of memory.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#75
I have been playing with a Raspberry 400 for couple of days now. I thought of recommend it for my nephew, but couldn't do it because of the following drawbacks.

1. Lack of 3.5mm audio jack or built-in microphone/speakers 2. Unable to run Zoom reliably

Given that schools are closed (at least in India) and classes are happening over zoom, these two drawbacks makes it a no-go for my use case.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#76

Sounds like a neat bit of kit. For anyone unfamiliar, it's essentially an ARM-powered PC, in the form factor of a keyboard. [0] > I was able to unbrick it I know it's a nitpick, but if it can be repaired, it's not bricked. [0] https://www.raspberrypi.org/products/raspberry-pi-400-unit/

In my opinion if the fix is not know at the time it could be considered bricked, at least temporarily until the fix is discovered. How would you called a device that meets a fate like that? Stuck? Blocked? Unaccessible?

Soft bricked vs hard bricked. There are recovery procedures (possibly intrusive or troublesome) for soft bricked.

As an example, if I have a network device so screwed up that I have to do a little power and connection dance to get it to reload via tftp, I'd call that a soft brick. If I have to solder in jtag pins, that's pretty firm. If the magic smoke has come out, that's definitely hard.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#77

I understand why the Raspberry Pi uses SD cards (cost, simplicity, ease of use) but the entire line would be so much more useful with onboard eMMC storage. SD cards are great for keeping cost down and getting started quickly by flashing OS images from a PC. However, enthusiasts spend so much time fiddling with external storage options and cobbling together messes of powered USB hubs, cables, external enclosures, and…

3B+ forward has support for USB boot, as of I think July this year it was built into the firmware for the 4b. I have a Zw with SD card as it requires more or less but everything lese is USB based with drives I swap around for raspbian, ubuntu, retropi/etc. But setting that up does require an SD card with respbian unless the pi shipped with the newest firmware.

I'm not against on board storage but I understand the tradeoff to allow user expandability and reduce production costs. I think they'd get heat on the eMMC size unless it was like 32gb and I don't think that cost increase would make it very far. But maybe with the push to the 400 they will start to go that route to create a self contained but expandable system that is plug and play raspbian by default.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#78

I understand why the Raspberry Pi uses SD cards (cost, simplicity, ease of use) but the entire line would be so much more useful with onboard eMMC storage. SD cards are great for keeping cost down and getting started quickly by flashing OS images from a PC. However, enthusiasts spend so much time fiddling with external storage options and cobbling together messes of powered USB hubs, cables, external enclosures, and…

I browsed the datasheet [1] for the BCM2711 processor and did not see an eMMC controller on this part. Assuming the SD card is connected by SPI which would explain why it's so slow. Also rules out eMMC. [1] https://datasheets.raspberrypi.org/bcm2711/bcm2711-periphera...

The Raspberry Pi Compute Module 4 has eMMC.

Jeff Geerling benchmarked it and found it faster than his fastest SD card: https://www.jeffgeerling.com/blog/2020/raspberry-pi-compute-...

It's definitely not NVMe fast, but it's perfect for average workloads.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#79

I understand why the Raspberry Pi uses SD cards (cost, simplicity, ease of use) but the entire line would be so much more useful with onboard eMMC storage. SD cards are great for keeping cost down and getting started quickly by flashing OS images from a PC. However, enthusiasts spend so much time fiddling with external storage options and cobbling together messes of powered USB hubs, cables, external enclosures, and…

Personally I wish they'd add an m2 slot and scrap the SD card. It really is the bottleneck of the whole system.

But they walk a fine balance with PCB space, backward compatibility, performance, cost and user-friendliness.

Re: I've now played with a Raspberry Pi 400 for a week and here are my conclusions

#80
post #28

I got a pi 400 to replace a 2009 mac mini that was serving as the kids' computer but was struggling to play the online games they wanted (including scratch) because of missing webgl support in recent chrome updates. Performance is roughly on par with the core 2 duo in the mini, but the graphics is more powerful and fully supported by webgl, so in practice it struggles less with the scratch environment and online game…

But why are you using Chrome in the first place - it's a known memory and CPU hog! Doesn't Firefox or other Webkit based browsers support webGL fully?

FF uses more memory on my system than Chrome now..
Post reply on HN