- 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
[Edited for formatting]
Also Ethernet is still connected via USB, and horrible slow.
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.
The ramshackle micro USB port is a nogo for me.
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.
(No idea - my applications for the rpi don't depend on it being a speed demon on the network.)
Although, for most of my projects so far, it's been plenty fast.
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.
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).
The Apple iPad charger works wonders.
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.
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.
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 :)
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.
(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.
 eg, the CUI V7805 (102-1715-ND at digikey)
* Traco TSR 1-2450 (available at Adafruit)
* Cheap adjustable dx.com step-down converter (can't find the exact part #, but it's very popular)
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.
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.
Let's hope it handles tail recursion.
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 :)
(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...)
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.
I think we can interpret this as RPI 2 will be released soon with a new processor.
1 - http://www.raspberrypi.org/blog/#introducing-raspberry-pi-mo...
Constraints are good.
Fortunately there are many inexpensive alternatives to the raspberry pi (probably thanks to it) if you really do need more CPU power.
It doesn't look as though they have made the RPI B+ communicate over the power line, are there plans for future versions to do so ?
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?
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?
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.
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.
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 :-)
In this he states that a second version of the pi isn't likely to happen until 2017. http://www.raspi.today/raspberry-pi-2-expected-in-2017/
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.
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.
It would be interesting to hear how many actually use the rca video.
+ 4 USB ports
+ more GPIO (now 40 pins)
+ better mounting
+ better audio controller
+ reduced power consumption
~ combined audio and video onto the 3.5mm jack
- power connector position moved to the side (bad for small form factor projects)
Given the price, I am pleased with it, but I wouldn't recommend it as a media center for the non-tech savvy.
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.
1 - http://www.phoronix.com/scan.php?page=news_item&px=MTQ4NDE
1 - http://openelec.tv/
Doesn't matter what version OS I am running either!
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.
Wish USB/Ethernet didn't share a bus, but I never actually ran into that being an issue yet.
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 ARMv7 and has a reasonable price.
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.
I also use mine as an SSH gateway.
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.
- micro sd card support
- more USB ports
- better mounting
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.
Can anyone tell me what is the use case of this?
* 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.
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.
Unfortunately, that also means there's a lot of inconsistency, conflicting advice and outdated code that beginners take for granted. It's quite annoying.
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'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
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.
Here's a huge list of others:
There was also a small Pi emulator posted as part of the StarFox project on HN a while back.
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,
> to be a counterpart to the BBC Micro of thirty years ago.
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.
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.
That said, I use mine as a simple NAS for backups.
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.)
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 ..
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.
- 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!
So, there is one pretty good use for an rPi.
I don't think a $5 microcontroller would have run a tiny web server, tiny email server, or the plotter code that forms the core of the project.
The Pi is a fine budget Linux computer. It's not fast, it's not powerful, it's not expensive.
But it's fast enough and powerful enough for embedded applications you can put online without breaking a sweat.
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.
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.
It works fine to stream stuff from YouTube, too. Shows for kids, etc. The XBMC remote on my phone is pretty handy too.
Overall, I'm pretty happy with it.
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.
"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.