Prev: make opencv to work with sensoray2255
Next: ARM Cortex-M3 (Stellaris LM3S811) soft float problem (GCC/QEMU)
From: -jg on 16 Dec 2009 19:49
On Dec 15, 4:17 am, Ulf Samuelsson <u...(a)a-t-m-e-l.com> wrote:
> I am involved in some internal discussions on how the future development
> kits for high end ARM products should look like.
>
> Have some ideas, but  I would be interested in feedback from any users
> on the current crop of kits. AT91SAM926xEK etc.  General comments on
> this are also welcome.
> Remember that the SAM9 products are mostly microprocessors (non-flash)
> intended to run things like Linux/WinCE etc.

What about the ones that ARE flash based ?


>
> Feel free to comment on anything.
>
> * What do you like?
> * What don't you like?
> * Single board computer vs tool based on CPU module?
> * Memory size
> * Too hard to use because of <...>
> * I like the following feature (please keep it): <...>
> * What connectors should be available. Location of connector
> * What physical format?
> * On board JTAG vs connector for JTAG?
> * Additional peripherals wanted?
> * Developed by Atmel vs outsourcing to board vendor
> * Difficult to get components, if you want to copy the design
> * Easy to connect to external I/O functionality (or not)?

Look at the new LPCxpresso tools from NXP.

Key features:

* High Speed USB DEBUG _included_ that users
can get at. Debug pathway uses a RAM based ARM9 IIRC

* Can be sliced, to Debug/target portions.

* Price of sub $30


Now I'll admit a microprocessor kit is a looser target, as you have
RAM/Code questions, but I do get annoyed at development kits where the
Debug pathway is either crippled, or not accessible.
It just has the whiff of 'dumb design' :(

I see a number of USB-stick products, now have high density edge
connectors, and that seems a nice way to give a lot of IO choices, at
~zero base cost.
[Infineon, Rabbit, NXP..]
- others have 0.1" pitch holes, for easy piggyback
deployment.

Small size seems a key element in low cost, so
focus on small size first.

-jg
From: Joerg on 17 Dec 2009 18:53
Ulf Samuelsson wrote:
> D Yuniskis skrev 2009-12-16 22:20:
>> Ulf Samuelsson wrote:

[...]

>>> * Too hard to use because of <...>
>>> * I like the following feature (please keep it): <...>
>>> * What connectors should be available. Location of connector
>>> * What physical format?
>>
>> CPU module. Something that makes it easy for folks to
>> prototype around (i.e., no BGAs).
>
> There are some chips which are available in TQFP208.
> These packages are very large compared to BGA.
>

I can't contribute much feedback in this thread because I am not really
an embedded guy. Well, only at night :-)

There are lots of applications that are exposed to rough environments.
Flexing, acceleration, deceleration (like a 50G smack), vibration. So
folks like myself try their darndest not to use BGA. IOW if a chip was
only available in BGA I'd go and look for another one that comes in
flatpack. And I'd prefer to test stuff with the right package right off
the bat, if possible. Occasionally eval/development boards are tested on
the actual system (vehicle etc.) which then is tested in the environment
it's marketed for.

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
From: D Yuniskis on 18 Dec 2009 01:06
[bits elided]

Ulf Samuelsson wrote:
> D Yuniskis skrev 2009-12-16 22:20:
>> Ulf Samuelsson wrote:
>>> I am involved in some internal discussions on how the future
>>> development kits for high end ARM products should look like.
>>>
>>> Have some ideas, but I would be interested in feedback from any
>>> users on the current crop of kits. AT91SAM926xEK etc. General
>>> comments on this are also welcome.
>>> Remember that the SAM9 products are mostly microprocessors
>>> (non-flash) intended to run things like Linux/WinCE etc.

>>> * What don't you like?
>>> * Single board computer vs tool based on CPU module?
>>
>> CPU module. Chances are I will *not* be using any of the I/Os
>> you are going to waste time, money and real estate implementing.
>> Make an OPTIONAL cheap passive backplane into which the module
>> can plug so folks can use PCI cards for the I/Os they might
>> want (purchased off the shelf from commodity vendors instead
>> of a low volume "specialty" manufacturer like atmel).
>
> The current crop of Evaluation Kits are just that.
> They are not Development Kits, allowing you to run your own application
> before you have your own hardware. A weakness, in my opinion.
>
> PCI connectors have crossed my mind.
> Not with a real PCI bus, since the AT91 processors don't have that,
> but rather a mix of serial peripherals like UART, SPI , I2C, SSC etc
> made available on multiple connectors using the same connectors as the
> PCI bus.
>
> I think that I have seen 1 customer out of maybe 400 Atmel ARM9 customers
> which has put a PCI bus in their own design, so this is not something
> people will find useful.
> I do think personally it would make sense to have AT91's with PCI or PCI
> Express,
> and then of course a development board should allow connections to
> standard cards.
> I think especially WLAN would be nice to add this way,.

My intent might not have been clear... :<

Here's one scenario:
- user plugs your "module" into a "motherboard" (lets not
get pedantic on terminology here) that *you* manufacture
and sell at a *reasonable* price (i.e., not what you think it
is *worth* to the user in terms of the work fabricating
something like this that it allegedly SAVES him -- since NOT
USING YOUR PRODUCT AT ALL will save him that work/money just
as easily -- but, rather, "for *your* DM+DL on that item")
- user grabs some number of COTS PCI cards and plugs them
into that motherboard (perhaps a gigabit NIC, a SATA controller,
a BT transceiver, etc.)
- user links/loads the sample drivers provided for those cards
to his application
User now has a viable platform for investigating the suitability
of your processor to his intended application *without* having
to spend much time or money hacking together "one off" prototypes
of his hardware.

The user obviously knows that any real hardware that he develops
will have a different cost basis than this "prototype". Just like
he knows it will have a different physical form factor, etc.

And, he knows that any software deployed on that final hardware
will have different performance characteristics.

But, he can *quickly* decide if pursuing a solution based on
your product makes sense to him. And, he doesn't have to make
a huge investment (time *or* money) to come to that decision.

If he decides to pursue this approach, this crude prototype
enables some software development to begin immediately.
Concurrently, *real* hardware can be in the works that will
allow the development effort to migrate to the "final"
target more quickly.

OTOH, users who don't fit this collection of COTS I/O's can
design a daughtercard (a mother-of-a-different name?) with
their I/Os and just piggyback your "module" onto/into it.

> In the end, I think there is a better solution, which will provide
> the pins to standardized connectors, instead of committing them to
> different kind of physical interfaces like RS232, EEPROM etc.
>
> It is a twist of the old 10 pin header available on the STK500.
> Instead of putting just the I/O ports out on each header,
> I would like to standardize the use of the header.
> I:E: UART.TXD is ALWAYS on pin 0 of a header.
> UART.RXD is ALWAYS on pin 1 of a header.
> I2C.SDA is ALWAYS on pin 7 of a header etc.
>
> When multiplexing allows it, you may have several functions per header,
> otherwise you could have a backplace with 5 UART headers, 4 SPI headers
> and 2 I2C headers etc.

I don't see that buying you -- or your user -- much of anything.
Use an *existing* standardized connector: PCI. Connect at a
much higher level, architecturally.

Connecting some level translators and a DB9/25 to a "standardized
header" saves you an hour or two of a technician's time (?).
You're saving "crumbs" and missing the Main Event.

When you have to design a strain gauge amplifier with A/DC
interface to that card of yours, those few man-hours are going
to be insignificant. OTOH, if the user can just *buy* a COTS
DAS card and plug it into some "Industry Standard" interconnect
mechanism (i.e., a PCI bus), then you have saved man-*months*.

>> Port some open source drivers (preferably NOT GPL'ed) for
>> a few industry standard cards to this "motherboard+module"
>> so folks can see how they can merge those hardware features
>> into their designs.
>
> Until there is a real PCI bus, there won't be any industry standard cards.

And who better than to undertake the cost of designing and
implementing that sort of *bridge* adapter (that will
probably NEVER have any chance of commercial success as a
"product" of its own) than the company who most stands
to benefit from it??

I.e., that "motherboard" design mentioned earlier will never
be the basis for a real product (well, I should learn never
to say "never" :> ). It is a cost of doing business for
you. A means of making it easier for users to investigate,
evaluate and *develop* products using your components.

Why do you think so many products end up x86-based? Because
it is just *so* easy to slap together something using a PC
as a development target. (You yourself said this uP is
targeted for "folks running Linux" and not "folks designing
microwave oven controllers"). I've been developing under
a PC target with *no* intention of deploying on that
architecture -- simply because I can piece together all
of the various I/O that I need (along with drivers) so
much easier using that "Standardized Interconnect" bus.
If I decide the network interface is just not going to be
fast enough using a given technology (e.g., 10 vs 100 vs 1000)
then I can just swap out a card without having to spend
months designing and debugging another "one off" prototype
with a *different* network interface :-/

>>> * Memory size
>>
>> DIMMs. Let the customer provide his own. *OR*, sell industry
>> standard DIMMs to the customer AT VOLUME PRICES despite the one-off
>> quantities.
>
> DIMMs are driven by the PC market and they are usually 64 bit or wider.
> A 64 bit DIMM would waste half the memory.
> With DDR-2, the AT91 interface is 16 bit, so you then waste 75%
> (I don't know, but I assume DDR2 DIMMs are still 64 bit).

So what? If the user wastes 98% of a part that he has lying in his
desk drawer, it's 98% of $0 that's wasted. And, he can chose to
waste 98% of a DIMM that is twice as large 10 minutes from now
(instead of wondering how he is going to get another few megabytes
onto this "custom" development board)

*I* can swap out a DIMM as easily as I can swap out a 100TX NIC
for a gigabit NIC. I don't need to get my boss/client involved.
I don't need to get purchasing involved. I don't need to wait
weeks (?) for atmel to process my order and ship the "special"
parts that I need. So, I can see what happens in a new
configuration without spending anything (money or prestige)
to do so.

> An old style DIMM connector optimized for 32 bit and custom memory
> module, would allow the user to build a prototype using their own
> preferred memory vendor.
>
> I don't think it makes sense to use DIMM if you have a CPU module.
>
>>> * Too hard to use because of <...>
>>> * I like the following feature (please keep it): <...>
>>> * What connectors should be available. Location of connector
>>> * What physical format?
>>
>> CPU module. Something that makes it easy for folks to
>> prototype around (i.e., no BGAs).
>
> There are some chips which are available in TQFP208.
> These packages are very large compared to BGA.

Yes. But prototyping with BGAs is a PITA. I can layout
a board and have it assembled by a technician here if I
avoid BGAs. And, have it in my hands very quickly.
And, run through another iteration just as quickly.
With BGAs, it has to be fabbed outside. It gets more
involved (read: management, purchasing) to do that.
So, you don't want to do it often -- lest folks start
raising eyebrows wondering why you are "wasting" all
this money, etc.

> I think it may make sense to deliver a CPU module with
> large amounts of SDRAM, and a small dataflash,
> with empty pads for adding large parallel NOR
> as well as the NAND flash of your choice
> in TSOP so that they can be handsoldered to the module.

Why stop there? I.e., decide what your philosphy is
going to be and then just stick to *that*. If you think
the user *needs* flash on the module, then *put* flash
on the module. If you think the user will provide
his own flash on a duaghtercard (or, my personal preference,
leave the flash out entirely and just treat ram as flash),
then why waste real estate on an option?

>>> * Additional peripherals wanted?
>>
>> None. Move them onto daughtercard(s) or motherboard.
> I see a CPU module containing
> * CPU,
> * SDRAM,
> * Flash,
> * Power Management
> * Ethernet PHY.
> * Possible a tiny 8 bit controller doing systems control
> * Battery
> * Optional Micro-SD card connector.

Again, you're engaging in feeping creaturism. Put those
things that *must* be there on the card. And, those things
that are really hard to do "off card" (e.g., one of the Cirrus
processors I used had a VCO for some of the video timing;
moving this onto a daughter card would have been a nuisance)
Those things that a user might chose *not* to use don't
belong on the card (unless you can do it for *zero* cost
and zero *space*/power).

I.e., why not include a power supply on the card, too? :<

>>> * Developed by Atmel vs outsourcing to board vendor
>>
>> I doubt folks would care too much -- it depends on how
>> atmel treats it in terms of pricing. I.e., if it becomes
>> a cost center that has to pay for itself, then it will be
>> far too pricey. OTOH, if atmel considers it a loss leader
>> and sells it for "the price of the components" (using
>> big volume pricing) then you'll find people more willing
>> to "give it a try".
>>
>> From comments in other thread here, it seems like this
>> might be anathema to atmel. If *smaples* are so hard to
>> come by, I suspect an *inexpensive* development kit
>> would be likewise.
>
> Low cost development kits has generally been the AVR realm
> and usually there are no problems getting hold of these kits
> at low cost or as giveaways.
>
> Theoretically there should not be a problem getting hold of these kits.
> Atmel like most electronics companies outsource to CEMs,
> sometimes you are at the mercy of their whims.

Perhaps you should consider a different marketing/sales model?

>> Think about the folks that are likely to be buying this:
>>
>> For large corporate users (possibly with deep pockets),
>> there is often a lot of bureaucracy in the way to making
>> a purchase. The last set of development tools I purchased
>> in such an environment took three months to run the paperwork:
>> "And *why* do we need this...?"
> Yes, people are aware of this.
> Ideally, you should only have to ask your personal manager for approval.

No. Ideally I shouldn't have to ask *anyone* for approval!
I.e., if it was cheap enough I could buy one out of my own
pocket, play with it and *then* decide to make a pitch for
a design-in based on it. That's where the PICs have made
a big impact. I don't think most folks like them. But,
they play with one at home. Or, at school. And its no
surprise that when they get into a position where they
have to make an engineering recommendation, they go with
something they already *know*.

No, I don't think many folks are going to reach into
their own pockets just to avoid dealing with their boss
or purchasing department. But, if your price point is set
that low that this is *possible*, then it is highly likely
that your boss won't feel like he is sticking his neck
out putting through a request for something like this.

> If it has to go 2-3 levels up, there is a lot of resistance in the system,
> which does not gain the vendor, nor the engineer.
>
> All things sold on TV-Shop is normally so cheap that you can buy
> without asking your spouse. Peg Bundy not counted.

Atmel has to decide what business they are in: selling
components or selling development tools and components.
If you consider tools to be a product and expect to make
money off them, then you approach them with an entirely
different mindset than if you consider the tools just
a means for selling components.

I did some work on a device that cost a few hundred dollars
to manufacture (DM+DL). It was priced at several *thousand*
dollars -- and *none* were ever sold! They were intentionally
given away to sell *other* products that had even more
promising profit margins and volumes. I.e., like giving away
gold plated toilet paper dispensers -- in order to sell
the toilet paper that is used in them!

> Things should be as cheap as possible, but not cheaper.

This all depends on what you consider as part of your
"cost". I.e., *I* see tools as a cost of doing business
so their "cost", IMO, is DM+DL. There is no "profit"
inherent in them. They have a role in selling other
items that drive the profits. If, OTOH, some bean counter
there wants to amortize the cost of developing the
hardware for your "module" over the total quantity of
modules that will be sold, then there is a huge accounting
cost reflected in your "cost" -- one that might make sense
when compared to the cost for a company that *wants* to
use your product and undertakes development of a platform
on which to evaluate it. The problem here is that if
some *other* company has a lower "cost" (because they
sell more of these development kits, or because they
underwrite their costs for developing them), then you
are at a terrible disadvantage.

>> I'm not fond of Microchip parts. It seems like we're
>> still living in the days of GI! :< But, they *do* seem to
>> have the right idea when it comes to development tools
>> and kits. Consider the cost of designing, building, selling
>> and supporting those tools just "part of the cost of
>> doing business" (i.e. SWALLOW IT!) and you'll probably
>> win more designs in the long run.
>
> That's the AVR strategy.
> For ARM, there is a lot of third parties so there is not a lot of S/W
> tools development for OS/Compilers etc. Only programming S/W and drivers.
> ..
> The typical simpler boards are like $500-800, which is one level
> above your typical first level manager signoff,
> but that seems to be low enough, for this not to be a problem.

Faced with exactly these sorts of numbers, I opted for the
"lets explore the application on a cheap platform -- a PC -- and
see if it makes sense before throwing money and time after
a *prorpietary* platform". For $800, most develppers
would probably rather have their boss buy them a new PC!

> It is fairly easy to borrow boards, and sales guys tend to
> give away to major customer anyway.

And if you aren't a major customer, tough luck. So, you
effectively limit how many *new* customers you gain.
As each time the customer has to make a choice for a
new product, they have to go through this analysis
again. And the politics, etc. (and, if you discontinue
products, you just exacerbate the problem and your
reputation within the company -- "Didn't we just buy
one of those things LAST year?")

> I think that if the boards could be brought down to below $300
> it would be good, but you also would like to have a lower price point.

When you go to your local department store, do they charge
you for parking? Do they charge you if you take a drink
from their water fountain? Or, use their bathroom facilities?
They consider these costs of doing business. Indeed, those
stores at which the patron must pay to park (i.e., because the
store itself has no parking to offer) tend to pay a price
in terms of sales volume: if you can find the products
that they sell offered elsewhere, you *buy* elsewhere. It
is particularly annoying to pay to park at such a store
and then discover that the products they offer don't fit
your needs (i.e., I have wasted money *and* time -- like
buying an overpriced development tool, spending time
evaluating the device in my application, and *then*
discovering that it is unsuitable for my needs: anyone
want to buy a slightly used boat anchor?)

> The ATNGW100 with an AP7000 (AVR32) processor sells for less
> than $100 and has 32 MB of SDRAM and 16 MB of Flash and runs Linux.
>
> The big difference here, I think, is that the guys working on the 32 bit
> AVRs deciced for low price in the beginning, and ordered
> in volumes high enough, that allowed them to get price breaks.
> If you order 100 boards here, 100 boards there, the price of
> components (non-Atmel) becomes signifiant.

Again, it depends on how you look at this activity in the
Grand Scheme. No doubt, your sales force "treats" clients
to free lunches. They think nothing of spending hundreds
of dollars weekly doing this (for each sales person).
So, clearly, they have decided that this is a necessary
cost of doing business. It is reflected (indirectly) in
the prices charged for the parts that are eventually sold.

I'm saying, treat the development tools in the exact same
manner. No, you don't have to *give* them away (though you
don't mind giving away meals!). But, pricing them at
DM+DL -- or, even better, DM! :> -- makes it clear to the
purchaser that you aren't trying to make money off of
this as a "product". Instead, it's "sales support"
(like free lunches, tech support, etc. -- do you charge
$3.95 per minute for your tech support hotline?? :> )

> I've seen Freescale sell their iMX25 development kit for $1500,
> and that is of course much worse.

And there are some folks who will buy. And a lot who won't.
What this says is they either think they have a monopoly on
this particular sort of device in the market *currently*;
or, they are happy with the number of customers that they
have and their sales volumes.

>> After all, isn't *that* what you REALLY want??
>
> There is always someone at the top that rather take the money.

Yup. And that works. Sometimes. And in some markets.
But, when it doesn't, its awful hard to regain a good
reputation as being "in partnership with" your customer.

I look at the businesses that I, as a consumer, "enjoy"
doing business with. And those that I don't. It is
easy to see the things that the "good" have in common and
how they differ with the "bad". The latter seem to always
be trying to figure out how to nickel and dime me -- "sorry,
you can't return that without a receipt", "sorry, the sale
ended yesterday", "Sorry, you will have to talk to the
manufacturer to handle that defect"... OTOH, the former
seem like they are working *with* me: "well, there is a
two item limit clearly printed on this coupon, but I'll let
you have three at that price", "yes, the sale was over
yesterday but I'm sure if we could afford to sell it for
that price yesterday, we can probably sell it for that
price today -- let me get a manager to approve this for me"

My goal as a *vendor* is to keep my customers thinking of
me in that former case and not the latter...
From: Ulf Samuelsson on 18 Dec 2009 11:30
D Yuniskis skrev 2009-12-18 07:06:
> [bits elided]
>
> Ulf Samuelsson wrote:
>> D Yuniskis skrev 2009-12-16 22:20:
>>> Ulf Samuelsson wrote:
>>>> I am involved in some internal discussions on how the future
>>>> development kits for high end ARM products should look like.
>>>>
>>>> Have some ideas, but I would be interested in feedback from any
>>>> users on the current crop of kits. AT91SAM926xEK etc. General
>>>> comments on this are also welcome.
>>>> Remember that the SAM9 products are mostly microprocessors
>>>> (non-flash) intended to run things like Linux/WinCE etc.
>
>>>> * What don't you like?
>>>> * Single board computer vs tool based on CPU module?
>>>
>>> CPU module. Chances are I will *not* be using any of the I/Os
>>> you are going to waste time, money and real estate implementing.
>>> Make an OPTIONAL cheap passive backplane into which the module
>>> can plug so folks can use PCI cards for the I/Os they might
>>> want (purchased off the shelf from commodity vendors instead
>>> of a low volume "specialty" manufacturer like atmel).
>>
>> The current crop of Evaluation Kits are just that.
>> They are not Development Kits, allowing you to run your own application
>> before you have your own hardware. A weakness, in my opinion.
>>
>> PCI connectors have crossed my mind.
>> Not with a real PCI bus, since the AT91 processors don't have that,
>> but rather a mix of serial peripherals like UART, SPI , I2C, SSC etc
>> made available on multiple connectors using the same connectors as
>> the PCI bus.
>>
>> I think that I have seen 1 customer out of maybe 400 Atmel ARM9
>> customers
>> which has put a PCI bus in their own design, so this is not something
>> people will find useful.
>> I do think personally it would make sense to have AT91's with PCI or
>> PCI Express,
>> and then of course a development board should allow connections to
>> standard cards.
>> I think especially WLAN would be nice to add this way,.
>
> My intent might not have been clear... :<
>
> Here's one scenario:
> - user plugs your "module" into a "motherboard" (lets not
> get pedantic on terminology here) that *you* manufacture
> and sell at a *reasonable* price (i.e., not what you think it
> is *worth* to the user in terms of the work fabricating
> something like this that it allegedly SAVES him -- since NOT
> USING YOUR PRODUCT AT ALL will save him that work/money just
> as easily -- but, rather, "for *your* DM+DL on that item")
> - user grabs some number of COTS PCI cards and plugs them
> into that motherboard (perhaps a gigabit NIC, a SATA controller,
> a BT transceiver, etc.)
> - user links/loads the sample drivers provided for those cards
> to his application
> User now has a viable platform for investigating the suitability
> of your processor to his intended application *without* having
> to spend much time or money hacking together "one off" prototypes
> of his hardware.
This is something I agree with, except for the PCI bus.
You want to be able do look at a specification, and and then
design a prototype around off the shelf components.
For this you need to have I/O expansion on the motherboard,
and lots of different I/O expansion cards.
I think the expansion units should have a serial interface like
SPI, I2C, UART, SDIO etc, instead of PCI
until there are AT91 parts available with on board PCI.
Onboard PCI Express is high on my wishlist for future parts.

> The user obviously knows that any real hardware that he develops
> will have a different cost basis than this "prototype". Just like
> he knows it will have a different physical form factor, etc.
>
Yes.

> And, he knows that any software deployed on that final hardware
> will have different performance characteristics.
>
> But, he can *quickly* decide if pursuing a solution based on
> your product makes sense to him. And, he doesn't have to make
> a huge investment (time *or* money) to come to that decision.
> If he decides to pursue this approach, this crude prototype
> enables some software development to begin immediately.
> Concurrently, *real* hardware can be in the works that will
> allow the development effort to migrate to the "final"
> target more quickly.
>

Fully agree.

> OTOH, users who don't fit this collection of COTS I/O's can
> design a daughtercard (a mother-of-a-different name?) with
> their I/Os and just piggyback your "module" onto/into it.
Yep.

>> In the end, I think there is a better solution, which will provide
>> the pins to standardized connectors, instead of committing them to
>> different kind of physical interfaces like RS232, EEPROM etc.
>>
>> It is a twist of the old 10 pin header available on the STK500.
>> Instead of putting just the I/O ports out on each header,
>> I would like to standardize the use of the header.
>> I:E: UART.TXD is ALWAYS on pin 0 of a header.
>> UART.RXD is ALWAYS on pin 1 of a header.
>> I2C.SDA is ALWAYS on pin 7 of a header etc.
>>
>> When multiplexing allows it, you may have several functions per header,
>> otherwise you could have a backplace with 5 UART headers, 4 SPI headers
>> and 2 I2C headers etc.
>
> I don't see that buying you -- or your user -- much of anything.
> Use an *existing* standardized connector: PCI. Connect at a
> much higher level, architecturally.

If all you want to do is to add an RS485 PHY, PCI is way overkill
If you have a serial connector where you can add this PHY,
then this will be easy to design, and you can start S/W development
immediately, while the PCI solution would force you to do driver development
on something which is not useful in the end product.

> Connecting some level translators and a DB9/25 to a "standardized
> header" saves you an hour or two of a technician's time (?).
> You're saving "crumbs" and missing the Main Event.
>
> When you have to design a strain gauge amplifier with A/DC
> interface to that card of yours, those few man-hours are going
> to be insignificant. OTOH, if the user can just *buy* a COTS
> DAS card and plug it into some "Industry Standard" interconnect
> mechanism (i.e., a PCI bus), then you have saved man-*months*.
If you decide that you can build your prototype without regards to drivers
etc. then you might as well put an embedded PC there for the prototype,
develop the application on that box, and then port the whole thing later.
I think you will be too far away from the end product that it wont make
a lot of difference.

>>> Port some open source drivers (preferably NOT GPL'ed) for
>>> a few industry standard cards to this "motherboard+module"
>>> so folks can see how they can merge those hardware features
>>> into their designs.
>>
>> Until there is a real PCI bus, there won't be any industry standard
>> cards.
>
> And who better than to undertake the cost of designing and
> implementing that sort of *bridge* adapter (that will
> probably NEVER have any chance of commercial success as a
> "product" of its own) than the company who most stands
> to benefit from it??

Better to design a chip with PCI (Express) built in and then you have
a natural solution.

> I.e., that "motherboard" design mentioned earlier will never
> be the basis for a real product (well, I should learn never
> to say "never" :> ). It is a cost of doing business for
> you. A means of making it easier for users to investigate,
> evaluate and *develop* products using your components.
> Why do you think so many products end up x86-based? Because
> it is just *so* easy to slap together something using a PC
> as a development target. (You yourself said this uP is
> targeted for "folks running Linux" and not "folks designing
> microwave oven controllers"). I've been developing under
> a PC target with *no* intention of deploying on that
> architecture -- simply because I can piece together all
> of the various I/O that I need (along with drivers) so
> much easier using that "Standardized Interconnect" bus.
> If I decide the network interface is just not going to be
> fast enough using a given technology (e.g., 10 vs 100 vs 1000)
> then I can just swap out a card without having to spend
> months designing and debugging another "one off" prototype
> with a *different* network interface :-/
>>>> * Memory size
>>>
>>> DIMMs. Let the customer provide his own. *OR*, sell industry
>>> standard DIMMs to the customer AT VOLUME PRICES despite the one-off
>>> quantities.
>>
>> DIMMs are driven by the PC market and they are usually 64 bit or wider.
>> A 64 bit DIMM would waste half the memory.
>> With DDR-2, the AT91 interface is 16 bit, so you then waste 75%
>> (I don't know, but I assume DDR2 DIMMs are still 64 bit).
>
> So what? If the user wastes 98% of a part that he has lying in his
> desk drawer, it's 98% of $0 that's wasted. And, he can chose to
> waste 98% of a DIMM that is twice as large 10 minutes from now
> (instead of wondering how he is going to get another few megabytes
> onto this "custom" development board)
> *I* can swap out a DIMM as easily as I can swap out a 100TX NIC
> for a gigabit NIC. I don't need to get my boss/client involved.
> I don't need to get purchasing involved. I don't need to wait
> weeks (?) for atmel to process my order and ship the "special"
> parts that I need. So, I can see what happens in a new
> configuration without spending anything (money or prestige)
> to do so.


Yes,
An alternative approach would be to equip the development board
with the maximum supportable DRAM size.
Today, you can only put 256 MB of DRAM on the AT91
bus, so if you put that, then there is no need for a DIMM.
If you put a DIMM there, then you need to be able to support
different variations of memories.
The way the AT91 bootROM works, you load a piece of code
from a flash into internal SRAM, and execute it.
The SRAM can be as small as 4 kB, and the application needs
to do various things. That small space is pretty crammed.

Personally, I do not think the idea suits a CPU module, because
you can get another CPU module with more memory
and when you design that CPU module, you probably wants
to have something which is suitable for production, to bring the price down.

If the DRAM controller is expanded to allow a lot more memory,
then the DIMM ideas should be considered.
I know Atmel used DIMMs on some dev kits (CAP9).



>> An old style DIMM connector optimized for 32 bit and custom memory
>> module, would allow the user to build a prototype using their own
>> preferred memory vendor.
>>
>> I don't think it makes sense to use DIMM if you have a CPU module.
>>
>>>> * Too hard to use because of <...>
>>>> * I like the following feature (please keep it): <...>
>>>> * What connectors should be available. Location of connector
>>>> * What physical format?
>>>
>>> CPU module. Something that makes it easy for folks to
>>> prototype around (i.e., no BGAs).
>>
>> There are some chips which are available in TQFP208.
>> These packages are very large compared to BGA.
>
> Yes. But prototyping with BGAs is a PITA. I can layout
> a board and have it assembled by a technician here if I
> avoid BGAs. And, have it in my hands very quickly.
> And, run through another iteration just as quickly.
> With BGAs, it has to be fabbed outside. It gets more
> involved (read: management, purchasing) to do that.
> So, you don't want to do it often -- lest folks start
> raising eyebrows wondering why you are "wasting" all
> this money, etc.

If you do a CPU module, one of the reasons is that you provide
them with something that does not need to change.
If a motherboard + module is available, the end customer can do
new modules with whatever they want including AT91's
with TQFP packages.

>
>> I think it may make sense to deliver a CPU module with
>> large amounts of SDRAM, and a small dataflash,
>> with empty pads for adding large parallel NOR
>> as well as the NAND flash of your choice
>> in TSOP so that they can be handsoldered to the module.
>
> Why stop there? I.e., decide what your philosphy is
> going to be and then just stick to *that*. If you think
> the user *needs* flash on the module, then *put* flash
> on the module. If you think the user will provide
> his own flash on a duaghtercard (or, my personal preference,
> leave the flash out entirely and just treat ram as flash),
> then why waste real estate on an option?
>

You will always need some amount of flash, and the dataflash will cover
that need.

Then customers want to check out different kinds of other flash memories,
and they can either design their own board, or solder some samples to a
module.


>>>> * Additional peripherals wanted?
>>>
>>> None. Move them onto daughtercard(s) or motherboard.
>> I see a CPU module containing
>> * CPU,
>> * SDRAM,
>> * Flash,
>> * Power Management
>> * Ethernet PHY.
>> * Possible a tiny 8 bit controller doing systems control
>> * Battery
>> * Optional Micro-SD card connector.
>
> Again, you're engaging in feeping creaturism. Put those
> things that *must* be there on the card. And, those things
> that are really hard to do "off card" (e.g., one of the Cirrus
> processors I used had a VCO for some of the video timing;
> moving this onto a daughter card would have been a nuisance)
> Those things that a user might chose *not* to use don't
> belong on the card (unless you can do it for *zero* cost
> and zero *space*/power).

I think that all these things are neccessary with the exception of the
MicroSD card connector.
This is howerever the same thing as your DIMM idea.
Adding the MicroSD connector will allow the use to put significant
amount of flash
and the size is of his own choosing.

The idea, would be to have something that would be useful in a real product.

..
> I.e., why not include a power supply on the card, too? :<
>

>>>> * Developed by Atmel vs outsourcing to board vendor
>>>
>>> I doubt folks would care too much -- it depends on how
>>> atmel treats it in terms of pricing. I.e., if it becomes
>>> a cost center that has to pay for itself, then it will be
>>> far too pricey. OTOH, if atmel considers it a loss leader
>>> and sells it for "the price of the components" (using
>>> big volume pricing) then you'll find people more willing
>>> to "give it a try".
>>>
>>> From comments in other thread here, it seems like this
>>> might be anathema to atmel. If *smaples* are so hard to
>>> come by, I suspect an *inexpensive* development kit
>>> would be likewise.
>>
>> Low cost development kits has generally been the AVR realm
>> and usually there are no problems getting hold of these kits
>> at low cost or as giveaways.
>>
>> Theoretically there should not be a problem getting hold of these kits.
>> Atmel like most electronics companies outsource to CEMs,
>> sometimes you are at the mercy of their whims.
>
> Perhaps you should consider a different marketing/sales model?
Like what?
>
>>> Think about the folks that are likely to be buying this:
>>>
>>> For large corporate users (possibly with deep pockets),
>>> there is often a lot of bureaucracy in the way to making
>>> a purchase. The last set of development tools I purchased
>>> in such an environment took three months to run the paperwork:
>>> "And *why* do we need this...?"
>> Yes, people are aware of this.
>> Ideally, you should only have to ask your personal manager for approval.
>
> No. Ideally I shouldn't have to ask *anyone* for approval!
> I.e., if it was cheap enough I could buy one out of my own
> pocket, play with it and *then* decide to make a pitch for
> a design-in based on it. That's where the PICs have made
> a big impact. I don't think most folks like them. But,
> they play with one at home. Or, at school. And its no
> surprise that when they get into a position where they
> have to make an engineering recommendation, they go with
> something they already *know*.
>
> No, I don't think many folks are going to reach into
> their own pockets just to avoid dealing with their boss
> or purchasing department. But, if your price point is set
> that low that this is *possible*, then it is highly likely
> that your boss won't feel like he is sticking his neck
> out putting through a request for something like this.

I think that the signature level you want to reach is below $300 or so.
I don't see a Linux capable board at less than $75.
>
>> If it has to go 2-3 levels up, there is a lot of resistance in the
>> system,
>> which does not gain the vendor, nor the engineer.
>>
>> All things sold on TV-Shop is normally so cheap that you can buy
>> without asking your spouse. Peg Bundy not counted.
>
> Atmel has to decide what business they are in: selling
> components or selling development tools and components.
> If you consider tools to be a product and expect to make
> money off them, then you approach them with an entirely
> different mindset than if you consider the tools just
> a means for selling components.

Atmel are in both businesses, it is depending on the group.

> I did some work on a device that cost a few hundred dollars
> to manufacture (DM+DL). It was priced at several *thousand*
> dollars -- and *none* were ever sold! They were intentionally
> given away to sell *other* products that had even more
> promising profit margins and volumes. I.e., like giving away
> gold plated toilet paper dispensers -- in order to sell
> the toilet paper that is used in them!
>
>> Things should be as cheap as possible, but not cheaper.
>
> This all depends on what you consider as part of your
> "cost". I.e., *I* see tools as a cost of doing business
> so their "cost", IMO, is DM+DL. There is no "profit"
> inherent in them. They have a role in selling other
> items that drive the profits. If, OTOH, some bean counter
> there wants to amortize the cost of developing the
> hardware for your "module" over the total quantity of
> modules that will be sold, then there is a huge accounting
> cost reflected in your "cost" -- one that might make sense
> when compared to the cost for a company that *wants* to
> use your product and undertakes development of a platform
> on which to evaluate it. The problem here is that if
> some *other* company has a lower "cost" (because they
> sell more of these development kits, or because they
> underwrite their costs for developing them), then you
> are at a terrible disadvantage.
>
>>> I'm not fond of Microchip parts. It seems like we're
>>> still living in the days of GI! :< But, they *do* seem to
>>> have the right idea when it comes to development tools
>>> and kits. Consider the cost of designing, building, selling
>>> and supporting those tools just "part of the cost of
>>> doing business" (i.e. SWALLOW IT!) and you'll probably
>>> win more designs in the long run.
>>
>> That's the AVR strategy.
>> For ARM, there is a lot of third parties so there is not a lot of S/W
>> tools development for OS/Compilers etc. Only programming S/W and
>> drivers.
>> ..
>> The typical simpler boards are like $500-800, which is one level
>> above your typical first level manager signoff,
>> but that seems to be low enough, for this not to be a problem.
>
> Faced with exactly these sorts of numbers, I opted for the
> "lets explore the application on a cheap platform -- a PC -- and
> see if it makes sense before throwing money and time after
> a *prorpietary* platform". For $800, most develppers
> would probably rather have their boss buy them a new PC!
>
>> It is fairly easy to borrow boards, and sales guys tend to
>> give away to major customer anyway.
>
> And if you aren't a major customer, tough luck. So, you
> effectively limit how many *new* customers you gain.
> As each time the customer has to make a choice for a
> new product, they have to go through this analysis
> again. And the politics, etc. (and, if you discontinue
> products, you just exacerbate the problem and your
> reputation within the company -- "Didn't we just buy
> one of those things LAST year?")

If I look at the number of design for ARM9, then
I think that the market can bear those prices.
If we are talking flash based micros, 8 or 32 bit,
then $500 is way, way too high.

>
>> I think that if the boards could be brought down to below $300
>> it would be good, but you also would like to have a lower price point.
>
> When you go to your local department store, do they charge
> you for parking? Do they charge you if you take a drink
> from their water fountain? Or, use their bathroom facilities?
> They consider these costs of doing business. Indeed, those
> stores at which the patron must pay to park (i.e., because the
> store itself has no parking to offer) tend to pay a price
> in terms of sales volume: if you can find the products
> that they sell offered elsewhere, you *buy* elsewhere. It
> is particularly annoying to pay to park at such a store
> and then discover that the products they offer don't fit
> your needs (i.e., I have wasted money *and* time -- like
> buying an overpriced development tool, spending time
> evaluating the device in my application, and *then*
> discovering that it is unsuitable for my needs: anyone
> want to buy a slightly used boat anchor?)
>
>> The ATNGW100 with an AP7000 (AVR32) processor sells for less
>> than $100 and has 32 MB of SDRAM and 16 MB of Flash and runs Linux.
>>
>> The big difference here, I think, is that the guys working on the 32 bit
>> AVRs deciced for low price in the beginning, and ordered
>> in volumes high enough, that allowed them to get price breaks.
>> If you order 100 boards here, 100 boards there, the price of
>> components (non-Atmel) becomes signifiant.
>
> Again, it depends on how you look at this activity in the
> Grand Scheme. No doubt, your sales force "treats" clients
> to free lunches. They think nothing of spending hundreds
> of dollars weekly doing this (for each sales person).
> So, clearly, they have decided that this is a necessary
> cost of doing business. It is reflected (indirectly) in
> the prices charged for the parts that are eventually sold.
>
> I'm saying, treat the development tools in the exact same
> manner. No, you don't have to *give* them away (though you
> don't mind giving away meals!). But, pricing them at
> DM+DL -- or, even better, DM! :> -- makes it clear to the
> purchaser that you aren't trying to make money off of
> this as a "product". Instead, it's "sales support"
> (like free lunches, tech support, etc. -- do you charge
> $3.95 per minute for your tech support hotline?? :> )
>
>> I've seen Freescale sell their iMX25 development kit for $1500,
>> and that is of course much worse.
>
> And there are some folks who will buy. And a lot who won't.
> What this says is they either think they have a monopoly on
> this particular sort of device in the market *currently*;
> or, they are happy with the number of customers that they
> have and their sales volumes.
>
>>> After all, isn't *that* what you REALLY want??
>>
>> There is always someone at the top that rather take the money.
>
> Yup. And that works. Sometimes. And in some markets.
> But, when it doesn't, its awful hard to regain a good
> reputation as being "in partnership with" your customer.
>
> I look at the businesses that I, as a consumer, "enjoy"
> doing business with. And those that I don't. It is
> easy to see the things that the "good" have in common and
> how they differ with the "bad". The latter seem to always
> be trying to figure out how to nickel and dime me -- "sorry,
> you can't return that without a receipt", "sorry, the sale
> ended yesterday", "Sorry, you will have to talk to the
> manufacturer to handle that defect"... OTOH, the former
> seem like they are working *with* me: "well, there is a
> two item limit clearly printed on this coupon, but I'll let
> you have three at that price", "yes, the sale was over
> yesterday but I'm sure if we could afford to sell it for
> that price yesterday, we can probably sell it for that
> price today -- let me get a manager to approve this for me"
>
> My goal as a *vendor* is to keep my customers thinking of
> me in that former case and not the latter...

I do agree.

--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

From: Ulf Samuelsson on 18 Dec 2009 19:44
-jg skrev 2009-12-17 01:49:
> On Dec 15, 4:17 am, Ulf Samuelsson<u...(a)a-t-m-e-l.com> wrote:
>
>> I am involved in some internal discussions on how the future development
>> kits for high end ARM products should look like.
>>
>> Have some ideas, but I would be interested in feedback from any users
>> on the current crop of kits. AT91SAM926xEK etc. General comments on
>> this are also welcome.
>> Remember that the SAM9 products are mostly microprocessors (non-flash)
>> intended to run things like Linux/WinCE etc.
>>
> What about the ones that ARE flash based ?
>

Thanks Jim.

Only one flash based SAM9 at the moment, SAM9XE, and that might hang on
to this discussion.
SAM3/SAM7 are really different things and may need totally different
setups for development tools.

>> Feel free to comment on anything.
>>
>> * What do you like?
>> * What don't you like?
>> * Single board computer vs tool based on CPU module?
>> * Memory size
>> * Too hard to use because of<...>
>> * I like the following feature (please keep it):<...>
>> * What connectors should be available. Location of connector
>> * What physical format?
>> * On board JTAG vs connector for JTAG?
>> * Additional peripherals wanted?
>> * Developed by Atmel vs outsourcing to board vendor
>> * Difficult to get components, if you want to copy the design
>> * Easy to connect to external I/O functionality (or not)?
>>
> Look at the new LPCxpresso tools from NXP.
>
> Key features:
>
> * High Speed USB DEBUG _included_ that users
> can get at. Debug pathway uses a RAM based ARM9 IIRC
>
> * Can be sliced, to Debug/target portions.
>
> * Price of sub $30
>

That is for the Cortex-M0 processors.
The AVR Dragon sells for $29 and is similar stuff.

If you want to run Linux/Windows CE, you won't do that on such a stick.



> Now I'll admit a microprocessor kit is a looser target, as you have
> RAM/Code questions, but I do get annoyed at development kits where the
> Debug pathway is either crippled, or not accessible.
> It just has the whiff of 'dumb design' :(
>
I am all in favour of adding the existing SAM-ICE on board.
That is based on SAM7S64 which is full speed USB.
I have friends selling ARM tools, and they have both with and without
builtin JTAG emulator
and the boards with built in JTAG emulator does not sell that well.
Personally I do not understand why.

> I see a number of USB-stick products, now have high density edge
> connectors, and that seems a nice way to give a lot of IO choices, at
> ~zero base cost.
> [Infineon, Rabbit, NXP..]
>

Does that not make for an expensive cable instead.
You can add a board connector, of course.



> - others have 0.1" pitch holes, for easy piggyback
> deployment.
>

You can bring out all the I/Os on an MCU this way but it does not solve
all problems..

Assume that you want to be able to add the following features to your board.
1) RS-485 driver
2) RS-232 driver
3) 16 bit ADC board
4) 64 Mbit Dataflash

You are a consultant, and you want to design one board per function above
For customer A, you want one combination of above,
and for customer B, you want another combination.

You should be able to support both customers using your MCU motherboard
and those 4 I/O modules, without having to build any adapters.

Ideally, you should be able to use the I/O modules, for low volume
production as well.

Having a standard definition of a 10/12 pin header would allow me to build
simple extension boards using SPI/I2C/UART.

Single line 0.1" are no good, since you cannot easily create those
nice STK500 flatcables that are possible with the dual row 0.1" headers.


> Small size seems a key element in low cost, so
> focus on small size first.
>
> -jg
>

BTW: I am taking notes, so even ideas that I personally don't like
will be communicated to others in my team, and they may have different
opinions.
Pls keep comments coming


--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

First  |  Prev  | 
Pages: 1 2
Prev: make opencv to work with sensoray2255
Next: ARM Cortex-M3 (Stellaris LM3S811) soft float problem (GCC/QEMU)