From: CEinTX <[email protected]> Reply-To: <[email protected]> Date: Thursday, June 5, 2014 at 7:22 AM To: <[email protected]> Subject: Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - Compute Module !? - Why not
> John, > > You definitely make some good points, however... > I don't really feel I missed the mark completely. > So when you say 'developer', do you mean hobbyist or product developer. > If you mean hobbyist, I understand your comments completely. > If not, that's a totally different situation entirely. If you are developing a > product for sale, > then I have little sympathy / empathy / whatever for not wanting to deal with > the > technology required to build a product. It's not cheap, easy, simple, > _________ fill in > any of a long list of adjectives to describe the difficultly of designing a > product much less > building a business around it to market and sell it. > > One is not entirely constrained by the BBB design > in doing your own - see what comes below.... > > (When I say 'you' in my comments - it's not pointed at you John but a general > you from > the community standpoint) > > I personally don't see these as problems as I've been doing this my whole > professional career. > So, yes I'm probably trivializing some of this as I don't see any of these > items as potential > stumbling blocks. > > By the BBB statements of use - this is not for commercial use. Although I know > from speaking > with Gerald, that many are using this for commercial apps. That's also one of > the reasons that > the supply is being gobbled up. So for those of you out there that are > complaining about not being > able to get BBBs, blame those that are not following the licensing and terms > of use and eating > up the supply for their commercial needs versus developing their own board. > > Here's a thought for you Gerald, require your distributors/resellers to have a > reverse discount > model. So as the volume goes up, so does the price - this should discourage > volume buys > without the organization's consent, which you are suppose to have if using > this product > commercially, and would make the distributors happy by increasing their > margins. > Or would require a custom 'factory' price to get a volume purchase at a > discount to get > around this. This is done the other way around - via product/design > registrations all the > time in the electronics distribution model. Just a thought. Gerald & Co need to keep their costs as low as possible and this doesn¹t only refer to the cost of materials and labor, but also the cost of money. Therefor they need a consistent supply model with minimal supply interruptions because the last thing they need is to sit with large inventory when the demand dries up. Don¹t mess with pricing because there could be all kinds of unintended consequences. While the inventory shortfall is really irritating to most, it is because of the demand that is helping to keep the pricing down. Gerald has to manage a find balance between delayed delivery and maintaining demand volumes. Gerald & Co are continuing to add resources to increase monthly volume and I think that is the best approach. > > So really it's suppose to be either for small non-commercial projects or using > as a shortcut > to figuring out what you need and don't to roll your own. It's not a one size > fits all or trying > to be everything to everybody - like a lot seem to think it is or should be. > So really the capes > and position of connectors, to me, are really a moot point as one is not > suppose to be relying > on this as a product platform. If it's not where you want or need for your > product - roll your own. > > Embedded system design is not for the faint of heart. You need tools and a lot > of patience to get > it done - education, experience, and skill doesn't hurt either. If you don't > have the tools or skills > needed to leverage what Gerald and Co have done here, maybe as part of your > business model, > you should have some budget for tools and an engineer or hire a design house, > um maybe like > CircuitCo or another, to help fill the void. Just a thought. If you're just a > hobbyist, then most of > this discussion is moot, because you should just try to make what's available > work or develop > a much simpler cape to do what else you need. And if that doesn't work - > you're back to roll your > own - or find a different development platform that will support your needs. I > even did a cape to > vet out what I wanted to do before starting my design. So, use the resources > available to you. > > Either using a SOM or not with this is probably not a project for a beginner. > But this is also very far > from the most complicated or demanding designs I've ever done. Even doing an > I/O board is not trivial > and that's the point I'm making. You still have a controlled impedance and > probably controlled dielectric > PCB to design and have fab'd. The I/O board will need to be a min of 4 layers > to be able to control the > impedances adequately and reliably. The diff pairs for the USB and Ethernet as > well as the MII interface do > require some work to get right - then there's the memory if you're not using > the SOM. As far as the 3 mil > min trace/space - the only part on their that needs this is the stupid eMMC. > What a poor package > design for this - following the JEDEC standard for the complete module was a > poor choice - but I digress. > I found a different package for my design so I didn't have to push the limits > of reasonable board fabrication. > My design is 5 mill trace / 4 mill space - could be 5 space if I wanted to > spend a bunch more time working > around the processor's BGA. But 5/4+ is good enough for me - some of that is > legacy from leveraging the > layout design / info from the BBB. My previous design was based on the > BeagleBoard. That was a lot more > complicated design the the BBB. But I rolled my own and went away from the POP > and did a design that > was 5/5 in 4 layers - so it is possible - just requires some effort. > > Thanks Gerald for at least making my life easier. > > So, to reiterate, the SOM has it's place - they exist and some do buy them. I > just don't think it's the really > the market segment the BeagleBoard/Bone/Black is trying to play in and support > - so I'm not at all surprised > that Gerald and the developers don't want to pursue that path. Again leverage > what Gerald has provided - he's > done a good portion of the heavy lifting - you have even been given gerbers to > be able to get it right or even just > use what he's done in many cases. If you think the SOM is really a good idea, > build one yourself and sell it - > again, Gerald has provided you with what you need to even do that. Hell, if > you want to throw some money at > me, I'd probably do the design for you - but I don't have much time for such > endeavors - so the money would > have to be larger for me to even consider it - I'm rather busy designing and > building and marketing my own > products to industry. > > As a community, do your homework/research - do your own due diligence - then > go down the path that will work > for your needs. There are a lot of people around here who are willing to help > solve problems - show what they've > done and help you get down the your path - whatever that might be. Just don't > be surprised when Gerald gets > tired / fed-up / or worse when he's kept on being asked to fit square pegs > into round holes so this organization can > become everything to everyone. > > I wish everyone in the community the best of luck in their endeavors. > > > On Wednesday, June 4, 2014 3:47:50 PM UTC-5, john3909 wrote: >> I think you missed the most important part. Most developers here are not able >> or do not want to deal with 6 layer boards with 3 mil trace and spacing (high >> tech boards). Working with 2 or 4 layer boards with 5 or 6 mil trace and >> space (standard tech boards) is low cost (< $40 in small prototype qty). As >> you pointed out, the cost to prototype and manufacture 6 layer high tech >> boards is expensive and requires a high level of expertise to make any >> modifications. As you know the cape concept doesn¹t always work because of >> the I/O conflict between capes but it would be easier to develop a standard >> tech board with all the I/O designed to work together. Also, the position of >> the connectors on the BBB may not be suitable for a specified enclosure so a >> module would provide that flexibility as well. >> >> Just my two cents worth to add a little balance to your comments. >> >> Regards, >> John >> >> From: CEinTX <[email protected] <javascript:> > >> Reply-To: <[email protected] <javascript:> > >> Date: Wednesday, June 4, 2014 at 6:41 AM >> To: <[email protected] <javascript:> > >> Subject: Re: [beagleboard] Do as Raspberry - Make a Beaglebone Black - >> Compute Module !? - Why not >> >>> Being a design engineer for close to 30 years now - doing mostly embedded >>> systems - I don't really see the appeal to this approach. >>> So - they (R-Pi) are saying the module is $30 in qty 100. A Pi is $35 - a >>> little more if you want an SD card. The BBB is $45. >>> So a compute module based on the BBB might be $35-40 based on the price >>> difference, I don't know. >>> >>> Let me get this straight, your paying just about as much just for the >>> processor and memory as you can get a complete system. >>> But you say, I want to develop my own. OK - you've just paid someone else to >>> do the processor side - you still have to have a >>> connector to make that connection to your processor. Then you get to design >>> and build your specific I/O card. >>> That, I'm sure, will be easier but at what cost. What's going to be more >>> reliable in the long run, a system with or without that connector? >>> If you've got to do the design anyway, why not save the money and keep it in >>> your pocket. >>> >>> From my experience, the people who benefit the most from the compute module/ >>> SOM approach are for those who know they need a long >>> time system life and also know that they will need to upgrade the processor >>> and memory capabilities down the road. Of course you also >>> need to be willing to accept what processor and memory choices they've made >>> - who knows maybe they will have different options for >>> different memory sizes and speeds. >>> >>> The most common place I've seen this approach in the past was with VME and >>> Multibus systems. These are expensive systems to begin with. >>> So it makes sense to be able to upgrade a portion of the system at a lower >>> cost. The only other option for this being a benefit is if someone already >>> has an I/O card that meets your requirements. Then it's off to the races. >>> How much is that I/O module? I didn't see a price, hum. Bet the two >>> combined are more than $35-$45. Also, is the compute module / SOM done to a >>> standard so that you can replace it with another down the road - even >>> a different architecture? >>> >>> I have done the cost analysis many times and most embedded systems do not >>> need the ability to upgrade the processor and memory down the road. >>> They usually have a specific purpose and once designed to that will function >>> that way for the life of the product. >>> >>> I understand that doing the processor and memory design on an embedded >>> system can be tough, challenging even, but Gerald and Co have already done >>> the lion's share of the work - leverage that effort. >>> >>> I do small runs on my projects all the time. In fact my current project is >>> an industrial temp spin on the BBB. Not 100% compatible, but that's the >>> point. >>> I'm priced out, for components and pcb, at less than $80 - I couldn't >>> justify spending $30-$40 for the processor and memory and still have to do >>> the rest. >>> Additional costs - NRE for stencils and production programming is estimated >>> at $500. Not sure what assembly/test costs will be yet, but I expect ~$20-30 >>> hopefully less. Yes, I'm just about to do my prototype on the board - so >>> I'll soon get to see what the actual costs are. >>> >>> So cost each for the 1st batch of 100 will be ~$110. Not too shabby for an >>> I-temp board in that quantity. Future runs will be less without the NRE >>> costs >>> and hopefully larger build quantities. Of course there are engineering costs >>> to be absorbed too, but that's an exercise for the accounting people to >>> figure out what budget that belongs to. >>> >>> So, yes the compute modules / SOMs are cool ideas and have their place - but >>> they are not that cost effective for most. So do your homework and see >>> if that approach will work for you and what you need. I suspect that the PI >>> community will not see the compute module as widely bought / accepted as the >>> base R-PI. I do suspect the the R-PI and the BBB will see strong sales as a >>> base platform at those price points. >>> >>> Good luck in all your endeavors. >>> >>> >>> On Wednesday, June 4, 2014 7:17:20 AM UTC-5, Gerald wrote: >>>> We are not interested in getting into the module business as a BeagleBoard >>>> branded device. Feel free to do it yourself however. All the information is >>>> there. Some people have already made these modules and are out there in the >>>> market in various forms.. >>>> >>>> Gerald >>>> >>>> >>>> >>>> On Tue, Jun 3, 2014 at 8:00 PM, <[email protected]> wrote: >>>>> I think the Raspberry idea of a compute module is a brilliant one. Now >>>>> they will be able to sell, not just to individuals but also to industry. >>>>> They will probably reach 5 mill. boards produced before the end of the >>>>> year. >>>>> >>>>> Why not do the same with Beaglebone. The profit margins could probably be >>>>> higher then on the Beaglebone Black and each extra $ could help get rid of >>>>> the terrible shortage of Beaglebone Black boards - that never seams to go >>>>> away. >>>>> >>>>> Accept that the Beaglebone Black is a huge success and that you probably >>>>> have to produce at last 50.000 boards a month to cope with the huge >>>>> demand. In the long run we'll all probably get tired of waiting for >>>>> boards, and eventually be forced to turn our attention to something else. >>>>> >>>>> /Bo >>>>> -- >>>>> For more options, visit http://beagleboard.org/discuss >>>>> --- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "BeagleBoard" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "BeagleBoard" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected] <javascript:> . >>> For more options, visit https://groups.google.com/d/optout. > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
