On Thursday, August 18, 2011 23:58:08 steve tell wrote:
> 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?the src/cmd/ files are geared towards interactive tools like `urjtag`. there isnt a way to pass this arbitrary type of state to the commands, so we're left with a single global variable. > 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? getting rid of the global urj_bus is good, but i'm not sure this would do it. running the "flashmem" command still won't know the active bus. > 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? a single part could have multiple buses. atm, it's pretty uncommon, but once we merge SPI/I2C support in, then it's trivial. > 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? i'm certainly open to ideas to make urj_bus go away, but i'd rather keep the current system than introduce another unofficial layer. > 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. in general, i think that's probably accurate, but i dont want to split out the cmd layer completely from the library. it's very useful imo to have arbitrary applications which sit on top of urjtag to be able to execute "raw" urjtag commands. the gdbproxy program for example uses urjtag to provide a gdb stub, but it also has a raw bypass mode that allows you to execute any urjtag command. useful when the app in question hasn't enumerated all the functionality and you want to make things "just work". -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
