USB Host

Ulf Samuelsson wrote:

>Cost reduction of parts is key to future success and can only be
>accomplished by shrinking devices.

The lowest cost parts (the one Mattel uses) are NOT shrunk.  
At the low end, bonding pads dominate die size.  The lowest 
cost parts are from Chinese facttories that buy the old equipment 
from those companies that believe in shrinking devices at fire-sale 
prices, combine them with cheap labor, and flood the market so that 
Atmel and buddies cannot compete at the low end with the products 
put out by Winbond. Elan, and SunPlus.

> Ulf Samuelsson <ulf@a-t-m-e-l.com> wrote:
>
> > Add an ATmega128 and an AT43USB380.
> > Let the 80C51 communicate with the AVR using SPI.
> > Since you  need 64 kB of code and 4 kB of data on an AVR,
> > you probably will find the 80C51 too small for this.
>
> Ulf, the problem here is one of reality vs. the ideal.  The design is
going
> to reuse a significant body of code that I wrote for the 8051 over several
> months.  It's an evolutionary step from an existing product.

I did not say throw out the C51, I said add an AVR.

>
> And so, throwing out the 8051 makes no economic sense at this point.  If I
> did that, I would simply implement Embedded Linux using one of the two
> PowerPC processors available in the Virtex2 Pro FPGA on the board.  This
> would get me all the I/O interfaces (including USB Host) that I want.
> However, as it is sometimes the case, there's no time to dive into that
one.
> Maybe for the next revision?  :-)
>

Then the best solution for the AT43USB380 is to run the AT43USB380 library
on one of the PowerPCs. You can run it bare, without an OS.
You need to have memory for the PowerPC of course, and
this should be less expensive than the AVR for this solution to make sense.

You also need to compare the cost of adding a CPU with a free library
to the cost of buying a license for code.
Some companies will charge a lo for the USB sack, some will not.
Don&#4294967295;t klnwo about Philips, but some others will charge an ARM and a leg for
the code.

>
> -Martin
>
>

On Sun, 23 Jan 2005 14:49:45 +0100, "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote:

>> First time I'd ever taken on a new processor with this much ease.  So,
>> I guess I've found programming in assembly on the AVR very nice.
>
>> However, that positive experience was colored by a number of subsequent
>> experiences.  One is that I have to go though a local FAE who often then
>> forwards my questions back to France (in the case of the ARM)  and it can
>> take several days to get my first reply back, though it often happened in
>> about 24-36 hours.  With Microchip, for example, I've a long distance phone
>> call I can make...
>
>You can always contact the support departments at avr or at91supprot ath
>atmel doth com.

This was regarding the AT91 and the technical support was/is located in France.
I believe I spoke with Jaques on several occasions on the phone, as well.  But
the point remains that whether I wrote them directly or went through my FAE (who
only forwarded the email, at first) there was still the almost "half-the-world"
around issue.  This isn't anyone's fault, at the time.

Atmel just didn't have knowledgeable people for the AT91 in a closer time-zone
and I've no reason to believe that these technical questions were seriously
delayed.  If I gave the impression otherwise, let me correct that now.

But, from my perspective here on the west coast of the US, it was a real issue
that contrasted with support I could get from a manufacturer who was, at most,
only a time zone away from me.

(Regarding the samples, though, I went through the usual channels -- namely, our
distributor and our local Atmel FAE.  I don't recall the FAE or the distributor
suggesting to me that I should bypass them in any way to press for the samples.
They were each quite aware of the situation in hand and I've no reason to
believe that they weren't already doing "their best" to help on this score.)

>The www.avrfreaks.net is another source of info.

It is, for the AVR.  However, as I already pointed out (well, I think) in my
post, I haven't been having technical problems with the AVR.  Instead, I found
it quite easy to use and I hope my post made that quite clear to all.  I really
have not needed any technical support for the AVRs I can get hold of.

>Personally, I prefer identifying and fixing the problem at a small customer,
>before the large customer gets pissed off.

Not sure I follow the point, here.  I my mind these are two, disconnected
phrases and I don't see the connection.  Could you clarify?

Jon

Ulf Samuelsson wrote:

> Then the best solution for the AT43USB380 is to run the AT43USB380 library
> on one of the PowerPCs. You can run it bare, without an OS.
> You need to have memory for the PowerPC of course, and
> this should be less expensive than the AVR for this solution to make 
> sense.

That's a good idea.  I'll look into that.  Shouldn't be too complex.  The 
8051 could have access to data placed in a buffer by the PowerPC (talk about 
upside-down and backwards!).  If I connect the peripherals to the FPGA, I 
can, later on, simply not stuff the board with the 8051-related hardware and 
migrate the firmware to fully implement the functionality on the PowerPC, 
which is what I want.

-Martin

On Sun, 23 Jan 2005 14:49:45 +0100, "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote:

>> I had already read that Atmel (on their site) was nearly
>> ready for sampling on the AT91FR40162-66CI, so although I expected some
>> delay I didn't expect the 10 months I experienced.
>...
>> Needless to say, I've not specified any Atmel parts and I'm not planning
>> to.
>>
>> Atmel has made us feel exactly like how we impacted their bottom line.  If
>> you can see _your_ impact in their annual report, you get treated accordingly.
>> And if you can't see your impact there, likewise is also true.
>>
>> This can be important to some.  It is, to me.  This isn't something I bring
>> up because I feel a mission here.  I like the AVR a lot and I really enjoyed
>> using the STK500 board, which was provided to me at an excellent price and has
>> served me well.  The documentation is good, too.  Also, my experiences with
>> programming on the family is excellent and the products are carried at Digikey
>> in some quantity.  So there is a lot going for this family of Atmel's.  I don't
>> pause for a second to consider them in my hobby projects and, in fact, I keep
>> tubes of them around here for that purpose.
>>
>> But as far as relationships go, I do not feel that I can count on Atmel to
>> be there when the chips are down, so to speak.  Not at volumes my company
>> has, anyway.  I guess it's going to take some effort (on both our parts, I
>> suppose) to improve the lost trust.
>
>I think these are quite valid points, but I think they affect both large and
>small customers.

They may.  But an experience I mentioned that may not be clear and which you do
not deal with is that the FAE on several occasions called me to ask more about
what my volume was likely to be.  As I'd already disclosed details such as the
product concerned, existing product lines and volumes, and a host of other
information, the only question he pounded on was about volume.  Somehow, this
was the salient point at the time about whether or not they would be
forth-coming with the parts, it seemed from the discussions.

Not that he said as much, of course.  But if you were present for the calls, I'm
pretty sure you'd understand exactly why I take this sense from them.

>SAP certainly does not make any differences.

SAP being?

>Atmel has still some work to do in its internal business systems.

That may be so.  Perhaps if this "work" were fully disclosed and transparent so
that I could judge how this affects me for now, it would help some.  But in any
case, I cannot judge anything from being ignorant about what is going on.

>The sampling system has been really problematic.

Putting it bluntly, yes.

>Before 2004, the sampling system was more or less manual

Which would now suggest to me that I was properly exposed to the real mindsets
of the real people involved.  In other words, I got a clearer picture of how
Atmel employees see the world, since it wasn't hidden behind some automated
system.

>During most of 2004, the sample department was simply overloaded
>due to unexpected consequences of the SAP implementation

Care to share more of this with us?

>It also did not send enough information to keep the stocklevels
>so parts would not be ordered in advance.

Perhaps.  But I was in biweekly contact (sometimes, as long as a month, later
one when things were certainly dragging out) with my distributor over those 10
months, who themselves sent emails to Atmel (they told me they were doing this
and I've no reason to imagine otherwise.)

I later found out that there were large customers receiving these parts 6 months
before I saw even one.  I cannot forget this detail in my case, coupled with the
constant return to "numbers" by the FAE, on those occasions we talked.  Look, my
FAE was feeling pretty guilty by the end of September.  That was clear from the
apologies I received.  Yet he also instantly returned to the only question he
had, which was "numbers."  It seemed that this is what he was being asked to
double-check, to me.  So when I discovered the fact that others were receiving
said parts, it put the pieces together as I have recounted them here.  For me,
at least.

>There is no feedback to the distributor when samples are to be shipped
>so they cannot tell you anything until the samples arrive.

I've no reason to doubt this point.

>People have been working on a new sampling system for about a year
>now so hopefully things will improve during 2005

Thanks for the response.

>I think in your case, it was probably just that the part was announced too
>early.

Perhaps, but as I hope I've made clear I don't think that was the entire picture
at the time.  Parts were being shipped to others -- larger 'others' at the time.

>One way of handling this is to make a conscious decision
>to avoid considering parts which are not in production.

Agreed.  However, this was a case of a project that was to start designing with
prototyping in September, hopefully to resolve the key technical hurdles in
using the AT91 by sometime in December/January, with design of the final product
starting then.  In other words, I already planned for the usual "slip" I
experience.  Also, assuming you accept my assurances (you can check for
yourself, since I've given you the exact part number here) that these parts WERE
shipped as samples to others months before I received my two in December, there
is an issue here that isn't quite as simple as you seem to suggest.

I'm still not convinced that there wasn't an evaluation going on, an intelligent
one with "malice aforethought," to decide whether or not I was worth taking two
parts from a much bigger customer wanting more than a few.  There was some kind
of balancing and weighing going on behind the scenes and I didn't rate high
enough, I think.

Understood, of course.  Perhaps our products didn't deserve a high score on the
Atmel "profit motive" scale.  But I have had experiences with companies who do
manage to make us at least __imagine__ we rate some attention, even if the truth
is still different.

Jon

> > Then the best solution for the AT43USB380 is to run the AT43USB380
library
> > on one of the PowerPCs. You can run it bare, without an OS.
> > You need to have memory for the PowerPC of course, and
> > this should be less expensive than the AVR for this solution to make
> > sense.
>
> That's a good idea.  I'll look into that.  Shouldn't be too complex.  The
> 8051 could have access to data placed in a buffer by the PowerPC (talk
about
> upside-down and backwards!).  If I connect the peripherals to the FPGA, I
> can, later on, simply not stuff the board with the 8051-related hardware
and
> migrate the firmware to fully implement the functionality on the PowerPC,
> which is what I want.
>
> -Martin
>

You need to contact your local Atmel FAE for more details.
There is quite a lot of info on the web, but you have to click go to tools &
software + register to get access
http://www.atmel.com/dyn/products/tools.asp?family_id=655

You need to have the same compiler as Atmel uses.

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

>
> >SAP certainly does not make any differences.
>
> SAP being?

SAP is a German Company that makes a lot of money from their Business
Management Software.
You have the customer order system, and everything else in SAP
so this runs the company, not management.
Many large corporations use it, but it is a beast that needs to be slowly
tamed
to make it do what you want it to do.
The favorite translation of SAP is "Simply Awful Program".

> >Before 2004, the sampling system was more or less manual
>
> Which would now suggest to me that I was properly exposed to the real
mindsets
> of the real people involved.  In other words, I got a clearer picture of
how
> Atmel employees see the world, since it wasn't hidden behind some
automated system.

I think you mean certain Atmel employees.

> Care to share more of this with us?

Don't know all the details, but the actual printout of the sample order was
a limiting factor
after SAP was installed. One or more pages per sample order on a slow
printer...

> Perhaps.  But I was in biweekly contact (sometimes, as long as a month,
later
> one when things were certainly dragging out) with my distributor over
those 10
> months, who themselves sent emails to Atmel (they told me they were doing
this
> and I've no reason to imagine otherwise.)

That would not give the disti more info. I had lot of problems myself last
year.
Called the sample dept, and they promised shipping the same week.
Eventually I started copying a VP on mails, and parts started to appear.
About one month ago, I started to see massive shipments coming oout
of the sample dept, and I talked to the Director of AVR and he said
that the problem at the sample department is more or less solved,
but the product lines needs to maintain the stock and they have problems
with SAP as well, due to lack of visibility. They will only find out
when the sample dept is sold out. Once they have good info, I think the
sample situation
is going to improve.

> I later found out that there were large customers receiving these parts 6
months
> before I saw even one.

Atmel do sampling in several stages.
------------------------------------
Alpha Site            a few companies world wide.
Beta Site              samples handled by marketing.
                            There is a finite amount of these.
General sampling. samples handled by sample department.

I generally do not have problem getting samples in phase 2, even for smaller
customers
but there is typically a very limited amount.
If you order samples from the sample department then you will find that
there can be considerable delay, because the parts are simply not available
there.
The only one I had significant problems getting hold of last year was the
tiny2313.
Now there seems to be plenty available.

>  I cannot forget this detail in my case, coupled with the
> constant return to "numbers" by the FAE, on those occasions we talked.

Would piss me off as well.

> Perhaps, but as I hope I've made clear I don't think that was the entire
picture
> at the time.  Parts were being shipped to others -- larger 'others' at the
time.

Personally I think 5k AT91FR40162 is quite nice business.
Rather have 10 x 5 k than 1 x 50k because the level of business becomes more
stable.

> >One way of handling this is to make a conscious decision
> >to avoid considering parts which are not in production.
>
> Agreed.  However, this was a case of a project that was to start designing
with
> prototyping in September, hopefully to resolve the key technical hurdles
in
> using the AT91 by sometime in December/January, with design of the final
product
> starting then.  In other words, I already planned for the usual "slip" I
> experience.

Schopenauers Law: Anything takes longer than you think, even if you take
Schopenauers law into account!

> Understood, of course.  Perhaps our products didn't deserve a high score
on the
> Atmel "profit motive" scale.  But I have had experiences with companies
who do
> manage to make us at least __imagine__ we rate some attention, even if the
truth
> is still different.

So you have met poor sales guys. If they think your volume is key,
then they should ask that once and tell you once and for all that you wont
get any parts
so you can drop it.
Personally I never promise anything which is not generally sampling.
Based on long experience,I only give best case scenarios on delivery.

>
> Jon

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

Martin <0_0_0_0_@pacbell.net> wrote:
> What's the least painful way to implement simple (as in a strictly limited 
> set of connecting devices) USB Host support on a C8051-based design?

The least painful way would be to not do it at all, of course.  Second
least painful: have somebody else do it.  Implementing even a subset
of a USB host's job on an 8051 is definitely not something you want to
do yourself unless you absolutely, positively,
beyond-all-reasonable-doubt have to.  Just about *every* other option
will be less painful.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Hans-Bernhard Broeker wrote:

> Martin <0_0_0_0_@pacbell.net> wrote:
> > What's the least painful way to implement simple (as in a strictly limited
> > set of connecting devices) USB Host support on a C8051-based design?
>
> The least painful way would be to not do it at all, of course.  Second
> least painful: have somebody else do it.  Implementing even a subset
> of a USB host's job on an 8051 is definitely not something you want to
> do yourself unless you absolutely, positively,
> beyond-all-reasonable-doubt have to.  Just about *every* other option
> will be less painful.
>
> --
> Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
> Even if all the snow were burnt, ashes would remain.

A USB Host for one device is not so bad.  The difficulty lies in what
you can't see or what is not published.  The easiest approach is to
Buy/Rent/Borrow a USB data analyzer and capture the enumeration
sequence for the targeted device.  Then use a Host controller like the
Cypress 811HS and a 8051 of your choice to enumberat the device
yourself.  After that, it is online and ready for communication.  We
have done this with several USB devices.

"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote

> The least painful way would be to not do it at all, of course.  Second
> least painful: have somebody else do it.  Implementing even a subset
> of a USB host's job on an 8051 is definitely not something you want to
> do yourself unless you absolutely, positively,
> beyond-all-reasonable-doubt have to.

Agreed.  A company should not be spending money on training staff
to do a task that is not at least somewhat central to their business.

There are exceptions, of course.  As an example -

 A medical device firm finds they do a lot of USB interfacing. They
 hire a _qualified_ consultant to do the job with one of their staff 
 (Sr./Jr. makes no difference) as apprentice/trainee on the subject 
 of USB so they have someone on call with an understanding of the subject.

I'm in the racket of being the one of those 'out of town experts' 
who comes in and does 'something', so take that bias into account.
I find I end up doing quite a bit of mentoring.

-- 
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix  . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/