As Michal Ludvig wrote: > one outstanding problem with the BusPirate programmer that should be > addressed before the next release is the behaviour when avrdude gets > killed (for instance with Ctrl-C) during programming. That leaves > the BusPirate in a non-default mode that isn't very easy to get out > from.
I've got my doubts we'll be able to fix that before the next release... > I'd like to prevent that by catching ^C, as that's the most likely cause > for an unclean exit, and reset BusPirate before avrdude dies. This can > easily be done in Linux/Unix(/OS-X?) with a custom handler for SIGINT > signal - is that an acceptable solution? > > How to do something similar on Windows? I tried adding a signal(SIGINT, ...). It compiles, but is obviously not called when hitting ^C. > And how do the other programmers handle unclean exits? Do we simply > leave them in a funny state and reset before the next run? Right, that's the way they currently (don't) handle it, and also the reason why I doubt we'll be able to hold off a release for that. There's quite a bit of overall cleanup needed before we can do that. Things to consider: . There are still many functions in libavrdude that directly call exit(1). They should not do that. Instead, they should propagate their failure through a return code, and leave it up to the caller to handle it. The only file that should ever call exit(1) is main.c. . We need a per-programmer cleanup hook, that can be invoked as part of main.c's cleanup actions right before exiting. Care has been taken that the programmer already arrived in a state where cleaning up actually makes sense, as well as de-installing the cleanup handler up normally shutting down the programmer. There might be applications in future that want to run more than one programming session before really exiting. . Remember that the amount of actions that may be performed within a signal handler is /very/ limited. For example, you are not allowed to perform anything that might invoke malloc/free, and this includes things like printf. Thus, the signal handler basically can only set a flag, and has to leave it to the upper layers to perform the right actions. This, in turn, requires a lot of structural cleanup. Just so nobody gets me wrong: I really appreciate that kind of feature, as leaving e.g. a JTAG ICE mkII in a half-baked state is a nuisance. But don't let us do it by introducing even more crocks, let's do it right instead. If it weren't for the sheer amount of existing code, I think rewriting everything in C++, using exceptions, would be a much cleaner way, but it's going to take man years to do that I'm afraid. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
