more sophisticated ways for updating the atusb firmware

Stefan Schmidt stefan at datenfreihafen.org
Thu May 12 10:17:45 EDT 2011


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




More information about the discussion mailing list


interactive