This is good.
The hub-and-ethernet chip is a real power-sucker. Getting rid of it should substantially reduce power demands. Looks like it sits somewhere between the 3B and the Zero.
Like the Raspberry Pi 3 Model B+ but feel that the RAM is just a bit too big, the price too high or the ports too numerous? Fear not, for the spiritual successor to the original Model A+ is here. Launched today, the Pi 3 Model A+ rocks the same processor as its bigger brother, the 3B+, in the form of a 64bit Cortex-A53 …
Agreed. Anyone can make an SBC with any number of cores and loads of RAM. It takes a special kind of designer to come up with something economical of power, making an SBC suitable for an IOT type use case, filling the gap between embedded microcontroller boards and office capable computers.
I'm already somewhat annoyed by the use of 5v on a micro USB port, given the limitations of the port itself for carrying current, which thanks to Ohm's law, has to be greater than if a higher voltage had been used, and makes the system more vulnerable to reduced power thanks to the high resistance leads and connectors that are to be found too often on the typical cheap Chinese power supplies people will be using.
I really wish the designers had gone with a coaxial barrel connector for power all along, which would have allowed the user to specify and solder their own cables.
For this reason, I like the Latte Panda's use of a barrel connector and 12v.
Us low-power/embedded people are annoyed at the 5V too - but in the other direction. We'd really like to be able to operate a Pi of of 3.3V, which it nearly can already - the processor is a 3.3V component, all the GPIO pins are 3.3V, including the UART. Unfortunately we can't, because the 1.8V for the memory is derived from the 5V rail via a buck converter just like the 3.3V.
If you could power a pi on 3.3V alone it would simplify running it off battery considerably and allow for the use of more efficient power supply circuitry. (li-ion -> 3.3V, rather than li-ion -> 5V -> 3.3V, which adds an extra conversion step where power is unavoidably wasted).
Incidentally, you don't have to power the Pi via micro-USB: The GPIO header includes pins for 5V supply input.
Us low-power/embedded people are annoyed at the 5V too - but in the other direction.
Can't say that I've ever encountered that attitude. Indeed it would make interfacing difficult for the average user case - how can you plug in USB peripherals without a 5V supply for them? I admit havign 5V power but I/Os that are not even 5V tolerant isn't the most comfortable design decision though.
If you could power a pi on 3.3V alone it would simplify running it off battery considerably and allow for the use of more efficient power supply circuitry.
Indeed. Saying it's aimed at "space-constrained, battery-powered applications" is rather laughable considering the Pi range is so at odds with being battery powered, requires external hardware, and that loses any space savings the board may offer.
There are probably quite a few people who wanted a 3B+ with reduced size, cost and power consumption, but won't find the reduction in memory size acceptable. I would guess that decision was made so they did not cannibalise their 3B+ sales.
I, to provide the other side, am happy that the power decision was 5V over USB. This allows me to power it from batteries designed for phone use, which you can buy for quite cheaply and which are easy for nontechnical people to use. I can therefore carry all the pieces needed to run the pi in a small container, rather than having to solder a battery power system together. I'll grant that, in a situation where space is very constrained, a smaller 3.3V battery would be preferable, but I don't think that is very frequent. The main reason is that the raspberry pi, as great as it is on most fronts, simply does not run very long on a battery. Even the zero will run for only a day or two on a large battery*. For devices to be placed in a situation without any power, usually much more time will be needed. The small batteries that are easily shoved into a small space will not provide enough lifetime for an independent** system.
*Large in the sense of a USB battery for phone usage. There are some really big ones that will run a pi zero for a week or more.
**There would be advantages for some projects in having a pi run on battery for a period measured in months. Unfortunately, that isn't going to happen.
Here's my $30. An additional $5 for twice the RAM is a no-brainer.
What I really want though is proper Gigabit Ethernet and a SATA port. Given the purchasing power the RPi Foundation would have, Broadcom would easily be able to spin up some Silicon for them that has an integrated GbE, and SATA controllers.
Passive Power over Ethernet would make the PI easier to use. You don't need that 48v nightmare. Most home routers run off a 12v PSU and have a little buck circuit to bring it down to 5v. These are very sturdy little circuits allowing 7v to 27v power. The advantage against 5v power is you can run some very long wires such as PoE. Many times I have powered 12v routers over Ethernet with no problems. You simply can't do that with 5v because there is no tolerance for volt drop.
I appreciate why the PI runs off 5v and does not have one of these 12v buck circuits. If there were a way to include a sturdy buck circuit as a hat with options for passive PoE, plug connector and screw terminals then it would mean putting PI in industrial locations much easier. Frankly 5v power is too flaky. With the right capacitors the buck circuit could handle 30v.
I'm already somewhat annoyed by the use of 5v on a micro USB port, given the limitations of the port itself for carrying current, which thanks to Ohm's law, has to be greater than if a higher voltage had been used, and makes the system more vulnerable to reduced power thanks to the high resistance leads and connectors that are to be found too often on the typical cheap Chinese power supplies people will be using.
That isn't actually Ohm's law, but simply an inevitable consequence of the way the units are defined, i.e. J/C (volts) times C/s (amps) inevitably cancels to J/s (watts), no scientific law, it's just maths.
I do understand the concern about the power connection but a barrel connector wouldn't be my first choice, I'd prefer the option of something with a positive lock that can't simply be tugged out. Powering using 5V attached to the GPIO port may be an option, how practical that is depends on your application. As for the supply voltage, I suspect that comes down simply to the cost objectives. Dropping the power down from e.g. 12V means either a switching (cost) or a linear (heat!) regulator and either do not allow for the use of a standardised commodity power supply the user may well already have lying around.
The first pis did use a linear regulator, but recent revisions are all switching.
That's a goer for 5V->3.3V since you are scrubbing 1.7V or 1.7W at 1A. Go down from 12V it's then 8.7W disspiated by a linear regulator which is getting into the region where you need to add a reasonable heatsink.
on finished devices i solder the power leads to the +ve and -ve TPs on the underside of the Pi board board below the power USB port. neater safer and more reliable. it reduces the size of the case or housing needed for the board too. I use rock 64s for heavy computing jobs and these have a barrel jack , I still prefer my method on the rock 64s too.
"I'm already somewhat annoyed by the use of 5v on a micro USB port"
well the 40-pin connector has power input points on it. But as I recall it uses a linear regulator for the 3.3v (which is simpler overall, and a smaller footprint than a switcher) but NOT ideal for battery operation.
[I guess newer Pi's use switchers and different configs than the earlier ones, though... making this impossible without supplying 5v and not just 3.3v]
Specifically for IOT they may need to re-think the use of the 5V rail and enable you to turn OFF various things (like ethernet) programatically to reduce power. And turn off 'video core' too, when it's not wanted/needed. [boot into a GUI for IoT? no. just no]
The original pis, the first generation ones, did use linear regulators. The current revisions uses switching regulators. This was made possible because the production volume grew large enough to have some custom silicon manufactured - a chip which combines all three of the needed regulators into one package, and brings the component count down to an affordable level. It's actually remarkably efficient, but it does make running off of 3.3V rather difficult.
The processor has hardware support for a lot of power management features, including powering down the video - or even powering down entire cores when not in use. Hardware support, but not software support. This capability has been requested many times, but the Pi foundation has concluded they lack the resources to support such advanced and hardware-specific capabilities which would need a lot of kernel modification work.
Got myself a couple of these instead:
https://www.ebay.co.uk/itm/142700706109
They're slung behind tellies so that Kodi works. Plenty of space to hide them there and no moving parts. And plenty cheap too. No more little lightning bolt in the corner from using wall sockets with USB built in.
The A+ might not be a bad idea for my lad. He tools around on RiscOS with the drawing programs and BASIC. Bit more poke, no need for LAN, no need for RAM. It's an original B that's set up there just now.
The 486 DX was great, it was the SX that was shit.
The SX was just the DX without the floating-point unit. Most software didn't use it at the time, so most people would never have noticed the difference.
I'll accept that the initial SXs were just DXs that had failed the FPU tests - that doesn't inspire confidence in their longevity. Then they started disabling the FPU in DXs and selling them cheaper, but finally they had a die with on FPU for the SX chips.
Wasn't an awful idea.
Maybe you're thinking of the 386DX vs 386SX, where the DX had a 32-bit external bus and the SX was only 16-bits so it took two turns to load a word. Again, though, most software was 16-bit DOS at the time. Would that have been a worry? (I honestly don't know if it would have slowed down 16-bit code signiifcantly.) When it came to the Cyrix 486DLC vs SLC, though, there was a noticeable difference.
When it came to the Cyrix 486DLC vs SLC, though, there was a noticeable difference. Both were essentially 386 chips with the additional 486 instructions bolted on but with no performance enhancements. The SLC was crippled further by using a 16 bit external bus just as the 386SX. People thought they were getting a 486-alike when the reality was was more similar to that 386SX.
People thought they were getting a 486-alike when the reality was was more similar to that 386SX.
I thought the 486DLC/SLC were significantly faster than the 80386DX/SX - they had a cache that the 386 was missing. But since the 80486SX was about 4x the speed (from memory) of the 80386DX, the DLC/SLC fell way short. Anyway, I think we can agree that the 386 upgrades were a bit pish.
A mate of mine had a 486DLC/25 and it was a bit cack! :)
Depends on the work. The Pi has interfaces for I2C and SPI - which may mean nothing to people coming from the PC side, but electronics tinkers recognise those as 'I can plug fifty ADCs, DACs, TFT displays and IO expanders into there' ports. What the Pi lacks is really high-throughput IO, but I don't know if the processor would be up to handling the sheer processing demands of anything faster than USB2 anyway.
SATA would be nice, though. But it'd mean a custom processor. Pricy.
"I/O is a real problem on any Pi doing real work: eSATA / USB 3 really should be available."
Doesn't that come down to philosophy in the end? Is the Pi supposed to be a low cost computer, or just a small one?
After all, if you want Power! then you could pick up (for much more money) an Intel NUC with an i7, SATA3, USB3 and NVME. It's all a matter of cost.
Is the Pi supposed to be a low cost computer, or just a small one?
... or just a computer that doesn't run x86? There are plenty of applications for a Pi for which the alternative would be an Atom or low-end Celeron, or maybe an AMD APU, and I for one am glad to see an ARM-based option too.
Re: switching SoCs, I'm more concerned about the GPU having been essentially in stasis all this time; it still supports only OpenGL ES 2 doesn't it?
I suspect I'm way out on a fringe for caring about the specific version of OpenGL, but it prevents support for the latest WebGL and, well, you know web developers. Something new and shiny through which they can reconstruct less accessible versions of what's already built-in? Yeah, go for it!
"prevents support for the latest WebGL"
WebGL is overrated, just like 'cloud' and client side scripting, in general. It's like a cancer. Time to re-think it.
So unless movie playback or localized gaming needs "the new, shiny" existing OpenGL should be fine. chasing the bleeding edge isn't something that's part of the design of a device like RPi anyway.
So this looks like it is intended to compete with the Orange Pi Zero+
Originally the FriendlyArm and Orange Pi ranges were brought out as cheap alternatives to the RPi. Often with more features included in the lower price. However the cost saving never really made up for the lack of community support, software or Linux updates. Now we have a "proper" Pi board that will hopefully compete on price (though I have never heard of anyone complaining their computer had too much RAM.
I got given an OrangePi Android flavour. While nice bit of Hardware, the software never got updated AFAIK, so make it rather moot/useless for my application (Which was to plug it into a TV/speaker as a Google Now assistant... but seeing as it was old Android, I could not get such play apps on it, and 'm no programmer to do my own kernal/os/apps).
I'm beginning to like the RPi's again.
I was an early adopter / tester for the original and their hardware was quite bad, and their educational focus was all-front-no-action (still is).
But the RPi is now a cheap, viable, fast, powerful, multicore, PoE-powered, small, ARM Linux machine with Ethernet, Wireless, Bluetooth and HDMI.
I now look at the things my workplace use on the network and the Pi is capable of replacing half of them - PoE powered tannoy, PoE powered phones, PoE powered CCTV, vehicle GPS trackers, hell, you can make a Pi-powered smartphone if you like.
I have one with RetroPie, also running Kodi, using the DVB-T hat (that was just released), plugged into an aerial, connected to a projector, offering TV on-screen and out over my network (using tvHeadend), PVR functionality, and just one button away are all my old games and a ton of open-source ports. It uses an XBox 360 USB dongle to connect a bunch of gaming pads, plus I've wired in a couple of "arcade style" buttons/joysticks, a Logitech G27 wheel-set and a Bluetooth keyboard (because you can't play Speccy games with only a joystick!).
If I ever fulfill my dream of buying an arcade cocktail cabinet, then that machine is more than capable of running it and controlling all those inputs, for all the games I like, and being the "TV" by offering HDMI out.
This post has been deleted by its author
As someone who has a number of poorly named products in his stable, I can say with some authority that naming things in such a way as they won't annoy you, your staff and probably your customers in 15 years when you've significantly changed your product lineup is harder than it first appears.
Generally around the point you're naming it, you're not even sure if anyone will buy it.
Yeah, either name consecutively (1, 2, 3, 4) or have a clear distinguisher (RPi 3+ has more on it but from the same series as the 3 - why do you need A or B AND a plus?).
Otherwise it's gets too tricky.
Basically:
Zero = very tiny one.
Pi 1 = single-core 700MHz, 256Mb/512Mb, composite video (later ones had HDMI - grr!)
Pi 2 = quad-core 900MHz, 1Gb, HDMI
Pi 3 = quad-core 1.2+GHz, 1Gb, HDMI
The + models have more USB / Gigabit Ethernet / faster speeds.
But they really mess it up by randomly changing things between models, including three models of zero, the compute modules, putting pins only on certain models (e.g. the PoE pins?), and changing the form factor and even layout between each one.
It would be much easier to standardise the modules, and just not solder the extra components onto the smaller models, just like every other manufacturer does.
Basically, stick with the highest numbers, largest-lettered model available (RPi 3B+ at the moment) unless you have a particular pressing need to optimise power / space.
"unless you have a particular pressing need to optimise power / space"
I think that you will find that the design philosophy behind the Raspberry Pi is just this... a mixture of low power and small size, with improvements along the way so that the models get more powerful or more features. What you get is what they can put in for the targeted low cost.
You don't buy an A+, that is only half of the model number. Many internet sites only offer the latest models.
If you want a small board that does more, buy a different brand of board.
Actually...all Pis have had HDMI going back to the original 256MB Model B and Model A.
The confusing point is really the Pi2B as the v1.1 used the BCM2836 and the v1.2 uses the BCM2837. Where the Pi3*+ comes in is the shift to the BCM2837B0 with the flipped silicon and the metal heat spreader...plus the addition of 5GHz WiFi, also under a metal lid.
You might be interested in the IV Port from Ivmech - pricey, but lets you multiplex four cameras on the Pi's CSI port. You can even stack four of them together, for a total of 16 camera inputs...
http://www.ivmech.com/magaza/en/development-modules-c-4/ivport-v2-raspberry-pi-camera-module-v2-multiplexer-p-107
By put to sleep, what do you want to continue running when it is sleeping? How quickly does it have to resume from sleep, and what triggers it to do that? For most available triggers, WiFi signal for example, enough of the system remains up in order to receive and decode that that there is little benefit to putting it to sleep.
The article makes a reference to a "Pi B". Please guys, there *is* a Model B (and a B+). The comparison today is between the Pi3B+ and the Pi3A+. The first generation boards (using the BCM2835) are the only ones that don't usually get a "generation number" included in the common name. (Officially, if you look at the box, the Pi3B+ is a "Raspberry Pi 3 Model B+". That "3" is important to know what you're discussing.)
The real confusion comes when discussing the Pi2B. You have to specify whether it's a Pi2Bv1.1 or a Pi2Bv1.2 as the SoCs are different.
It is the price of the pi zero with wifi built in, which I see as this model's main competition. That lacks plenty of the features of this model, but it does offer most of the ones wanted for running headless*. The processor is slower, which would be painful if using it directly or if it has a lot to drive, but it is very low on power usage, also has built in networking, the same memory, and can use the same hardware on GPIO. If you're using something running a GUI or using a bunch of processing, you're probably going to want the 3B+ anyway for the ability to use USB accessories. Similarly if you're going to attach this as networking equipment because ethernet will probably be desirable. For me, all use cases where I don't want either of these will be decided in the zero's favor because it is smaller and requires less power to run. Those can be critical.
*headless use of pi zero: set up the environment on something else so you can have a more convenient experience, then enable SSH and move the card over.
Not sure I get the logic for reducing RAM capacity, OK, so it sucks a little more power but a memory constrained system has to be the worst design option out there and I have a deep loathing for machines with low RAM as they are ALWAYS slow as they are constantly swapping. On a Pi, that translates to it eating your memory card quicker. Surely the power cost on the SD card and performance impact outweighs the power reduction from the reduced memory size ?
+1 for adding a SATA / mSATA connector (on some high speed bus, not crippled behind USB) as it means higher performance and I won't need to have to rebuild system X in 18 months when it eats the next microSD card and starts acting all weird and takes me a while to work out what the problem is again.
I'd happily pay for a "Model C" - where C is all about capabilities, not price. I don't care if the board is bigger and has free space for options I've not populated (mSATA) or uses some form of stacking arrangement like PC104 used to.
They are great little boards and I've got them doing all sorts of handy jobs, but they could do a lot more for the higher end hobby and business markets, rather than just focusing on the maker/educational end of the spectrum.
I love the USB-C standard, and have it on my laptop.
Thoughts on why USB-C is not on Rasp PI? I guess that having a separate HDMI output is no big consumer os space, and it allows hobbyists and schoolchildren to hook up a cheal HDMI Cable to a standard television. With a USB-C port you would need a separate hub to fan out to HDMI, stanrard USB for keyboard and mouse, and for ethernet. Which would cost more than the Rasp PI
Also I guess USB-C chipsets aren't integrated with the SoCs used on Rasp Pi.
Thoughts?
HDMI also allows a simple, cheap cable to be used to connect to any monitor that has DVI-D input...which most of them have had for a decade or more.
Also bear in mind that the VC4 that is in all Pi SoCs to date wasn't new when the first Pis hit the market in 2012. One may surmise that then next gen Pi (popularly referred to as the "Pi4B") will *probably* have sort sort of upgraded version of the VC4, as Broadcom has SoCs on the market with something that fits that description.
The real key to figuring out what is feasible on Pis is to look backwards, not forward, because at the Pis price points, up and coming tech is too expensive. I used to refer to building with that technique, "trailing edge technology".