LUFA 101122 BETA3, Internship

I’m totally freaking out right now, and no, it’s not because of my exams next week. It’s because my Atmel internship is almost here! My flights are booked, my accommodation contract is nearly finalized, and in only a few short weeks I’ll be heading over for my first solo overseas trip. If anyone’s in the area of where I’ll be staying, give me a buzz since otherwise I’ll be stuck in a room by myself all day, and spending Christmas alone with nothing to do is just plain no fun. I’ve found that my dorm room will be equipped with high speed internet access while I’m there, so I’ll try to post updates about my internship – and my trip in general – rather than going radio-silent for three months.

It’s time for the third – and most likely final – beta of the upcoming LUFA 101122 release. This new release contains a big “gotcha” for those that don’t read the migration notes; the EVENT_USB_Device_UnhandledControlRequest() event has been renamed to EVENT_USB_Device_ControlRequest() which will break device mode operation for those not paying attention. This change isn’t just because I like being sadistic – it actually serves a purpose.

Some people have asked me what the “cleanest” way to intercept and alter incoming standard control requests – the ones normally processed internally in the library. Either they want to supply their own handler for specific requests to override the internal handler, or they want to be able to filter out requests and prevent the library from handling them at all. Before now the only way to do that was to resort to ugly hacking of the library core.

But no more. This event name change hints at the small underlying change I made to the event; it is now fired before the internal library handlers. That means that the user application now gets first dibs over control requests (regardless of how the request read was initiated) which means you can now filter and override handlers in a standard manner without special hacks. As a bonus, reversing the order this way also makes the compiled code very slightly smaller.

As always, thank you to the throngs of groupies people who have been kind enough to respond back with bug reports, suggestions, questions and donations. I don’t like sounding like a broken record, but suffice to say your contributions keep me motivated to keep coding.

One last quick thing to mention; LUFA now has a public Bazaar mirror to match the existing SVN, GIT and Mercurial mirrors. I know that people like to have personal choice on which client they wish to use for source control and project development, so hopefully these pre-made public mirrors will make life easier for everyone.

Grab the new beta via Google here.

 

Comments: 12

Leave a reply »

 
 
 

[…] This post was mentioned on Twitter by KnurdStuff, Dean Camera. Dean Camera said: New post: http://bit.ly/bDfdXL […]

 

AVRISP-II failed to programm eeprom atmega32 (atmega8). Flash programmed very fast and without errors.
Sorry for bad english.
Thank you for this big anf greatifull work!

 

You’re going to be living in Trondheim? I’ve only been in the southern part of Norway but from the pictures I’ve seen that should be pretty sweet. Have fun with your daily two hours of daily sunlight!

 

Pavel,

What ISP speed are you using? The programmer should default to 125KHz, which may be too fast for your target depending on the clock it is using. Are you certain you have the target attached to the correct ISP and GPIO pins of your programmer? What programmer hardware are you using?

– Dean

 

I’ll be taking a boatload of lactase enzyme pills (damn lactose intollerance!) and vitamin D pills to try to combat the local cuisine and lack of sunlight. Should be lots of fun, I can’t wait to get there now.

– Dean

 

I have use at90usb162 board (avrisp-ii from this site without gtl level-shifter).
speed change from 125khz to 4mhz. flash writing well always.
eeprom(atmega8) only first 100-120 byte..

ATtiny2313, ATtiny44, ATtiny13, Atmega162. – eeprom and flash good.

Eeprom ATtiny26, Atmega8535, atmega8l, atmega32 – flash-good, eeprom – errors. (if write in eeprom small byte (5-10), sometimes programm eeprom not reports about error, but if programm full eeprom – error.)

programm from avrstudio (last from atmel site)

sorry for this terrible english…

 

Pavel,

Sorry, I didn’t read your comment properly the first time where you said that FLASH programming worked, but EEPROM did not – I thought neither was working correctly. Could you please try the latest revision of the code (from http://www.lufa-lib.org/latest-archive) and see if that helps? I fixed a non-paged FLASH/EEPROM ISP programming issue a month or so ago, which hasn’t made it into an official release yet.

– Dean

 

Thank you very much. Everything work fine. I compiled abcminiuser-lufa-lib-d03b55b – trunk.
then i erase, write, read eeprom and flash atmega32 and atmega8 – all work fine!

 

Great to hear Pavel! Enjoy your programmer, and please let me know if you encounter any more issues.

– Dean

 

Hello Dean !

I have a problem with the lastest beta release of LUFA. I’m using the latest WinAVR stable release (20100110) to compile the demos. When using LUFA-100807 GenericHID lowlevel device demo on a at90usb162, control reports works perfectly (IN and OUT), but does not work when using LUFA-101122-BETA3, i.e. I got an exception when sending a control message using libUSB-win32 and a .net wrapper.

The interrupt endpoints seem to work correctly though.

Best regards,
Carl

 

Carl,

Whoops! In the latest beta the name for the control request handler has been changed from EVENT_USB_Device_UnhandledControlRequest() to EVENT_USB_Device_ControlRequest() as the user application callback is now fired before the internal library handlers. Looks like I forgot to fix this in a few of the demos. Renaming this yourself should have it working again – I’ll prepare a BETA4 tonight with the patch.

– Dean

 

Hi Dean !

Thanks for the kind reply, since you already explained this in your original blog post. Next time I will try to RTFM, and avoid bothering you for nothing in the same time…

Have a nice evening,
Carl

 

Leave a Reply

 
(will not be published)
 
 
Comment
 
 

 

Vital Stats

  • 35 Years Old
  • Australian
  • Lover of embedded systems
  • Firmware engineer
  • Self-Proclaimed Geek

Latest Blog Posts

RSS