Device debuggers and programmers tend not to work so well under virtual machines. VMWare is supposedly better in this regard, but I don't have personal experience.
Any special reason you don't want to use a Windows-native toolchain?
Cypress makes USB controllers designed for high-performance streaming. I haven't used them myself so I can't comment on software support etc. but since it's a large part of their business it can't be too awful.
[quote author="arhi"] [quote author="brian"] I can't say for sure but I suspect throughput will be king. Exact timing isn't possible on USB anyway, but gross latency could matter.[/quote] well, there's that isochronous driven transfer when you have some type of timing (if host can't achieve agreed timing the whole thing fails)[/quote] I guess it depends on what you call exact timing, but even with isochronous transfers there is a fair amount of clock jitter, and eg. an audio device that doesn't handle it in some way will soon be playing random noise.
I've got a previous generation WD1M, and I'm fairly sure it uses the magnet (though I haven't actually bothered testing), so I guess that's something they redesigned for the WX series. Based on your report the motion sensor seems less reliable, but on the other hand if you're in the habit of leaving hot irons lying around I guess it has its upsides as well.
[quote author="presslab"]Where did you learn of this reed switch?[/quote] It's listed in the specifications in many places, eg. here. You could try resting the pencil in a non-magnetic holder and see if the standoff timer ever kicks in (alternatively wave the pencil around).
The magnet in the holder activates a reed switch in the handle, this controls the idle/off timers. One thing you could have shown off in the video is how easy it is to change tips.
[quote author="sebm"]by the way, when looking for info on the OSX crash with the bus pirate on the internet, I found that some people were saying that one should not unplug it when a "screen" session is active, does somebody knows if that is still the case and if it is only something to watch out only with "screen" and/or with OSX-only?[/quote] That would suggest a bug in FTDI's drivers. An application can't cause a kernel crash.
The binI2C function from the Bus Pirate firmware contains some "interesting" indenting. Mixing decimal and binary constants in the switch-case statements is also quite creative.
[quote author="Bertho"]I agree that things are made overcomplicated, however, I disagree that it is easy. The intricacies of cross-dependent versions and incompatibilities is a real pain. F.ex. some versions of gcc can be build statically, while others must be build dynamically. It sucks...[/quote] Nah, it really is. That whole static/dynamic thing is a good example of making things needlessly complex. As long as GCC has had external library dependencies, it has had a mechanism to build them as part of its own build process. For the past few releases there's even a script included that downloads and sets up all the needed source packages. I posted a tutorial on how to do this some years ago on another forum. I'll brush it up for current tool versions and post it here.
I think people are needlessly overcomplicating things. Building a cross-toolchain (binutils, GCC, newlib, GDB) is actually very easy. I've seen some scripts for automating it, but they seem to be written by someone going through the documentation and filling out every configuration option, needed or not. A linker script is something you write once, when changing part you only have to adjust the RAM and flash size.
The manufacturer's peripheral libraries are easy enough to add to your project, either as a whole or by adding individual source or header files. I'm not too fond of the idea of mixing the peripheral libraries with the C library like avr-libc. There are RTOSes with permissive licenses (eg. eCos) that use the HAL model, but so far I don't have experience in that area. Trying to write portable drivers will inevitably lead to difficult design decisions (eg. how do you handle ST's famously broken I2C peripheral?)
I didn't have any problems with the one design I sent to Seeed. IIRC the only change from the default export settings was to disable vertical mirroring of drill hole coordinates (when you load the files into a viewer, the holes from the drill file should line up with the Gerber files).
Open a terminal and type "ls /dev/tty.usbmodem*", the Bus Pirate's device should show up once you plug it in. If you have the USB Prober tool installed, look for the communication class device with the vid/pid 0x04D8/0xFB00 (in the current firmware the product string is still "CDC Test").
I've just used Linux virtual machines. So far my programming needs have been met by xsvf players, in my experience USB programming interfaces rarely work from VMs.
There is a list of assigned addresses, but it hasn't been updated since 1999 so it's a fair bet NXP gave up on the idea. In version 3 of the I2C specification they added a new device identification mechanism that uses registered vendor IDs, but it is separate from addressing. Just stay away from the addresses reserved by the specification (see page 17 in version 4 of the spec) and you'll be fine. Patent fees are only a worry if you're designing a chip. If you're using a microcontroller with built-in I2C support, the manufacturer has already paid any relevant fees.