Trapped in exams, send help! Also, LUFA development.

All’s been unsettlingly quiet this last week; almost no discussion around the latest release at all. Usually I have many LUFA support requests (both on the mailing list, and via private email) banked up with no time to answer them all, so I’m a little disconcerted to actually have an empty inbox. For now, I’m going to assume that everyone is happy with the new release and no one’s having any problems — although the truth is probably more along the lines of no one’s bothered to upgrade.

This month is exams month; I am busy studying – well, partially studying – for my midyear exams which start at the end of this week. For this reason I’m not quite as active as I usually am in developing and replying to messages, but I hope everyone will just bare with me until the end of the month when I can go back to being a crazed caffeine-fuelled coding maniac. Early next month I’ll be sailing in a “small bathtub” (the Pacific Dawn, a mega-cruse ship which has featured prominently on the national Australian news for its Swine-infected crew these last few weeks) with my family for a week.

I’ve almost completed the device-mode class drivers for LUFA, although they are still a work-in-progress as I figure out how to design the corresponding host mode drivers. My goal for the host mode drivers are to allow for multiple drivers to be used in the one app, so that several classes of attached devices can be driven from the one one application easily. That’s not the same thing as driving multiple devices at once; this will only allow for a single device, but will allow for different class interfaces to be driven from the different drivers in the one application. That’s causing me a little grief working out how it will all fit together, but the results will be worth it.

I was a little astonished to go over the LUFA codebase earlier today. From such humble beginnings, the exported repository now weighs over 6MB, contains well over 500 source files and supports all the released Atmel USB AVRs and USB AVR boards. I realise that many of those files are duplicates thanks to the new Class and Low Level demos, but I still can’t believe that I’ve managed to accomplish so much.

As the current release is to be the “stable” API, I see no reason currently to continue with monthly releases at the expense of quality. Assuming no critical bugs are found, I’m comfortable in light of my exams and holiday to push back next month’s release to the end of the month, to ensure that all the new features are as complete and high quality as possible. The planned featureset is as follows:

  1. Removal of the cruddy “Scheduler” from all demos, switch to true loops instead for clarity (complete)
  2. Better library documentation page structure, with sub-page grouping (complete)
  3. New Device mode class drivers for easy implementation of the standard USB classes (complete)
  4. Documentation of the new Device mode class drivers (complete)
  5. Creation of new demos using the Device mode class drivers to be included alongside existing low level demos (complete)
  6. New Host mode class drivers for easy implementation of the standard USB classes as hosts (in progress)
  7. Documentation of the new Host mode class drivers
  8. Creation of new demos using the Host mode class drivers to be included alongside existing low level demos

So as one can see, the focus is on the new class driver framework which can be used in preference to the low level APIs for rapid application design. This means duplicating all the existing demos and re-implementing them using the class driver framework to give the same results using the different API layer.

On a final note to this rather eclectic post; I received an interesting comment from “Truth”, stating that all the compatibility troubles we’ve been experiencing with the Mass Storage Host demo can be tracked down to the routine waiting for data to be received, where it unfreezes both data pipes at once. It seems not all USB controllers can handle this, and it causes them to lock up. I’ve patched the function in the SVN to only unfreeze one pipe at a time, and it seems to have helped on the sticks I’ve tested, with all four working flawlessly. Hopefully that will mean an end to compatibility problems with USB flash drives from the next release.

 

Comments: 4

Leave a reply »

 
 
 

I have upgraded to new release, all works fine :-) Thank you :-)

Dean, can you give me an advice how can I implement complex USB device: one is my SmartCard reader, and second is Serial port. Serial is needed for debug purposes, as my Dragon with AVRStudio do not support my AT90USB1287.

 

Quote: “PJRC has brought out the Teensy++ sporting a larger ATMEGA32U4 microcontroller”.

This is not true. The Teensy++ sports a AT90USB646.
Have a look for yourself: http://www.pjrc.com/teensy/index.html

 

So it is – don’t know how I missed that. I’ll correct it in the original post.

Hey, turns out someone’s actually reading and checking the rubbish I’m writing ;) .

- Dean

 

Kreyl,

You need to have a look at the “DualCDC” demo in the library, to see how to combine a CDC serial port and another class (in this case, it’s actually two CDC serial ports but the principal is the same). As the CDC class is unusual because it uses two interfaces for the one function, you need to add in special “Interface Association” Descriptors to ensure they remain linked when you make a compound device.

Start a thread in the LUFA mailing list and I’ll be happy to help you further.

- Dean

 

Leave a Reply

 
(will not be published)
 
 
Comment
 
 
 

Vital Stats

  • 21 Years Old
  • Australian
  • University Student
  • Future Engineer
  • AVR Enthusiast

Languages Learned

  • LOGO (Forgotten)
  • Visual Basic 6 (Mostly Forgotten)
  • C
  • C++ (Passable)
  • Java