Memos From the Cube

So, a few new scraps of news on my end.

Firstly, there’s a new LUFA BETA out. This will the first release of 2010, and with the huge, huge increase in popularity of the last 091223 release, I want to make sure this release is as defect free as possible. To do that, I’m doing a full two-week beta cycle, where people are encouraged to download the beta code, try it out in their projects, and report back any issues (letting me know by email is fine too). This new code contains a bunch of neat things – see this discussion post for the changelog. Please try it out. Pretty please?

In other news, last week fellow AVR nut enthusiast Mike came over, to discuss his pet project, a LUFA powered HTTP client, using a common 3G wireless modem to pull data from the internet. I met Mike at last month’s AVRFreaks Melbourne meetup, where he showed me the current state of his project in an awesome demo done right there, wirelessly. I’ve since worked with Mike to clean up the code quite a lot, so that it is now in a state where people can actually read it, an attribute underappreciated in today’s society *grin*. We’ll be working on this a lot more hopefully in the near future, replacing the PPP layer with one from the Contiki project, and making it work with more 3G modems from other vendors. This is pretty cool stuff, as it opens up the door to future things like self-updating remote telemetry devices, with data being uploaded to the internet anywhere there is 3G access for only a couple of dollars each.

Finally, I went to my first Combined Community Hackerspace Melbourne meeting on Saturday, and got a great lesson in surface mount soldering (using the toaster oven method) from Michael, another AVRFreaks member from the meet up. We all got to solder three different sizes of surface mount parts ourselves on a test board, ranging from “Damn small” to “Goddam where the hell is it?” sizes. I think the most important lesson I learned that day was that yes, wind is in fact the enemy of SM electronics. Playing “is that a resistor or a chip crumb” with the others was certainly not something I would have predicted. Good times were had by all, and I look forward to future futile attempts trying to convert Ross over from the Teensy USB stack to my LUFA USB stack in the near future.

While the LUFA beta is pushed to kind testers, I’m still waiting on a package from the land of Uncle Sam, containing a custom AVR programmer board, and a bunch of TINY10 samples. Hopefully I’ll receive it and be able to complete my AVRISP-MKII clone project’s TPI programming support for the 100219 release deadline.

Wowza. The 091223 LUFA release has had around 1100 downloads, nearly causing my server to go into conniptions. That’s easily more than double the number of releases of previous releases, and I’m pleased as punch with the increased uptake. I’m dying however to get a new release out with the major fixes to the AVRISP-MKII project code and other demos, but I want to complete TPI protocol support in the AVRISP-MKII project first. Thankfully it looks like I’ll have that working very soon, so we can all look forward to the next official release. I’m planning to have it enter a two week beta testing cycle (with the increased user-base, it is now more important to ensure each release is as free of defects as possible) beginning late this week.

I thought I’d fill up this entry with a short guide to loading my XPLAIN Bridge firmware into the XPLAIN board, after some coaxing. Without further ado, here it is!

Loading the XPLAIN Bridge code into the XPLAIN board

Step 1: Get the Source

Before you begin, you will need a fresh copy of the latest XPLAINBridge code. This is part of my LUFA project, however you will need the most recent in-development code instead of the latest LUFA release. Start by downloading a zipped package of all the latest LUFA code, straight from my online source repositories.

Extract out the entire package somewhere on your hard drive – a path without spaces is best (such as C:\AVR\LUFA_SRC\).

Step 2: Get the AVR-GCC Compiler and Tools

Most people should already have the required tools installed for AVR development, but I’ll put it here for completeness. On Windows, look no further than the WinAVR package – just download, install and you’re done. On Linux, grab the “avrgcc” package from your repositories. This will install the required compiler which can compile your source code into machine code that can be loaded into the AVR microcontrollers on the XPLAIN.

The other tool you’ll need is the Atmel FLIP software, which will act as our programming frontend for the USB AVR later on. Download and install it – if you are on an x64 based system, you’ll need these signed drivers instead.

Step 3: Build the Source

LUFA is a big project. No seriously, it’s HUGE and I’ve spent a lot of time on it. While it can make the USB AVR on the XPLAIN board to wondrous things with a minimum amount of pain, we’re only interested in one small project I’ve made with it. For that reason, you’ll need to navigate to the {LUFA Root Directory}/Projects/XPLAINBridge/ folder before you compile, lest you sit around for 10 minutes watching around 100,000 lines of source code be compiled.

Once in the XPLAINBridge project, you need to open up your terminal (that’s Command Prompt in Windows-land) and type make all. This will compile the XPLAINBridge code into the machine code needed for the AVR processor to execute.

When run, you’ll see a lot of similarly named files with different extensions be created. Most of these are related to the compiling itself, and we are only interested in the XPLAINBridge.hex file that is created – that’s the file which contains the compiled machine code for our programmer software to use.

Step 4: GET TO THE BOOTLOAAWDERRR!! (this is funny if you read it in an Arnold Schwarzenegger voice)

Unless you’re unlucky enough to have a first revision XPLAIN board (which 99.99% of you will not) your XPLAIN’s USB AVR comes preloaded with a special AVR program in it called a bootloader. This special program lives in the upper sections of the chip’s non-volatile FLASH memory, and allows you to reprogram the remainder of the memory with a regular AVR application through a non-standard interface (in this case directly from the USB port) without external hardware.

To get to the bootloader, you need to jumper the TCK pin to GND on the USB AVR JTAG header, that is, pins one and two shown here:

When jumpered, plugging in the XPLAIN to a PC via the USB port will cause it to start it’s DFU class bootloader. You should get a driver popup under Windows – point it to {FLIP Install Directory}/usb for x86 systems, or to the drivers in the signed driver package you downloaded earlier for x64 systems.

Step 4: Program the USB AVR

After you have started FLIP, you should see a screen similar to the one below (click to enlarge).

First click the Select Target button (#1). From the dropdown, choose the AT90USB1287 entry (this is the USB AVR mounted on the XPLAIN board) and click OK to dismiss the window. Next, open the device via the Select Communication Medium button (#2) and choosing USB – click OK when the dialog opens up to establish a connection with your XPLAIN’s USB AVR.

Now you need to load the XPLAINBridge firmware into FLIP. To do this, click the Load HEX File button (#3) and select the XPLAINBridge.hex file you compiled earlier in step 3. Program it into the USB AVR by hitting the Run button (#4). Remove the jumper you placed earlier to access the DFU bootloader, then start the new firmware via the Start Application button (5). Don’t worry if you forget to remove the jumper before this step – just remove it and power cycle the board to exit the bootloader.

Step 5: Load the Bridge Drivers

By now, you should see a new driver window pop up, asking for the LUFA XPLAIN Bridge drivers. You’ve now successfully programmed in the bridge firmware! In the mode you are currently seeing, the firmware is acting as a USB-to-Serial bridge for the XMEGA AVR on the XPLAIN board. Before it will work correctly however, we need to supply the right drivers. In actual fact, Windows already contains the appropriate drivers, but you’ll need to supply the XPLAIN Bridge.inf file in the {LUFA Root Directory}/Projects/XPLAINBridge/ folder for it to use them. This will probably pop up an unsigned driver warning on your system — this is Microsoft’s fault (and not mine!) for not signing their own driver.

When loaded, you’ll be able to communicate with your XMEGA chip by the new virtual COM port the driver will create on your system.

Step 6: Load the PDI Programmer Drivers

The XPLAINBridge firmware contains a second mode – it can act as a clone of an Atmel AVRISP-MKII so that you can reprogram the XMEGA from within AVRStudio. To access this mode, you’ll need to jumper the TDI and GND pins of the USB AVR JTAG connector (pins 9 and 10) together and power-cycle the board, much like you did to enter the DFU bootloader:

This should cause Windows to ask for a second set of drivers, for the new AVRISP-MKII Clone Programmer device. Point it to your {Atmel Program Files Folder}/AVR Tools/usb/ folder (for x86 systems) or {Atmel Program Files Folder}/AVR Tools/usb64/ folder (for x64 systems) and let it install Atmel’s drivers. You’ve now got yourself a programmer! To exit programming mode and return to the USB-to-Serial bridge mode, just remove the jumper you placed on the JTAG port and power cycle the board.

Step 7: Program the XMEGA AVR

When in programmer mode, you can reprogram the XPLAIN’s onboard ATXMEGA128A1 microcontroller via the PDI protocol, using any supported host software you like, such as AVRDude (note: PDI programming is broken in the latest release and requires manual patching) or Atmel’s own AVRStudio. For AVRStudio, you can follow the procedure in the AVR Tools help file, included with the application – just connect to the AVRISP MKII programmer, select the ATXMEGA128A1 target and use it like you would a regular AVRISP-MKII device.

Well nuts.

Last week I completed my final goal for my XPLAIN replacement firmware – to merge the XPLAIN USART bridge and PDI programmer into the one single firmware, so that either can be used with the use of a jumper, much like the method used to access the DFU class bootloader. I was hoping that people would be jumping for it, but it seems not the case; not only has the interest been marginal at best, but it turns out I forgot to add a critical file to the SVN repository. That’s right, it would never have compiled for anyone anyway, yet I only find out almost a week later. Hear that? That’s the sound of my nerd heart breaking when I realized that no one cared about the work I did. Nevertheless, perhaps when Atmel begin to use it, it will gain a little more recognition — and the repository is now fixed.

Actually, I did have a big success last night; I managed to connect the free uIP TCP/IP stack up to my RNDIS host class driver, and make a very simple webserver work when connected to my ADSL modem via USB. That’s a little different to my own home-grown TCP/IP stack used in the regular LUFA demos, because uIP is designed to be far more robust (and can handle multiple simultaneous connections). The code is now in the SVN under Projects/Webserver, and I’ll be extending it to include FatFS so that it can serve files off of the dataflash.

I was having some real trouble getting it all working correctly, with some very odd behavior: while about 30% of the time my code would read in packets correctly, process them via uIP and respond, the other 70% of the time it seemed that something was getting severely corrupted (corrupt data being read in from the USB interface, random restarts, etc.). Initially I suspected a uIP misconfiguration causing stack corruption, but eventually I narrowed it down to the way I was handling bidirectional data endpoints in the RNDIS host driver. It seems a patch I made a while back broke things rather than fixed them. While the USB AVRs can’t really support bidirectional endpoints in device mode (it’s possible to do it, but only if the host expects half-duplex communications) host mode is another matter entirely. I was under the impression that a trick similar to device mode was needed to get bidirectional data flowing, but it turns out I can just allocate two separate pipes. Doh – when I switched the pipe token to change the data direction, data from the device being sent would corrupt the USB banks and cause all the random issues.

That means the RNDIS and CDC host drivers in the latest release are badly broken, and will be fixed in the next official release. I hate rolling back patches, but in this case I was wrong to change the code in the first place. For those wanting the code right now, you can either download it as an archive straight from the GIT repository host, or use the GIT/SVN mirrors.

I was planning on connecting my USBKEY up to the general internet to show off its new capabilities, but yet more heartache – something either in my ISP or my equipment is blocking outside connections, despite my fiddling with port forwarding, DMZ and Firewalls. For now, you’ll just have to test the source on your own network equipment.

One more bit of news; while no one seems to care about my XPLAIN work, LUFA in general is finding more new users. Each LUFA release typically gets around 450 downloads total – the latest releast is just about to hit the 1000 mark. Awesome!

I’m totally excited to hear that Atmel actually wants to “refer” to my XPLAIN programmer firmware (that is, my AVRISP-MKII project which just to happens to work great as an XPLAIN PDI programmer). What “refer” means isn’t totally clear to me — either they’re scrapping their own effort and just want to link to my code, or they want to purchase a license to use it without attribution. Yeah right, in my dreams. Not to worry, at least I’m getting an AVR-ONE! from Atmel for my efforts.

On the XPLAIN front, I have some good news; no longer do you have to wrestle with two different sets of firmware for programming and USART debugging! Today I merged the two into one, updating my LUFA XPLAINBridge project (in the current SVN, not the current release package) so that it will act as either a PDI programmer or a USB-to-USART bridge, depending on a jumper placed across the TPI pin of the JTAG port on startup. Those wanting to see how it works (basically I just pull in the AVRISP-MKII project files and run them when the jumper is set) can grab the latest code from the SVN repository, or those who are impatient can just download the precompiled .HEX (AVRFreaks login required) for the XPLAIN board.

As mentioned above, on startup, the new code will sample the TDI pin (pin 9) of the “USB AVR JTAG” port on the XPLAIN. If this pin is left unconnected to anything the device will enumerate as a USB-to-Serial bridge for the XMEGA. When grounded to pin 10 of the JTAG port the board will enumerate as an AVRISP MKII for PDI programming of the XMEGA through AVRStudio.

Finally, another BIG THANK YOU to those kind souls who have donated to support my LUFA and other work. Words fail me – I am very touched by your generosity. Open Source!

I forgot to write about this the other day, but better late than never. Last Monday we Melbournians had our first (of many?) real-world meetups where several AVRFreaks members got together for a drink and a chat. I had a blast of a time, and it was great to finally put some names to faces in the AVRFreaks community. Turnout was good, with eight or nine people braving the 43 degree (Celsius, not Fahrenheit!) heat outside in the city.

I must say, it was both fascinating and odd to be talking to people who you’ve only met over the internet; it was a sort of surreal bleeding from one world to another. That said, all the members were very engaging and I hope there will be many similar meet-ups in the future with more people attending. One thing that shocked me the most was that one or two people actually mentioned things I’ve written here on my blog – I wasn’t aware that anyone actually read the junk I put down here; I’ve been using it mainly as a brain dump to ease the mental pressure. I’ll have to be more careful what I write in the future.

I hope Neil will forgive me for appropriating his group shots so I can post them here. I’ve labeled everyone with their first name and AVRFreaks username, so you can put a name to the, well, name. Click the photos to enlarge.

Awesome. One of the highlights of the night (for me) was the personal demo Mike gave me of his pet project – a LUFA USB host connecting to and downloading a webpage via a Three Mobile Broadband USB modem. There’s a heck of a lot of work he’s put in there to get it all up an running, including mashing LUFA, a set of PPP code examples, a TCP/IP stack and a lot of glue logic together to make a small unit of pure awesomeness. With a bit of cleanup it could become very useful for mobile units in the field, downloading updates straight from the internet wherever there is mobile coverage. Let’s see people do THAT with a Zigbee .

Hard to believe that it will be another month since the last LUFA release in only a few short days – and yet, there hasn’t been enough changes to warrant another official release just yet. That’s mostly because I’m starting to run out of things to work on, and can’t find the motivation to finish some of the large unfinished sub-projects I’ve begun.

However, I do have some exciting news. Up until now, LUFA has only solved half of the equation about USB devices — it allows for the creation of feature rich embedded devices and hosts, but doesn’t solve the “PC Problem”, or more aptly, how the hell one can drive a custom USB device from a PC. All of LUFA so far has focused on the standard classes which most operating systems support out of the box, which means no need for the creation of drivers. Those wanting to create custom devices (such as a data interface for a temperature monitor) have usually resorted to misusing the HID or CDC-ACM (virtual serial) classes for the transport of arbitrary data.

The only other options have been either to code for libusb under Linux – or, to a very limited degree, Windows – or get friendly with the Windows Driver Development Kit. I myself had a go at the latter, but as it relies heavily on Win32 API stuff, I was less than useless at getting anything to work. However, now there’s another solution.

Enter WinUSBNet. This is a MIT licensed .NET wrapper around the Windows LibUSB driver, present in Vista, Windows 7 and (once a patch is installed) XP. This gives a very user friendly way to bind to custom USB devices, using completely vendor-specific interfaces – eschewing the standard classes completely. This isn’t a cross-platform solution (libusb would be required for *nix platforms) but in the world of Windows, it makes all the difference. Seriously, try it out if you are primarily after Windows compatibility, as it works under all the .NET languages from Microsoft.

WinUSBNet is a creation of Thomas Bleeker, who as mentioned has been kind enough to make it MIT license — the same license used with LUFA. That means that by using both, you can have a custom USB device and Windows software for free, with no legal obligations other than to give both of us credit for the components used in your design.
I’ll be making a LUFA demo using WinUSBNet soon for the next release, so that people can see just how powerful the two are when used together. I’m excited, to say the least.

Well, the last few days has had several successes for me.

USB Gamepad: As part of my Christmas present, my girlfriend got me a neat USB gamepad — basically, a USB Playstation controller. Since it has a USB connector, I naturally jammed it into my USBKEY so I could write a host driver for it. Imagine my surprise when the LUFA Josytick Host demo worked perfectly on it, without any modifications. I’m not used to having hardware just work with my own code. Perhaps this warm feeling is what LUFA users feel when they try the demos out themselves.

USB Temperature Datalogger: Actually, I’m currently becoming bored with LUFA. No, that’s not to say I don’t want to develop it anymore (far, far from it) — I’m just fresh out of ideas on how to improve it. On that note, if you have any suggestions on where LUFA can go from here, post a comment! In any case, I thought I’d spend a little time writing a simple LUFA project which hooks into ELMChan’s FAT library so that temperature samples can be recorded to the board’s Dataflash, and later read off with a computer. People have been bugging me requesting something like this for a while, so I thought I might as well add it in. It’s currently in the LUFA SVN, under Projects/TemperatureDataLogger. I’m not convinced that FatFS is the nicest FAT library around based on its code, but for now it’ll do until I (perhaps) write my own.

XPLAIN DAC: After my abysmal non-start with the AVR32 line of AVRs, I thought I’d try to use the XMEGA chip on the loaner XPLAIN board I received. I’ve not gotten into the XMEGAs before now, as they are rather like the Unobtanium mineral in the new-and-great Avatar movie; you hear a lot about them, but they’re bloody hard to get a hold of. Now that I’ve played with them a little, I have to say I’m in love. They’re programmable with the familiar AVR-GCC toolchain using makefiles and simple text editors, yet they have so many fantastic features. If only Atmel could ramp up production, I’d be recommending them for use in just about everything. On that note, I made a simple XPLAIN DAC demo, which outputs real-time 8-bit mono sound from the PC using a simple XMEGA DAC program and a modified LUFA Audio Output demo. Score another win for LUFA.

TPI Programming: While I’m still waiting on the arrival of some TINY10 AVR samples to test it with, I’ve basically finished the TPI programming protocol implementation in my AVRISP-MKII Clone project. I’m not convinced that it’s all correct just yet, but I don’t think I’ll need to change too much to get it running once the test hardware arrives.

Elektor Magazine: A few days ago I received a nice package from Antoine Authier from Elektor magazine, containing the English versions of the December/January Elektor magazine, plus the January magazine in several other languages. This is the magazine with Antoine’s article about LUFA, which has me grinning from ear-to-ear. My only regret is not catching the missing semicolon terminators on one or two of the included projects earlier, as having a paragraph dedicated to LUFA errata is a tad embarassing. Perhaps I’ll have to write some magazine articles of my own in the future.

New Server: Angus Peart (gussy from AVRFreaks) has been kind enough to use some of his small fortune to host FourWalledCubicle.com over the years entirely for free, and deserves a lot of kudos from everyone who either reads this tripe, or downloads any of my code. From the new year, Angus has moved the site onto a shiny new server here in Melbourne, Australia. Hopefully this hasn’t caused anything to glitch, but if you notice anything funny please contact me so I can get it all sorted out.

Only six days released, and the new LUFA release has already got 133 unique downloads, not including checkouts from the public SVN and GIT source mirrors. Not too shabby for a niche project – each release only gets around 400 downloads total after a month, so at least takeup isn’t going backwards. Actually, one thing that is certainly going up is site hits in general, which is somewhat baffling since I only write junk here, and most of the content (save for new downloads) is entirely static. Here’s the site metrics since I started it:

Which, if this trend holds, means I’ll get 100% of all internet traffic by the time the sun burns out and becomes a dead star. I wonder what LUFA version will be out by then?

Actually, speaking of baffling LUFA related trends, I’ve noticed two others; since my mention in Elektor magazine, downloads of the November release have jumped quite a bit. Normally one would expect that if that’s the version the article was specifically targeting, but the article was about the September release. If people aren’t going to use the same version as in the article, why not use the latest?
The other trend was with the MyUSB downloads — that is, the versions of LUFA so old that they’ve grown mouldy and have been lost at the back of the pantry. The two year old 1.5.3 release has been downloaded 53 times this month alone, which leads me to suspect that people believe that LUFA and MyUSB are different projects. People! Not true! I’ve whacked an “obsolete” warning on the MyUSB downloads, just to drive the point home; MyUSB is simply the original name for the LUFA project. It’s not something separate at all, although it is old and manky.

On the Christmas front, I hope everyone had as much fun as I did. From my parents I got a new soldering station (which should encourage me to actually build something physical and permanent, rather than mucking around with prebuild boards/breadboards and concentrating purely on the firmware. From my girlfriend and her sister I got two totally AWESOME t-shirts. Here’s a picture of one of them:

That’s right. Wifi. Detecting. Shirt. Once University starts, I’ll be heralded as supreme alpha-nerd! The other t-shirt, alas, I cannot find a picture of, but it also animates and plays space invaders. Heaven.

I’m currently developing an extension to my open source AVRISP-MKII clone project (part of the LUFA package) which will give it support for the 6-pin ATTINY TPI programming protocol, just like the real AVRISP-MKII since the AVRStudio 4.18 SP1 release. TPI is actually very, very similar to the PDI protocol, which has greatly reduced the amount of effort required to implement it — in fact, much of the existing PDI code is shared. The trouble has been that Atmel won’t release the Host-to-Programmer protocol specs, so I’ve had to work it all out manually. Still, I’m now awaiting the arrival of some sample 6-pin AVRs to test it with, so it’ll be in the next LUFA release.

I’m actually floundering a bit for things to do with LUFA — while I’ve got a number of half-finished demos and projects left to do, the actual library core code is getting to be pretty stable. If you’ve got any ideas on where it needs improvement, leave a comment. I need some user-feedback and inspiration for working out what changes need to be made.

Everyone have a safe and happy new year. Onwards to 2010!

Another month, another LUFA release. So far, there’s been no (reported) issues with the BETA, so I thought I’d go ahead and release it to the public as an early Christmas present. I want to again publicly thank everyone who has contributed towards what should prove to be yet another popular LUFA package. This release incorporates the new AVRISP MKII clone project changes, giving it PDI programming capabilities for the XMEGAs, as well as a new RNDIS host demo and class driver, plus a bunch of other highlights – see below for the full changelog.

I’m still stoked about the big mention of LUFA in Elektor; the article’s interesting, and it’s pulling in a good number of hits/downloads to the LUFA page, which I’m hoping will convert to donations (please?). Actually, the editor of Elektor has put up a new news item about that article which apparently offers a good deal on USBKEY boards for those not in the US (since the US$ price is about on par with general US distributors). If you’re not in the mood for a USBKEY board, there are now plenty of alternatives which have cropped up over the last year, including the Bumble-b, Micropendous line, Teensy boards, and several other similar vendors. And no, apart from a few free boards for review, I don’t get any kickbacks from that, I really think they’re great products.

Merry Christmas to everyone! If you’re living in Melbourne, Victoria, Australia, see this AVRFreaks thread — we’re organizing for a get-together somewhere in the city after the new year. Looking forward to seeing some of you there.

Version 091223

New:

• Added activity LED indicators to the AVRISP project to indicate when the device is busy processing a command
• The USB target family and allowable USB mode tokens are now public and documented (USB_CAN_BE_*, USB_SERIES_*_AVR)
• Added new XPLAIN USB to Serial Bridge project (thanks to John Steggall for initial proof-of-concept, David Prentice and Peter Danneger for revised software USART code)
• Added new RNDIS Ethernet Host LowLevel demo
• Added new RNDIS Ethernet Host Class Driver
• Added new RNDIS Ethernet Host ClassDriver demo
• Added CDC_Host_Flush() function to the CDC Host Class driver to flush sent data to the attached device
• Added PDI programming support for XMEGA devices to the AVRISP programmer project (thanks to Justin Mattair)
• Added support for the XPLAIN board Dataflash, with new XPLAIN_REV1 board target for the different dataflash used on the first revision boards compared to the one mounted on later revisions
• Added new HID_ALIGN_DATA() macro to return the pre-retrieved value of a HID report item, left-aligned to a given datatype
• Added new PreviousValue to the HID Report Parser report item structure, for easy monitoring of previous report item values
• Added new EVK527 board target
• Added new USB_Host_GetDeviceStringDescriptor() convenience function
• Added new LEDNotification project to the library, to give a visual LED notification on new events from the host
• Added new NO_DEVICE_REMOTE_WAKEUP and NO_DEVICE_SELF_POWER compile time options

Changed:

• Removed code in the Keyboard demos to send zeroed reports between two reports with differing numbers of keycodes as this relied on non-standard OS driver behaviour to repeat key groups
• The SCSI_Request_Sense_Response_t and SCSI_Inquiry_Response_t type defines are now part of the Mass Storage Class driver common defines, rather than being defined in the Host mode Class driver section only
• The USB_MODE_HOST token is now defined even when host mode is not available
• The CALLBACK_HID_Device_CreateHIDReport() HID Device Class driver callback now has a new ReportType parameter to indicate the report type to generate
• All Class Drivers now return false or the “DeviceDisconnected” error code of their respective error enums when a function is called when no host/device is connected where possible
• The HOST_SENDCONTROL_DeviceDisconnect enum value has been renamed to HOST_SENDCONTROL_DeviceDisconnected to be in line with the rest of the library errorcodes
• Make MIDI device demos also turn off the on board LEDs if MIDI Note On messages are sent with a velocity of zero, which some devices use instead of Note Off messages (thanks to Robin Green)
• The CDC demos are now named “VirtualSerial” instead to indicate the demos’ function rather than its implemented USB class, to reduce confusion and to be in line with the rest of the LUFA demos
• The SImage_Host_SendBlockHeader() and SImage_Host_ReceiveBlockHeader() Still Image Host Class driver functions are now public

Fixed:

• Added missing CDC_Host_CreateBlockingStream() function code to the CDC Host Class driver
• Fixed incorrect values for REPORT_ITEM_TYPE_* enum values causing corrupt data in the HID Host Parser
• Fixed misnamed SI_Host_USBTask() and SI_Host_ConfigurePipes() functions
• Fixed broken USB_GetNextDescriptor() function causing the descriptor to jump ahead double the expected amount
• Fixed Pipe_IsEndpointBound() not masking the given Endpoint Address against PIPE_EPNUM_MASK
• Fixed host state machine not enabling Auto VBUS mode when HOST_DEVICE_SETTLE_DELAY_MS is set to zero
• Fixed misnamed Pipe_SetPipeToken() macro for setting a pipe’s direction
• Fixed CDCHost failing on devices with bidirectional endpoints
• Fixed USB driver failing to define the PLL prescaler mask for the ATMEGA8U2 and ATMEGA16U2
• Fixed HID Parser not distributing the Usage Min and Usage Max values across an array of report items
• Fixed Mass Storage Host Class driver and Low Level demo not clearing the error condition if an attached device returns a STALL to a GET MAX LUN request (thanks to Martin Luxen)
• Fixed TeensyHID bootloader not properly shutting down the USB interface to trigger a disconnection on the host before resetting
• Fixed MassStorageHost Class driver demo not having USB_STREAM_TIMEOUT_MS compile time option set properly to prevent slow devices from timing out the data pipes
• Fixed the definition of the Endpoint_BytesInEndpoint() macro for the U4 series AVR parts
• Fixed MIDI host Class driver MIDI_Host_SendEventPacket() routine not properly checking for Pipe ready before writing
• Fixed use of deprecated struct initializers, removed library unused parameter warnings when compiled with -Wextra enabled
• Fixed Still Image Host Class driver truncating the PIMA response code (thanks to Daniel Seibert)
• Fixed USB_CurrentMode not being reset to USB_MODE_NONE when the USB interface is shut down and both Host and Device modes can be used (thanks to Daniel Levy)
• Fixed TeensyHID bootloader not enumerating to the host correctly
• Fixed AVRISP project timeouts not checking for the correct timeout period (thanks to Carl Ott)

Over the last week, I’ve been implementing what might be the world’s first *open source* XMEGA PDI programmer, thanks to a generous loaner XPLAIN board from Ross McKenzie (a fellow AVRFreak) and a lot of PDI related assistance from Justin Mattair. The programmer is now in a working beta release, available either as a prebuilt HEX for the XPLAIN board (see here) or as source code via the LUFA SVN.

The PDI programmer is part of the LUFA AVRISP MKII project, located in Projects/AVRISP of the LUFA codebase. From the latest AVRStudio4 release the official AVRISP-MKII supports XMEGA PDI programming mode, which means that I’ve been able to add it to my open source clone firmware too. It’s been a lot of work and taken many late nights, but it’s now ready for public consumption. It is able to program the complete XMEGA family of AVRs via any of the USB AVRs, as well as the normal AVRs via ISP mode. Both PDI and ISP modes can be selectively removed to save on compile space, allowing the programmer firmware to fit into even the 8KB USB AVRs (but 16KB is recommended).

Two pinouts are supported; a faster hardware USART mode which breaks compatibility with the official AVRISP-MKII pinout, but is very fast, and a slower bit-banged USART mode which is quite slow, but follows the official device’s pinout exactly. When compiled for the XPLAIN board, ISP mode is automatically removed and the hardware USART enabled for the fastest possible programming experience.

Note that AVRDude 5.8 is currently broken, and won’t work with my (or the official) AVRISP-MKII – you’ll need to download the AVRDude source and apply this patch until a newer release becomes available.

Have a Merry Christmas every one, and I hope this will lead to many new XPLAIN related projects in the future, now that everyone can program them easily without an external programmer! Look out for a new LUFA release soon.