Project MyUSB

Go To Last Post
57 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First up, yes, the project is not currently in the AVRFreaks project section. This is because it's not finished yet, and it's much easier for me to upload the latest code changes via FTP to my site than it is to manage it here - plus I don't want to hijack the projects front page.

This is a thread for discussion, suggestions, bug reports and requests for help about all things MyUSB.

What is MyUSB?

MyUSB is my latest project, and is a completely open source library for the USB-controller enabled AT90USB series AVRs. It provides many peripheral drivers, as well as what will eventually be a complete USB driver suitable for Device, OTG and Host mode operations. My aim is it make it as clean and functional as possible.

Why use it?

As mentioned, it's open source, under the GPL - unlike Atmel's driver which is under their own license. MyUSB can be used freely in commercial and non-commercial applications, in accordance with the GPL license. I'd ask that commercial users donate a small amount to me for the use of the library via my website, but this is entirely optional.

It's mean, clean and just better than the Atmel driver. The code is written from scratch, and I've put a lot of thought and effort into its design.

What's it for?

Eventually, the entire AT90USB series AVRs, which have inbuilt USB controllers (but which still need quite a complex driver, hence why MyUSB exists). Currently only the AT90USB1287 is supported - as used on the popular USBKEY - since it's the only USB AVR I have access to. If you want it ported to your particular USB series AVR, send me a development board ;).

What's the status?

As of the time of writing, it includes many working peripheral drivers for the USB1287 specifically, and the USBKEY board. The USB driver's host mode is incomplete and the OTG code non-existent, but it works just fine in device mode.

A test application is included, as are demo USB device applications for a mouse and (thanks to Denver Gingerich) a keyboard. I'm about to start work on a CDC example, which is why that incomplete demo is in the library.

Where can I get it?

The current code is available from my website, on the MyUSB page here:

http://www.fourwalledcubicle.com...

Note the last updated time on the page - that will automatically change as I upload newer versions.

As the library is unfinished, expect newer versions to move things around and rename them, so don't expect the current code to reflect the finished library.

Where can I get updates?

If you have a specific question, post here or send me an email. I post blog entries about what I'm doing with the project on my website's blog.

Why the boring name?

Well, at the time of starting I couldn't think of anything more imaginative. If I'm going to change it I'd better do it very soon, as any later and I'll end up confusing a lot of people, and spending weeks changing all the references to the MyUSB name. If you have a better name, post it here.

Documentation?

I'm currently documenting the project on the MyUSB section of my website's Wiki pages.

Hardware?

I'd recommend purchasing a USBKEY for use with the project, however any USB1287-based board will be suitable for the library as it currently stands. I personally have a set of Tom's fantastic USBKEY header adapters and a set of female jumper cables which makes working with the board extremely pleasant.

That's all for now. Enjoy!
- Dean :twisted:

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

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

Off topic for this forum. Read the guidelines!

Seriously Dean, you should know better. How can you expect others to respect the guidelines when you abuse them in this way?

Jim

Your message here - reasonable rates.

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

Quote:

Off topic for this forum. Read the guidelines!

Seriously Dean, you should know better. How can you expect others to respect the guidelines when you abuse them in this way?

Jim

I've had an exam today, so my sarcasm detector's broken. Should it be registering a class-7 sarcasm level for your post?

EDIT: Aha!

Quote:
The Academy Projects area is a place to share your completed projects with others.

If you have a project in progress, or a project looking for contributors, please post a thread in the AVR Forum to gain feedback.

I think the spirit of that is to prevent 10,000 posts of "I want to make a AVR-powered super computer". MyUSB is not finished, but it does work and can be used to implement USB devices. It's far from complete however, but it's usable for a subset of its final features.

- Dean :twisted:

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

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

Dean,

By your own admission your project is not yet in the Academy section of this website. In any case the quote you have given clearly says that your post should have been in the AVR Forum. Or are you suggesting the rules don't apply to you?

Jim

Your message here - reasonable rates.

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

AND YOU WILL KNOW THAT I AM THE MODERATOR... WHEN I LAY MY VENGEANCE UPON THEE!

Hehe, sorry Jim. Just reminded me of Samuel Jackson in pulp fiction for some reason =)

Have to agree in principle, though. If it's not in the academy section, this thread could go in AVR forum and then get moved here once you post it. Otherwise people are free to post topics here about any project anywhere on the web and it defeats the whole purpose of this forum.

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

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

MyUSB is now in it's first stable, 1.0 release. It contains completed USB Host, and USB Device functionality. I've just created a project entry (to appease Jim) in the Projects section.

MyUSB contains demonstration projects showing off the following applications of the library:

    *  Audio In Device
    * Audio Out Device
    * CDC Device
    * General Library Test Application
    * Joystick Device
    * Keyboard Device
    * Keyboard Host
    * Keyboard Host (Using Pipe Interrupts)
    * Magnetic Card Reader Device (based on Keyboard demo)
    * Mass Storage Device
    * Mass Storage Host
    * Mouse Device
    * Mouse Host
    * Mouse Host (Using Pipe Interrupts)
    * USB-RS232 Device (based on CDC Device demo)

In addition, MyUSB now supports the AT90USB1286, AT90USB1287, AT90USB646 and AT90USB647 AVR microcontrollers.

Click here to visit the project entry.

- Dean :twisted:

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

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

MyUSB 1.1.0 has now been released. It contains quite a few enhancements and fixes:

Quote:
* Fixed DCONNI interrupt being enabled accidentally after a USB reset

* Fixed DDISCI interrupt not being disabled when a device is not connected

* Added workaround for powerless pullup devices causing false disconnect interrupts

* Added USB_DeviceEnumerationFailed event for Host mode

* AVR_HOST_GetDeviceConfigDescriptor routine no longer modifies ConfigSizePtr if a valid buffer pointer is passed

* Added ALLOCABLE_BYTES to DynAlloc, and added code to make the size of key storage variables dependant on size of memory parameters passed in via the user project's makefile

* Fixed incorrect device reset routine being called in USBTask

* Devices which do not connect within the standard 300mS are now supported

* Reduced control pipe freezing/unfreezing when sending control requests

* Removed incorrect ATTR_PURE from Scheduler_SetTaskMode(), which was preventing tasks from being started/stopped, as well as USB_InitTaskPointer(), which was breaking dual device/host USB projects

* Changed scheduler to use the task name rather than IDs for setting the task mode, eliminating the need to have a task ID list

* ID transistion interrupt now raises the appropriate device/host disconnect event if device attached

* Fixed double VBUS change (and VBUS -) event when detatching in device mode

* Added ability to disable ANSI terminal codes by the defining of DISABLE_TERMINAL_CODES in makefile

* Removed return from ConfigurePipe and ConfigureEndpoint functions - use Pipe_IsConfigured() and Endpoint_IsConfigured() after calling the config functions to determine success

Check out my blog for more details. If you are migrating from V1.0.X, there is a migration information page on my site wiki.

- Dean :twisted:

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

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

Hi Dean, good work again!

One question, when the device is in CDC mode, can it handle hardware flow control(DTR-DSR,RTS-CTS) on the serial port?

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

No, the CDC class doesn't allow for RTS/CTS as far as I know, unless you're interfacing to the outside world via a real USART. Could be in the specification somewhere and I missed it, however.

- Dean :twisted:

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

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

Hi Dean, just been looking in the class definitions, found this;
USB Class Definitions for Communication Devices Copyright © 1996-1999 USB Implementers’ Forum

Request SET_CONTROL_LINE_STATE (code 0x22), this request generates RS232 control line signals.
bmRequestType : 00100001B
bRequest : SET_CONTROL_LINE_STATE
wValue : Control Signal Bitmap
wIndex : Interface
Wlength : Zero
Data : None

D15..D2 : RESERVED (Reset to zero)
D1 : Carrier control for half duplex modems. This signal corresponds to V.24 signal 105 and RS- 232 signal RTS.
0 - Deactivate carrier
1 - Activate carrier
The device ignores the value of this bit when operating in full duplex mode.

Notification SERIAL_STATE (code 0x20), this notification sends asynchronous notification of UART status.
bmRequestType : 10100001B
bRequest : SERIAL_STATE
wValue : Zero
wIndex : Interface
Wlength : 2
Data : UART State bitmap

D15..D7 : RESERVED (future use)
D6 : bOverRun Received data has been discarded due to overrun in the device.
D5 : bParity A parity error has occurred.
D4 : bFraming A framing error has occurred.
D3 : bRingSignal State of ring signal detection of the device.
D2 : bBreak State of break detection mechanism of the device.
D1 : bTxCarrier State of transmission carrier. This signal corresponds to V.24 signal 106 and RS- 232 signals DSR.
D0 : bRxCarrier State of receiver carrier detection mechanism of device. This signal corresponds to V.24 signal 109 and RS-232 signal DCD.

So after all the CDC class does implement RS232 hardware flow control.
I’ve tested the SET_CONTROL_LINE_STATE request, and it work’s (with the Atmel CDC demo)

Now I need to write the SERIAL_STATE notification code to give feedback to the host of the control lines.
Any suggestions?

Thanks, marco.

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

Well, it looks like that's what the mandatory Notification endpoint is for. I see that SERIAL_STATE is supposed to be supported by the device when in ACM mode, although the host doesn't complain if it never receives any notifications.

The notifications seem to work over the notification INTERRUPT IN endpoint, but have the same structure as a control request. That makes life a bit simpler, as you can re-use some of the standard request defines.

I've typed the following straight in without testing, but it should suffice with a little tweaking to fix any of my typos:

Defines:

typedef struct
{
	uint8_t  RequestType;
	uint8_t  RequestData;
	uint16_t Value;
	uint16_t Index;
	uint16_t DataLength;
} USB_Notification_t;

typedef struct
{
	int RESERVED     : 9;
	int DataOverRun  : 1;
	int ParityError  : 1;
	int FramingError : 1;
	int RingSignal   : 1;
	int Break        : 1;
	int TXCarrier    : 1;
	int RXCarrier    : 1;
} USB_SerialState_Notification_t;

#define SERIAL_STATE 0x20

Notification Code: - Put this into the CDC task, and only send a notification when one of the bit states changes

struct Notification
{
	USB_Notification_t Header = {
					RequestType: (REQDIR_DEVICETOHOST | REQTYPE_CLASS | REQREC_INTERFACE),
					RequestData: SERIAL_STATE,
					Value:       0,
					Index:       0,
					DataLength:  2
					};

	USB_SerialState_Notification_t Data = {
						DataOverRun:  false,
						ParityError:  false,
						FramingError: false,
						RingSignal:   false,
						Break:        false,
						TXCarrier:    false,
						RXCarrier:    false
						};
};

uint8_t* NotificationPtr = (uint8_t*)&Notification;

Endpoint_SelectEndpoint(CDC_NOTIFICATION_EPNUM);

while (!(Endpoint_ReadWriteAllowed()));

for (uint8_t NotificationByte = 0; NotificationByte < sizeof(Notification); NotificationByte++)
  Endpoint_Write_Byte(*(NotificationPtr++));

Endpoint_FIFOCON_Clear();

I might update the USB-Serial demo with this code in the future.

- 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, it finally works. :D

I had to change some naming constants to be compatible with the CDC demo from Atmel (I'm using interrupt based instead of polling like in your version, right?), but it runs rock solid until now.

All I need now is more speed...

Looking at the datasheet, the maximum voltage the DataFlash can handle is 3.6V, that would bring the maximum speed to 12MHz, is there a way to get the full speed on the USBKey? I read somewhere on the forum that someone was running it at 16MHz. Did you ever experiment with different speeds?

Thanks,
Marco.

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

Dean,

Project is looking good- it looks like your simplification of the USB tasks is easier to work with than Atmel's examples.

One suggestion- I only recently started looking at your library, and thus have only your latest release. It looks like previous versions of the library are needed to "round-out" the package- but those are not available for download. For instance, I don't see any way to implement CDC functionaly with only your current download. You might want to make previous versions available.

I can probably assume that some portion of your examples and demonstrations in previous versions of the library will require a bit of re-write?

-Reid-
W0CNN

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

Dean,

Never mind! My unzipper wasn't working correctly, and I didn't see your Demos folder where I should have. All is well.

-Reid
W0CNN

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

fleemy wrote:
Thanks Dean, it finally works. :D
All I need now is more speed...
I have now been testing MyUSB, and it seems that using the CDC class demo, the data transfer is one byte at a time. For example:

		/* Read the recieved data endpoint into the transmission buffer */
		while (Endpoint_BytesInEndpoint())
			Buffer_StoreElement(&Rx_Buffer, Endpoint_Read_Byte());	

In the above, Endpoint_BytesInEndpoint() (which is defined as UEBCX) is always zero. At least that's what I saw when running within the debugger. If this is true, full speed really can't be realized.

Dean- any idea why this might be occuring?

-Reid-
W0CNN

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

Quote:

You might want to make previous versions available.

While I know this is moot point now, as you found the demos directory, previous versions are avaliable directly at http://fourwalledcubicle.com/files/.

Quote:

In the above, Endpoint_BytesInEndpoint() (which is defined as UEBCX) is always zero. At least that's what I saw when running within the debugger. If this is true, full speed really can't be realized.

Dean- any idea why this might be occuring?

If Endpoint_BytesInEndpoint() always returns 0, wouldn't that prevent it from ever storing anything in the buffer? In any case, I'd suspect your terminal app or drivers.

One guy managed to get 4.6MBit/S out of the demo, when the firmware dumped full endpoint packets to the host. Your drivers probably send out each byte in separate packets (possibly due to the fact that they try to emulate a real serial cable, with no buffering), resulting in a slow transfer speed.

- Dean :twisted:

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

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

abcminiuser wrote:

If Endpoint_BytesInEndpoint() always returns 0, wouldn't that prevent it from ever storing anything in the buffer? In any case, I'd suspect your terminal app or drivers.
I guess what I meant was Endpoint_BytesInEndpoint() is always zero _after_ reading the first byte. I suppose it could be my terminal (in this case, testing with Hyperterminal), but I don't know why it would do that. For instance, I have Hyperterminal send an ASCII text file and then have the debugger stepping through, looking at the various registers after each read byte. Even though you would think Hyperterminal would time out and stop sending, every single byte is making it through- no clue where it is getting "buffered". The debugger shows that we are reading the bytes one at a time.
Quote:

One guy managed to get 4.6MBit/S out of the demo, when the firmware dumped full endpoint packets to the host.
Impressive!
-Reid-
W0CNN

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

Hyperterminal isn't written with USB in mind, it works with virtual serial ports. To that end, internally it would probably have something like this:

void SendData(char* DataPtr, uint8_t Bytes)
{
   Serial.Open(Port);
   
   while (Bytes--)
      Serial.SendByte(*(DataPtr++));
}

The Windows USB-Serial driver is probably coded to emulate a true serial link's behaviour -- byte in, byte out. It would probably have a design like:

void EVENT_SendByte(char Byte)
{
   USB.SendPacket(USBtoSerialEndpoint, DataBuff, 1);
}

Which would send single bytes in separate packets to ensure that small amounts of data sent would be received by the attached device with as little delay as possible. Note that it would reduce throughput, but would also reduce communication latency.

Windows will automatically buffer USB packets for transmission, via its built-in USB stack. Thus adding breaksteps will not cause Windows to report errors if the device comes back online within its Tpacket timeout period (as the device never detaches from the bus).

The guy who got 4MBit/second used Linux, and the data direction was device->host. By sending full endpoints worth of data each time, the throughput was increased.

- Dean :twisted:

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

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

This may be a dumb question, but I was wondering if MyUSB in host mode supports hubs? IOW -- can I plug a hub into the USBKEY and both a keyboard and a joystick into the hub and have MyUSB enumerate and talk to both of them in the same application?

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

I'll have to look into that one. I, too, had the same thought when I first started, but I seem to remember some Atmel literature saying that it wasn't possible due to the reduced host controller. Actually, I think I'll ask Atmel on this one; no sense wasting my time if they've already got a definite answer.

- Dean :twisted:

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

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

I've asked Raphael (who is away until the 14th apparently), but thinking about it some more I wouldn't think it possible, or at least possible to do it well. The hub enumerates as a USB device, and sends event notifications through endpoints, requiring a good three or so pipes. That leaves four pipes left over for the four HUB ports -- not enough to properly drive four attached devices (or even just a mouse and a keyboard).

Best solution would be an extra USB82 or similar hanging off the SPI bus.

- Dean :twisted:

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

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

I forgot to post Raphael's reply:

Quote:
The AT90USB1287 reduced host controller was not originally designed to support hub.

There are several hardware limitations:

- No SPLIT transaction support (allow to mix full and low speed devices for the same hub)

- The target USB device address is common to all hardware pipe.

- The dynamic memory allocation mechanism for pipe generates troubles for devices disconnection and reconnection. (pipe memory should be allocated in the ascending hardware pipe number).

I have personally developed a USB host stack extension that support USB hub and real USB tree for USB mass storage devices (bulk only). The common address for all pipes requires special manual management for interrupt pipes.

I really do not recommend you to develop hub support or only for specific usage, because the hardware was not originally design for. You’ll have to implement special firmware tricks that’ll make the firmware really less understandable and with special limitations.

So while possible, it really isn't worth it. Again, much easier to just hang extra USB82s off the SPI bus or similar.

- Dean :twisted:

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

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

I've just uploaded a beta version of the 1.3.3 library, see my blog post at:

http://fourwalledcubicle.com/blog/archives/133

The new version changelog:

Quote:
Version 1.3.3 - UNRELEASED:
--------------------------------------------
* Added HID Report Parser API to the library
* Added Mouse and Keyboard host demo applications, using the new HID report parser engine
* Added MouseFullInt demo, which demonstrates a fully interrupt (including control requests) mouse device
* Fixed incorrect length value in the audio control descriptor of the AudioOutput and AudioInput demos
* Added MIDI device demo application to the library
* Fixed problem preventing USB devices from being resumed from a suspended state
* Added new CDC class bootloader to the library, based on the AVR109 bootloader protocol
* Added header to each demo application indicating the mode, class, subclass, standards used and supported speed
* Functions expecting endpoint/pipe numbers are no longer automatically masked against ENDPOINT_EPNUM_MASK or PIPE_PIPENUM_MASK - this should be manually added to code which requires it
* Fixed DFU class bootloader - corrected frequency of flash page writes, greatly reducing programming time

- Dean :twisted:

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

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

Quote:

* Added MIDI device demo application to the library

Thank you very much for that addition :D

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers

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

Nice additions, Dean -- I'm looking forward to testing some of them.

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

I've finalized 1.4.0 (bumped the version up to a minor rather than a revision, due to the number of additions and breaking changes) and uploaded it for general consumption.

Enjoy guys!

- Dean :twisted:

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

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

Your website isn't working. I've been trying to download the code all day but can't seem to get it to work.

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

Since the server hosting my site is currently down, I've attached a copy of the latest working version (not the official release) until the issue is resolved.

- Dean :twisted:

Attachment(s): 

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

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

Hi Dean, I was wondering if it is possible to have one USB device with a CDC interface combined with a Mass Storage interface?

I tried it, both get enumerated but neither work (I can’t install the CDC driver for XP, and XP ask's me to insert a medium in the mass storage disk).

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

There's no technical reason why not, per the USB standard. What AVR are you running it on? I'd suspect that you are running out of USB FIFO memory -- with six pipes and possibly double banking, you'd exhaust the available bytes fairly quickly.

- Dean :twisted:

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

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

Well Dean, it does not work, at least not if you want it to be CDC compliant.

From the USB-IF forum: https://www.usb.org/phpbb/viewtopic.php?t=13308&highlight=cdc

Quote:
After some more playing around, I believe the answer to "Works on Windows?" is "No".

If the device descriptor is associated with the composite device driver, regardless of the class/subclass/protocol value it will be treated as a composite device and the interfaces will be enumerated separately.

This results in the CDC Comm interface being associated with USBSer.sys (assuming the INF file references the interface as it should) and enumerated properly, but leaves the Data interface as an unknown device as there is no INF file associated with the interface number (nor should there be).

I haven't found a way around this regardless of what I do to the INF file, and trying to associate the composite device with usbser.sys results in catastrophic system failure (probably due to the extra interfaces / endpoints which usbser.sys does not expect).

I think I'm going to pursue option 5, even though it's outside the CDC spec. I need to support W2K so IADs aren't really an option (nor can we expect the customer to install a hotfix for XP) and it only needs to work with windows so being noncompliant is OK as long as it works with usbser.sys.

Option 5 is:

Quote:
Option 5. Composite: CDC + independent interface (HID, mass storage, etc.).

bDeviceClass = 00h.

CDC Interfaces:
communication interface that also handles CDC data
No union functional descriptor

Windows: Must provide an INF file for the CDC interface.

Happens to work under Windows but using the communication interface for data isn’t CDC-compliant

Can your code handle the CDC interface with only one interface for communication and data? Will the overall speed be slower?

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

Hmmm, an interesting read. The limiting factor here isn't the USB standard or the AVR - it's Windows. So the answer is that it should work, but won't because Windows isn't bright enough to properly delegate the interfaces to the appropriate generic built in drivers.

Quote:

Can your code handle the CDC interface with only one interface for communication and data? Will the overall speed be slower?

It won't be compliant by any means, so all bets are off regarding other OS and even other Windows OS version compatibility.

A Google search for "CDC and Mass Storage" brought me right back here, to this thread. Seems someone's made up a nice PDF on how to do exactly as Jan described in your post, using a single interface for all the CDC endpoints. It's written for Atmel's code, but you can apply the theory to my MyUSB code.

Yes, my library supports just about anything you can think of inside of the USB Standard/hardware/OS restrictions -- it supports more features than Atmel's own driver, such as multiple configurations. No, it won't cause any slowdown at all (although the hardware is limited to full speed only which is slow anyway) as the descriptors have no bearing on the device speed.

- Dean :twisted:

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

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

Hi Dean, thanks for the link, I’ve looked all over the net but not on this forum, I’ve should have known better. :oops:

Apparently I’m not the only one looking for this functionality, and having problems with it to work on Windows.

I did exactly what mikeboro explains in his tutorial, but was using 3 interfaces, there lies the problem as Windows was enumerating 3 devices instead of two and was looking for drivers that did not match.

Thumb up for this forum! 8)

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

Since my site is currently being transfered to a new host, I'll post the new BETA release here for public testing.

Attached is the BETA of the MyUSB 1.5.0 library. It contains a few significant changes to the library, plus many tweaks, enhancements and API cleanups. The most important feature is the full documentation via DoxyGen, downloadable pre-made as a separate file.

Please post here if you encounter any problems (or corrections, suggestions, etc.) with the new version.

Changelog for the new version:

Quote:

* Fixed MIDI demo, now correctly waits for the endpoint to be ready between multiple note messages

* Added CDC Host demo application

* Added KeyboardFullInt demo application

* Endpoint and Pipe creation routines now mask endpoint/pipe size with the size mask, to remove transaction size bits not required for the routines (improves compatibility with devices)

* Fixed AudioInput demo - now correctly sends sampled audio to the host PC

* Shrunk round-robbin scheduler code slightly via the use of struct pointers rather than array indexes

* Fixed off-by-one error when determining if the Usage Stack is full inside the HID Report parser

* Renamed Magstripe.h to MagstripeHW.h and moved driver out of the library and into the MagStripe demo folder

* Added preprocessor checks to enable C linkage on the library components when used with a C++ compiler

* Added Still Image Host demo application

* The USB device task now restores the previously selected endpoint, allowing control requests to be transparently handled via interrupts while other endpoints are serviced through polling

* Fixed device signature being sent in reverse order in the CDC bootloader

* Host demos now have a seperate ConfigDescriptor.c/.h file for configuration descriptor processing

* HostWithParser demos now have a seperate HIDReport.c/.h file for HID report processing and dumping

* Removed non-mandatory commands from MassStorage demo to save space, fixed SENSE ResponseCode value

* CDC demos now send empty packets after sending a full one to prevent buffering issues on the host

* Updated demo descriptors to use VID/PID values donated by Atmel

* Added DoxyGen documentation to the source files

* Fixed Serial_IsCharRecieved() definition, was previously reversed

* Removed seperate USB_Descriptor_Language_t descriptor, USB_Descriptor_String_t is used instead

* Changed USB_GetDescriptor() prototype to support multiple languages

* Removed unused Device Qualifier descriptor structure

* Renamed the USB_CreateEndpoints event to the more appropriate USB_ConfigurationChanged

* Fixed MassStorageHost demo reading in the block data in reverse

* Removed outdated typedefs in StdRequestType.h, superceeded by the macro masks

* Corrected OTG.h is now included when the AVR supports both Host and Device modes, for creating OTG products

* USB_DeviceEnumerationComplete event is now also fired when in device mode and the host has finished its enumeration

* Interrupt driven demos now properly restore previously selected endpoint when ISR is complete

* USB_HOST_TIMEOUT_MS is now overridable in the user project makefile to a custom fixed timeout value

* Renamed USB_Host_SOFGeneration_* macros to more friendly USB_Host_SuspendBus(), USB_Host_ResumeBus() and USB_Host_IsBusSuspended()

* Renamed *_*_Is* macros to *_Is* to make all flag checking macros consistant, Pipe_SetInterruptFreq() is now Pipe_SetInterruptPeriod() to use the correct terminology

- Dean :twisted:

Attachment(s): 

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

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

I think the project deserves a proper name. How do people feel about renaming MyUSB to LUFA - Lightweight USB Framework for AVRs? If not that, any suggestions for another proper name?

MyUSB is now released under the MIT license, allowing for its use in commerical applications with no obligations towards source disclosure.

Is anyone interested in a mailing list for the project?

Finally, is there any interest in an AVR32 port of MyUSB to the UC3B devices?

- Dean :twisted:

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

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

Quote:
to LUFA

which instantly made me think:

Was that intentional? ;)

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

Quote:

which instantly made me think:

Yes -- funnily enough I thought of it in the shower (which led me girlfriend to raise an eyebrow when I jumped out to write it down.

I thought the acronym was memorable like ButtLoad, but unlike the former unlikely to offend. Thoughts?

- Dean :twisted:

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

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

You were taking a shower with your girlfriend? If so I'd have thought that thinking about computer project names would have been the last thing on your mind! :lol:

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

Quote:

You were taking a shower with your girlfriend? If so I'd have thought that thinking about computer project names would have been the last thing on your mind! Laughing

I have a multithreaded mind ;).

- Dean :twisted:

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

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

abcminiuser wrote:
Quote:

You were taking a shower with your girlfriend? If so I'd have thought that thinking about computer project names would have been the last thing on your mind! Laughing

I have a multithreaded mind ;).

- Dean :twisted:

As long you don’t end up with a blue face and need to reboot, no problems. :lol:

‘LUFA’ is fine for me.

abcminiuser wrote:
Finally, is there any interest in an AVR32 port of MyUSB to the UC3B devices? Dean :twisted:

That would Interest me, is it a big jump to code 32bit AVR’s?

Marco.

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

Quote:

That would Interest me, is it a big jump to code 32bit AVR’s?

Haven't a clue - I don't have any. I believe the UC3B's are similar to the AVR8's (but obviously 32-bit), while the USCA's are slightly different. The whole point of the AVR32 architecture is that it's an extention of the original AVR core, so you can still program them in the same way as their smaller bretheren. There's a special version of AVR-GCC and binutils that targets the AVR32s.

The UC3A USB controller is quite different to the AVR8 USB controller, so a port to that would be difficult. The UC3B is much more similar, thus would be a good place to start.

MyUSB 1.5.2 was released yesterday. It is now licensed under the permissive MIT license, rather than the LGPLv3 license. I've decided to keep the name as it is for now (since no one seems to care much).

- Dean :twisted:

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

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

Hi Dean

thanks for sharing MyUSB.

I have two minor issues with the header files only (I like to turn on most of GCC's warnings on my code, notably -Werror) which I would like to point out here.

I would greatly appreciate it if you could support C99's way of initialise structure members by name, i.e:

{ .xxx = 123; .yyy = 456; }

instead of GCC's (obsoleted) extension

{ xxx: 123; yyy: 456; }

I also stumble on binary constants (0b...) in header files. They give me a lot of warnings on each .c file that includes a header file from MyUSB.

I admit they are very minor issues in an otherwise great piece of software. But fixing it would increase portability to other compilers as well.

Cheers,
Thomas

pycrc -- a free CRC calculator and C source code generator

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

The binary constants complaint is a legitimate one, as some users would not be using the WinAVR patches to get them. However, doesn't the latest GCC versions include the 0b prefix out of the box now? That makes me hesitate a bit, as binary constants makes the code clearer.

As for the second, placing the dots before the element names just causes GCC to fail to compile, whining about a ":" token which doesn't actually exist in the file. Since the code is specifically written for GCC, is there any practical reason to implement this change?

Just trying to avoid unnecessary busy-work for the sake of it, if there's no technical reason to implement the changes.

- Dean :twisted:

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

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

Hi Dean,

I have tried the structure declaration with avr-gcc 4.2.2 and get the same error as you do. With avr-gcc 4.3.0 the code compiles. Since I get only warnings with the "x: 123" initialisation, I also think it is probably better to leave it as it is for the near future.

Thomas

pycrc -- a free CRC calculator and C source code generator

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

abcminiuser wrote:
There's no technical reason why not, per the USB standard. What AVR are you running it on? I'd suspect that you are running out of USB FIFO memory -- with six pipes and possibly double banking, you'd exhaust the available bytes fairly quickly.
What about 1 USBKey and 2 virtual serial ports?
I have some thoroughly untested code that
steals heavily from your USBtoSerial demo.
It occurs to me that having an extra virtual
serial port would be good for debugging.
The USART is busy doing SPI work and using
RS232 with my hardware is a bit messy.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

All, please note that there is a new Google Groups for MyUSB support/discussion over at http://groups.google.com/group/myusb-support-list.

Skeeve: CDC + anything isn't really a viable option under Windows for technical reasons. However, CDC x 2 should work -- you could use the same notification pipe for both I suspect, reducing the total number of endpoints needed.

- Dean :twisted:

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

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

Hi Dean,

I want to build an USB joystick host with the AT90USB1287. In detail I need to acquire data from a Saitek X52 and do some stuff.

Before reinvent the wheel... your MyUSB code can do this?

Thanks a lot for that and all others tips!
Marco / iw2nzm

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

Sure, you can modify the existing "MouseHost" demo to work with your particular joystick (just change over the protocol code the demo looks for to the Joystick rather than Mouse protocol, and change the data in to match your joystick's data).

If you want a more general solution, do the same with the "MouseHostWithParser", which includes a HID report parser so you can design your host to work with any USB joystick, as you can then enumerate the joystick's report components (X, Y, Z axis, buttons, hats, etc.) even if the report structure is different between devices.

- Dean :twisted:

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

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

Very, very cute :)

Thanks!
Marco / iw2nzm

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

Thanks for doing this!

I'm thinking about using USB to let a PC program fiddle with my gadget.

Download - Read Read Read - Confused - Read Read Read...

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

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

Thanks for doing this!

I'm thinking about using USB to let a PC program fiddle with my gadget.

Download - Read Read Read - Confused - Read Read Read...

Oh. Well, I guess you deserve to be thanked twice.

274,207,281-1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

Pages