The original title of this enhancement item was "Cable driver 'help' functionality is no good idea". However, it's actually a bigger issue: As the power and necessity for configuration of cable and bus drivers grows, the new drivers all take an increasing number of (textual) parameters.
A list of strings, as it is passed from the command shell, is a nice generic solution, but it could be discussed if the API of the drivers shouldn't rather just accept strictly typed arguments (and no need for parsing strings).
This, together with the problems of "help" texts embedded in the driver, all belongs to the same topic: Everything that would have to be done differently for a different way of using UrJTAG should be moved from the driver level to some upper layer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=478715
Originator: YES
The original title of this enhancement item was "Cable driver 'help' functionality is no good idea". However, it's actually a bigger issue: As the power and necessity for configuration of cable and bus drivers grows, the new drivers all take an increasing number of (textual) parameters.
A list of strings, as it is passed from the command shell, is a nice generic solution, but it could be discussed if the API of the drivers shouldn't rather just accept strictly typed arguments (and no need for parsing strings).
This, together with the problems of "help" texts embedded in the driver, all belongs to the same topic: Everything that would have to be done differently for a different way of using UrJTAG should be moved from the driver level to some upper layer.
Sounds relevant for liburjtag.