Memos From the Cube

Sometimes I worry that I’m not accomplishing enough each week to have something to say here, while others I’ve got so much to write about I have to cherry pick to avoid putting those who stumble here into an irreversible coma. This week I think I’ve hit the right balance.

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.

It’s been two weeks since I last posted here, but it feels like months. I’ve been absolutely flat out working to try to get all my University assignments and projects up to scratch, putting in 9-6 days every day during the week even though I’ve only got classes scheduled for a fraction of that. I’ll try to make up for it now in my stolen downtime for the day via a long post.

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).

Today’s post comes in three parts.

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

One of the great things about LUFA is the community – giving it away for so long as undoubtedly made it as good as it is today, as all those free guinea pigs users helped motivate me to develop it further. Originally licensed under a LGPL license, I then moved to an even more lax MIT license (with attribution), which is where the project stands today.

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!

It’s been just under a week since I announced my little competition for free gear and, well, either I’m a fantastic programmer, or not many people are out testing the beta code. Knowing myself, I highly doubt the former and I’m much more inclined to believe it’s a case of the latter. Not to worry; the brilliant people over at Elektor magazine have offered to promote my competition to their subscribers this week! The Elektor editors have been especially generous, and have also made their previously published article “My First AVR USB” a free download for everyone, which features LUFA prominently. Thanks Elektor!

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.