USB Host

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? USB Peripheral mode is easily handled with something like FTDI's chips.

Atmel's AT43USB380 looks interesting. However, not sure if their API's support the 8051.

Thanks,

-Martin

Reply to
Martin
Loading thread data ...

Hello !

In this case, I would consider Phillips's ISP1160BD/01, ISP1160BM/01, ISP1760BE or ISP1760ET. They are all USB host controllers designed for embedded applications. The latter two are Hi-Speed rated. All feature a generic, programmable parallel connection to any modern microprocessor, thus I would imagine that the 8051 is also supported. The most common use is make these controllers appear like a memory mapped devices for the microprocessor/-controller. I do not know if they'll directly fit a 8051-compatible bus, because I didn't read the datasheets. But you could try checking them out. Here's a link to get you started:

formatting link

-Antti

Reply to
Antti Keskinen

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

Reply to
Ulf Samuelsson

Ulf, is there anything in this world for which the AVR is not the ultimate solution?

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Reply to
Nicholas O. Lindan

It's a floor wax _and_ a desert topping!

--
Grant Edwards                   grante             Yow!  World War III? No
                                  at               thanks!
                               visi.com
Reply to
Grant Edwards

limited

solution?

Yep, lots of applications for ARM as well! My favorite application for the C51 is road filling in China ;-), but from time to time, due to peripheral contents it can be the best solution. You may disagree, but there are many people that don't like the C51 and don't want to use it. I never see this reaction to the AVR.

Nicholas, to be serious: The AT43USB380 is a package containing S/W and H/W. Part of the S/W runs on the chip and another part is a library which is only available in object form.

Anyone that want to use the chip can only work with chips supported by this library. There are also limitations on performance and code size. I do not think it makes sense to go for any controller with less than 128 kB memory which rules out the vanilla 8051. If there is a significant opportunity, then Atmel will port to a new chip but I do not think that the 80C51 is supported today.

You can add an ARM, a Coldfire, A PowerPC and others to the AT43USB380, but I believe the AVR is the lowest cost solution offered at the moment.

Reply to
Ulf Samuelsson

My boss sure likes them. Our latest system has up to 21 ATmega128s in each box.

Peter

Reply to
Peter

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.

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

If I simple path for USB Host on a fast (Slicon Labs) 8051 is not available I'll just make provisions for migrating to Embedded Linux with a firmware update and handle it that way. The Philips chips might be an interesting option. I'll have have a look.

As Mark Twain said: A man holding a cat by the tail learns something he can learn no other way.

-Martin

Reply to
Martin

I have a toy design that has a requirement that the microcontroller and all peripherals (including xtal if one is required) must cost less than ten cents total, and the vendor muct be able to deliver

100,000 chips per day as bare dies to an assembly plant in China.

Which AVR should I choose? :)

Reply to
Guy Macon

For 36 Mu/year I am sure you can do a ROM based 0,13u ASIC containing the AVR. Even at 10 cents it even meets the minimum business guidelines... Atmel do die business regularily so if the chip is simple enough, no sweat!

/Ulf

Reply to
Ulf Samuelsson

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 ?

-jg

Reply to
Jim Granville

Looks like your gambit has been accepted, Guy! Point to über-Atmel.

Jon

Reply to
Jonathan Kirwan

I don't think that an ASIC with an AVR in it can hit the ten cent mark. A 4-bit microcontroller can it the 5 cent mark.

Reply to
Guy Macon

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

Reply to
Jonathan Kirwan

ASIC's do not have to be massive, merely application specific. If a 4bit uC can be 5c, then I'd imagine a ROM AVR (toy class) could be 10c. (This is a $3.6M/yr hypothetical die customer). Atmel are one the of bigger suppliers of Serial EE, so they are well used to fab/test of very low cost silicon.

-jg

Reply to
Jim Granville

Who ever said there aren't.

You just have. I was on the receiving end of a new Atmel design. You may think it is 'fun to design new chips': I can assure you it is no fun for your customers when you pointlessly do so.

Oh, dear. Maybe Atmel should work on supporting present chips rather than 'having fun'.

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

Yes, it does not support 1GB of DRAM and does not run Linux. It would be surprising that an entire industry would fail to produce anything which is unavailable with an AVR.

Very few companies deliver standard parts from 1kB to 256kB, supply it as ASIC for up to 8 MB, and makes available versions with integrated programmable logic.

The new strategy to let each design team build multiple compatible parts with mainly changes in memory sizes is resulting in a quick expansion of the options.

The original question was for a nice device to start with. I do not see a reason to start with a technology that forces people spend multiple extra hours to handoptimize C code to bring out the most of the part just because the architecture does not support good code practices. You can get pretty far with the AVR with just a few guidelines.

Shrinks are a fact of life, but pin compatible parts are normally available. The window from release of a replacement to the obsolecense of the predecessor has been on the short side for a few devices. I think this needs to change, and I think that it will.

The supply cycle varies, and there may always be trouble. The question is what conclusions you draw by the fact that a part is sold out. The leadtimes are based on the production cycle which is 3-4 months. If you are interested in getting supply, then you realistically have to order at least that far in advance to ensure you do get parts. If you want to have 4 weeks leadtime, then you are taking a risk. It happened about one year ago, that someone put in an order for the entire stock of ATmega8s. Anyone without orders then immediately suffered. Leadtimes for other parts were not affected at all. Leadtimes generally go up when there is a capacity problem. At that time, the Atmel fabs were running at max throughput, and it took time to sort that out, but with the North Tynside fab and the expansion of the Rousset factory to 2 x capacity, I think that the time to handle a sudden increase of demand is significantly reduced.

It did not help that the order processing at that time was more or less manual. The lesson learned here is the SAP business system which will make life easier.

They are more reasons not to like Atmel than to not like the AVR.

Reply to
Ulf Samuelsson

AVR.

sweat!

And if you don't ask for a quote, you will never find out, The AVR is maybe 1/10 of a square mm in the 0,13u technology.

Best Regards Ulf

Reply to
Ulf Samuelsson

I see this as a reaction to Atmel, more than to the AVR. Cost reduction of parts is key to future success and can only be accomplished by shrinking devices. This is true for all companies. Atmel shrinks the 8051 as well,. is that a reason not to use the 8051?

The shrink can be more or less compatible. An effort is made to ensure compatability. This is not always achieved, but the problems in doing the migration is AFAIK always documented in an app note.

I try to solve the problem for my customers in different ways and try to influence the product line to change some decisions

I think the fab in North Tyneside is a good example that Atmel does want to support present chips.

/Ulf

Reply to
Ulf Samuelsson

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.

Reply to
Guy Macon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.