Hello. On Thu, 2011-05-12 at 13:29, Werner Almesberger wrote: > Stefan Schmidt wrote: > > What value have you currently set for bcdDevice? If you start with 0 > > or one you could just bump the version _if_ there will be another > > batch which needs different firmware. Or you just go with a > > different PID. :) > > All the atusb boards, old (C8051F326+AT86RF230) and new (ATmega32U2+ > ATRF86231), identify themselves as bcdDevice = 1. All the old boards > ever made are in a neat pile on my lab bench, keeping support > overhead manageable ;-)
Good. If needed at some point we could bump it without going for a new PID. There are way more ways to handle such things though. Its more theoretically. > > Yeah, its more on the level of less error-prone user interaction > > during flashing. > > Combined with devices like Openmoko's GTA01, where mis-DFU'ing > u-boot meant a rather entertaining session with debug board and FPC, > both loaded with more self-destruct features than your average > top-secret spy plane :-) Psst, don't tell anyone. :) > > Broken dowloads of the firmware, wrong files, etc. > > The CRC can be useful indeed. Perhaps you should make dfu-util > require a DFU suffix by default (the wording in appendix B suggests > as much). That way, it would also reject truncated files. Yeah, it needs to be mandatory. But for that it needs to get written and integrated nicely first. :) Once that is done, not much stuff but diploma is taking its time right now, it will be mandatory with a commandline option to ignore it. > > Hopefully I have some time over the summer to integrate the suffix > > handling in dfu-util. I come back to you as guinea pig with real > > world hw to test and fix the needed tooling for it then. :P > > Perfect ! :-) Will let you know. regards Stefan Schmidt _______________________________________________ Qi Hardware Discussion List Mail to list (members only): discussion@lists.en.qi-hardware.com Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
