- Now comes with 4 USB ports so you can now connect more devices than ever to your Raspberry Pi.
- There is a 40pin extended GPIO so you can build even bigger and better projects than ever before. The first 26 pins are identical to the Model B to provide 100% backward compatibility for your projects.
- Micro SD slot instead of the full size SD slot for storing information and loading your operating systems.
- Advanced power management:
-You can now provide up to 1.2 AMP to the 4 USB ports
– enabling you to connect more power hungry USB devices without needing an external USB hub. (This feature requires a 2Amp micro USB Power Supply)
- The B+ board now uses less power (600mA) than the Model B Board (750mA) when running
- Combined 4-pole jack for connecting your stereo audio out and composite video out
Most mobile devices draw much more power than 500mA over micro USB as well, I was assuming this was in-spec now, it certainly seems to work fine. And many people have spare 1A+ chargers lying around as mobile devices tend to break before their chargers (ramshackly plug notwithstanding). Those chargers are usually really tiny, as well.
So I think micro USB is a fine choice. It also lets you draw from the fairly rich ecosystem of other USB power gadgets such as external batteries. I'd be really annoyed if they switched to a "normal" round plug.
It will work fine in 95% of the cases, but 5% will ruin their computer USB port, because the PI is not within the specs. The PI not only draws 750mA (old) or 600mA (new) when idle, but much more, if you attach SSD, and USB devices.
You don't have to power it from the USB port. You can supply juice to the 5V and GND pins on the GPIO header. That's probably a better power inlet interface than either a ramshackle micro USB connection or a janky barrel plug.
I'm not aware of any spec requirements for overcurrent protection on the host ports (devices have strict power behavior per spec), though they may be there.
I am aware, however, of countless USB host designs that simply put a 5v regulator rail on the power line and could probably be induced to overheat by a misbehaving device.
It's definitely in the USB 1.1 spec, (with some verbiage that excessive current draw on one port is not allowed to affect other ports) though they may have relaxed it later. I have several old Belkin hubs that will terminate (with prejudice) power to any port that draws over 550 mA, until you physically power-cycle the hub. This is annoying for obvious reasons, especially on 7-port hubs with beefy power supplies, so most hub manufacturers don't do that anymore.
What the pi should do is monitor the voltage level of port it is drawing from, if it draws it down, it should turn on a fault LED or disable onboard services (like ethernet and usb).
The whole point is that most people (especially the target market) have a spare USB charger hanging around. The Pi takes exactly the same connector as your mobile phone - it's one less bit of kit to buy.
But as far as I read, the PI can still not boot over Ethernet, which is a requirement for me to boot into backup cycle (Installation = Restore), and it still can not wakeup on LAN.
If you load U-Boot onto an SD card, the rPi can be configured to use that to boot over Ethernet. It's not a completely "pure" network boot, but that's impossible given the hardware. (There's simply nowhere for a bootloader to live besides the SD card.)
You need some sort of bootloader, even in a traditional PXE boot scenario... it's just that your BIOS hands off to the bootloader on your onboard PXE chip instead of to your OS's bootloader, etc. So, it's chain-booting no matter how you slice it.
You can setup your SD card to have U-Boot and not much else... just what's necessary for U-Boot to, well, boot. Then it takes over and does it's network boot of your full OS. So you can get a sort-of PXE boot setup.
-You can now provide up to 1.2 AMP to the 4 USB ports enabling you to connect more power hungry USB devices without needing an external USB hub. (This feature requires a 2Amp micro USB Power Supply)
Nice. In my experience, using a good power supply for the pi (instead of cheap ones selling for 5 bucks on ebay) is mandatory also in the current revision, and solves a lot of problems with video and USB devices (for example, cellular modems).
Current != power. I recommend altering this to say "uses less power (600mA at X volts) than the old (750mA at Y volts)," filling in X and Y with the voltage that the systems run at.
Or: "uses less power(X mW) than the old one (Y mW)," filling in X and Y wit hthe power that the systems run at.
Power = Current * Voltage so just giving the voltage doesn't help either. I believe the voltage is unchanged so stating a decrease in amperage would suffice.
Right now it's possible to back feed power with a powered hub instead of using the micro USB connection. I'd like to see the schematic to find out if that's still possible, but I can't find one yet.
You're bypassing a fuse. If you have a crappy powered hub that isn't well regulated you could fry your pi.
In reality, the chance of that happening is very small, and safety here is only in the context of the "safety" of a $35 board. Most hubs won't let you draw more than a couple of amps anyway.
Well, I'm not sure how well regulated my $3 powered usb hub is. I find myself having to do this weird ritual of plugging stuff in under the correct sequence otherwise I get some power from the hub and the pi won't boot fully (goes into a weird boot loop).
This is quite the impressive release. The additional USB ports are a welcome addition, as-is the additional GPIO. I have one project in particular that will benefit from the additional GPIO.
The microSD slot is also a big deal. microSD's are much more common now-days than SD's due to most people's phones having them. I own a slew of old mSD's from old phones and can re-purpose them into a Pi project now :)
The microSD card and changes to the ports (more flush USB) also reduce the footprint which means I should be able to cram a new version of my Pi motion activated camera into a smaller waterproof case. This makes me very happy. The lower power demands may also let me get away with using a smaller battery and solar panel.
While we're here, I'd like to call attention to the fact that the Pi foundation has hired someone to opensource the X display driver, addressing one of the common criticisms about openness:
For people saying they want a faster revision - do remember there are other computers in this form factor. I recently got an Odroid U3 and am very happy with it. Of course, it's $65, not $35. I tried setting up owncloud, nginx, a web server, etc. on a Pi and it couldn't handle it (everything ran, but terribly), the Odroid does well.
I still like the Pi, though. There are some people for whom saving $30 really does make a big difference, and if the goal is learning how computers work, having lots of GPIO pins, etc, the Pi is still awesome.
My biggest gripe with the Pi is a lack of proper USB power, so if you add all the stuff you need, especially for a wireless setup it's not so cheap and compact anymore. I'm happy that they've (hopefully) fixed the USB power problem, that makes it much nicer as a platform.
I've been providing power over the GPIO header directly, and have had great results. Combine a DC-DC supply with a few smoothing capacitors on a small daughter-board, add a barrel jack + 0.1" headers to interface and you get a lot more headroom and flexibility with how you power it.
(Same-ish end result as the other fuse bypass methods, but with no soldering on the pi, and the caps seem to help with the inrush current required for hot-plugging USB devices. )
It's a tradeoff vs device safety, but is super cheap, and the operational reliability is worth it for me. Every time I stage a pi for a project that isn't powered this way, I'm surprised how much frustration is involved.
Looking forward to this improvement with the B+ as much as anything else.
The Rpi is now a totally open source platform though, unlike the Odroid. Same for the Novena laptop.
Also, I've heard bad things about the Odroid's stability under load. Do you have any problems? I've also definitely had problems with the Rpi under load, but I expect the new switching power supply to solve that.
I've had horrible experiences with Pi over load. SD card corruption very often. Tried various power bricks and several Pi's, always same issue - corrupt SD card after a couple of months of 24/7 use.
Have an Odroid U2 running now for 6 months on an eMMC card without any issues. I know which one I prefer. :)
The last time I looked, it still requires a binary blob to even boot, and despite Broadcom releasing (partial) documentation for the GPU, and claims that it should be possible to replace that blob, I haven't seen any advances on that front.
The Pi would be infititely more useful to me if the ethernet interface was attached to a "real" bus and not hung on USB. Here's to hoping that will be the next upgrade!
The only interface that can do DMA is the USB one. All the others have relatively small FIFO buffers and require the CPU to do all the I/O work. So you could attach an ethernet interface to one of the SPI buses, or bit bang a few GPIOs but surely the CPU load is going to be painful?
Edit: Oh wait, there's a main SPI bus that can do DMA as well. See page 148 on the doc linked above. If you can find a suitable chipset & driver then have at it :)
The internal bus - AMBA/AXI/etc., so it's basically another peripheral block the CPU can access directly.
(That datasheet is also very incomplete - there's lots of other interesting stuff in the SoC like the MIPI CSI/DSI interface, and if you felt perverse enough and had the right skillset you might be able to get Ethernet-like data transfer out of one of those...)
I agree, and bet it would also reduce power consumption even further because of higher efficiency. Does anyone know if they use the USB bus because of the space constraints?
Bascially performance, one way or the other. Ethernet over USB is terribly CPU and power ineffective. I've also found the Ethernet to be a bit wonky (I suspect sleep mode issues) so I suspect reliability could be improved as a bonus.
Switching to another (faster) bus won't necessarily improve anything. You have CPU overhead to contend with, as well as relatively slow I/O on the SD card. So, just because the port is moved to a faster bus and could support GbE, doesn't mean you would get GbE performance.
Your home network is likely already faster than the Pi can handle, let alone your internet speed. A file transfer across your network (scp a video to the SD cart for example) will already burst, then slow down as-is. You can see, the SD cart write i/o is the current bottleneck.
Nope, he's stated publicly that any major overhaul isn't likely to see the light of day until 2017. Listen to an interview here: http://www.raspi.today/podcast-episode-6/
Slow and proprietary, which is not a great combination... there's a lot of interesting new ARM SoCs from China that are coming out, like the Allwinner A3x series (quad A7s, >1GHz). It would be pretty unlikely for one of those to show up in the next Pi though; if anything, it'll probably be another Broadcom.
Ebon Upton [0], one of the main folk from the Raspberry Pi foundation works for Broadcom and does SoC. So odds are slim considering that connection probably enabled them to get extreme price arrangements otherwise not doable.
His Broadcom relationship is probably much less relevant now that the foundation has some money in the bank and a product that has achieved wide spread success.
On the other hand: The VideoCore IV GPU used in the Raspberry Pi is the only recent embedded GPU for which (large parts of) the specification are publicly available.
Yeah, which is a shame because I think an Allwinner SoC or similar would also fix the other problems people are complaining about in the discussion, like the slow/unreliable USB and Ethernet and the lack of line-in. (Allwinner SoCs have proper USB and Ethernet controllers and audio DAC/ADCs onboard.)
Some of the Android "HDMI stick" devices I've seen running Allwinner SoCs aren't very fast either. Granted they're faster, but compared to SoCs in cell phones, they're dog slow. The Android builds also always seem to not work in one way or other.
It's nothing to do with the voltage, USB is always 5v. It's about the current these ports can draw, which is 1.2A for the 4 (i.e. 0.3A each if all 4 are under load)
When they say reduced power consumption, they're really talking about overhead. Let's say to supply 5W at 5V, they needed to take in 7W at 120V. This means that voltage step down process results in some power being wasted as heat. By using a switching regulator they waste less power and thus there's less heat output, but the power delivered to the device remains the same. So, in this example, they might only need to take in 6W at 120V to output 5W at 5V. (Note, the numbers are complete BS because I haven't done hardware in a while, but that should give you an idea.)
They'd probably piss off a lot of their developer community if they didn't keep the B in production. There's a huge number of third-party cases and projects that are built around the original connector arrangement.
I wonder if this would run a Quake (3) server? Myself and a few of my friends still like to play the old classic... $35 seems ideal for something I could just leave on all the time for a quick game.
Curious they're explicitly naming this the "final evolution".
First up, I'd be surprised if they continued with a "Raspberry Pi 2" soon. The RPi is still very adequate for its original goals in education and will likely remain so; it hasn't ever been quite enough for people wanting a cheap server or media center except for those with very modest needs. Given their announced goals, I doubt that the creators are going to cater to the second group with a hypothetical RPi 2.
One thing that can be improved upon the original Pi is a more open SoC, but currently no SoC vendor will be able to provide a significantly more open one. Even if you pick an open source friendly SoC vendor like TI, there are currently no GPU designers for these SoCs that have open source drivers. It is unlikely improvemants can be made in that area that anytime soon.
The second thing they could improve for their education goals in the inclusion of a dual core SoC to be able to teach about concurrency. That would probably be quite a bit more expensive than the current Pi, for a feature that would not present that much more value for education.
So I'm wondering what they mean with this 'final' comment. Will they simply stay with supporting the current Raspberry Pi models? Or will they start developing a second Raspberry Pi? Or will they develop other computing devices for education?
I think that the fuller quote "the final evolution of the original Raspberry Pi" is important. The word "original" in there doesn't lead me to believe they are at the end of the road overall, just end of the road for this one design.
To clarify, I expect to see a more complete redesign in the not-too-distant future. If nothing else, you want to use components that are recent so you can keep producing more of them without increased costs for legacy components.
Yeah, that's exactly the question I got from reading it. If they are implying the end of the road for this design, does that imply they have a next design? If so, why would they want to redesign?
> you want to use components that are recent so you can keep producing more of them without increased costs for legacy components.
Good point, didn't think of that. Is this a problem even on their scale?
> Even if you pick an open source friendly SoC vendor like TI, there are currently no GPU designers for these SoCs that have open source drivers. It is unlikely improvemants can be made in that area that anytime soon.
Intel looks pretty good, current gen tablet SOC and followons have i915 lineage GPUs. Bay/Cherry Trail.
AMD too, current tablet SOCs and upcoming ARM models.
There are also reverse engineering efforts at various stages for Mali, Adreno, Tegra. Tegra even has some fledgling vendor support.
Please skip ARMv7 and jump straight to ARMv8 for Raspberry Pi 2. No need to force OS/app developers to support 3 different ISA's for years to come.
Ideally it would also be dual core and have a clock speed of at least 1.2 Ghz, since that's what most operating systems need these days to run reasonably well, but I guess that depends on your target price. 1 GB of (LP)DDR3(L) RAM should also be the minimum for the next one.
Looks like a nice upgrade, more USB ports. The additional I/O might be in response to the Beaglebone Black taking share but video has consistently been better with the Pi. I've got a number of both and they each have their uses.
I've been whacking on a USB host driver for the Cortex M4 in my not very copius spare time and it amazes me how much the Pi manages to get done being handicapped like that. The difference between "old" computers where the system designer was making every effort to make I/O flow through the system as effectively as possible, and the Pi has a system where polling for I/O is part of the design spec. And not done well like the channel controllers of old, no done in a very inefficient way. Amazing what ubiquity will force upon folks :-)
The Galileo has some interesting caveats, like a much slower CPU than even the Raspberry Pi and the GPIO, PWM, etc going through an IO expander chip on the really slow I2C bus. (Apparently there's a Rev2 with some native GPIO pins now, presumably not compatible with the Rev1 unless you use Intel's official abstraction layers.)
RPi B+ and I2S DACs will not work directly anymore: changed GPIOs and pinmux different now.
I did the Rasbian Kernel Patch and with four jumper wires - it works:
http://www.tjaekel.com/T-DAC/raspi_Bplus.html
Even with latest Rasbian image (June 2014) - without Kernel Patch I2S does not work (and RPi B+ will hang).
Change three bytes in a kernel module and all fine.
A dedicated digital audio jack would be a useful addition, it could even take the place of the useless composite video RCA, so the port arrangement of the Model B would be kept.
With a digital audio jack a pi could be a decent hifi music streamer, better and cheaper than the AirPort Express. Now you need a $30-50 splitter (or the hifiberry add on) to get the audio off the hdmi, which makes the total cost more than double.
I'm interested in Raspberry Pi. I bought one before. It's just a small PC, use one hand you can hold it. But when you want to Raspberry to do some complex works, it let you down. I want to know where does Raspberry Pi can work well?
"Fantastic" may be overstating it. I've been running Raspbmc for about 15 months now, and although the video rendering is very good, the XMBC UI is a bit laggy and unresponsive (although there seems to have been an improvement recently). I've also used it as an SFTP client and to run a few light cron jobs (rock solid there).
Given the price, I am pleased with it, but I wouldn't recommend it as a media center for the non-tech savvy.
Agreed. I wish that RPi has some kind of cheap prebuild of a mediaplayer. If would be GREAT for non-techies if it just had a real power on/off switch, IR sensor & a basic remote that just works (probably asking for too much there).
I reckon you could fix the lag of the GUI if someone implemented Raspbmc/OpenELEC with Wayland instead of X-server. Not much has to change for this to be possible. Only the power switch & IR sensor would have to be apart of it. Remote could potentially be third party and WBMC would a man hours issue.
If you're willing to spend quite a bit of time configuring XBMC it runs smoothly. I use openelec with the theme 'bello', any animation heavy themes will kill it straight away.
Does the new Compute Module share the same increased USB ports (with more power available)? Have had nagging issues prototyping Pi's with cell modems due to power consumption and was looking at the Compute for an embedded application
Have they fixed the stability issues when it is under high load with a lot of networking traffic? I have a RaspberryPi B and each time I start a large file transfer the entire board locks up.
Doesn't matter what version OS I am running either!
Have you tried another power supply? I used a "high quality" one from RS (I think) and had odd problems with disk corruption and crashes when pushing the limits. I switched to a old iPad charger and the crashing problems went away.
There is a nasty bug with overclocking and filesystem corruption that is especially easy to hit under low-power conditions. Not sure if it's been fully fixed. eg:
That's still $50 though, at that price I'm just not sure its worth it - especially since it only has a 10/100 NIC and USB 2.0 while those specs might be an acceptable for educational purposes, at $50+ hobbyists may not find it the most cost effective solution.
I'm my experience I've found it hard to push the CPU/memory/"disk" enough to saturate the NIC, so don't worry about it.
The limiter to streaming multiple high def video streams (one at a time is OK) or doing SDR/DSP work doesn't seem to be the NIC.
I'm having trouble thinking of a real app that wouldn't be memory/SD card/CPU limited on my pi that would simultaneously be limited by the NIC. By real app, I don't mean sending ping floods or running weird benchmarks, or something that isn't an app, like transferring a file.
My main pain point with the pi hardware at this time is there's some JVM stuff I'd like to fool around with where I'm totally patient with something that takes an imperceptible 5 ms on the desktop taking a still imperceptible 50 ms on the pi, but can't handle only having a half gig of ram.
> Not sure what projects needed more pins but not complaining.
The added pins include a couple of important ones from the SoC that were previously not available, or were only available on a secondary connector. You can now get JTAG over the expansion port, for instance.
It has extremely good 3D acceleration, provided you're not unreasonably upset by using binary drivers. You can now get fairly good results with the open source ones too (30fps Quake3).
I am running a web server on mine using PipaOS and Lighttpd, but I rewrote my database system to SQLite instead of MySQL. Granted, this meant I had to reimplement some stored procedures that I had written in PHP instead (for parent/child page traversal and navigation building) but it returns pages much faster. I know that reading from a file all the time is likely to harm the attached USB drive's read count, but I'm not getting many hits!
I intend to rewrite the system using C++ instead (using an old Mongoose C++ web server edition) and load the SQLite database into SQLite :memory: (without a disk backup) instead, which means that it'll return pages much faster; it'll only touch the "disk" database on program startup.
I see from the others that they have put PHP and MySQL and a host of other things on theirs but for simple sites, that is probably somewhat overkill.
If your site will serve only few static pages and you going to have less as 500 unique daily visitors RPi should be fine.
But if you run some heavy framework like Wordpress and will have more as one visitor at once RPi cant handle.
I used it to serve files via http, and it was very poor at it. I would not recommend using it as an http file server. Light application use, or for things like hosting git repositories works well though.
I'm running my girlfriends portfolio page on a Pi, nginx + mysql + php / Wordpress with a caching plugin.
Works quite well if the pages are cached (which most are), admin stuff is quite slow.
Ive used it to run an openvpn client on which connected/bridged two WiFis over internet and forwarded igmp packets and multicast (not broadcast). Worked fine, so that my DLNA (minidlna) server could be reached and play movies on a Samsung smart tv as if the minidlna server was on the same wifi as the tv, but it was in fact in another city.
Streaming HD movies in this way - flawlessly. 30mbit up/down conneciton on the minidlna+openvpn server, and 24mbit down 1mbit up ASDL on the Samsung tv receiving end.
In theory you could use the I2S, but I went the easy route and hooked up a USB DAC (Behringer UCA-202 - good cheap DAC). Thanks to Pi's USB issues, you need to switch to USB low speed (dwc_otg.speed=1), but it's worked well.
I'd be surprised if they did. Netflix doesn't have a Linux client, and the only way to get it running on desktop Linux is using Wine with custom patches. Seeing as Wine depends on the CPU being x86, this method won't work.
I still can't see why would anyone buy one except as one of those toys that you buy and then gets tossed in the closet. 10 years ago I could see the appeal, but now? The robotics, home automation, and weekend project use cases seem like would be better served by a $5 microcontroller.
Some projects, such as the weather station, justify the use of a full-fledged OS, but with the cost of buying an existing, proven, weather station being so low ... why bother?
And for a cheap webserver? A $1/month VPS is more powerful than this thing.
I don't have the Raspberry Pi, mainly because, since I develop embedded software for a living, I have an endless supply of development boards I can hack on at work and am free to take home (during those evenings when I am not so fucking tired of flipping bits that I don't even want to SEE C code!), but:
* A platform with less legacy crap than x86 is wonderful for learning about OS development. I don't know how the Pi fares for this, with Broadcom's chip and all, but if I had the free time to hack an OS in my spare time, not dealing with all the thirty year-old cruft nor shedding a gazillion EUR on a PowerPC system would be ideal.
* There's a legitimate audience of visual artists, musicians or just tinkerers who, as outrageous as might sound to us, long-bearded bit twiddlers, find learning anything other than Python either hopelessly complicated or just not refreshing enough. Aye, their needs would be better served by a 5-dollar MCU, but when an extra twenty dollars buying you the ability to write the code on the same computer that runs it, it's hard to resist. I find myself breaking the sacred oath of not using even one bit more than I need, too, because it's Saturday and my cat wants some attention too and I derive far more pleasure from seeing the jukebox playing music than from knowing the half-done file loader module that will eventually be part of a jukebox eighteen Saturdays from now on is so optimized that even an optimizing compiler would slash its veins in envy.
* The "cheap webserver" part is generally useful when you actually want one to interface something with the outside world over the Interwebs. I find the idea of using HTTP for much of this rather... repugnant, but there are people to whom it isn't, and a VPS isn't of much use if the requirement is to toggle this relay in response to that HTTP request.
> A platform with less legacy crap than x86 is wonderful for learning about OS development. I don't know how the Pi fares for this, with Broadcom's chip and all, but if I had the free time to hack an OS in my spare time, not dealing with all the thirty year-old cruft nor shedding a gazillion EUR on a PowerPC system would be ideal.
Actually I'd say the x86/PC is probably one of the best-documented and most stable platforms out there to learn on at the moment, precisely because it has been around for so long. Largely due to Broadcom policy the Pi is notoriously closed and proprietary at the hardware level, and unless there is somehow a massive amount of reverse-engineering like what happened with early home computers (which were better documented so the process started more easily), or a datasheet leak, the situation is unlikely to change. Any of the other open ARM devboards in the same price range would also be good candidates for OS development, but not the Pi.
> Actually I'd say the x86/PC is probably one of the best-documented and most stable platforms out there to learn on at the moment, precisely because it has been around for so long.
Unfortunately, that also means there's a lot of inconsistency, conflicting advice and outdated code that beginners take for granted. It's quite annoying.
This is something I'm very interested in, and nearly bought a Pi today; I want a board that I can learn ARM assembly and C on to build a toy OS. I built half of a tiny kernel on X86 (woo real-mode!) nearly a decade ago, so I know a tiny bit about it all, but I'd assumed the Pi was a great target: well priced, tonnes of them out there so hopefully well documented, etc.
What would you suggest instead? I'm considering just firing up QEMU and it's ARM baseboard target then dealing with porting to real hardware later, but there's something exciting about seeing a real circuit firing up your kernel that makes me smile.
I had to deal with them before, so if you can, stay away from cheap Chinese boards or hackable routers. When you're just learning, it's not worth it, the dollars you save will be more than made up in working around subtle bugs and trying to figure out what the poorly-worded, incomplete documentation is trying to convey.
I also warmly suggest not to bother with anything that says Atheros or Broadcom on the case. Their documentation is hopelessly tucked away behind a gazillion NDAs you have to sign, and working based on leaked material isn't fun. As for their SDKs, if you could get me started (but you can't because I signed that gazillion bazillion NDAs and I don't wanna go to jail), I could talk for days.
Sadly, I haven't worked with it either, but the Beaglebone Black looks like a good option and there's an actual community around it.
I'll definitely pick a up a Black then, as I do love TI chipsets and have had good experiences with their documentation. Such a shame they left the mobile market.
I'm setting up QEMU to have a crack at that while I wait for it to arrive. Thanks for the advice! I wish I could get you started, damn NDAs, I reckon you'll have a few stories to tell
Do you, by any chance, know of a resource that documents the process of actually getting your toy OS (which I assume was cross-compiled) to run on another board such as the BBB or the RPi?
Sorry for the late reply, I just saw your message. I don't have a toy OS (not enough spare time), but I did work on one as part of my job.
I don't know of any documents, but the way you'd generally want to do it is wrap hardware- and board-specific parts of your code in a hardware-agnostic interface which is what you use to write higher-level code in the system. That way, getting the OS to run on another CPU or board is all about writing the relevant callbacks. You can get the general idea from Linux's mach-* and plat-* files. This isn't really OS-specific; I'm pointing at Linux because it will probably be easiest to get documentation about it, though my personal preference is elsewhere.
If you're looking for something in the Pi price range, a Beaglebone Black seems about right and the TI SoC it uses has tons of publicly available, detailed documentation. On the other hand, if you want more features/periperals/cores, and don't mind not-so-thorough documentation, one of the boards based on Chinese SoCs could be more fun...
Running Linux in embedded projects is still super useful. You can use pretty advanced software like speech recognition (PocketSphinx, etc.), image processing (OpenCV), and more to make cool stuff that would be miserable/nearly impossible to implement bare metal on a fast CPU. Even networking heavy or UI heavy projects would be much easier on a machine that runs a real operating system.
The use case of the Pi is a computer that can be given to small children to be theirs, to be a counterpart to the BBC Micro of thirty years ago.
It's also an attempt to get right what the OLPC people got wrong (too expensive, too different from all other systems).
It has to have a decent display, which really rules out microcontrollers (an early prototype was indeed an AVR that ran Lua and output composite video). It has to be cheap, and indeed it is cheaper than all the other full-fledged Linux boards with larger processors and more RAM.
> The use case of the Pi is a computer that can be given to small
> children to be theirs,
I completely agree with this part...
> to be a counterpart to the BBC Micro of thirty years ago.
But I don't really agree with this part. The BBC Micro was much more expensive in real terms when it launched, and never got down to an equivalent price during its lifespan. Only when it became a hand-me-down, replaced by something more powerful, did it have become the property of a kid. (I saw this happen with several friends.)
The Pi is something new --- its the first computer truly designed to be owned by almost all kids, from new. It's so cheap, and uses equipment most people have already (especially the TV), that only the very poorest can't afford one, and it's cheap enough that destroying one whilst tinkering isn't a disaster.
Speaking of "hand-me-down", the pi kind of kills the used/junker PC marketplace for little experimental projects, when you can work on your project instead of debugging old/worn out hardware for only $40 or so. Also it uses about 1/10th the power of a repurposed desktop, so why not.
For an experiment, I could pick up a free, dusty, worn out desktop that draws 100 watts and stick a new small/tiny hard drive in it for about $50 and have a giant paperweight that needs hardware troubleshooting, or spend the same cash on something tiny that draws about as much power as a clock radio and is new so presumably more reliable.
Its hard to justify picking up junker "free" PCs in the era of the pi.
Well yes, we've had 30 years of cost reduction, but "play the same social role as the BBC Micro in computer education in the UK" was the goal of the Foundation.
I built my own home security system with a Pi as the brains to control camera streaming and do face recognition using OpenCV. Is there a $5 microcontroller that can do all that? Admittedly, it's a big load on the Pi and I'm looking for more powerful single board computers, but that again eliminates $5 MCUs.
I have another Pi working as a drop-in replacement wifi router that routes data via a USB data dongle in case my main internet connection fails. This too may be too much to ask from a $5 MCU.
My understanding is that the Raspberry Pis are intended to be used in education. The front page says: "We want to see it being used by kids all over the world to learn how computers work, how to manipulate the electronic world around them, and how to program."
That said, I use mine as a simple NAS for backups.
The problem is that it's too slow to be used as an actual development computer, so you have to write your code on another computer and then copy it over to the pi.
"Too slow"? Thats a very consumer-centric point of view. Compiling onboard is quite sufficient for most small projects, and really .. its a matter of patience, but for sure its quite usable. For those more used to the fat-IDE approach, where everything is done for you at a few clicks, its certainly not interesting .. but if you want to get really familiar with software development, doing things onboard the rPi can be a very effective way to develop. The so-called limitations of the device can also work in your favour: write smaller, tighter, leaner modules, and you don't have to wait so long in between compiles.
Not to mention that there are plenty of ways to use the rPi that don't require compiling. I myself use an onboard Lua environment, which just plain rocks .. ssh in, open up vim, edit Lua .. run in another terminal. Quite a comfortable environment, and I hardly even care that its on a 'small/slow CPU' (after all, I lost interest in the speed race decades ago. Those of us who grew up building the Linux kernel on MHz-class machines don't feel your pain.)
Hooking the Pi up to a monitor and using it to actually edit on is extremely slow, once you've loaded an editor a browser a couple of terminals and maybe an MP3 player it's a crawl compared to devices anyone is used to in 2014.
I don't, ever, even think about lag in between :w and :ma .. these things just plain work. For everything else, there's 'cscope -R -s /usr/include #&etc'.
For pure C/C++ projects, I use cscope+vim+make on the rPi. For Lua projects, just vim .. and a few judicious 'watch ./ make' style sub-cmds in another shell.
GUI editors are not your friend, I accept that. But there is more beneath the hood than such a dilemna as not enough RAM to load bitmaps ..
Check out sshfs or similar user-mode filesystems to make the Pi look like a drive. Cyberduck is another tool that has a decent file explorer UI around SSH/SFTP and is cross platform.
If you're writing C/C++ you can set up a cross compilation tool chain to write and compile code on any Linux machine. It's a pain but there are lots of blogs posts and guides on it.
Sure, but I mean you already need another computer in order to program the pi at which point you already have a computer that can run programs without the pi.
- Stick it on the back of your 3D printer and run OctoPrint on it to give a nice web interface for your 3D printer (and a web cam for time lapse capture).
- Connect it to my digital piano to record playing sessions and upload the MIDI files automatically to dropbox without me having to push any buttons except the "on" button on the piano.
There are a thousand other use cases where you want something more than a microcontroller, you just have to use your imagination!
I'm currently putting together a data recorder for an academic experiment. It requires: GPS, Camera, Environmental data, inclinometer, and a few other odd bits. I could build up a custom system, but that is a big NRE expense for something that less than ten of will probably ever be produced. I could also use a "better" but less common developer board, but that path has its own problems. The experimenter could have stuck with a COTS solution, but the reason that I'm working on it now is the inconvenience and poor quality of the current implementation (lots of COTS stuff bodged together). Currently, they are using a lot of COTS stuff, and then putting the data together in batches. Even though it is a somewhat automated process, it remains slow, labor-intensive, tedious, fragile, etc. When I am done, I get to hand off an integrated, fully automated system that is flexible, built with easily replaceable parts, and best of all; due to the abundance of freely shared examples and documents, a grad student, or even an ambitious undergrad can take over and manage or even customize the system. Also, the rPi based system is much cheaper than the current system.
I can run python on it. Yes, I'm aware of http://www.pymcu.com/index.html , but they're cheap enough for projects and familiar enough for people vaguely familiar with Linux that it ends up being a good combination for lots of fun projects. It's probably overkill for >90% of things people use it for, but usability is the big advantage.
I bolted some 10A 5V relays onto the GPIO pins via a 3V3-5V converter board to switch the heating circuits on and off.
There are some standard 1-wire temp sensors - docs are easy to find online. The 1-wire protocol allows for really long cabling and doesn't need external power, so it's ideal for this kind of project
There's some incredibly simple Python code controlling the relays and reading the sensors, and GNUPLOT runs off a cron job to plot the temperatures to image files that get served in a web page via lighttpd.
Because I don't have a static IP at home the Pi pings my Linode server with its IP address every minute, and the Pi server web pages are wrapped in an iframe that pulls them off the current home IP.
The whole thing is a total hack, but it works well enough. Bottom line is I can see the indoor/pipe/tank/outdoor temps from anywhere, and the heating turns on if it thinks the pipes are going to freeze, and turns off if the water in the tank and/or room temps are warm enough. I can also turn the heating on and off remotely.
It wasn't quite trivial to do, but it wasn't a hair-tearing challenge either. So far as I can tell, it was easier than it would have been with alternative boards.
Basically anyone who knows beginner-level Linux server set-up and some very basic electronics should be able to build something like this around the Pi. It's perfect for this kind of embedded micro-server/controller project.
Are you controlling the heating in each room separately?
From your description saying "relay", I'm presuming this is electric heating?
Do you find that this keeps all the rooms around the right temperature? The usual problem with a normal heating system is that you have parts of the house that regularly are hotter or colder than the rest, so I was wondering if you had managed to solve this.
I'm looking to control radiator valves electronically, which of course relies on someone actually making electronically controlled radiator valves that don't cost a stupid amount of money.
Not a heating project but maybe this will inspire you. My RPi monitors of temperature and humidity in- and outdoor of my apartment: http://pi.tafkas.net/temperature
I've been using a Pi running XBMC for about a year. It's connected to a big hard drive. I can copy stuff there from my laptop (movies, music, etc.) It works pretty well; I don't remember having to "service" it in any way since I plugged it in.
It works fine to stream stuff from YouTube, too. Shows for kids, etc. The XBMC remote on my phone is pretty handy too.
It's a valid question, not sure why you're being down voted. It nicely fills the use case of "I could totally run this project from an 80 cent microcontroller, except that it needs network connectivity, and the only practical way to do that in my environment is with 802.11 or 802.3."
The Raspberry Pi designers made a bunch of, IMHO, totally bone-headed design decisions early on (e.g., RTC "costs too much", but let's throw on a bunch of expensive ZIF connectors for overpriced peripherals that nobody will use) and the B+ is a move in the right direction to fix that.
My use case is "wifi terminal server." Which is to say that I built a battery-powered RPi system to connect Sky Safari on my iPad to a go-to telescope. The official Sky Safari wifi peripheral is $180 and can't even act as an access point! With the RPi, I have a better uart bridge (in that it runs hostapd) for one third the cost of the official solution. Plus, there is the possibility of adding auto-guiding using the gpio pins and some hacking.
My colleague uses it to run a python script to periodically download and store virtual currency prices. As I understand it, it is useful if you want to download stuff from the internet in certain time intervals.
There are roughly a billion ways to "download stuff from the internet in certain time intervals", but if for some reason the machine needs to be physically present, and dedicated to that task, then a Raspberry Pi is probably the cheapest way to do it.
One funny social dynamic to watch with the pi is you give people a little computer with specs that would be pretty good five or so years ago and you get some responses like:
"Humanity didn't use computers five years ago at all, for any purpose, being capable of doing anything that was done five years ago is inherently totally useless today and any thought of it should be abolished because I say so la la la I'm not listening to your real world examples la la la and that's somehow your problem not mine la la la". If you ram it past their self censorship to prove there exists a real world application for a five year old computer they get really angry. Its kind of funny to watch.
Maybe its astroturfing from people selling more powerful computers.
- Same Broadcom BCM2835 Chipset
- Same 512MB RAM
- Same full size HDMI port
- Same 10/100 Ethernet port
- Same CSI camera port and DSI display ports
- Same micro USB power supply connection
What has changed:
- Now comes with 4 USB ports so you can now connect more devices than ever to your Raspberry Pi.
- There is a 40pin extended GPIO so you can build even bigger and better projects than ever before. The first 26 pins are identical to the Model B to provide 100% backward compatibility for your projects.
- Micro SD slot instead of the full size SD slot for storing information and loading your operating systems.
- Advanced power management:
-You can now provide up to 1.2 AMP to the 4 USB ports
– enabling you to connect more power hungry USB devices without needing an external USB hub. (This feature requires a 2Amp micro USB Power Supply)
- The B+ board now uses less power (600mA) than the Model B Board (750mA) when running
- Combined 4-pole jack for connecting your stereo audio out and composite video out
(Source: http://raspberrypiaustralia.com.au/products/raspberry-pi-mod...)
[Edited for formatting]