On Sunday 07 June 2009, Duane Ellis wrote:
> But - today I think what you mean is this:
>
> Today, all target reset handlers are done like this:
> $_targetname configure -event reset-init { CURLYBRACE }
They aren't "all" like that, though. So the solution you list
below can't always work
duane> $TARGETNAME mdw
david> Though "mdw" is really impractical for scripting.
yea, it's probably a very bad example, one probably needs to use
'$targetname mem2array" or "$targetname array2mem", or we can create a
helper sub-command
david> A third option: too painful to use. How exactly is
On Saturday 06 June 2009, Rick Altherr wrote:
> > Again, we don't have such cases today. We can speculate all kinds
> > of things, but in the absence of real hardware I don't think the
> > results of speculation are compelling. Plus, "$target_name curstate"
> > has a very limited range of state o
On Saturday 06 June 2009, Duane Ellis wrote:
> duane> $TARGETNAME mdw
Though "mdw" is really impractical for scripting. The "memread32"
thing would be better ... but notice that *it* ignores $TARGETNAME
too, for much the same reason other scripts can't use it.
> david> You'll notice most of t
duane> $TARGETNAME mdw
david> You'll notice most of the reset-init event handlers can't use that.
CAN'T - or "just happen to not use that" - Big difference.
By design, they should be able to do exactly that, see:
src/target/target.c - lines 3559 ... 3731
By design, it should work, that
On Jun 6, 2009, at 4:27 PM, David Brownell wrote:
[ second part of reply, focussed on before-0.2.0 ]
On Saturday 06 June 2009, Rick Altherr wrote:
On Jun 6, 2009, at 1:20 PM, David Brownell wrote:
Which just
points out another concep
On Saturday 06 June 2009, David Brownell wrote:
> if { [jtag tapisenabled [$t tapname]] == 0 } {
> continue
> }
Turns out I can already:
if {[jtag tapisenabled [$t cget -chain-position]] == 0} {
continue
}
so can make $SUBJECT work
[ second part of reply, focussed on before-0.2.0 ]
On Saturday 06 June 2009, Rick Altherr wrote:
> On Jun 6, 2009, at 1:20 PM, David Brownell wrote:
>
> >>> Which just
> >>> points out another conceptual problem ... either (a) "target create"
> >>
Splitting my response here in two parts ... this first one
seems more in the "after 0.2.0 ships" territory.
On Saturday 06 June 2009, Rick Altherr wrote:
> On Jun 6, 2009, at 1:20 PM, David Brownell wrote:
> Sorry, I thought you were recommending naming things such as
> "omap3530" for both the
>>> [ targetname & tapnames are the same, and is confusing]
Yea, ugh, that is my fault, I did all that last year, I set the
example. What I did not consider well was the TAP names when I setup my
examples after creating the "tcl-target-as-an-object-command.
FYI - The original idea was to supp
On Jun 6, 2009, at 1:20 PM, David Brownell wrote:
On Saturday 06 June 2009, Rick Altherr wrote:
Having the target and tap names be the same is _not_ preferable. It
makes the relationship between those two layers very confusing.
Hmm, having them be the same is the convention that's encourage
On Saturday 06 June 2009, Rick Altherr wrote:
> Having the target and tap names be the same is _not_ preferable. It
> makes the relationship between those two layers very confusing.
Hmm, having them be the same is the convention that's encouraged
already, as well as being the one used in every
Having the target and tap names be the same is _not_ preferable. It
makes the relationship between those two layers very confusing. For
example, when a target is created, it introduces a new command names
for the target. The same does _not_ happen for a TAP. If you make
the names the s
On Thursday 04 June 2009, David Brownell wrote:
>
> > ... although this touches on some other glitches in the
> > vicinity of tap enable/disable logic. The "tapenable"
> > code paths don't seem to have an obvious way to fail and
> > report that the tap was not enabled.
Still true, but not direct
> > How about fixing this in the calling code?
>
> ... although this touches on some other glitches in the
> vicinity of tap enable/disable logic. The "tapenable"
> code paths don't seem to have an obvious way to fail and
> report that the tap was not enabled.
Glitch in the patch I sent, nyet s
On Thursday 04 June 2009, Øyvind Harboe wrote:
> > It won't work, but is is not an error. Return ERROR_OK so other targets in
> > the chain can be examined.
>
> How about fixing this in the calling code?
... although this touches on some other glitches in the
vicinity of tap enable/disable logic
On Thu, Jun 4, 2009 at 5:54 PM, Magnus Lundin wrote:
> It won't work, but is is not an error. Return ERROR_OK so other targets in
> the chain can be examined.
How about fixing this in the calling code?
It *did* fail to examine the target, so isn't returning ERROR_OK best?
What if some other c
It won't work, but is is not an error. Return ERROR_OK so other targets
in the chain can be examined.
Reagrds
Magnus
Index: src/target/target.c
===
--- src/target/target.c (revision 2051)
+++ src/target/target.c (working copy)
@@
18 matches
Mail list logo
