Hacker News Board Hacker News, browsed like a classic message board
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

Post reply on HN
Print view View original

111–120 of 222 posts

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

#111

Post by grawprog »

908B64B197 wrote: post #82
grawprog wrote: post #23

I've been looking at either the pi 400 or or one of the pi 4 starter kits. For around the same price as the 400, I can get the 8GB pi and a full kit of accessories. But, I really like the idea of having everything just built into the keyboard. In your experience was the 4GB of RAM on the 400 reasonable? Ever since the 400 popped up on here i've been looking into both of them. I just worry the 400 lacks more long term…

There's a dead comments that's saying exactly what I'll say: The 400 uses a slightly different chip that can be overclocked to 2.2 GHz while the regular Pi 4 can't really go above 1.8 if I recall. More info here: https://www.jeffgeerling.com/blog/2020/raspberry-pi-400-tear... EDIT: The comment I was referring to has been restored!

Hmmm that doesn't seem true

https://www.seeedstudio.com/blog/2020/02/12/how-to-safely-ov...

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

#112

Post by tartoran »

johnklos wrote: post #20
zbrozek wrote: post #16

Earlier quoted context omitted.

I agree; I think bricked is a fine word for this, even if it's reversible. Once you give up it's permanently bricked.

Whether you agree or not, it's incorrect. Common usage of "bricked" has been one thing and not the other for many years.

From wikipedia brick(electronics) is quite relevant that bricking is not necessarily permanent.

Some devices that become "bricked" because the contents of their nonvolatile memory are incorrect can be "unbricked" using separate hardware (a debug board) that accesses this memory directly.[5] This is similar to the procedure for loading firmware into a new device when the memory is still empty. This kind of "bricking" and "unbricking" occasionally happens during firmware testing and development. In other cases software and hardware procedures, often complex, have been developed that have a good chance of unbricking the device. There is no general method; each device is different. There are also user-created modifier programs to use on bricked or partially bricked devices to make them functional. Examples include the Wiibrew program BootMii used to fix semi-bricked Nintendo Wiis, the Odin program used to flash firmware on Samsung Android devices,[6] or the fastboot Android protocol which is capable of reflashing a device with no software installed.[6]

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

#113

Post by magicalhippo »

anderspitman wrote: post #104
magicalhippo wrote: post #101

Earlier quoted context omitted.

It seems they recently changed[1] the default boot order to SD Card followed by USB Mass Storage, from just SD Card. Of course if you get an Raspberry Pi made before this became the default then you're SOL. [1]: https://www.raspberrypi.org/documentation/hardware/raspberry...

Are those settings in hardware, or the EEPROM?

This is the EEPROM settings.

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

#114

Post by fulafel »

snapetom wrote: post #46
jstanley wrote: post #41

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.

The main advantage of eMMCs in reliability is that you can't buy a RPi with a eMMC for camera use soldered on. You can have this same advantage by buying the right kind of SD cards (embdedded/industrial ones, or on a budget, overkill capacity "surveillance" camera cards that advertise wear leveling).

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

#115

Post by bitwize »

shiftpgdn wrote: post #107
bitwize wrote: post #105

Earlier quoted context omitted.

I've never experienced this SD card corruption, even when power goes down to the Pi. I believe it happens, but I wonder what my unique circumstances are. Is it that I always use Samsung or SanDisk SD cards with the Pi?

Those will still eventually die due to log being written to the card using all available read/write cycles.

That's a problem that will eventually affect any flash solution -- SD card, SSD, or USB flash.

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

#116

Post by Teknoman117 »

m-p-3 wrote: post #79
PragmaticPulp wrote: post #24

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.

The speed would be much better than an SD card, but nowhere near the peak M.2 performance we've come to love. The SoC they use only has a single lane of PCIe Gen 2. So 500 MB/s peak (MB, not MiB) with large transfers.

Throw in a PCIe switch or something so you can still attach a USB 3 controller and now you've doubled the price and power consumption.

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

#117

Post by Zaskoda »

danparsonson wrote: post #52

> And the SSD was bricked. I was able to unbrick it again with the long-powerup-without-data-cable trick... What's the long-powerup-without-data-cable trick, if that's not a stupid question? Sounds like a useful thing to know!

I was wondering the same as I have an SSD I used as an external usb drive that has stopped working. I've never heard of a drive getting bricked much less there being a way to resolve it. I was assuming a permanent hardware failure of some kind.

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

#118

Post by LegitShady »

justin66 wrote: post #9

> I plugged in a Kingston brand 120GB SSD on a USB3 adapter. > Then I accidentally yanked a cable. And the SSD was bricked. People who are going to use this as as their setup ought to buy a real, fast USB SSD, instead of relying on SSD drives plugged into adapters. They're engineered to deal with stuff like this and they're fast. (the Samsung T5 and T7 both benchmark even faster than what you saw, well above 300MB/s)

I think the limitation is the raspberry Pi which has no sata or m.2 interfaces. That's why they used a drive with an adapter.

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

#119

Post by m-p-3 »

Teknoman117 wrote: post #116
m-p-3 wrote: post #79

Earlier quoted context omitted.

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.

The speed would be much better than an SD card, but nowhere near the peak M.2 performance we've come to love. The SoC they use only has a single lane of PCIe Gen 2. So 500 MB/s peak (MB, not MiB) with large transfers. Throw in a PCIe switch or something so you can still attach a USB 3 controller and now you've doubled the price and power consumption.

If they add a m.2 slot now, at least it's already there for the next revision which they could improve the PCIe lane.

And hopefully that would ensure the new form factor to be somewhat stable for a while after that.

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

#120

Post by hohloma »

iddqd wrote: post #34
PragmaticPulp wrote: post #24

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 agree. I have run quite a few Raspberry Pi over the years and so many of them died because of SD card corruption. Eventually I got a NanoPC T4 with built in eMMC and it’s been tugging along for a good 2 years with zero issues.

I've had a raspberry with SD card for more than 3 years now, still working fine. YMMV obviously
Post reply on HN