Reply by Martin January 25, 20052005-01-25
Sorry for the multiple posts.

Cypress most definetly has the answer.  Their links are horribly long and 
complex, so I won't post one here.  Just search for CY3662.  Code, 
schematics, PDF's and Powerpoint presentations for embedded host mode using 
an 8051.

Code requirements for stripped-down, dedicated-device support (i.e. You know 
what is likely to attach to your host port): 350 bytes!!!

All of a sudden the nightmare scenarios are gone.  This ain't bad at all.

Thanks for the very useful posts on this topic.

-Martin


Reply by Martin January 25, 20052005-01-25
Cypress seems to have a couple of good solutions, as well as eval boards 
with 8051-based Host mode firmware examples.

www.cypress.com
CY7C67300
CY3662

-Martin 


Reply by Martin January 25, 20052005-01-25
> 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.
I couldn't agree more. I wish I didn't have to do it. Hence the Mark Twain quote. One of the challenges in Engineering is to make something with what you have, not what you wish you had. Even if it is not ideal. Hell, anyone can do it under ideal conditions! Of course, if impossible you have to know when to call it. In this case, I think that there are a few interesting possibilities of either full or "highly-customized-crippled-but-usable-single-peripheral" implementations with varying degrees of pain. -Martin
Reply by Martin January 25, 20052005-01-25
> 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.
That's exactly what I was thinking about today while reading through the USB specs! We control what device/s will connect to this box. I reasoned that it couldn't be that hard to figure out how to make the connection happen and then, once the pipes are established, it should be just bunches-o-data moving back and forth (and not that much of it). We basicly need to interface with an instrument that only has USB I/O...very low data volume to. A few measurements per second. A handful of bytes per measurement. Any suitable analyzers you might recommend? I know that this wouln't be real USB "plug in whatever" interface. The point is, it doesn't have to be and it will never be. The worst that can happen is that a newer, better version of the test instrument is released. It shouldn't be a big deal to issue a patch for that. -Martin
Reply by Nicholas O. Lindan January 24, 20052005-01-24
"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/
Reply by Noone January 24, 20052005-01-24
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.
Reply by Hans-Bernhard Broeker January 24, 20052005-01-24
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.
Reply by Ulf Samuelsson January 23, 20052005-01-23
> > >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.
Reply by Ulf Samuelsson January 23, 20052005-01-23
> > 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.
Reply by Jonathan Kirwan January 23, 20052005-01-23
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