1 2 3 Previous 188 Replies Latest reply on Jul 21, 2012 4:04 AM by puddle1944 Branched to a new discussion.

    Raspberry Pi - Hardware Flaws and Fixups?


      Several people have commented on the hardware design of the Raspberry Pi.  Some are buried in other topics so please post your comments here.  I'll try my best to answer questions about the design decisions we made.  The Raspberry Pi is not perfect, never will be.  I've always found that perfect designs have a habit of never getting built, engineers are always a bit guilty of that, but I had Eben phoning/emailing me every day wanting to know when it would be finished.  Also, one persons perfection is another persons nightmare.


      e14 is the home for engineers so please contribute to make Raspberry Pi better.





        • 1. Re: Raspberry Pi - Hardware Flaws and Fixups?
          John Beetem

          First, I would like to say that RasPi is a very beautiful board design.

             This is very minor suggestion.  I would like to have the option of bypassing the micro USB power input S1 and soldering 5V power inputs directly to the board using little wire jumpers.  I can almost do this already since there are vias on the traces connected to S1 pins 1 and 5.  However, it looks like there's solder mask in those vias, which is a pain to clear.  So it would be really nice if the solder mask could be changed so those vias aren't filled.

             While you're at it, the trace connected to S1 pin 1 seems awfully close to (unused) pins 2-4.  I'd shift the trace away a bit so the cleared via doesn't short to S1 pins 3-4.

          • 2. Re: Raspberry Pi - Hardware Flaws and Fixups?



            Might be able to help...for now


            +5V (unfused) is on P1/2 and P1/4

            0v on P1/6


            If you do not want to go in there then solder across D17 - biggish pads should be able to cope but again unfused (probably better than trying to get in vias..


            I'll add a proper Aux +5V (fused) input option to my 'wish' list.



            • 3. Re: Raspberry Pi - Hardware Flaws and Fixups?

              I know that Gert and Eben are already on the ball about this one, but I'll just mention it here so that it's not forgotten again:  the I2S signals got lost in the final layout and need to be brought out.

              • 4. Re: Raspberry Pi - Hardware Flaws and Fixups?

                I know it has probably been mentioned before, but would it be that difficult (or expensive) to increase the on board memory, which apparently is shared with the GPU anyway, up to 512 Mb.?

                This would enable certain Linux distros to run more 'smoothly' and should increase performance generally... shouldn't it?

                I am by no means a hardware 'expert', so if this a silly rerquest. then I will apologise now!

                • 5. Re: Raspberry Pi - Hardware Flaws and Fixups?

                  It's a very reasonable question. The answer that's been given before was that the price of the 512M memory modules is much higher and it couldn't be done for the required price.  My guess is that if memory prices fall a future version could have more memory. I think the limit is1G because of the number of pins available.


                  All this is unofficial but based on what's been said before.

                  • 6. Re: Raspberry Pi - Hardware Flaws and Fixups?



                    I have said before that it was not in our roadmap - but I hesitate things can always be changed  - I don't want to be in the situation where I say there is no interest or call for something when it is clearly not true.  So a measurement is in order.  I'll kick off a poll soon.


                    Our original (and still current) aim was to make the cheapest functional device to do the target educational job.  Given the tremendous support we have been given from so many different quarters we will re-evaluate it.  Price is an issue but interestingly bringing the model A up to 256Mb worked to increased volume of a single device and the price impact was minimal on A and positive on B.


                    Being absolutely honest my (not the foundation) concern is that providing a 512Mb device will mean that application developers will be tempted (not unreasonably) to use it and then not be able to support the 256Mb educational device - we are almost setting ourselves up for potential incompatibility issues. It's a concern not a fact - I'm and engineer and perhaps I'm plain wrong - comments?



                    • 7. Re: Raspberry Pi - Hardware Flaws and Fixups?

                      My opinion is that the Pi board created this magnificent niche purely as a result of its low price, so you're totally right to focus on cost in my estimation.  After all, there is no shortage of higher-priced boards, but they never created this degree of interest.  $25 is a sort of magic threshold.  (The $35 model B is actually riding the wave created by the model A's magic price.)


                      Personally I'd not worry about RAM size incompatibility, for four reasons:


                      • Educational use rarely requires large amounts of memory, and education is after all the primary target.
                      • The Unix model works well with very little memory, and encourages the use of multiple small processes.
                      • Darwin will ensure that large monolithic programs that don't run in 256MB are discouraged. :-)
                      • Technical progress will inevitably mean that memory size will increase, so size variation is inescapable.


                      In summary, I suggest to always provide as much memory as current technology allows whenever a new iteration of the board is being designed, but always respecting the existing cost constraint.



                      • 8. Re: Raspberry Pi - Hardware Flaws and Fixups?

                        Thanks for your interesting reply Pete.


                        As it is so easy to do, what with all the 'hype' surrounding this device, I had forgotten for a moment its primary purpose which is, as you say, as an 'educational device'.


                        So far as the 'home user', 'enthusiast' or 'geek' (call them what you will) is concerned... and I include myself in one of those categories, I am sure they would welcome the involvement of more application developers, and hopefully the appearance of some more dedicated OS's also.


                        The idea of a cheap, but functional, 'mini Linux box' is very appealing, (especially when enclosed in a smart case!) although obviously ARM support is essential here, and of course the Foundation have their own pre-determined path to follow.


                        It would however be a very attractive option I feel, and one which would probably increase sales also... although perhaps not all in the intended market.


                        Definite food for thought... and for much further discussion I expect!

                        • 9. Re: Raspberry Pi - Hardware Flaws and Fixups?

                          Not  a flaw, but I'd like to know if in future it'll be possible to power more demanding usb2 peripherics from the onboard hub, having the right power source; I'm referring to a RPF blog entry where protections on power input were discussed.

                          My interest would be the possibility of plugging a 2,5 harddrive, and have it powered directly by the RPi, without the use of an hub; right now this is not possible, since the spinup currents would fry the tracks, 500mA max if I remeber it right, where a spinup is >1A.

                          Is this feasible? Sure it's more for non-educational users, but it'll be a nice plus.


                          Unrelated question: I read that the usb and the lan share bw, is that true? If it is, can you give some details about how that is managed? Like usb attainable speed, lan attainable speed, both combined...


                          • 10. Re: Raspberry Pi - Hardware Flaws and Fixups?

                            It seems that the foundation, or one of its members, decided to become "open".

                            Good news, i am happy to learn that i was not the only one banned from the official forum for trying to tackle subjects that were not the taste of Liz and  friends.

                            Pete, are you going to post some schematics. It will be more convenient to talk about hardware.
                            I see nothings really technical in the technical documentation section of this

                            • 11. Re: Raspberry Pi - Hardware Flaws and Fixups?

                              I know about the textbook Turing Machine example, but this remarkable project:

                              http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit  really makes the point that it is only the memory size that limits what a computer can do. The CPU just limits how *fast* it can be done.


                              That said, for me the most distinguishing feature of the RasPi is the price. If you really need more performance, at some point you're really better off with just using a bigger system, for somewhat more $$ of course.  But, not sure where that point is exactly.

                              • 12. Re: Raspberry Pi - Hardware Flaws and Fixups?

                                Wouldn't it be possible to release a preliminary schematic now, in advance of further work?  If necessary print large diagonal PRELIMINARY banners across it like ARM and others do with datasheets, and label it clearly as a draft, but it's hardly necessary.  The revision number is all that matters, and the schematic wouldn't apply to any board labelled with a different revision number.


                                I really can't see any merit in delaying a preliminary release.  Only engineers and electronics enthusiasts will ever look at it, and technical people don't have any trouble understanding the concept of 'preliminary'.


                                It would help hugely in threads such as this one which refer to circuit points and components.  It's really hard to follow the discussion otherwise.

                                • 13. Re: Raspberry Pi - Hardware Flaws and Fixups?


                                    I think your concern about application developers taking advantage of 512MB and leaving

                                  users of the 256MB device in the cold, is misplaced.  Most applications aren't being written

                                  from scratch for the RPi, they are being rehosted from other linux systems.  So the application

                                  is going to be identical regardless of the memory available. 


                                  For most applications, the application's code will fit fine in 256MB.  It's the data that matters.

                                  For example, a web browser's code will fit in 256MB, but if you are browsing large pages, or if you

                                  have multiple tabs open, you will run out of memory.


                                  Both Debian and Fedora have stated recommendations/requirements for substantially more than 256MB, so the 256MB RPi is not compliant.  It's not much different than trying to reduce costs by using a smaller cpu heat sink than the cpu manufacturer recommends/requires.   You wouldn't want to do that because inevitably it will lead to increased support costs and user frustration.

                                  • 14. Re: Raspberry Pi - Hardware Flaws and Fixups?
                                    Roger Wolff

                                    piovrauze wrote:

                                    Unrelated question: I read that the usb and the lan share bw, is that true? If it is, can you give some details about how that is managed? Like usb attainable speed, lan attainable speed, both combined...


                                    The SOC chip is meant to be used  inside a phone. So whereas modern CPUs have high speed busses to connect to peripherals either on the motherboard or on expansion cards, that simply isn't going to happen for a chip inside a phone or tablet.


                                    So the SOC has... USB. The model B has an USB-ethernet dongle integrated on the board. And because there is just one USB port on the chip, there needs to be an USB hub on the board as well.

                                    1 2 3 Previous