Re: USB Host
From: Jonathan Kirwan (jkirwan_at_easystreet.com)
Date: 01/23/05
- Next message: Michael N. Moran: "Re: So... What are the alternatives? Was: I don't use an RTOS because..."
- Previous message: Guy Macon: "Re: USB Host"
- In reply to: Jim Granville: "Re: USB Host"
- Next in thread: Ulf Samuelsson: "Re: USB Host"
- Reply: Ulf Samuelsson: "Re: USB Host"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 23 Jan 2005 01:43:01 GMT
On Sun, 23 Jan 2005 13:22:16 +1300, Jim Granville <no.spam@designtools.co.nz>
wrote:
>Hmmm...
> I've seen the AVR designed out, because there was no larger-code
>version in the same package.. [thin family syndrome...]
>
> Then there is the (usually unprintable) reaction to the AVR where
>a) Someone cannot buy a variant because it is now EOL .. :(
>b) or the device is on long leadtime, or allocation... :(
>
>You will remember the last AVR allocation supply-cycle, Ulf ?
I really like the AVRs, speaking as a programmer or for-fun electronic design
hobbyist.
When I did my first professional application on an AVR, an AT90S2313-4PC, I'd
expected it to take a couple of weeks of work to get done and maybe another week
to work through "issues." This project needed me to operate a front panel for a
power supply and included keeping font definitions and using them for the
display. There were a number of complex details about the power supply, as it
was a specialized system used for calibrated lamps and required careful ramping
up and down, for example, with feedback in a closed loop control. User
parameters were allowed and needed to be saved and restored each time the power
was applied. And lamps needed to have their operating time clocked and
recorded. Nothing surprising for me, but it was a new processor I'd picked for
this job and I didn't know what I'd be faced with when I got to writing the code
for it. I actually got it done in 4 days, using assembly, and used the last day
of the week to find the only bug I've yet found (and it's been years in
operation) -- I'd simply mistaken the order in which two bytes needed to be
written to one of the 16-bit latches in one place in the initialization code.
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 (or my distributor,
who will simply go through the FAE anyway) 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. But this
1-2 day loop can led to unavoidably protracted discussions. I can usually live
with this, knowing the situation. But it is still a point of comparison for me.
With Microchip, for example, I've a long distance phone call I can make and get
hold of some excellent staff and get an answer within minutes, even on complex,
highly narrow and technical questions that aren't entirely disclosed in the
manuals -- detailed logic behavior of functional blocks, for example. Quite a
difference, when timing is vital.
Some time ago, in a case of regarding Atmel samples when I was wanting to
evaluate their use, I actually ordered two samples from Atmel of a new part
through my local distributor. In this case, I explained our estimated volumes
and general application area to both the distributor as well as to our local
Atmel FAE, directly. 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. My request letter went to All
American in late February, that year. The response from Atmel (looking up my
email now to refresh my memory), a few weeks later, said,
"Atmel's AT91FR40162-66CI will be available as samples
sometime in April or May."
In April, I was told by my distributor,
"Atmel came back on the AT91FR40162-66CI and advised that
samples would be available sometime in May."
On the phone, in late May, I was told that it wouldn't be until late July. And
then in June, I was told in writing,
"I was advised this morning that the production schedule
slipped and the samples will not be available around the
24th of July."
July became August, August became September, and then in late September, I spoke
again with the FAE after some phone calls on my part in early September. This
time, the FAE started grilling me even more on our application details and
wanting to know "numbers" and how "certain" I could be of them. More, he was
now also asking if I really needed them before November.
By this time, I have to admit I wasn't really caring nearly as much. We were
near the end of September and I had pretty much set the possible use of their
chip aside. It was still remotely possible we could use it for a different
project, though, so I told him that I'd prefer it before November and disclosed
my frustrations up to this point in time.
Keep in mind that I *had* disclosed to them an expected annual purchase, early
on, of about 5000/yr. This was a pretty accurate figure, since we were already
shipping those quantities for a version we were replacing.
I finally received the two parts in December, shortly before Christmas.
Needless to say, I've not specified any Atmel parts and I'm not planning to.
In contrast, for example (we use a number of vendors, including TI and Microchip
and Motorola, to name just some), we've had excellent and direct support from
Microchip. When they fly out, they see us. When I have questions, I get
through to people who can answer them. When I've had chip bugs, I get immediate
and excessive efforts to help validate my report and to flush it out in more
detail -- this has happened several times. When I had problems with their C
compiler (crap that it was), I was able to talk with two of the three active
developers/coders on the project by phone within 24 hours of the request. It
wasn't denied me. Instead, they consider the situation carefully and I got a
direct line to people who could deal with me, directly.
The point here is that Microchip treated us like a big customer, even though
they knew exactly what we were buying from them. There was (and is) no question
about our tiny role in their bottom line. But they made us feel important. And
that speaks for much, when you aren't important to _their_ bottom line, but when
you really have products that are important to your own bottom line. And when a
vendor cares about you, you care about them, too.
While I have no problem using Atmel parts for hobbyist work (in fact, I've tubes
of them around here for exactly that reason), I would think several times before
specifying them in a commercial product. Well, at least if I knew in advance
that the project would be "small potatoes" to them. I'm sure that Atmel treats
their big customers like the gold they are. But then, that's just obvious.
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. And perhaps I'll see about that some time in the
future when I don't need to rely on being provided some urgent attention. It
may very well turn out that things are much better. But I just don't know
because I don't specify their parts in my commercial projects, now. Luckily,
there are other excellent choices.
Jon
- Next message: Michael N. Moran: "Re: So... What are the alternatives? Was: I don't use an RTOS because..."
- Previous message: Guy Macon: "Re: USB Host"
- In reply to: Jim Granville: "Re: USB Host"
- Next in thread: Ulf Samuelsson: "Re: USB Host"
- Reply: Ulf Samuelsson: "Re: USB Host"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
