Thanks to everyone for the continuing comments! This sort of thing really helps us prioritize.
Your call is important to us... <annoying elevator music>...
Ok, so bootloader and autoreset are the clear winners so far. Here's our plan for getting this fixed; comments/help welcome/solicited.
In terms of source code patches, this is really two problems:
(1) Fixing the known issues in libmaple/usb/, and doing more testing (test feedback from you is a big help; more on this later).
(2) Reworking the bootloader itself (this is the code in the maple-bootloader repo).
Problem (1) is important because that's where the autoreset code lives. If it's not working, you need perpetual bootloader mode, and that's very annoying. Problem (2) is important too, and we've hashed out new bootloader schemes on the forum in the past. However, any improvement we can get from it requires existing users to flash a new bootloader, which requires external hardware. Thus, solving (2) helps fewer people, and doesn't help as much. For these reasons, solving (1) seems like the bigger win.
We figured there'd be widespread agreement on bootloader/autoreset being by far the most painful part of the Maple experience, so work on (1) began this week. More on that:
The libmaple/usb/ directory is essentially borrowed wholesale from the bootloader code, so there's lots of stuff in there that has nothing to do with USB. My first priority is to remove duplicated functionality and get it written in terms of existing libmaple code (this has the ancillary benefit of exercising the rest of libmaple).
Progress on that has been OK so far. I got sidetracked for most of yesterday by confusing/contradictory ST/ARM documentation, but among other things, I've removed the files usb_hardware.h and usb_hardware.c entirely. There's no shortage of low-hanging fruit for chopping out code that doesn't really belong in usb/, which will make hunting for bugs much simpler.
It's badly named (the bugs lie in libmaple proper, not SerialUSB), but Issue 10 on the bugtracker ("Generally buggy SerialUSB", http://code.google.com/p/leaflabs/issues/detail?id=10 ) is where we track updates to solving (1). You can keep an eye on that as time goes on.
As the bugfixes occur, we'll put together some "snapshot" IDE releases you can download and try out. I'll make a note on the bugtracker and post in the forum whenever an Issue 10-related snapshot gets released.
As I said earlier, any feedback ("improved behavior on XP", "breaks on OS X when my iPod is plugged in") is extremely valuable, so if this issue is important to you, please help us help you by downloading and testing these snapshots as they come out.
Besides getting the existing scheme working better, here are some other improvements I'm planning. gbulmer, on a thread a while ago, you mentioned a need for a user-visible means for attaching a function for use in the USB interrupt, so that users can make up their own autoreset schemes. That's a good idea, and will happen. x893 (and anyone else who wants CAN) also needs something like this so they can handle CAN interrupts; it seems likely to me that we can kill two birds with one stone here. And luckily enough, we've even got a proposed solution that kills a third bird: using linker scripts to make it easy to override IRQ handlers. That means that these IDE snapshots will also be fertile ground for hashing out and testing a solid mechanism for this as well.
Again, thanks for the feedback! We feel your pain, and are working on getting this done.