I notice that the commands code in src/cmd/cmd_* that require a bus to be
initialized make use of the global urj_bus declared in
src/bus/buses.c:
urj_bus_t *urj_bus = NULL;
There's also the list of buses, "urj_buses_t urj_buses = { 0, NULL };"
Given good library design and previous discussion on this list about
globals in a library being a bad idea... is there any consensus on a plan
for how to fix these?
While jotting down some terse documentation for my urjtag python bindings,
I came up with somthing like:
FUTURE: urc.initbus() will return a urjtag.bus object. [corresponding to
urj_bus_t*] Currently, there is one implicit global bus, and only one bus
can be active at a time.
FUTURE: detectflash(), peek(), poke(), and flashmem() will be a methods
in a new urjtag.bus class, not urjtag.chain.
Is this reasonable in the abstract?
I'm not quite clear however on the potential for multiple busses in
current or future urjtag code, and the relationship of busses to chains
and parts. Clearly, several chains, each with their own cable, should be
able to be open at the same time. Their bus(es) should be independent.
And certainly there could be a bus within each of several integrated CPUs
on a single chain. Can a bus that accesses a non-jtag flash chip using
boundary scan registers span several parts?
Thoughts on how to get there from here? Should there be a urj_bus pointer
and urj_buses list in each chain? Or perhaps a urj_buses list per each
chain, and one urj_bus pointer used as the implicit bus only by the cmd/cmd_*
interactive parser, but not considered part of the C library API?
As a further aside, is it right to think of the interactive interface in
cmd/cmd_*.c as just one client of the core urjtag library? I'm finding
that distinction useful when thinking about backwards compatibility of the
"jtag" program+scripts vs. general library design.
Steve
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
UrJTAG-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/urjtag-development
