First and foremost – it’s time to announce the winners of the USBTINY-MKII competition! I was a bit annoyed that the finish date crept up on me so quickly, as I had plans to create a LUFA noise generator device using the CDC class driver and a zener noise source to pick the winners. Not to worry, I ended up just using three values from Random.org to choose the lucky three. Without further ado, let’s all congratulate the winners:

1. Marco (No Last Name Given)
2. Jim Bowen
3. Martin Degelsegger

I’ll notify the winners via email also to get their shipping addresses. I’ve been really, really happy with the way the competition’s gone; some great (big and small) bugs were reported, leading to a less buggy code and (hopefully) more satisfied user-base in the future. Totally win-win and something I hope to repeat in the future, with (possibly) a small reward for every reported bug so that no one misses out. My apologies to those contributors who didn’t win this time around; as much as I’ve love to give away something to everyone who contributed, I simply can’t afford to.

Each of those three winners has won a brand new USBTINY-MKII V1 programmer from Tom – but paid for by yours truly, of course. Last week I reported on Tom’s adapter boards and reset recovery board, however I’ve now been told this is false information; while the reset recovery board is now available, the remaining adapter boards are only being considered for production. Actually, Tom’s now told me that he’s considering selling the adapter boards with the programmer as a small “kit” for a few dollars more than the base price, as the adapters alone would be swamped by shipping costs.

One last thing I’ll post here for now on the programmers is a shot of Tom’s “V2″ prototype, which come in a fancy blue translucent case with silk-screening, and will become available in a limited supply soon. I really hope Tom posts some articles on the production process, as he’s done the case milling and silk-screening himself.

Tom's USBTINY-MKII Programmer Kit

Now on to my own electronics efforts. Last week I mentioned that I was laying out a PCB as part of my third year electronics project (I’m actually in my fourth University year, however as I’m doing a double degree, I’m doing third year subjects of both Electronics and Computer Science at the moment). Since that post I’ve come a long way and I’m actually very nearly finished:

My first PCB design

Which I’m fairly happy with, given that it’s my first ever PCB layout, and first time using Altium Designer. There’s still some tweaking to be done before the final submission for production on Monday, but all things considered I think I’ve learned a huge amount in only a few short weeks. Special thanks to my friend Andrei for his great feedback on my (cruddy) design, as his advice has helped me a great deal in improving my layout.

After production comes board population, which will be a huge undertaking it of itself; I’ll need to work out a strategy for which components to populate first in order to make later components easier to mount. Actually, given that I’ve only soldered a few surface mount components before, I’m a little worried about trashing the board since we only get the one.

Finally will come the coding, and that’s where I hope to shine, since it’s my strong suit. What got me was that no one is expected to actually finish the project. Exactly bunk number of people finished it completely over the past few years – the point of it is to get us comfortable progressing from schematic to finished board, with the operation being, well, optional. I’m told one can pass if the board powers on without catching fire and the LCD can be controlled – but of course I aim to be the first in several years to make it work before the final deadline.

As of this week, I’ve now got a job at the University teaching C code (regular and embedded) to a bunch of 5th year international master’s students once a week for the next month or so. It’s certainly an experience for me and a good chance to develop my teaching skills, so I’ve taken it on quite happily. In a few weeks I’ll be running my first lab class solo, meaning that I’ve been given a copy of the laboratory task sheet, a stack of marking sheets, a pat on the back and a “you’ll do fine“.

But finally today is a bit of news I stumbled across this afternoon while idling. A few weeks ago there was a lot of buzz about an Australian crew who managed to jailbreak the Playstation 3 console, using only a small USB dongle that plugs into the front USB ports. It’s great to hear news of a solution to PS3 homebrew problem now that Sony’s killed the “OtherOS” functionality of the consoles, however the inevitable legal injunction taken out by Sony means the (rather expensive, I thought) dongles are currently off the market. Not to worry, as an enterprising hacker has come up with an open source – and LUFA powered – clone of the dongle’s functionality, called PSGroove. Just download the source code, compile it for the USB AVR of your choice, and plug it into your console.

That’s bloody great news, as it will obviously be a high-visibility project right up until Sony’s pack of fun destroying jerks engineers figure out a patch to prevent the jailbreak. Until then, LUFA should become quite a bit more popular – and used around the world – and hopefully other interesting hacks will come about from it.

Primarily, my time has been taken up by two assignments:

Assignment 1: Programming FPGAs

Yes, I’m back into the land of VHDL again, this time moving up from tiny CPLD devices in my introduction to digital design subject to a somewhat larger Cyclone II FPGA. While I haven’t even thought about VHDL in over a year now (last year was entirely Computer Science subjects, courtesy of my double degree and scheduling) I’ve been pleasantly surprised how quickly I’ve remembered everything. Since I have a sequential programming background I initially found parallel design quite mind-bending, but I’ve now somewhat mastered the (warped) way of thinking required. That makes me a happy chappy, since I’m no longer fighting myself to finish my first assignment: an asynchronous ALU coded entirely in VHDL.

I’m all done with it now, with even most of the report all written up, including simulation. I’ve found it quite funny that I’ve become the go-to guy for VHDL code almost immediately, despite me being in the same boat as half the other students. Unfortunately I’m way too time poor at the moment, or I would snap up one of the awesome Altera DE2 boards we’re developing with and see what else I can code up at home.

Actually, all that’s got me thinking – why not create a processor with a regular core, plus a small amount of programmable logic? Companies could produce the one chip with zero on-die peripherals, and instead produce tools so that the engineer could drag-drop the desired peripherals (SPI, I2C, timers, etc) to create the custom chip they need. Done cheaply enough, it could really take off – not only does the company save money by only needing to create the one low cost design, the engineer could do such advanced things as adding custom coded peripherals to speed up execution in addition to the hand-holding default drag-drop interface. Think of how many times you’ve thought something like “I really love the Atmel AVR model X, but I wish it had Y timers with PWM instead of the Z USARTs I’m not using…” and tell me you wouldn’t jump all over that.

Assignment 2: Power/Voltage/Current Meter

In order to prepare us for our large-scale project next year, we’ve been tasked with a somewhat simpler project to complete this semester, to familiarize ourselves with the tasks of creating a schematic, choosing footprints, laying out and drilling boards, soldering surface mount components and programming microcontrollers. Most of those I’ve somewhat perplexed they haven’t taught us up to now, but according to the lecturers “throwing you all in the deep end makes you learn quicker”. Bah humbug.

Unfortunately for me, not only is my project (an isolated power meter) set for me, the schematics are also similarly fixed, so I’m stuck with using a tool I don’t know, laying out what must be the most over engineered piece of junk known to mankind. To me a power meter is something requiring only a few analogue parts, a LCD and a modern AVR or similar processor. No such luck here – we must use the truly awful Z8 microprocessor that was developed when bows and arrows were considered “the next best thing”, along with four switchmode power supplies producing no less than five voltage rails.

Five. Voltage. Rails.

And we have to lay them out, with no previous experience laying out such much as a morse code beeper, let along anything so complicated. What makes it more fun is that they are teaching us the critical design knowlege (current loops? What are those?) in parallel with our efforts, so we’re finding the need to rip up large sections and re do them after almost every lecture.

Having said that, I am indeed learning quickly; I’ve been showing off my progress periodically on Twitter with my Altium efforts (initial design, second design – I’ll post an updated and near complete screenshot of my latest layout on Monday) during the week and receiving some very helpful comments. Before now I never really understood why PCB artwork was called artwork, but now I do; layout truly is an art, and those who are naturally good at it should just get a job as a hardware designer. Just as I regularly cringe at the code produced by hardware orientated people, they too cringe when they see my horrible hardware attempts, but I’ve learned that there should indeed be different people allocated for the two different tasks.

And LUFA stuff too…

In LUFA news, I just about cried when I received this bug report, along with a solution from Martin Degelsegger – it pointed out a critical flaw in the way LUFA allocates endpoints and pipes in the class driver which didn’t seem to have any easy solution. I admit it is my fault for not seeing the one-line warning in the USB AVR datasheets, but I still feel like kicking the Atmel engineer who designed the damned thing; if endpoints or pipes are allocated with a non-ascending index, the bank memory locations in the internal controller DPRAM can be silently overlapped at random offsets even though the controller reports a successful allocation. That’s damned nasty and something I had no idea about until now, as I was only aware of the “bank memory fragmentation will break everything” caveat warned quite prominently in the datasheet.

I’ve not yet totally QA’d my fix, but I’ve adjusted the Endpoint_ConfigureEndpoint() and Pipe_ConfigurePipe() routines to work around the solution. Basically, the routines cache the configuration of all the endpoints and pipes, then clears them before reallocating them in order with the new endpoint or pipe inserted in the correct place. That seems to fix the problem with out any obvious side effects, other than the deletion of anything currently in the endpoint or pipe banks. Given that endpoint and pipe configuration is done during the enumeration process before any non-control endpoint or pipe is used, this doesn’t seem to be a problem.

Finally today is an update on my competition for a free USBTINY-MKII programmer – with the above people added to the list, we’ve got two new contenders:

A. Paulin (One entry)
B. Paddock (Three entries)
A. Rohde (One entry)
N. Braun (One entry)
Simon [No Given Last Name, Google Code issue report] (One entry)
J. Bowen (One entry)
M. Degelsegger (Two entries)

Which makes things really interesting. I’ll clarify the competition here; only one programmer per winner, so while multiple entries will increase your chance of winning a programmer, it won’t increase your chances of winning more than one programmer. If you think you’ve found a bug, report it before the 30th to get your chance of winning too!

Even if you’re not going to enter into the running for a free programmer, Tom’s just released news on some really neat little adapters for his programmer (although they are generic and will in fact work with any AVR programmer) to make it easy to insert into breadboards (including one with 3.3V voltage regulation) and program AVRs with the RSTDSBL fuse set. Check them out, and if you’re interested bug him until he releases them up for sale – scroll down the linked page for the pictures and information. (Tom’s decided not to sell these for now. Perhaps he’ll sell them as cheap kits in the future).

PART 1: USBTINY-MKII Competition Update

My little competition to win a nice free programmer is finally that, a competition, now there are five names competing for three programmers. There’s still plenty of time to get your bug reports in on the new release (more on that later) before the end of August so you too can have quite a decent chance of winning some free stuff.

So far the possible entrants are as follows – if your name does not appear here and you believe you should be included a you have submitted a bug report since the competition was announced, send me an email.

A. Paulin (One entry)
B. Paddock (Three entries)
A. Rohde (One entry)
N. Braun (One entry)
Simon [No Given Last Name, Google Code issue report] (One entry)

Thank you to the above people. If you want to be on this list, get testing!

PART 2: LUFA Licensing Update

Woah boy. I’ve been more than surprised by the volume of feedback I’ve received over the last week once I opened up the public discussion about the changing of LUFA’s licensing. I wasn’t expecting to receive loads of happy messages, but now I know how the folk over at Twitter feel; all the responses I’ve got via public and private emails so far have all indicated that LUFA is, by and large, entirely worthless in its current form. Not worthless in that it’s not useful for commercial purposes, but that it’s worthless in that no one’s willing to pay me to use it.

I was planning on collecting everyone’s thoughts, and posting them here argument-by-argument with my own feedback, so that the optimum licensing conditions could be fleshed out so as to minimize the impact to everybody while still giving me some income for my work. However, it is no clear from all the “change it and we will fork the codebase/switch libraries before paying” comments that this won’t work. To that end, I’m ending the discussions early, keeping the licensing as-is for now, and adjusting my support/development/release efforts to suit.

Once I begin porting LUFA I will ensure that all ported code will be heavily restricted for any use other than private testing before committing it to the public repository, and try again. As has been made clear, if a free older version exists, people simply won’t license newer code. With ports will come new users, and hopefully new income opportunities for myself.

I apologize to everyone who has sent me emails on this which I have not answered due to their volume and my time constraints – however seeing as this issue is currently dead I hope all those kind enough to contact me will forgive me.

PART 3: New LUFA 100807 Release!

I’m a little late on my schedule on this, but today I’ve released LUFA 100807 – I simply forgot what day the seventh was when I scheduled in 100807, as I’m usually away from my PC on weekends. Nevertheless, going by the age-old saying of “better late than never”, today I’ve packaged up the repository trunk and pushed it out as a public release. So as not to confuse everyone too much I’ve kept the 100807 name, even though it’s technically one or two days late.

As I’ve said above, this release maintains the existing MIT+Attribution license that has been a component of LUFA for over a year now, so no need to worry.

Special thanks to Bob Paddock for his excellent feedback during the beta cycles, as he did an amazing job of testing various components of the library and finding issues. Also thanks to all the other testers and donators, who’ve helped out.

As usual, the downloads are all available on the LUFA project page, although I’ll also link to the direct downloads here too for convenience.

LUFA 100807 Release Download

LUFA 100807 Prebuilt Documentation Download

Online LUFA 100807 Documentation

Changelog for Version 100807

New:

• Added new ADC_DisableChannel() function (thanks to Mich Davis)
• Added new VTARGET_REF_VOLTS and VTARGET_SCALE_FACTOR compile time defines to the AVRISP-MKII programmer project to set the VTARGET reference voltage and scale factor
• Added new pgm_read_ptr() macro to Common.h for reading of pointers out of flash memory space
• Added new SWAPENDIAN_16() and SWAPENDIAN_32() macros to Common.h for statically initialized variables at compile time
• Added new Drivers/USB/LowLevel/Device.c file to house Device mode specific functions that are more complicated than simple macros
• Added new AVRStudio 4 project files for all library demos, projects and bootloaders
• Added ability to set the serial baud rate via the user’s terminal in the XPLAINBridge project
• Added new LUFA module variables for the different source modules in the core library makefile to simplify project makefiles
• Added start of a new Test and Measurement class demo (thanks to Peter Lawrence)
• Added new SPI_ORDER_* data order masks to the SPI peripheral driver
• Added support to the AVRISP-MKII project for ISP speeds slower than 125KHz via a new software SPI driver
• Added support for the new button/LED on the latest model USBTINY-MKII

Changed:

• The RingBuff library code has been replaced in the XPLAINBridge, Benito and USBtoSerial projects with an ultra lightweight ring buffer to help improve the reliability of the projects
• The EEPROM stream read/write functions now use eeprom_update_byte() instead of eeprom_write_byte(), so that only changed bytes are written to EEPROM to preserve its lifespan
• Changed over the AVRISP-MKII and TemperatureDataLogger projects to use eeprom_update_byte() when writing non-volatile parameters to EEPROM to preserve its lifespan
• Removed unused line encoding data and control requests from the CDC Bootloader code, to save space
• Renamed SERIAL_STREAM_ASSERT() macro to STDOUT_ASSERT()
• The USB_Device_IsRemoteWakeupSent() and USB_Device_IsUSBSuspended() macros have been deleted, as they are now obsolete
• Rewrote the implementation of the SwapEndian_16() and SwapEndian_32() functions so that they compile down in most instances to minimal loads and stores rather than complicated shifts
• The software UART in the XPLAINBridge has been largely altered to try to improve upon its performance and reliability
• The USBtoSerial and Benito projects now flushes received data via a flush timer, so that several bytes can be transmitted at once
• Removed the automated checking of event names in the demo, project and bootloader makefiles due to inconsistencies between the behaviour of the command line tools used to perform the check on each platform
• Internal USB driver source files renamed and moved to ease future possible architecture ports
• All internal pseudo-function macros have been converted to true inline functions for type-safety and readability
• Changed LED indicator masks for the AVRISP-MKII project, so that there are defined roles for each LED
• Altered the CDC Device and Host Class drivers’ receive byte routines, so that no data is indicated by the function returning a negative value (thanks to Andreas Paulin)
• Added auto flushing of OUT data to the CDC Host Class driver’s USBTask function to automatically flush the send pipe buffer

Fixed:

• Fixed AVRISP project sending a LOAD EXTENDED ADDRESS command to 128KB AVRs after programming or reading from the last page of FLASH (thanks to Gerard Sexton)
• Fixed AVRISP project not sending a full erase-and-write EEPROM command to XMEGA targets when writing to the EEPROM instead of the split write-only command (thanks to Tim Margush)
• Fixed RNDISEthernet demos crashing when calculating checksums for Ethernet/TCP packets of more than ~500 bytes due to an overflow in the checksum calculation loop (thanks to Kevin Malec)
• Fixed XPLAINBridge project not correctly reading the XMEGA’s supply voltage when reporting back to the host
• Fixed incorrect signature for the ATMEGA32U2 in the DFU bootloader (thanks to Axel Rohde)
• Fixed internal device serial not being accessible on the ATMEGAXXU2 AVRs (thanks to Axel Rohde)
• Fixed void pointer arithmetic in ConfigDescriptor.h breaking C++ compatibility (thanks to Michael Hennebry)
• Fixed broken PDI EEPROM Section Erase functionality in the AVRISP-MKII project
• Fixed USB_Device_SendRemoteWakeup() not working when the USB clock was frozen during USB bus suspend (thanks to Brian Dickman)
• Fixed occasional lockup of the AVRISP project due to the timeout extension code incorrectly extending the timeout in PDI and TPI programming modes infinitely
• Fixed HID device class driver still using PrevReportINBuffer for GetReport control requests even when it has been set to NULL by the user application (thanks to Axel Rohde)
• Fixed MIDI_Device_SendEventPacket() not correctly waiting for the endpoint to become ready (thanks to Robin Green)
• Fixed Benito and USBtoSerial projects not turning off the USART before reconfiguring it, which could cause incorrect operation to occur (thanks to Bob Paddock)
• Fixed Serial peripheral driver not turning off the USART before reconfiguring it, which would cause incorrect operation to occur (thanks to Bob Paddock)
• Fixed software application start command broken in the DFU class bootloader when dfu-programmer is used due to application start address corruption

A few months ago I tested the waters into monetizing my work, by offering companies a chance to opt-out of the attribution clause of the MIT license via a one-time US$1500 payment. While this has been taken up on a handful (singular) of parties, the results of my experiment have not exactly been encouraging for me.

I’ve identified a number of issues:

1. People seem to have trouble working out what exactly the attribution clause of the license requires them to do – I agree, it is a little less explicit than I would like. My intention was for the user to be legally required to put something like “uses components from the LUFA library, by Dean Camera, <link>” in their product manual and website, but in practice this has resulted in just a simple link back to my LUFA page with no information.
2. Companies like money. I like money too, but companies aren’t charitable. Unless I force them to, few will fork out the money for a license with few obvious benefits to them.
3. Unless the company is producing many units or is making a high margin, the current fixed license fee isn’t attractive. A better per-unit block breakdown is required, even though I detest such things.

And so at the risk of becoming hated by the masses everywhere, I’m now getting the feeling that the license of the library core needs to be changed, so that companies are forced into paying a license for my work. I hate rash decisions as much as everyone else, and I really, really don’t want to risk losing all the kind, generous and fascinating users I’ve gained so far, so I’m putting this up for discussion here.

Here’s what I’m thinking of so far. I’d like everyone who uses LUFA, who has thought about using LUFA, or just has something to say to chip in here, so I can get a feel for the public’s reaction to this. Please also mention how you are using LUFA, so I can see how the following changes will impact existing users.

Here are the proposed changes to the Licensing of LUFA:

• Non-commercial users will be granted a license to use LUFA freely, with attribution, via a Creative Commons BY-NC-SA license. Put simply, this means you can use LUFA all you like, as long as you don’t make money off of it selling devices in any reasonable quantitiy, and give attribution. From a practical standpoint, this is pretty much the current status quo, except it forbids most uses of LUFA commercially outside one-offs or internal evaluation/use. Hopefully this will not alienate the existing user-base, as free projects can continue to exist and be produced using LUFA.
• Commercial users with less than 10 units produced - this will usually only be due to internal evaluation – will also be able to use LUFA for free, via a license which permits commercial use on this very small scale, but does not permit redistribution under this license.
• Commercial users with less than 50 units produced will be required to license LUFA commercially, for a cost of US$400. This is a one-time, perpetual license like the current commercial license, and will include two hours of free consultation with myself to get companies off and running with LUFA.
• Commercial users with less than 150 units produced will also need a license with the same terms, but the cost will increase to US$800. This should remain profitable, while gaining me a little more income at the same time.
• Commercial users with over 150 units produced will need a US$1500 license, and will get three free hours of consultation – the same as the current license.

Of course, licenses would be upgradable just by paying the difference, so it would be fine to start low and ramp up as your company produces more units. Existing license holders would automatically switch over to the “best” commercial license offered, and all commercial licenses would be valid for any future enhancements of LUFA subject to the terms of the purchased license.

So, that’s what I’m currently leaning towards; the existing hobbyist community – which is very, very important to me – can continue to enjoy LUFA free of charge, so that only commercial users will need to pay anything to use LUFA. Some special projects I make (like the XPLAINBridge) will be exempt from the licensing structure, and free use will be granted of the LUFA core when used inside those projects.

Ok people, voice your thoughts and objections!

Over the last few days I’ve uploaded two newer betas for testing – BETA 2, which introduced support for low speed ISP in the AVRISP-MKII project, spell checked documentation and fixes to the USBtoSerial and Benito projects, and BETA 3 which introduces changes to the CDC Class driver APIs which has the potential to reduce program overhead, plus an improved version of the lightweight ring buffer used in several of the projects which reduces the time spent locking on atomic operations.

These new BETAs push us closer and closer to the release date, which is still subject to change based on the feedback I get, but is currently looking firm. Time will tell if there are any bugs waiting to be discovered, so download, test and report back today for your (currently 100%!) chance at winning a nice AVR programmer.

For 100807 BETA3 downloads and documentation, see the LUFA project page.

That’s right folks! Only here do you get the chance to win one of three AVRISP-MKII clone programmers, ready made and shipped to you entirely for free! These three programmers are all the new V1.1a board revision of Tom’s excellent design and manufacture, worth US$33 each. Tom sent me one a few weeks ago to test out, and I’m so happy with it I thought I’d buy three from him and give them away here to LUFA users. This is the programmer I’m talking about:

What?

The USBTINY-MKII programmer features high speed ISP, TPI and PDI programming (for all 8-bit AVRs, including the new 6-pin TINY and the gigantic XMEGA chips) as well as native AVRStudio 4 compatibility, logic level translation, target powering from the USB bus, and easy firmware upgrades via the USB interface. At the core of the programmer is an AT90USB162, running my LUFA AVRISP-MKII firmware. That means the programmer itself is open source, and you’ll receive future updates for it through the regular LUFA releases.

For more information of the USBTINY-MKII programmer, see Tom’s website page about it.

How?

How do you win one? Simple. Just submit a full bug report for a reproducible bug in the current SVN repository, LUFA 100807 BETA package or (eventually) the 100807 official release via email, and you’ll go into the draw. At the end of August, I’ll randomly select three bug reporters as the winners of one of these most excellent pieces of hardware. That’s it – you don’t even need to post a fix for the bug, just report it. The more new bug reports you submit, the more chances you have to win.

All eligible bug reports must be submitted to me before the 30th of August, 2010, and must contain full details of how to reproduce the bug, including the exact version/revision of LUFA, the hardware and software used.

You can download the current 100807 BETA and – when it is ready – official release from the LUFA project page. Happy hunting!

This new beta contains a large number of internal changes, as well as the usual user visible improvements to the APIs, demos, projects and bootloaders. Bugs have been fixed, but I’ve also gone to a lot of effort to clean up sections of the internal library core code, so that (in theory, at least) ports to different architectures will be less difficult to achieve. There’s still some work to be done there, but the groundwork I’ve laid so far will mean that if the library does become targeted to multiple platforms, it shouldn’t become an (even bigger) gigantic pile of preprocessor macros.

Notably, I’ve converted over all the pseudo-functions used heavily in the library to real static inline functions. That gives several benefits – the documentation and code is now always in-sync, the static inline functions are properly type-checked and syntax checked at compile time, and the functions can be extended with more complicated implementations as needed when and if the library is ported to different architectures. Overall I’m quite happy with this, as it has already uncovered a fault in an obscure pipe interrupt macro, which has apparently been there since the dawn of time.

I implore everyone to please, please download, test and report back on the new beta version. The more issues that are uncovered now, the less issues that will be in the official release in two weeks. I hate seeing bugs in the release packages, as it means the fixed version won’t enter wide circulation until the following release, since most sane people don’t pull straight from the repository mirrors in production project code. I’ve uploaded the beta downloads and documentation to the regular LUFA project page, so that it will get maximum exposure throughout the beta testing window.

If you uncover any issue with the beta release, please let me know as soon as possible so that I have as long as possible to correct it.

Direct download of the 100807 BETA package

Direct download of the 100807 prebuilt documentation package

• Added new ADC_DisableChannel() function (thanks to Mich Davis)
• Added new VTARGET_REF_VOLTS and VTARGET_SCALE_FACTOR compile time defines to the AVRISP-MKII programmer project to set the VTARGET reference voltage and scale factor
• Added new pgm_read_ptr() macro to Common.h for reading of pointers out of flash memory space
• Added new SWAPENDIAN_16() and SWAPENDIAN_32() macros to Common.h for statically initialized variables at compile time
• Added new Drivers/USB/LowLevel/Device.c file to house Device mode specific functions that are more complicated than simple macros
• Added new AVRStudio 4 project files for all library demos, projects and bootloaders
• Added ability to set the serial baud rate via the user’s terminal in the XPLAINBridge project
• Added new LUFA module variables for the different source modules in the core library makefile to simplify project makefiles
• Added start of a new Test and Measurement class demo (thanks to Peter Lawrence)

Changed:

• The RingBuff library code has been replaced in the XPLAINBridge, Benito and USBtoSerial projects with an ultra lightweight ring buffer to help improve the reliability of the projects
• The EEPROM stream read/write functions now use eeprom_update_byte() instead of eeprom_write_byte(), so that only changed bytes are written to EEPROM to preserve its lifespan
• Changed over the AVRISP-MKII and TemperatureDataLogger projects to use eeprom_update_byte() when writing non-volatile parameters to EEPROM to preserve its lifespan
• Removed unused line encoding data and control requests from the CDC Bootloader code, to save space
• Renamed SERIAL_STREAM_ASSERT() macro to STDOUT_ASSERT()
• The USB_Device_IsRemoteWakeupSent() and USB_Device_IsUSBSuspended() macros have been deleted, as they are now obsolete
• Rewrote the implementation of the SwapEndian_16() and SwapEndian_32() functions so that they compile down in most instances to minimal loads and stores rather than complicated shifts
• The software UART in the XPLAINBridge has been largely altered to try to improve upon its performance and reliability
• The USBtoSerial project now flushes received data via a flush timer, so that several bytes can be transmitted at once
• Removed the automated checking of event names in the demo, project and bootloader makefiles due to inconsistancies between the behaviour of the command line tools used to perform the check on each platform
• Internal USB driver source files renamed and moved to ease future possible architecture ports
• All internal pseudo-function macros have been converted to true inline functions for type-safety and readability

Fixed:

• Fixed AVRISP project sending a LOAD EXTENDED ADDRESS command to 128KB AVRs after programming or reading from the last page of FLASH (thanks to Gerard Sexton)
• Fixed AVRISP project not sending a full erase-and-write EEPROM command to XMEGA targets when writing to the EEPROM instead of the split write-only command (thanks to Tim Margush)
• Fixed RNDISEthernet demos crashing when calculating checksums for Ethernet/TCP packets of more than ~500 bytes due to an overflow in the checksum calculation loop (thanks to Kevin Malec)
• Fixed XPLAINBridge project not correctly reading the XMEGA’s supply voltage when reporting back to the host
• Fixed incorrect signature for the ATMEGA32U2 in the DFU bootloader (thanks to Axel Rohde)
• Fixed internal device serial not being accessible on the ATMEGAXXU2 AVRs (thanks to Axel Rohde)
• Fixed void pointer arithmetic in ConfigDescriptor.h breaking C++ compatibility (thanks to Michael Hennebry)
• Fixed broken PDI EEPROM Section Erase functionality in the AVRISP-MKII project
• Fixed USB_Device_SendRemoteWakeup() not working when the USB clock was frozen during USB bus suspend (thanks to Brian Dickman)
• Fixed occasional lockup of the AVRISP project due to the timeout extension code incorrectly extending the timeout in PDI and TPI programming modes infinitely
• Fixed HID device class driver still using PrevReportINBuffer for GetReport control requests even when it has been set to NULL by the user application (thanks to Axel Rohde)
• Fixed MIDI_Device_SendEventPacket() not correctly waiting for the endpoint to become ready (thanks to Robin Green)

So far, I’ve had a few teething troubles; the new Atmel AVR Toolchain package is missing a lot of the neat *nix tools that WinAVR included, such as grep. The existing makefiles of LUFA made use of these tools to process the source code to automate some tasks, but that’s now got to change. Biting the bullet, I’ve remade all of the LUFA project makefiles, so that with one exception (the main library core makefile’s doxygen target) these special tools aren’t needed anymore.

While I was at it, I decided to finally get around to doing something I’ve been wanting to do to the makefiles for a long time; make the core library makefile includable in the project makefiles. This has the distinct advantage of being able to inject extra common targets into the project makefiles as needed (say, to check for invalid events if I find a way to re-add it without the grep dependencies) but also the advantage of being able to list the module source files in the one place.

Why is this neat? It means that no longer do you need to care about what I call the source files inside the library core. I can now move and rename them as I see fit, and the user projects will still compile, providing they use the new “module source” names I’ve added to the makefile. Here’s an example of what the makefile source list use to look like for a typical class driver demo:

# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c                                                 \
      Descriptors.c                                               \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/DevChapter9.c        \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Device.c             \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Endpoint.c           \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Host.c               \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/HostChapter9.c       \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/LowLevel.c           \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/Pipe.c               \
      $(LUFA_PATH)/LUFA/Drivers/USB/LowLevel/USBInterrupt.c       \
      $(LUFA_PATH)/LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c  \
      $(LUFA_PATH)/LUFA/Drivers/USB/HighLevel/Events.c            \
      $(LUFA_PATH)/LUFA/Drivers/USB/HighLevel/USBTask.c           \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Device/CDC.c            \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Host/CDC.c              \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Device/HID.c            \
      $(LUFA_PATH)/LUFA/Drivers/USB/Class/Host/HID.c

Which is, let’s face it, damned ugly and hard to maintain. Instead, here’s how the new system works:

# Create the LUFA source path variables by including the LUFA root makefile
include $(LUFA_PATH)/LUFA/makefile
 
# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c                                                 \
      Descriptors.c                                               \
      $(LUFA_SRC_USB)                                             \
      $(LUFA_SRC_USBCLASS)

Which is much neater – once the library core makefile is included (with the LUFA_PATH value set beforehand) the new module source names become available. In the documentation, just look for the module names rather than the source names, and add those as needed to your project makefile. Of course, you can still use your existing makefiles, but this new system means less restrictions on how I internally structure the library code.

Finished Bluetooth code or not, it’s about time I thought about releasing all the changes I’ve made to the project over the last two months, so I’ll be releasing a public beta version in a few days.

Now, back to the good stuff. I believe that every programmer has an Achilles Heel, that one algorithm that everyone else seems to have no trouble with, but for that person it causes endless frustration and misery. For me, that algorithm is the implementation of a software U(S)ART. I’ve now written and re-written different implementations several times, and although they eventually work, my bidirectional software UARTs always seem to miss the occasional character.

A software UART is supposed to be a simple affair – after all, with the most common 8-bit, no parity, one stop bit setting that many devices use, each frame is just the raw bytes framed by a low start and a high stop bit. This translates to some fairly simple code, which is usually run in a timer ISR to ensure that the timing of each bit is constant, to prevent reception errors at either end.

A unidirectional UART is possibly the easiest algorithm to get working, with the exception perhaps of a software SPI port. It’s when the requirements are for a bidirectional software UART that things get hairy, since now you’ve got to work out how to prevent the bit transmission and reception ISRs from tripping each other up and delaying the other long enough to corrupt the transfer. This is needed in my XPLAIN Bridge firmware for Atmel’s XPLAIN board, when the bridge operates as a USB to Serial converter. Since the AVR’s hardware UART is instead used as the PDI programmer transport to the XMEGA chip on the board, the serial channel is instead implemented in software on the USB AVR side.

It’s not just me that’s had trouble with this algorithm however; recognizing that it’s not as simple as it appears I originally outsources the software UART code on AVRFreaks, and ended up with an ASM and a C implementation from two kind members there. Both of these worked, but things got wonky when both ends of the link tried to send at the same time, as the transmission and reception code blocked each other.
After some complaints about my less-than-perfect UART code, I took yet another crack at it last night, trying to fix up the implementation so that lost characters would be the exception, rather than the rule. This has led to my new implementation of the software UART, which uses two timers and an external interrupt pin. This new implementation uses one timer for bit transmissions – each bit period, either the next bit to send is transmitted, or the next byte to send is loaded into a temporary buffer so that it can be shifted out. The reception code relies on an external interrupt pin to sense the start bit, which then starts the bit reception timer to shift in the incoming bits.

Additionally, I found that the Windows CDC driver does not like mostly-empty incoming packets, even though it is quite happy to issue them to attached devices – I found my Windows 7 machine locking up when I barraged it with a constant stream of single-byte packets (one for each incoming character). This also lead to the reception buffer being overflown due to the host not processing the packets fast enough, which corrupted the incoming data stream occasionally. To combat this, the bridge code has a third timer which flushes the current reception buffer contents to the host in a single packet rapidly (30 flushes a second) to aggregate multiple bytes into a single USB IN packet.

Tests on the latest code show this new code to be far, far more reliable that the old, although large streams in both directions can still cause some issues. I’d like some more testers on this before the next official release to get a wider opinion on the new code’s performance – I’ve started uploading pre-built versions of the project to the XPLAIN Bridge project page for convenience.

Sorry, I’m a little distracted today – it’s a special day! My girlfriend decided to show her baking prowess (and knowledge of the T1 line to my heart) through this creation:

Has it been four years already? I think I need to go lie down. Regular programming will return next week. For now, there’s cake.