What do people want to do that the rpi currently cannot do??

[expandables]

The SoC range used in the Pi only has a single USB channel in to the device, so throughput will always be an issue until a different range of SoC is selected. At which point, almost all the work done on optimising Raspbian and apps goes out of the window(new architecture, new GPU, new camera I/F, new DSI I/F, new GPIO system etc). So it's more than a $20 upgrade. It's definitely a limitation, but currently one with no sensible solution.

I have a solution, and it is this what if some one makes a Ethernet HAT?

[W. H. Heydt]

the main issues for me with the PI2 are

1 desktop performance. Web Surfing still not useable. Needs 50-100% more CPU and a couple more GBs RAM.

I wouldn't expect more than 2GB for a *long* time. I know of two (one "real" as in people have them, and one proposed as in KS campaign is running) that have or have as an option, 2GB of RAM. Those are the Lemon/Roseapple Pi and a version of the PINE64+.

2 server performance. IO throughput too slow (2.5MB/s). Lose The USB - NIC hardware contention to hopefully double throughput.

I'm not particularly concerned about Ethernet running off the USB bus. What I'd like to see is a decent, and independent, mass storage bus, such as SATA. Even SATA I (1.5Gb/s) would suffice. The Allwinner A20 (Cubieboard 2. Banana Pi) has SATA II and those boards have an exposed connector for it. I class an intedependent Ethernet supporting bus as a "nice to have", but hardly essential.

None of this need cost much 10-20$ ? and we now have a low-end but useable desktop or server. This is the PI3 hopefully. There is SOOOO MUCH demand

I'm not even going to touch what the desired features might cost. There are far too many unknowns even to speculate, and those costs are very much a moving target.

USB3 and another CPU doubling in the PI4 and we have a sweet mid range

Again, USB3 is a "nice to have", though it could be used in place of SATA, since it's faster than SATA II and a bit slower than SATA III. When you say "CPU doubling" are you talking about going to 8 cores? !.8GHz? A second SoC on the board? Personally, I don't think any of those would bring any real benefits over spending what they require on much more useful features. Going octacore doesn't look to do much for anybody. Observing the crop of boards that have been announced over the last year, everyone seems to be stopping at 1.2GHz (with the exception of the Odroid-C1/C1+/C0, which has really small, single dispatch 32-bit cores). The one "doubling" that will almost certainly happen eventually is a move to 64-bit cores, and along about the time of a "Pi4B" may be the right time. (Though I'd say that there is a modest chance that the "Pi3B" might go 64-bit.)

[blc]

My Pis have been pretty reliable, (Samba server,VPN gateway and more)

the main issues for me with the PI2 are

1 desktop performance. Web Surfing still not useable. Needs 50-100% more CPU and a couple more GBs RAM.

2 server performance. IO throughput too slow (2.5MB/s). Lose The USB - NIC hardware contention to hopefully double throughput.

None of this need cost much 10-20$ ? and we now have a low-end but useable desktop or server. This is the PI3 hopefully. There is SOOOO MUCH demand

USB3 and another CPU doubling in the PI4 and we have a sweet mid range

and yes I know this is not what the original Pi was about (Kids experimenting). But it is what the new Pis will become

Dont forget that the Kids need a desktop to find the info they need in order to experiment

I think what you want is this: https://www.kickstarter.com/projects/13 ... escription

But of course that's total vapourware until they actually deliver. They're quoting March 2016, but I highly doubt that. The Raspberry Pi is available now.

[jamesh]

1.2Ghz seems to be the top sweet spot for ARM devices at the moment - it costs too much to make them any faster.

The original Pi could just about squeeze 1.2 in extreme cases, the Pi2 isn't really capable of it.

So the obvious options are more cores, more memory, or 64bit or a combination of all three if you are staying with ARM and still want cheap. But tbh, the current Pi2 is a pretty fast bit of kit if you use it fully. I'd like to see more optimisation effort on things like LDXE and graphics acceleration. That likely to give just a good a speed up as the options listed. Note, a lot of work is going into the SW stack, that the Foundation have control over (GPU acceleration of X via Glamour and OpenGL, Scratch optimisation, LXDE optimisation) but it's third party stuff that also needs work that I would like to see getting some attention.

[steveb4pi]

I want to use it away from mains-power, i.e. for a mobile 'in the field' application (= specifically positioning control of an astronomical telescope and control of the imaging sub-system)

This requires that the Pi run directly from a 6v battery power source (= specifically, 4x 1.5v primary cells, a 6v 'lead acid' or 5x1.2v NiMH .. and all without blowing itself up when the battery is new (and delivering more like 7v) or dropping out when the battery is almost flat (and delivering more like 5v))

[gordon77]

I want to use it away from mains-power, i.e. for a mobile 'in the field' application (= specifically positioning control of an astronomical telescope and control of the imaging sub-system)

This requires that the Pi run directly from a 6v battery power source (= specifically, 4x 1.5v primary cells, a 6v 'lead acid' or 5x1.2v NiMH .. and all without blowing itself up when the battery is new (and delivering more like 7v) or dropping out when the battery is almost flat (and delivering more like 5v))

Why not a 12v lead acid battery and a 12v to 5v usb adaptor? That's what I use for my pi on a telescope.

[W. H. Heydt]

I want to use it away from mains-power, i.e. for a mobile 'in the field' application (= specifically positioning control of an astronomical telescope and control of the imaging sub-system)

This requires that the Pi run directly from a 6v battery power source (= specifically, 4x 1.5v primary cells, a 6v 'lead acid' or 5x1.2v NiMH .. and all without blowing itself up when the battery is new (and delivering more like 7v) or dropping out when the battery is almost flat (and delivering more like 5v))

How long do you need it to run off the battery? I have a battery intended for smart phones or tablets that I hook up to a Pi2B and an RPF 7" display. The whole rig will run for 11 hours.

[Heater]

My Pi 2 plus WIFI dongle runs off a 12000mA phone "power bank" for 24 hours or so.

All kind of very efficient switched mode boost and buck converters are available on ebay for just a dollar or two if you want to use other batteries and voltages.

[ausppc]

I want to load lots of data really quickly. I want a full speed (m)sata connector on the next Pi. And if that means ditching the current SoC, all the better. Please use a less munted, more open SoC. 2x hdmi would also be a good move. Other than that, I think the choices made in the current Pi offerings are spot on.

[Heater]

ausppc,

Do you know of "a less munted, more open SoC"?

Never mind open what is "munted".

There are already many cheap ARM boards with SATA out there if you want.

Personally I would love the next Pi to be revolutionary. Not just more of the same or following others.

A 64 bit RISC V processor for starters. More open than any ARM. Perhaps the Low RISC which is being developed in Cambridge as well I believe.

I'm happy with what we have. Who knows what comes next? The Foundation is full of surprises.

[W. H. Heydt]

I'm happy with what we have. Who knows what comes next? The Foundation is full of surprises.

That's really the ultimate "I want"...I want to see what the RPF does next. Whatever it is, it will be interesting, probably exciting, and will cause sleepless nights among those making or planning to make competing devices.

Here's to the future!

[ausppc]

@Heater

You get 'em in a twist over 'open' and 'munted' and then you say you want 'revolutionary' as if that clarifies anything? Interesting...

Do I have to know of a better SoC to be aware of the issues with the current one?

But ok... In this context, 'more open' would mean better, more complete documentation. And 'less munted' means that it doesn't cause developers of low level board support functionality for various OSes to spit the dummy - as is the case with OpenBSD.

[Heater]

ausppc,

You get 'em in a twist over 'open' and 'munted' and then you say you want 'revolutionary' as if that clarifies anything? Interesting...

You might have to elaborate on that. I have no idea what you are talking about.

Firstly this the first time I have ever seen the word "munted". Google tells me it's slang for "drunk", "intoxicated", "damaged" or "unusable". In what way is the Pi SoC any of those things?

Secondly "revolution" is a very commonly used word. We can take it's meaning as "involving or causing a complete or dramatic change." It is used a lot to describe jumps in technological progress. Like moving from valves to transistors or from transistors to integrated circuits or the arrival of the internet. My use of "revolutionary" with respect to my suggestion for a 64 bit, open source, and new processor architecture seems quite appropriate to me.

What is not clear about my statement?

Do I have to know of a better SoC to be aware of the issues with the current one?

I did not say "better".

You said "Please use a less munted, more open SoC" so I assumed you had examples of less munted and more open Soc in mind that you could suggest.

Admittedly I have little knowledge of any problems with providing low level board support. But what is wrong with the OpenBSD developers? Linux and RISC OS are working fine on the Pi. There's a whole bunch of people programming the Pi with no OS at all. All the other BSDs run on the Pi as far as I can tell.

[ausppc]

Aside from the notorious difficulty of making an OTG USB host behave like the typical desktop equivalent, the OpenBSD developers have no motivation to support hardware that only works with unknown, undocumented drivers due to the imposibility of being able to maintain credible security in such an environment.

re: That same driver, I can't comment on how RiscOS was able to reinvent the wheel and actually work with it but there's at least one other non-linux OS that will have to do the same - that being HaikuOS.

[Heater]

ausppc,

I totally appreciate the desire for open source software in all things. For security reasons as you say. Also for many other reasons, like avoiding vendor lock in for example. I'm a great supporter of Richard Stallman.

As far as I understood there are no closed source, binary only drivers in Raspbian and other Linux distros on the Raspberry Pi. Do point one out if there is.

Documentation may well be an issue, as it is with a lot of hardware we use today.

Am I to understand from your statement that OpenBSD does not support any device that requires closed source binary firmware "blobs" to get working?

How does OpenBSD actually ever run on anything now a days? There is closed source firmware in SD card controllers, SSD and hard drives, WIFI and ethernet adapters, keyboards, mice, everything!

[karrika]

I am pretty scared about closed software today. A small example from 2014:

Zombie Zero – barcode scanners used as hacking devices
This example borders the maritime industry in as much as it was directed at the logistics
industry. The attack was termed Zombie Zero, tailor made to attack logistics companies
and was discovered in July 2014 by the company TrapX 2 .
It consists of a cyber attack hidden within a piece of hardware – in this specific case it was
embedded in a hardware scanner used by logistics companies. The attack was verified to
be present within at least 8 different companies. In a specific case study made public by
TrapX, they found 16 out of 48 scanners at the company to be infected with the malware.
It is important to note that the malware was pre-installed within the scanners before
delivery to the logistics companies.

And this is just the tip of the ice berg.

[ausppc]

The thing about the BCM2835 and its closed source nature is that *all* the Pi OSes interface to that closed source driver or it's no-soup-for-you.

I swear I've read the point of view you just offered re: everything is closed source elsewhere...

http://comments.gmane.org/gmane.os.openbsd.misc/219675

One other thing to note, if the BCM2835 was properly documented, there'd most likely be software to fully emulate a Pi - which can be a significant aid with software development.

[Heater]

There is no closed source driver in the Linux systems for the Raspi.

It's not clear to me why one would object to closed source drivers in their operating system but be quite tolerant of having close source code running all the peripherals of the machine.

I don't quite get the logic there. Except of course that if one does not tolerate all that closed source peripheral code one pretty much does not have a computer now a days. I cannot think of any machine that is open from top to bottom.

[karrika]

This is pretty much a question of trust. The way the Raspberry Pi Foundation operates makes me believe that I can trust the boards to be free from malware. Perhaps I am naive. But this is the way I feel.

I do not feel the same if I buy a Windows laptop. I kind of expect my data to flow to some "authorities" when I am using it.

It does not matter if there is an undocumented blob or a few undocumented transistors on board. It is the same thing. You can hide anything in the silicon if you want.

[blc]

I'm all for open source everywhere, but the devout "Richard Stallman"-type attitude that some posses can go do one (definition link included for Heater's benefit )

I understand the need and desire for open source in all things, but on a practical level that's not always possible. Since we're talking about the Pi, take GPUs as a prime example: even though there are open source Nvidia and AMD drivers available, there will still be proprietary binary firmware in the actual cards themselves. That proprietary code is part of what gives them a competitive edge. Same deal with SSDs: in the early days of SSDs it was a real minefield when it came to controllers, because some firmwares were implemented extremely poorly despite using the exact same hardware as a company who had written excellent firmware. The company with the better firmware sold more products, and if that firmware had been open source then they would not have had commercial advantage. Despite all the ideals being thrown around the bottom line here is money. These companies exist only to make money, and if they're giving away one of the things that gives them an edge over their competitors then their competitors can easily copy that thing and use it in their own products. Suddenly the competitive advantage is gone and you're going to have a hard time pleasing the shareholders.

People seem perfectly happy to run a system which has a 100% open source operating system, including all drivers, yet still probably has closed-source firmware in almost every hardware component. Feel free to correct me if I'm wrong on this, but: Pi software is open source, the hardware is not and never has been - the GPU blob is just firmware needed to make the hardware work, just like the firmware in your SSD controller. It was just cheaper to ship it on an SD card rather than design a built-in flash chip.

You only have to look at the Novena laptop project to see the difficulties - and expense - involved in making a truly "open" system.

[rurwin]

...if one does not tolerate all that closed source peripheral code one pretty much does not have a computer now a days. I cannot think of any machine that is open from top to bottom.

It isn't just computers. Microcontrollers are so cheap and easy to use that pretty much everything uses them in preference to discrete logic. You couldn't have a toaster or a washing-machine if you objected to closed-source blobs everywhere.

Peripherals are a special case of course since they have theoretical access to the outside world. A hard-drive or SD card could be subverted to add malware when reading out particular files in certain circumstances. That is probably more likely than the Broadcom GPU blob being subverted, and probably easier to do. It would be much harder to spot too.

Of course you would have to flood the world with bad SD cards to have a chance of some of them being used on the RaspPi, but it isn't impossible. See Stuxnet, a Windows worm who's sole purpose was to subvert the closed-source blobs of industrial controllers in Iran.

The most any software developer can say is that there are rigidly defined areas of doubt and uncertainty.

At some point you have to put a cap on paranoia and say, yes it's theoretically possible but it's also highly unlikely and mitigating it for me personally is not a reasonable course of action.

[mung]

I think you can try and predict the future, with differing levels if success, l am not sure about understanding the future.

I stand under it.

I heard the universe was totally deterministic actually!

https://en.wikipedia.org/wiki/Terence_M ... ewave_Zero

https://en.wikipedia.org/wiki/Pi_%28film%29

[mung]

I like this post, very true, and also saddening, I wonder if the whole point of the pi has been lost?.

I would love to see more people starting projects to optimise and utilise the pi hardware, unfortunately only a very small number of people are ever going have the talent and interest to put in the hard work required to achieve this.

Seems what some people want is a gigabit network media server or better web based media viewing, but do not think how could they achieve it using the pi in creative ways.

Instead of saying I want to run a server stack with wordpress, they should be saying what does wordpress do and how can I write some code that achieves the same thing and runs fast on the rpi.

Instead of saying they want to stream media to a backup disk they should ask what data rates are involved/required and where the bottlenecks are, then trying creative ways to work around the problems.

For example I have heard even 4k ultra HD streams only use 15Mb/s, why need gigabit?, if you do really need the higher data rates why not try writing a distributed SAN RAID driver so storage/network load can be shared between many rpi?

I suppose the problem maybe that the rpi is targeted at beginners who cannot implement such things until they have a few years learning and experience, but then again a beginner would not probably know that they wanted gigabit?

I would love to see replies to some of these types of 'I want a professional grade system like a PC for $25' requests being given outlines about how the requestor could go about achieving the same result using a rpi if they put the work in, maybe 1 in 1000 might actually add something to the project.

The question is all wrong. It should be:
How can people do with the RPi what they currently currently cannot do?
And the answers are quite simple:
1) Use better software
2) Write better software
3) Use the GPU (all parts) wherever possible (there's still a lot of unused potential), see 2)
4) Tell the web designers which use tons of Javascript where nobody needs it is to go to hell (meaning, don't visit their pages any more).

The Pi was developed for kids. They should learn to create great things with limited resources. That's what we all have to learn before the planet becomes inhabitable.
Don't cry for more power (CPU, GHz, RAM etc). Educate yourself to get along with what we have (not only the kids need education).

[mung]

I have just in the last year been playing with the current pi camera and it seems an amazing part of the rpi system, I don't know why no one is selling rpi+camera packaged up as an IP cam as it has amazing possibilities.

I also just got started learning about astro photography (still not had much time to do much), but an upgraded camera with global shutter and larger sensor area would be very very very nice, I wonder what options there are on the omnivision web site?

More GPU/VPU programming information would be nice so people could implement their own sensor post processing.

In the exotic / unreasonable wish list category: have a camera that can record HD video with a high-speed strobe that illuminates the whole frame even with a short shutter time. This would require a global shutter camera instead of the much more common/ inexpensive rolling shutter, plus have a frame-start sync output signal, and is a niche use case so I'm pretty confident it will not happen. In fact, you can almost do this with the existing RPi camera, but you have to use shutter speed = 1/fps (frame rate) or in traditional film terms, a 360 degree shutter angle, so that limits the (strobe light / ambient light) exposure ratio. Also, AFAIK you can already do this with existing USB global-shutter cameras (starting around US$ 1000).

[W. H. Heydt]

I also just got started learning about astro photography (still not had much time to do much), but an upgraded camera with global shutter and larger sensor area would be very very very nice, I wonder what options there are on the omnivision web site?

Well... We do know that the sensor in the current Pi cameras has gone out of production, so at the very least, a new sensor has to be located/decided on, and quite possibly and entirely new camera module. With that in mind, the most significant "upgrade" I would to see would be the provision of some sort of standard lens mount so that a different lens could be attached. My personal preference would be (depending on what coverage is needed for the physical sensor) either C-mount or D-mount because I already own some lenses with those mounts. C-mount would be the preferred one as the lenses are more common and the ones I own are more....interesting...ones. It should also be relatively easy to get a C-mount adapter for telescopes.

In any case...it'd be a kick to attach a 6" (152mm) focal length lens to a Pi camera.