at90usb162 and at90usb1287..

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to discuss following thing:

at90usb162:"¢ Support full-speed
"¢ 176 bytes of DPRAM
"“ 1 endpoint of 64 bytes max, (default control endpoint)
"“ 2 endpoints of 64 bytes max, (one bank)
"“ 2 endpoints of 64 bytes max, (one or two banks)
total-5 endpoints...

at90usb1287:Support full-speed and low-speed.
"¢ 832 bytes of DPRAM :
"“ 1 endpoint 64 bytes max (default control endpoint),
"“ 1 endpoints of 256 bytes max, (one or two banks),
"“ 5 endpoints of 64 bytes max, (one or two banks)
total-7 endpoints...

now my point is that one can transfer atleast (64*5=320bytes) in or out per frame of usb....in usb162 and
atleast (256 + 64*5) bytes in or out per frame of usb in usb1287.....

Currently I am transfering 64 bytes in interrupt mode in usb162 and approx. I can transfer 80 times in one second...now if I configure more endpoint I can transfer 320 bytes per frame....?????

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

no replys..........

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Each frame, the contents of all filled endpoint packets (depending on the endpoint type and available bus bandwidth) will be sent to the host. A larger endpoint bank means more data can be transferred per frame, and more endpoints increases the overall bandwidth between the PC and the device.

However, note that the endpoints' data packets may not be synchronized, so it would be VERY unwise (and non standard!) to split up a single logical stream into many endpoints to try to increase bandwidth. Instead, try to use a double-banked 256 byte endpoints, which will give you a maximum transfer rate of 256000 bytes per second.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so are you saying, one should try such that least no. of endpoint with maximum data size???
Then in at90usb1287... you should use 256 byte endpoint in double bank mode(? what is real diff. for one bank and two bank?)...and what about usb162..is this speed achievable in that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should have one endpoint per logical data channel, per direction. A typical application might have several logical channels. Take for instance a USB Webcam - this might have a video source, an audio source (a microphone), and a HID source (a "capture image" button).

For that application, you would have three endpoints for the logical streams - two isochronous IN endpoints for the video and audio data, and an interrupt IN endpoint for the HID button date.

Endpoints are designed to separate the logical data streams from one-another within a device, in a standard manner.

Each second has 1000 USB frames, inside of which each endpoint has one or more chances to send their contents. On the USB AVR, double banking an endpoint requires twice the USB DPRAM of a single banked endpoint, but allows you to write data to the second bank while the USB controller is busy transmitting the first. This reduces the overall time needed to create each packet and thus allows the USB controller to send more packets per second to the host.

Similarly, it also speeds up packet reception by allowing you to process one packet while a second is still being received.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for reply...so if 1000 frame per 1 second...so by going on that equation....can we count data transfer rate for usb162 and usb1287?? provided all idle condition...can we count max. acievable data transfer rate???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Each second has 1000 USB frames, inside of which each endpoint has one or more chances to send their contents.

Have you any reference to back the "or more" part of this? (given full speed operation).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am still clueless regarding data transfer rate in usb162 and usb1287........please share your experience regarding data rate achieved in your case......In my case I am able to achieve (inpipe only) 4080 bytes per second in bulk method for usb1287...
I am becoming restless to find out...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you go to Dean's LUFA page, there are some throughput numbers IIRC. Or maybe in a LUFA post here--search it out.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At this link Dean said he was going to profile and put numbers into the doc.
http://groups.google.com/group/m...
Note the first poster is getting 185KB.

Side note on LUFA Google searches:
http://www.lufa.ca/quickfacts.asp "LUFA -- Law-abiding Unregistered Firearms Association"

Quote:
Principal payment fee: $286/gun*
Licence fee: $80**/5 years
Handgun Licence fee: $80***/5 years
Yearly Registration fee: $25/firearm
Transfer of gun fee: $25

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lurcher wrote:
Quote:
Each second has 1000 USB frames, inside of which each endpoint has one or more chances to send their contents.

Have you any reference to back the "or more" part of this? (given full speed operation).

I am starting to wonder if I understand this at all. Reading the doc (section 5) today, it seems to infer that here are more than one packet per flame for Iso data, and seems bulk can do much more, in which case I apologize for asking for a reference. But unfortunately it doesn't seem to help me as the standard host audio device only seems (whatever I set in the descriptor) to send one per frame. And I am still stuck with the In Out endpoint number restriction. Sorry for the thread hijack anyway. I should shut up and read more.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Have you any reference to back the "or more" part of this? (given full speed operation).

See "Table 5-2. Full-speed Control Transfer Limits" in the USB Specification -- that is for Full Speed (not High Speed) operation and seems to suggest that multiple transfers are possible.

Under high speed devices frames are split into even smaller microframes, but that's not applicable here.

- Dean :twisted:

PS: Benchmarking is a bit of a crapshoot on the USB AVRs, due to variations on how fast the data is transferred from the USB controller, but this this page for a guide:

http://code.google.com/p/micrope...

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep but (going round in circles here), I get the feeling that while multiple packers per frame are possible and expected, it may require multiple endpoint. But then the bench mark code linked to shows that at least for bulk transfer that is not the case. I have been focusing on Iso transfer so what may be true for that is not for the other types. The high speed descriptor does have a flag to send 1, 2 or 3 packets per micro frame, which leads me to believe the normal iso behavior is one packet per endpoint per frame.I should read the other chapters I guess :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps we both do!

Bulk transfers use up the remaining bandwidth on the bus, but do not get a guaranteed timeslice -- so perhaps the host controller is able to request multiple bulk packets from the device in each frame because of that.

Interrupt and Isochronous are supposed to have guaranteed time slices, so perhaps the host controller is only requesting them on their allocated frame slice to ensure their periodicity.

Much of the actual on-the-wire remains a mystery to me.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will come back to this after some reading pages provided by "theusch".....I want to improve the speed desperately.......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using at90usb1287 in HID class mode...is this something do with speed of it???
I read here
http://code.google.com/p/micrope...
it said" Keyboard firmware may be useful but it is limited to transferring a maximum of 6 characters per keyboard report. There is also significant overhead in the HID (Human Interface Device) USB class. More useful are the firmware examples based on USB Virtual Serial which appear as serial ports on your computer and can be communicated with using a serial terminal or standard serial port software. "

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With HID you are limited to the interrupt rate you have given in the device descriptors -- so with an interrupt rate of 20ms for example, you can only have a maximum of 50 packets transferred each second. However, you can change the interrupt rate to 1ms to regain the 1000 frames per second.

HID is actually very low overhead, except for all the setup you need - once set up, reports are just packed bytes in each packet which the host interprets. You're not limited to only 6 key codes if you make a custom keyboard; the 6 key codes per report limit is for legacy BIOS compatible keyboards.

If you are not looking to transfer data relating to input and visualization to a person, then HID class is not what you should be using. If you just want to send/receive packets, use the CDC-ACM class to make a virtual serial port or, if you really want to be fancy, create a completely custom interface with double banked endpoints.

I'll sum up with this: if you want useful advice on how to proceed, tell us what you are planning on making so we can guide you on the best practices.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks dean for the info.
My ultimate aim is to transfer maximum bytes or get maximum data rate in usb162 and usb1287...
I am currently having USB add on support from MCS electronics in which I am using USB in HID class (Interrupt and bulk transfer)...
Does CDC class will help to improve datarrate?
I should learn more before asking....:(
Currently I can send only 4080 bytes/sec inpipe using one in endpoint and 510 bytes/sec outpipe in both usb162 and usb1287.....
I don't think 1000 frames are transfered per sec. in my case even setting Interrupt polling time of 1ms...

If I use multiple endpoints...would it help??
even I am not able to configure endpoint of 256 bytes in at90usb1287...
I am bit confused....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm just an innocent bystander but perhaps you can say what bandwidth it is you are actually aiming for 5KiB/s, 10KiB/s, 20KiB/s, 50Kib/s,... what?

Simplistically if you are down around 5K but what you really need is 50K then I think it's clear this may be the wrong silicon (assuming that 5K isn't "slugged" somehow?)

(numbers in this post are for illustration only!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want datarate which would maximum possible in my case....i.e HID class..bulk transfer...and want to improve with best possible way...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's not much of a specification? How can you design a solution if you don't actually know what you want? Perhaps only USB3.0 delivers the bandwidth you require in which case the solution isn't even going to be Atmel based.

It just seems pointless to me trying to make a silk purse from sow's ear. If the AT90USB don't go fast enough ditch them and pick a chip that does deliver the bandwidth the solution requires. I'm wiling to bet the USB in an AP7000 AVR32 has higher performance for example.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I cannot help with such vague terms -- there's no point trying to maximize throughput if you don't know that you actually need the extra bandwidth. If you can determine what you need to make, and have trouble with the the datarate being too low I can help you, but just saying "I want it fast" isn't enough to go on.

That said, CDC will probably give you a good datarate depending on the OS driver -- although note that some drivers (e.g. Windows) will send each byte in a separate packet. Making a completely custom device will give you the best datarate, but will require special host drivers.

What language are you coding in? If you are using BASIC or something, that will almost certainly be responsible for the low datarate -- after all, you can only transfer as fast as you can fill and empty the buffers.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you both are right....thatd why I said I need to learn more before asking.....but my only point was to know that using at90usb1287 or usb162...how far you can achieve or I wanted to know someone's experience regarding datarate....as I am still beginner in usb, I wanted to make sure if I am not trying beyond limits...
can you suggest me some documentation....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But datarate doesn't actually matter until you haven't got enough (same goes for MIPS, code flash and SRAM). But the process of design usually involves doing some "back of an envelope" rough calculations of what bandwidths, RAM, flash, MIPS you need and THEN you pick the silicon that delivers enough of each.

So first identify your application, then determine the likely datarate(/bandwidth) you will need THEN consider whether the AT90USB is up to the job.