On 2012.08.08 14:58, Markus wrote: > I just applied your patch to 1.0.12 and can't see any problems > with it. From a number of simple tests, it looks as if it > behaves well.
Great. Glad to hear I haven't broken anything... ;) > I'd however still keep a decent path length for the file name > (binary_name), as 256 is not a whole lot. I ran into the 256 > boundary quite often with Delphi to consider it insufficient > (in particular for maze-like development directory hierarchies > and when calling the command in scripts). It would not really > hurt to increase this value. My consideration is that this is a sample, with the expectation that whoever is using the FX2/FX3 feature would have the files close by. If people start to use xusb for FX upload in toolchain scripts, it'll tell us that we should really start looking into producing our own version of fx2load... Also, my usual concern on Windows has to do with [1], though this may not apply to CRT calls such as fopen(). Now, this being said, I don't have that much of an issue bumping the limit, but 4K seems awfully large for a file path. Would 512 bytes be OK with you? > Furthermore, as the FX3 files are expected to come as an .img > file, I'd suggest not to use "data.bin" as default file name > (I'd rather opt for no default filename at all for FX2/FX3). And the FX2 ones come as .bix, so if we wanted to satisfy everyone, we'd need a .bin for the mass storage dump, .bix for FX2 and .img for FX3, plus the logic that goes with it. Except it's a sample, so we might as well keep things simple. Likewise, you'll see that I reused the data.bin section we already had for the -b option, which was optional, so that's the reason why it's still optional for the FXes. If you think it's preferable, I can make the filename mandatory of all of -b|f|g, but I didn't see it as a major point and it helped minimizing the diff. > As for upload vs. download, this seems to be a matter of taste. > From my experience, the hardware development crowd tends to > prefer download when flashing firmware to a device. I'd say you should always consider users who aren't familiar with the operation first and foremost, as they're the ones for whom the terminology will matter. If it goes from PC to an external device, and the program that is run by the end user to perform the data transfer executes on the PC (or, in a more general manner, if the environment where the end user is going to actively perform actions is not the target), then, as far as I'm concerned, it should logically be labelled as an upload. Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247.aspx#maxpath ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
