Hello. On Thu, 2011-05-12 at 10:47, Werner Almesberger wrote: > Stefan Schmidt wrote: > > 1) Fill in the bwPollTimeout value with a sensible value (?6.1). > > I set it to 100 ms. If I understand things correctly, this should > be the time it takes the device to process one packet. The MCU > takes about 5 ms per Flash operation, making the worst case (write > followed by erase) 10 ms plus processing overhead.
Normally you would use some kind of dynamic algorithm, but in your case a fixed value with enough overheads should be more then enough. This really comes into place when going into mbyte range or higher data to be flashed. > > 2) Have a real USB from the USB forum assigned and be prepared to have > > a way to identify between different hardware revisions. > > atusb uses a PID under the official VID of qi-hw. I guessed that much. All fine on this front then. > It's even registered at ... wait a minute ! www.linux-usb.org has > fallen into the clutches of a domain grabber ? Wow :-( To bad. > I don't manage bcdDevice for now. There's a bunch of ID features > in the atusb-specific protocol, though. I have not much experience with this from a hw point of view. My simple understanding is that it just reflects the hw revision(?). This may be different between companies anyway. From a DFU suffix view it would be mostly relevant if there are new boards with the same PID/VID but different firmware needs, or more problematic incompatibilities, for the devices. 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. :) > > 3) Add a dfu-suffix to your firmware file. > > Okay, that may be something useful to add in the future. Not that > it would be particularly horrible to flash some junk, because > recovery is easy enough. Yeah, its more on the level of less error-prone user interaction during flashing. Broken dowloads of the firmware, wrong files, etc. Usually not a problem for the people around here and maybe the current target of the hw anyway. If you go into high volume production and still need a way to allow user updates such stuff becomes handy to avoid support costs. :) 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 regards Stefan Schmidt _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
