PART DUEX ========== To understand this - please - read my earlier thread: "Target AJAX like support - User Interface Thread".
This thread discusses the "command ideas". The user interface part is in the earlier thread. What ever we do - we need to come up with a Nifty Protocol name for this part, some name that is utterly silly or socially offensive. -Duane. =============== I will repeat my self, this point is UTTERLY important that we get this API correct - otherwise we will screw this feature up big time. I cannot recommend this GOOGLE TECH TALK - enough http://lcsd05.cs.tamu.edu/slides/keynote.pdf http://video.google.com/videoplay?docid=-3733345136856180693 http://www.youtube.com/watch?v=aAb7hSCtvGw =============== SENDING COMMANDS =============== The tiny server supports HTTP post, and HTTP GET, those are probably enough for our purposes. Lets assume those 2 methods are plenty. ================= RECEIVING REPLIES ================= Today, we have a TCL command server. That can continue easily enough. But I want to verify that this is *STILL* a good solution. I cannot judge from the stand point of AJAX, FLASH, and JAVA, which is better. To what degree can they open a socket and talk to it? is this utterly easy? Or is the answer something else: "They can, but it is painful, it is easier if we do some type of "XHTML" requests instead? My understanding of AJAX comes from this: http://www.brainjar.com/dhtml/ajax/default.asp Let us assume the server *CANNOT* easily respond with XML.. Can we choose another format that is simple and easy to parse? Most if not all commands need to return data in some "name/value" type format that is extendable and easy to parse. I am ignoring the transport scheme, pending resolution of the above). Using the "version number request" - (below) as an example, the element names (or tag-names) might be: protocol-version: 123 svn-version: 456 sign-on-string: "The fancy new openocd version 1.2.3 built by du...@borgcube on 2009.06.03" XML is another idea. JSON is another. Simple ASCII text, as shown above is also very simple, in effect, the reply data component looks like http-headers (on purpose). I cannot judge how easy it is for any of these common web-script languages do the majic they do. I would like input from others about this. ===================== Minimal Commands: ===================== (a) What version are you Reply is multi-part (1) the protocol version number (2) the SVN version number (3) the sign on string OpenOCD gives @ startup. ===================== (b) What are the list of targets. ===================== Reply is the list of names supplied to 'target create' ===================== (c) What are the list of taps? ===================== Reply is the list of names supplied to 'jtag newtap' ===================== (d) There should be *NO* concept of "active tap", nor "active target" ===================== In all cases, all command should *require* a specific target or tap name be specified ===================== (d) For any target, or tap, or board ===================== A means to get *details* about the target or tap, or board Using the TAPNAME, the TARGETNAME, or ?something? as a key. In general, this "details" request should be redirected to a *static* pre configured file, perhaps a *JSON* file, for example, the request URL might be: http://localhost:6666/openocd/static/chipatmel/at91sam9260/memory.json (See the 'static meta-data files' in my earlier thread). ============================== (e) The ability to read the value of some TCL variables. ============================== For example, assume I have a TARGET name in my Javascript. That target name might be: "at91sam9260.cpu" Return the "details" file for this target. [see above] =============================== (f) The ability to read/write memory =============================== In effect, where one can specify the *width* of the access. target_read_memory() And target_write_memory(). ================================ (g) CPU Registers (specifically GDB registers) ================================ The ability to get the *NAMES* of the CPU registers. This might come from a "cpu-reg-names.json" file. The ability to *read* and *write* those registers. I'd hope this would use a common viewer sheme. ================================ (h) The ability to read "special cpu registers" ================================ For example ARM "cp15" - is not a GDB register. These might be a *special-register-viewer* file. ==== It is late, that is the idea I've had in mind for +1 year And is probably good "food for thought" for now. ==== *END* _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
