Requests for feedback on future AT91SAM9 development kits

Small, inexpensive, extensible. I doubt anyone would have problems hanging their own IO off a daughter card (that *they* create) so why try to be all things to all people? A CPU with a bunch of RAM that can be loaded with an "I/O-less" application and a driver (UN*X/WindBlows) that can talk to it.

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).

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.

DIMMs. Let the customer provide his own. *OR*, sell industry standard DIMMs to the customer AT VOLUME PRICES despite the one-off quantities.

CPU module. Something that makes it easy for folks to prototype around (i.e., no BGAs).

If it's a uP and not a uC, then why the JTAG?

None. Move them onto daughtercard(s) or motherboard.

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.

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...?"

For smaller corporate users (possibly also with deep pockets but SHORT ARMS) there is often a lot of *resistance* to spending. "And why can't you just use the LAST toolkit you bought...?"

For garage shops and hobbyists, there's often very little desire to throw money after something that might not pan out. After all, they will be investing time, too, and having to part with that *and* a bit of cash just adds insult to injury (folks seem to think differently when it is *their* time and money vs. The Boss's)

In any case, cheap wins. In big corporations, you can do an end-run around the paperwork just by purchasing out of petty cash. If a manager can't find a way to move $100 out for "office supplies" then he really isn't the sort of guy you want running a "new technology" business.

The same holds true for smaller companies. Though here any expense might be more visible (i.e., family owned companies) so you can't just hide it. But, you can rationalize it as minimal: "Sure, it's $100. But, if we pay Joe to research this, after an hour or two we'll have spent more *thinking* about it than if we had just *tried* it!"

And, for one-man-shops where every dollar comes out of

*their* pocket, showing that you (your company) *cares* about *their* welfare/profitability goes a long way to winning a design.

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.

After all, isn't *that* what you REALLY want??

Of course! Unless you are going to offer me a development board with a six axis 20A microstepping drive controller built in, why do I want to buy *any* I/Os from you? What makes you think I need a "video display"? Or a USB port? Or a disk controller? Or...

I agree.

Well, if it comes to things like USB or Ethernet I'd like to see them on the module. It's no fun to add these things on a breadboard.

JTAG. Period. Otherwise I'll end up with missing drivers for my favorite compiler.

You could sell some cheap FTDI2232-based USB JTAG adapter as an addon.

I agree.

I don't care.

--
Mit freundlichen Grüßen

Frank-Christian Krügel

Sounds fine with me. Thats not how it is done today.

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,.

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.

Until there is a real PCI bus, there won't be any industry standard cards.

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).

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.

There are some chips which are available in TQFP208. These packages are very large compared to BGA.

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.

You can debug embedded applications which are so large that you have to use uP with external memory. I have seen some motor controllers using > 2 MByte of flash.

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.

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.

Yes, people are aware of this. Ideally, you should only have to ask your personal manager for approval. 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.

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

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.

It is fairly easy to borrow boards, and sales guys tend to give away to major customer anyway. 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.

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.

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

There is always someone at the top that rather take the money.

Anyone buying an AT91SAM9261 instead of an AT91SAM9260 is bound to want a display, otherwise he would have bought the 9260. For an evaluation kit, it is OK to deliver a display IMHO. For a development kit, even if people want a display, they are likely to want to use a different display anyway.

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

Frank-Christian Krügel skrev 2009-12-16 23:18:

USB is difficult. Some people making PC CPU modules (ETX) which are stacked on top of the motherboard, discovered that the connector can have a big impact on the USB bus.

They are using a HiRose connector, and this can only be a few mm high or the USB bus will suffer. It will still work, but the cable length can be reduced from the 5 meters in the specs to 10s of cm.

Atmel already sells the SAM-ICE which is based on the AT91SAM7S. Personally, I would like to have the JTAG integrated on a motherboard.

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

What about the ones that ARE flash based ?

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

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

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.

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.

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*.

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 :-/

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. 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.

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?

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? :<

Perhaps you should consider a different marketing/sales model?

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.

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!

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.

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!

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?")

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?)

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?? :> )

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.

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...

D Yuniskis skrev 2009-12-18 07:06:

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.

Yes.

Fully agree.

Yep.

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.

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.

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

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).

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.

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.

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.

.

Like what?

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.

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

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 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

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.

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.

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.

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

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.

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