frauenfelder at March 14th, 2014 12:08 — #1
ambiguity at March 14th, 2014 12:49 — #2
But if you want to be able to remotely access the thermostat via the web
to change its settings and download temperature log files, you should
consider using the Raspberry Pi.
Or you could consider a http://beagleboard.org/Products/BeagleBone+Black . I understand what today is and all, but the Beaglebone gets surprisingly little press for how chocked full of awesome it is. It's kind of like a Pi and an Arduino all wrapped up into one. And it is a very capable platform.
AND: The corners of the board are explicitly rounded so that it'll fit in a mint tin. I mean, how cool is that? Attention to detail!
hallam at March 14th, 2014 13:35 — #3
Are you sure the Raspberry Pi in the picture is running a Minecraft server?
Looks to me like its actually running...
flugfrei_jones at March 14th, 2014 14:22 — #4
vanilla minecraft? how does it handle it? i'd spring for one right now if i could keep a vanilla server up just for the hell of it.
masterprompt at March 14th, 2014 14:50 — #5
700 Mhz with 512 Mb of ram for a minecraft server? Must be a very boring server...
tacochucks at March 14th, 2014 14:55 — #6
Apparently it runs an MC server like this one:
Acceptably for about 5 players
Never done it, just read about it.
atarifan2600 at March 14th, 2014 15:01 — #7
Looks like it's running. Hard to tell what, but it's got power and a wireless adapter in it. Mine looks a lot like that, but i've got ethernet instead of a USB WiFi dongle.
atarifan2600 at March 14th, 2014 15:05 — #8
I bought a Pi and first thing I did was put Minecraft on it- but I started getting a lot of crashes as soon as I overclocked it to 'maximum'. Backed it off and it seems to be a lot more stable. Not sure if I have a problem with the Pi, or something else.
I haven't had a great experience with it as a minecraft server- draw distance is terrible, and it's almost unplayable as a result. Some of the suggestions/tips/mods that are supposed to help this (max blocks calculated and so on) appear to not work in the most recent version of Minecraft, so I'm not sure where to start troubleshooting from there.
What I have had a little more luck with is a MAME cabinet. It handles the few 80's games I've thrown at it relatively well. Won't play Atari Tetris without garbly sound, but the graphics look fine. Super low power innards for my cab, so that's a big plus.
technogeekagain at March 14th, 2014 15:28 — #9
Overclocking is always a gamble; that's what's "over" about it. You're pushing beyond promised/supported speed. Success or failure will depend on random sample variation and is entirely At Your Own Risk. Be happy if you can get away with it, don't complain if you can't -- if you need more speed, buy a product that promises the higher speed, or plan on buying a bunch until you get lucky (probably more expensive).
I don't know enough about the Beaglebone, but I did want to point out that it seems to be moderately common to program an arduino for hardware control and interface it to a Pi or similar which runs the main intelligence/communications.
kentkb at March 14th, 2014 18:34 — #10
Great story for 3.14 day. Thanks Mark.
atarifan2600 at March 17th, 2014 12:52 — #11
Support for the Pi seems to indicate that the overclocking is fully supported out of the box, and the only reported issues I've heard with OC are related to file system corruption, on which I was ready to take a gamble.
I've heard that some stability issues are more related to the power supply itself, which I haven't investigated- I've put it on a fairly beefy USB adapter. I'll probably try it again with a different supply the next time I fire it up as minecraft- but my kids are having too much fun with vintage arcade games to suggest switching it back right now.
fuzzyfungus at March 17th, 2014 13:37 — #12
I do like the Black (for a very modest premium, you get some nice additional features, plus things like 'ethernet that isn't a slightly dodgy USB hack'; but its resemblance to the Arduino (aside from the 'capes') shouldn't be overstated.
Like the Pi, the Black is basically a full-fledged embedded computer at heart, not a microcontroller, so while it does have somewhat better I/O, it still doesn't bit-bang or do other time-critical microcontroller stuff without some very careful attention.
The PRU is one hell of a trick up the Black's sleeve when it comes to doing timing-critical stuff (no OS overhead, just like a microcontroller; but runs at 200MHz, so things that your microcontroller couldn't dream of bitbanging fast enough are within reach, plus tight integration with your spacious application processor and its tasty memory space, networking, etc.) Hand writing less-than-totally-copiously documented assembly code to get there, though, isn't exactly baby's first Arduino sketch.
I do find it rather surprising how much less buzz the Black gets (especially how modest the price premium becomes once you factor in an SD card for the Pi, and the more-or-less-incontestable superiority of the Black's specs); but using it for any sort of I/O that isn't tolerant of sloppy general purpose OSes is a comparatively advanced topic, though it is undeniably brutally efficient at such specialty tasks if you are up to it.
ambiguity at March 17th, 2014 14:14 — #13
Hmm. Wasn't aware of the PRU (but the stuff I've done with my BB is pretty straight-forward, like a DLNA music streamer for the home network).
The standard way to access Aurduino-like IO pins (and the way that I have done it), is through the file system, and I do admit there's a bit of latency there which could be bad for some applications. The PRU sounds sweet!
fuzzyfungus at March 17th, 2014 14:58 — #14
My understanding is that TI added the PRU (and then called it about 15 zillion different cryptic acronyms depending on which documentation you consult, just because) specifically to please specialist embedded customers who needed to deal with assorted oddball medium-ish speed interface and networking protocols in various embedded applications that weren't standardized or common enough for fixed-function implementations(the way ethernet or HDMI are); but also weren't necessarily slow enough to be bit-banged by some 32MHz-or-less microcontroller, or timing-insensitive enough to be bit-banged by an application processor with a full OS doing unpredictable things; but for which the customer really didn't want to add an entire FPGA to the cost of the design.
The result is not particularly user-friendly (the target audience isn't exactly newbs, and there appears to be next to zero 'critical mass' of the sort that has made dabbling in hobby microcontrollers nearly 100% painless); but it does offer some very interesting capabilities.
Even aside from the PRU, I'm not quite sure why the BB gets so much less attention(it is slightly more expensive; but the rPi is really dangling into 'downright painful if you load it wrong' territory, and lacks some of the onboard capabilities of the BB, so the extra power is much appreciated and the savings not huge; but the difference is pretty remarkable.
rPi? Has its own Debian-derivative specifically to cater to the (rather weird) ARMv6-but-with-hard-floats CPU.
BB? Well, there's some documentation about how to cross-compile a Debian ARM image, and pull in the various out-of-tree stuff required to actually work. It's a pity, really, because the BB is the (nontrivially) superior general-purpose-low-power-linux-widget-thing; but for some reason has a much less enthusiastic following.
ambiguity at March 17th, 2014 15:10 — #15
I put Debian on my BB (Angstrom didn't have the packages I needed), and while it wasn't trivial, it was easy.
Yea, the BB's lack of press is strange. Maybe the Pi gets the press not necessarily because of the platform, but just that they have the PR skill-set that the BB folks don't....
frauenfelder at March 19th, 2014 12:08 — #16
This topic was automatically closed after 5 days. New replies are no longer allowed.