Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 70 replies
  • Subscribers 687 subscribers
  • Views 4738 views
  • Users 0 members are here
Related

new RPi model B planned soon

Former Member

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=23600&start=3

 

Maybe it will fix the USB hot plug problem.

Maybe it will fix the residential CE/FCC compliance issue.

no actual information available.

 

Six days ago, JamesH wrote:

"AFAIK there will be no change to the Raspi (overall - so same SoC, same memory etc) in the next year. There will be changes in SW though, but that is a simple upgrade."

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=23&t=23131&start=1

 

There seems to be a pattern that new hardware revisions are released shortly after JamesH says they won't be.

 

Model A's planned for March.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=3225&start=7

Parents Reply Children
  • in reply to Former Member

    I wonder what "device" is being updated.

     

    Interesting to notice that now they think model A will be used for industrial applications (hard to believe it is reliable enough for that kind of environment,) and that model B is the one recommended for schools and learning.

     

    30 weeks lead time for the BCM SoC?, that really sucks.

     

    Interesting post pointed by your last link.

  • in reply to jamodio

    Heh, I guessed on various occasions that the bottleneck was Broadcom's maximum fabrication rate of BCM2835 SoCs and not the board manufacturing capacity nor the chosen ordering volumes.  The evidence did point to it all along, as nothing else can explain a lead time of over half a year.

     

    As usual the fanbois tried to deny everything and paint RS as the guilty party, but coder27's links above make the situation clear.  Not even RPF can obtain more SoCs for Model A, every one produced reduces the number of BCM2835 parts for Model B.  The posts indicate that the restrictions are entirely at Broadcom's end.

     

    Interesting that the Model A will have only 256MB RAM, if the posts are to be believed.  I expect this is more a case of increasing profit than necessity, because the BOM cost will have plummeted way below RPF's original 10-30k batch values, and 512MB is at a pricing sweet spot now or very close to it.  It's probably a reasonable choice though, because most prospective Model A users are likely to be thinking of projects where power savings are beneficial.

     

    If the expectation is that Model A will be ready by the end of the year then it seems strange that the comments by "official people" are so fuzzy.  After all, it's Nov 26th today, so "end of year" is so close that there can't be any uncertainties remaining about expected ETA.  Only a new problem arising could change the ETA this late in the process.

     

    Morgaine.

  • in reply to morgaine

    Morgaine Dinova wrote:

     

    Interesting that the Model A will have only 256MB RAM, if the posts are to be believed.  I expect this is more a case of increasing profit than necessity, because the BOM cost will have plummeted way below RPF's original 10-30k batch values, and 512MB is at a pricing sweet spot now or very close to it.  It's probably a reasonable choice though, because most prospective Model A users are likely to be thinking of projects where power savings are beneficial.

    Unless the Model A ships soon, it will probably end up with 512MB as well.  Old timers here will remember that the Model A was originally to ship (in March 2012 image) with just 128 MB.  The inventory overhead of having two different parts will probably be high enough that they might as well do 512MB for both.

     

    I might consider a Model A if it comes with 512MB.  My display/keyboard/pointer for RasPi is a Motorola Atrix Lapdock, which has a built-in hub with two extra USB A ports.  Right now the RasPi Model B's LAN9512 doesn't get along with the Lapdock's hub, for example a USB Flash drive works in the RasPi's spare USB A port but not in the Lapdock's.  With a 512MB Model A, there's a good chance that the Lapdock's hub will work better.  Also, the Model A will use less power since the power-hungry LAN9512 with linear regulators will be replaced by the switching regulators in the Lapdock.

     

    But first I need to hear reports about how well browsers work with 512 MB versus 256 MB.

  • in reply to johnbeetem

    But first I need to hear reports about how well browsers work with 512 MB versus 256 MB.

    I can report that everything is much faster on the 512mb model.

     

    I have not used a broswer specifically but I have used programs such as gparted - which loads twice as fast on the 512mb (even with no overclock).

  • in reply to johnbeetem

    John Beetem wrote:

     

    I might consider a Model A if it comes with 512MB.

     

    I might consider a Model A for headless operation by plugging its single USB into an external Ethernet adapter.  That would probably overcome the Pi's USB hardware bugs, although not even that much is certain.

     

    My original Model B is destined for framing along with a suitably blunt caption.  The Model A had better work, or I'll have to find a frame large enough to hold both, and the caption will become a lot blunter.

  • in reply to morgaine

    I'd not venture yet to say that the model A will work better USB wise since the problem is not the LAN9512 but the limitations imposed by the USB IP on the BCM2835 which is an OTG implementation than a full featured USB HOST, plus some other issues in the driver code.

     

    Without the LAN9512 will alleviate some power and thermal issues, still not really clear how much better things will work with an ethernet interface hanging from USB.

     

    Still power hungry (as any other ethernet PHY that sinks current through the ethernet transformer) one experiment I'm planning is to hook up a standalone ethernet controller such as the Microchip ENC28J60 (10BaseT) or ENC424J600 (10/100BaseT) via the SPI interface. These controllers are not for heavy duty networking stuff but may work well in many applications, I know that there are some Linux drivers for the ENC28J60, didn't search yet for the ENC424J600.

     

    Model A could be a good alternative for a headless WiFi configuration, the power budget gained by removing the LAN9512 can be used to power a decent WiFi USB dongle.

     

    About browser speed, I didn't play with it much, but didn't notice a huge difference using Midori with the 256MB or 512MB board, it runs awfully slow in both. Still X is not hardware accelerated so I don't know if that could be the root problem.

     

    My .02

     

    -J

  • in reply to jamodio

    Only experience will tell, but I'm hoping (for RPF's sake, not mine) that the Model A's single USB directly plugged into an external Ethernet controller with no hubs nor any other USB device in sight will manage to stay within the narrow bounds of what the crappy USB implementation on the BCM2835 can handle without errors.

     

    We'll just have to wait and see. image

  • in reply to morgaine

    To be frank I didn't have the time to dig too much into the USB problems on the BCM2835, also I don't know how crappy Synopsys IP actually is, but what I can tell from previous experiences is that it will be very challenging to make USB OTG to fully behave as a HOST, I think that some people were working trying to put together some abstraction layer on the driver so Linux sees it as a host but I still think it is a long stretch and there will be some compromises/limitations, so Model A or B, USB host IMHO will still suck.

     

    BTW, there is a more recent thread about USB issues on the RPF Forum http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=23544

     

    And after the "pub" yada yada, there is only a single update from Gordon and it does not say much, or what it says is not much ...

     

    Edit: Ohhh and I just noticed another post from the "friendly moderator" essentially telling people to back off reporting problems they already know exist, what a nice gesture.

  • in reply to morgaine

    Morgaine Dinova wrote:

     

    As usual the fanbois tried to deny everything and paint RS as the guilty party, but coder27's links above make the situation clear.  Not even RPF can obtain more SoCs for Model A, every one produced reduces the number of BCM2835 parts for Model B.  The posts indicate that the restrictions are entirely at Broadcom's end.

     

     

    Why are you talking as if the RPF has anything to do with the purchasing and distributing of the SoCs?  It's a very well know fact that they have 100% outsourced the production of the device to Farnell and RS.  Liz says "we" but knowing they don't actually produce the device, it would stand to reason that she is speaking for the business partners; something she's done often.  With a 30 week lead time, not purchasing enough SoCs would result in some crappy results like about 7 months of constantly running out of supplies because you didn't anticipate demand.  We've discussed this before, you certainly know a lot about general things and electronics, but you are out of your zone of knowledge when it comes to real life fabrication environments.  Not that I mean to absolve B-com from all responsibility here but RS started having backlog issues well within 7 months of the pi being released.  With the firm fact that there's a 30 week lead time for the SoC, it would be impossible for the problem too have been on B-com's end as all they were doing was filling the demand that RS had already requested.

     

    Edit: Also the comment would seem to indicate that the parts being reduced by making model As is referring to the parts on hand, which again would be an issue of the one populating the board purchasing a large enough supply 7 months ago and not a matter of B-com not making enough SoCs today.

  • in reply to Former Member

    You are completely missing the point.  RPF has said clear as daylight that every Model A that could be produced would result in one less Model B being produced.  Who orders what is irrelevant.  Not enough BCM2835 devices are being produced by Broadcom, period.

     

    If you are trying to suggest that Broadcom would deliberately switch a fab line off BCM2835 devices or run it at less than full capacity despite knowing full well that the Pi is back-ordered around the world then you are painting Broadcom as incompetent and deliberately holding back the Pi ecosystem and not being interested in selling product.   After all they know with 100% certainty that every BCM2835 manufactured would be sold tomorrow if it were available.  I find it incredible that anyone would think Broadcom is that stupid and willfully losing out on revenue.  The mind boggles.

     

    So no, no, no, no.  The scarcity has absolutely nothing to do with poor order planning by one partner, because that wouldn't alter the picture even if it were true (and indeed it might be true, I'm not saying it's not, but only that it's irrelevant).  You're listening too much to RPF excuses (which you should realize operate very much as an arm of Broadcom) and not thinking about what your interpretation would say about Broadcom's commercial interest.  They are in this to make money.  If they're not printing money by churning out chips faster than they are now when they know full well that they could sell every one instantly, then you can be certain that it has nothing to do with missing paperwork.  The only answer that makes commercial sense is that they don't have any more capacity.

     

    Morgaine.