On Sun, Dec 19, 2010 at 7:56 PM, David Brownell wrote:
>
>
> --- On Sun, 12/19/10, Øyvind Harboe wrote:
>
>> So you don't think there is a disadvantage to
> using variables
>> to pass information around?
>
> I never said that. Are you saying that one
> goal is reducing usage of globals? That's
--- On Sun, 12/19/10, Øyvind Harboe wrote:
> So you don't think there is a disadvantage to
using variables
> to pass information around?
I never said that. Are you saying that one
goal is reducing usage of globals? That's
generally a good thing ... but since you had
stipulated that the sing
On Sun, Dec 19, 2010 at 6:50 PM, David Brownell wrote:
>
>> Øyvind Harboe wrote:
>> > A board script should export a single procedure
>> without arguments
>> > with a name that's fixed by convention.
>
> Is there an advantage to that approach? After
> all, a script file *is* essentially a single
> Øyvind Harboe wrote:
> > A board script should export a single procedure
> without arguments
> > with a name that's fixed by convention.
Is there an advantage to that approach? After
all, a script file *is* essentially a single
procedure etc (nameless, but no never mind).
_
Øyvind Harboe wrote:
> A board script should export a single procedure without arguments
> with a name that's fixed by convention.
This sounds good to me, for starters!
//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
h
> How does this work in case we have multiple devices in one scan chain? does
> the last included "setup_target" replace the previous one, or do we need
> unique names?
What target scripts export that board scripts can use would have
to be defined by each individual target script as there is no
si
On 12/18/2010 10:15 PM, Øyvind Harboe wrote:
How about having target scripts export a proc as the default
behavior rather than just executing statements?
This would get rid of using (effectively global)variables as
a way to communicate with these scripts.
A proc also opens up for handling varia
How about having target scripts export a proc as the default
behavior rather than just executing statements?
This would get rid of using (effectively global)variables as
a way to communicate with these scripts.
A proc also opens up for handling variations of targets in
a single script.
A stab at
