On Tue, Sep 29, 2009 at 5:57 PM, David Brownell <davi...@pacbell.net> wrote: > On Monday 28 September 2009, Ųyvind Harboe wrote: >> >> Is this the expected behaviour now, as previous versions would fail >> >> silently >> >> if no id was given. >> > >> > I changed that when I changed it to make sure it didn't >> > drop messages in various cases. I think it's better to >> > get the config files updated, so startup verification >> > can do a better job, but I might be persuaded otherwise. >> >> It should at least be *possible* not to check the ID's even >> if one is strongly encouraged(kind word and a gun) to >> add them... > > By "not check" you must mean some more complex conditional than > is there now ... it'd obviously have to check to see whether it > should "not check"! Else it'd be "never check". Maybe you just > want to suppress the warning?
"not check" means simply list the TAP ID (if any) and not to fail examine. > Now, I'd contend that all those are handled well just now. It's not what we think of that will get us, it's what we don't think off. E.g. I can easily think of a situation where it is not practical to check for the id code, or in the future where we want to *read* the id code and have some conditional behavior scripted. > Would handling "-expected-id 0" as a "match anything" wildcard > suit, as an explicit "stifle warnings" option for (2a) or, in > fact, any branch of (2)? Don't override the meaning of integers, use a separate keyword :-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
