On Mon, Jul 14, 2008 at 11:18 PM, Jonathan Larmour <[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
That's not true for OpenOCD.
>>>
>>> So what's the best way to proceed here?
>>>
>>> Make Jim Tcl + LGPL?
>
> I didn't think you were able to change the licence of Jim or OpenOCD, as you
>
On Tue, Jul 15, 2008 at 3:03 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Oyvind,
>
> Earlier I said that we needed some support for the "array" feature in
> Jim TCL.
> Actually - we do not, we have enough there now - by other means!
>
> It can be accomplished as follows:
>
> > set foo(me) Duane
Oyvind,
Earlier I said that we needed some support for the "array" feature in
Jim TCL.
Actually - we do not, we have enough there now - by other means!
It can be accomplished as follows:
> set foo(me) Duane
> set foo(you) Oyvind
> set foo(mouse) Micky
> set foo(duck) Donald
If one doe
Ville Voipio wrote:
Oyvind> Here of course there would have to be something like a
"keep-alive" progress messages minimally.
ville> But would they then be sent in the same communication channel?
Becausethat would then break the beautifully simple architecture; one
remote call results in one re
Øyvind Harboe wrote:
>>>That's not true for OpenOCD.
>>
>>So what's the best way to proceed here?
>>
>>Make Jim Tcl + LGPL?
I didn't think you were able to change the licence of Jim or OpenOCD, as
you would need the permission of all copyright holders.
The only route I can see is to take advanta
>
> #2 has stm32f103zet6 22089vc mlt 3r816
> 512k flash part.
> (I include the added info - because it is probably a date
> code and that might matter here)
>
> Dumping memory @ 0x17e0 gives:
>
> > mdw 0x17e0 16
> 0x17e0: fff
>> That's not true for OpenOCD.
>
> So what's the best way to proceed here?
>
> Make Jim Tcl + LGPL?
Also, we don't need to link Jim Tcl into OpenOCD, but it's less hazzle.
There are many ways forward. Including ditching Jim Tcl.
The scripting work that is being done with Jim Tcl specifically
ap
> The issue is not the same with eCos and OpenOCD unfortunately. eCos is in a
> better situation because eCos does not have a vanilla GPL, but has a
> special exception clause which means that stuff linked with it does not
> also have to be GPL'd. OpenOCD does not have that.
>
> So people using Jim
Øyvind Harboe wrote:
>
>> - Jim is licensed under Apache license V2, which is listed as being
>> incompatible with GPLv2 on the FSF page. Large parts of the OpenOCD are
>> licensed under the terms of GPLv2 or later.
>
> jifl on ecos-discuss is looking into this, so it will get sorted
> one way or
On Monday 14 July 2008 19:34:06 you wrote:
> This is work in progress. Development happens on trunk and we'll
> have to cut stable branches if need be.
>
> There is a great need to synchronize work because many people are
> involved. Both "scripting" people and C people.
>
> Once the dust settles(g
On Mon, Jul 14, 2008 at 5:25 PM, Ville Voipio <[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
>> On Mon, Jul 14, 2008 at 3:58 PM, Ville Voipio <[EMAIL PROTECTED]> wrote:
I'd rather make it the responsibility of the client to implement support
for
this. This can be done via multithr
This is work in progress. Development happens on trunk and we'll
have to cut stable branches if need be.
There is a great need to synchronize work because many people are
involved. Both "scripting" people and C people.
Once the dust settles(give it a month or two), the concerns you raised
should
The majority of these issues can be addressed by refactoring and
simple code cleanup, but the one that cannot be resolved without a
rewrite of jim is going to be the License.
So, unfortunately - I do not want to start a flame war about Licenses
- but, can the authors come to agreement on what they
Hi List,
unfortunately I don't have nearly enough time to follow all the changes going
on in the OpenOCD SVN repository, but I'd like to make some comments here:
- Some people have raised concerns about the direction of OpenOCD development.
The use of TCL for integral parts of the OpenOCD seems
On Wed, Jul 09, 2008 at 12:49:50PM +0100, Spen wrote:
> > Could you clean it up a bit & exclude interface specific stuff?
> >
> > LM3S8962 does not match LM3S811... I don't know what that means.
> >
>
> The problem is more related to ftdi drivers
> ftdi own drivers require
> ft2232_device_desc "
Øyvind Harboe wrote:
> On Mon, Jul 14, 2008 at 3:58 PM, Ville Voipio <[EMAIL PROTECTED]> wrote:
>>> I'd rather make it the responsibility of the client to implement support
>>> for
>>> this. This can be done via multithreading or using a post + check for
>>> reply concept.
>> The question is if the
> I think it is important that all commands return very soon (from the human
> point of view). If a command takes long (such as a large memory read/write),
> it should not block, as that makes HMI design more difficult. It is much
> easier to poll than to create a number of threads and to wait for
Duane Ellis wrote:
> Øyvind> whether the low level tcl API's should take a call back proc.
>
> ville> Callback to what and how? How do you call back to a script?
>
> Øyvind> In terms of implementing(don't know of a case where we need them
> yet)
>
> I am confused - can you give me a better exam
On Mon, Jul 14, 2008 at 12:46 PM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Øyvind> whether the low level tcl API's should take a call back proc.
>
> ville> Callback to what and how? How do you call back to a script?
>
> Øyvind> In terms of implementing(don't know of a case where we need them
> yet)
Charles Hardin wrote:
> Ok, so what is the preferred solution?
>
> 1. stick with objcopy and do the #ifdef
> 2. stick with objcopy and do an external script to rename the symbols
> 3. go back to making a startup.c - maybe use a bin2hex c program
> instead of tclsh
>
> I don't like 1 since there a
Øyvind> whether the low level tcl API's should take a call back proc.
ville> Callback to what and how? How do you call back to a script?
Øyvind> In terms of implementing(don't know of a case where we need them
yet)
I am confused - can you give me a better example of where something like
this i
On Mon, Jul 14, 2008 at 12:38 PM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
>>
>> Currently there is state stored in the command context. I'd like
>> the low level API not to use that state.
>>
>
> And - state is stored in multiple globals - as you put it - the "flash
> banks" o
Øyvind Harboe wrote:
> Currently there is state stored in the command context. I'd like
> the low level API not to use that state.
>
And - state is stored in multiple globals - as you put it - the "flash
banks" of the current target.
Is there something inside the "jim interp" - a void pointer
On Mon, Jul 14, 2008 at 12:05 PM, Ville Voipio
<[EMAIL PROTECTED]> wrote:
> > The nasty remaining problem is LOG_XXX() and command_print. I was
> wondering
>>
>> whether the low level tcl API's should take a call back proc.
>>
>> Probably should according to my reasoning.
>
> Callback to what and
> The nasty remaining problem is LOG_XXX() and command_print. I was
wondering
> whether the low level tcl API's should take a call back proc.
>
> Probably should according to my reasoning.
Callback to what and how? How do you call back to a script?
As I see it, the problem here is that we ha
> However, are there any low-level commands which would require several pieces
> of information from cmd_ctx?
The nasty remaining problem is LOG_XXX() and command_print. I was wondering
whether the low level tcl API's should take a call back proc.
Probably should according to my reasoning.
--
Øyvind Harboe wrote:
> Currently there is state stored in the command context. I'd like
> the low level API not to use that state.
>
> I.e. "flash_banks" currently takes the currently active target
> from cmd_ctx, rather than taking it as an input argument.
I agree that having some invisible stat
Currently there is state stored in the command context. I'd like
the low level API not to use that state.
I.e. "flash_banks" currently takes the currently active target
from cmd_ctx, rather than taking it as an input argument.
Ideally, I'd like to see the low level tcl commands not rely on
cmd_ct
28 matches
Mail list logo
