Just in case this was an indication that RPF is interested in (and will act upon) suggestions for small incremental changes that can be done one at a time 1) to the BOM, 2) then to the layout, and 3) finally to the design, would anyone like to volunteer suggestions organized in that way, as small baby steps?
Borrowing liberally from everything that people have discussed here, an obvious trio could be:
Increase USB reservoir caps to reduce reboots on plugging in power-hungry devices.
Unlink the incorrect connection between 1.8V LDOs (certain to be in the plan already).
Feed the two host USB +5V lines from the other end of F3 to reduce +5V0 rail voltage deregulation by USB current fluctuations.
BTW IMHO the power design needs to be redone from scratch, including how power is delivered to USB devices. They can take a closer look at the Beagle Bone and Pand boards for a reference.
Aye, I agree regarding overall power design. Sadly that would be a rather XXL-size baby step, but yes, it does need to be redone.
I'm not really sure I should be in such a hopeful mood as I am, but good things seem to be so rare from that quarter that it really brightened my day to see that small revision.
I agree it is not a small change, but it would be a shame because I still consider the R-Pi a great idea and something worth to have, both for education and for people interested to thinker with embedded Linux.
To reduce costs I'd get rid of the FPC connectors and put together a board layout that is more case/mount friendly with mounting holes, a decent power jack, etc.
Also I'd add more GPIOs and interaces coming out of the SoC.
But the best thing that could ever happen is if they are willing to open the re-design process to the rest of the community and among other things release the schematics before going to production.
Adding those two connectors as standard on a board that sought minimum cost was a severe design misjudgment, and it actually points to ulterior motives. The plain goal of "lowest cost for engineering education" simply does not justify them being there at all, particularly when it resulted in a reduction in GPIOs and hence reduced education utility.
I also agree with all of your other points. A board for education should of course be totally open and their processes and design considerations should be shared with the community as well, and forum discussions about problems should be embraced openly and warmly of course. Alas, given their utter hatred of openess, I fear there will be no change on this front.
@John: Proclaiming that feature X has been accepted for addition to a future board revision does not require a date to be attatched to the announcement. Dates would probably result in ordering slowdowns, so are not a good idea. And dates would take us back to the silliness of the waiting game that was so annoying before.
Adding those two connectors as standard on a board that sought minimum cost was a severe design misjudgment, and it actually points to ulterior motives. The plain goal of "lowest cost for engineering education" simply does not justify them being there at all, particularly when it resulted in a reduction in GPIOs and hence reduced education utility.
I also agree with all of your other points. A board for education should of course be totally open and their processes and design considerations should be shared with the community as well, and forum discussions about problems should be embraced openly and warmly of course. Alas, given their utter hatred of openess, I fear there will be no change on this front.
@John: Proclaiming that feature X has been accepted for addition to a future board revision does not require a date to be attatched to the announcement. Dates would probably result in ordering slowdowns, so are not a good idea. And dates would take us back to the silliness of the waiting game that was so annoying before.
Of course, the best-ever design change that could be made to the Pi is one that would be completely impossible for the Broadcom-tied Foundation to make --- replacement of the Broadcom BCM2835 by a better and more open SoC.
