On Tuesday 07 July 2009, Øyvind Harboe wrote: > reset_config currently manipulates the current state rather > than just sets the state by some scheme which I'm not > able to decipher immediately.
It's what's documented. There are several categories of options, and what you pass changes *only* the category of that parameter. The categories are what they have always been: signals, combination/bugs, and drive types for nSRST and nTRST So for example you can say how TRST is driven without having to say how SRST is driven and whether the board has bugs in that area. > There isn't a way to *read* the current state. Yes, that's a problem. Not a new one of course. > How about modifying reset_config to simply *set* the > state based *only* on the arguments to reset_config, > ignoring the current reset_config state? That makes it impossible to combine constraints that come from different spots, so I don't like that notion. Is there some problem the current scheme has? - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
