Roger Wolff

Yeah . Ran into this too. For newbies (like David and me) it is annoying that before anything works, you have to delve into the GCODE figure out what G64 is supposed to do determine that it shouldn't matter, and then A) edit the generated GCODE file and then B) find where in the config that command is coming from. From a usability perspective it would've been better to have the config file sparse, and allow people who know what they need/want add stuff to the config. Alternatives are to by default...

gerbv fails to display logo.

OK. starting a project again, and the time to download an image (ten minutes) is enough to search for the sources, recompile the wrong sources, find the right sources, update them from git, recompile them, restart the download, search for the home page, find the bug tracker edit another bug, then search for this one and start typing..... It is still the same machine having this problem. but I did upgrade the OS from 16.04 to 18.04, so I'm likely running a newer libusb now. Anything I can do to debug...

FYI: I don't agree with the label "doc" and I still think that an effort should be made to work towards the situation where something like dfu-util somefile.dfu simply does the right thing which is to flash the chip. I have less technical clients that may need to field-upgrade a board/module/system, so the less they have to type, the less that can go wrong. But I don't have time to work on this, and probably you don't either....

Yes... I've been a dfu-util user since "before" the .dfu file format. I had a script...

dfu-util requires -a x on the commandline when flashing .dfu files.

I would hesitate to recommend less-secure solutions in the documentation. As such:...

I vote for Github! :-) With other source code control systems, if the master suddenly...