[Openocd-development] Tcl API rules documented in openocd.texi
I think we have gotten far enough that we can start writing up
the API rules in openocd.texi
Committed the attached patch as a start.
Patches most gratefully accepted! Anyone who writes up the
API rules gets a pretty free hand in the definition ;-)
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Index: C:/workspace/trunk/doc/openocd.texi
===
--- C:/workspace/trunk/doc/openocd.texi (revision 808)
+++ C:/workspace/trunk/doc/openocd.texi (working copy)
@@ -52,6 +52,7 @@
* Sample Scripts::Sample Target Scripts
* GDB and OpenOCD:: Using GDB and OpenOCD
* TCL and OpenOCD:: Using TCL and OpenOCD
+* TCL scripting API:: Tcl scripting API
* Upgrading:: Deprecated/Removed Commands
* FAQ:: Frequently Asked Questions
* License:: GNU Free Documentation License
@@ -1399,6 +1400,49 @@
This script can easily be modified to front various GUIs or be a sub
component of a larger framework for control and interaction.
+
[EMAIL PROTECTED] TCL scripting API
[EMAIL PROTECTED] TCL scripting API
[EMAIL PROTECTED] TCL scripting API
+API rules
+
+The commands are stateless. E.g. the telnet command line has a concept
+of currently active target, the Tcl API proc's take this sort of state
+information as an argument to each proc.
+
+There are three main types of return values: single value, name value
+pair list and lists.
+
+Name value pair. The proc 'foo' below returns a name/value pair
+list.
+
[EMAIL PROTECTED]
+
+ set foo(me) Duane
+ set foo(you) Oyvind
+ set foo(mouse) Micky
+ set foo(duck) Donald
+
+If one does this:
+
+ set foo
+
+The result is:
+
+me Duane you Oyvind mouse Micky duck Donald
+
+Thus, to get the names of the associative array is easy:
+
+ foreach { name value } [set foo] {
+puts Name: $name, Value: $value
+ }
[EMAIL PROTECTED] verbatim
+
+Lists returned must be relatively small. Otherwise a range
+should be passed in to the proc in question.
+
+
+
@node Upgrading
@chapter Deprecated/Removed Commands
@cindex Deprecated/Removed Commands
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim TCL
Øyvind Harboe wrote: 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 would need the permission of all copyright holders. Are you saying that LGPL for Jim would be the best alternative? (Ignoring work involved, someone would have to do that work). If you get everyone to agree to it, then that would certainly work. If you're going to contact them anyway, it would be nice if you could also get permission to use it under the eCos licence (which isn't quite the same as LGPL). Or perhaps something even more permissive like the same licence used by FreeBSD: http://www.fsf.org/licensing/licenses/index_html#FreeBSD The only route I can see is to take advantage of the version 2 or later clause of the existing licence, and move to GPLv3. Because of the or later bit, you don't need the permission of copyright holders to do that. (But once done, you can't go back without permission of copyright holders who contributed code when it's under GPLv3). What happens when one mixes GPL and GPLv3? That is not a problem. The or later clause in GPLv2 means that that's permitted. The whole would be covered by GPLv3 in practice. Also, we don't need to link Jim Tcl into OpenOCD, but it's less hazzle. The FSF's view (untested in court of course) is that linking does not have to mean literal 'ld'. In fact the relevant bit of GPLv2, section 2, does not mention linking. It only refers to 'works' in the copyright sense. Having them as separate executables, but making one wholly dependent on the other means they are not separate 'works' in the copyright sense. If OpenOCD and Jim Tcl _were_ separate works which can work together and separately, that would be fine. But if Jim is an inherent part of OpenOCD then that does not side-step the GPL obligations. Another reason to make OpenOCD support multiple scripting engines. Is there, in practice, a problem to work w/Jim Tcl until we've got the scripting infrastructure sorted and at that point make a separate executable for Jim Tcl? (If we state this as a goal, we'll be getting patches steering us in that general direction hopefully). It depends what you mean by in practice. If anyone distributes openocd before that work is complete, strictly that would be a licence infringement. There are many ways forward. Including ditching Jim Tcl. Obviously. The scripting work that is being done with Jim Tcl specifically applies to other scripting engines and perhaps we'll define up an interface to OpenOCD where one can place any engine on top. Sure. As above, if openocd is not dependent on Jim TCL, that would be fine - if Jim just happens to be one of a choice of front-ends (one of which being GPL-friendly :-)). I think your easiest route is still GPLv3 though, IMHO. That would cause problems for athttpd(eCos license) using Jim Tcl or? I was talking about licensing OpenOCD as GPLv3, not Jim. It's easier to move OpenOCD to GPLv3 than change Jim's licence I believe. Because the existing GPLv2 code can be switched to GPLv3 without a need for any permission. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. --[Si fractum non sit, noli id reficere]-- Opinions==mine ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim TCL
On Tue, Jul 15, 2008 at 4:34 PM, Jonathan Larmour [EMAIL PROTECTED] wrote: Øyvind Harboe wrote: 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 would need the permission of all copyright holders. Are you saying that LGPL for Jim would be the best alternative? (Ignoring work involved, someone would have to do that work). If you get everyone to agree to it, then that would certainly work. If you're going to contact them anyway, it would be nice if you could also get permission to use it under the eCos licence (which isn't quite the same as LGPL). Or perhaps something even more permissive like the same licence used by FreeBSD: http://www.fsf.org/licensing/licenses/index_html#FreeBSD I believe the intention of the Jim Tcl licensing was to make it as flexible as possible. Jim Tcl is intended to be embedded into some other product, open source or not, that has the overall license for the product. Would http://www.fsf.org/licensing/licenses/index_html#FreeBSD be the best choice then? I assume FreeBSD would work well w/eCos? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Jim TCL
Øyvind Harboe wrote: I believe the intention of the Jim Tcl licensing was to make it as flexible as possible. Jim Tcl is intended to be embedded into some other product, open source or not, that has the overall license for the product. Would http://www.fsf.org/licensing/licenses/index_html#FreeBSD be the best choice then? I assume FreeBSD would work well w/eCos? It would. It's a very liberal licence. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. --[Si fractum non sit, noli id reficere]-- Opinions==mine ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] target scripts
Hi, if i setup a target reset script, eg. target_script 0 reset debug.script debug.script contains echo hello flash info 0 shutdown nothing seems to get executed - ok if i call from the telnet prompt. I see the following in the debug log, so the script is being called. Debug: 174 1000 target.c:741 target_call_event_callbacks(): target event 0 Debug: 176 1000 command.c:397 command_run_line_internal(): script debug.script Had a quick look, but i find debugging the tcl stuff a real pain. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
