Re: [Openocd-development] Target AJAX like support - User Interface Thread
duane> I think your view is more (A), and mine is more (B). david> Yet my example of a "flash download" tool seems more like (B) to me. :) Seems like we both sit at two different ends of the spectrum, you see "de-bricking/flashing" a board as day to day I don't. That is perhaps good, it makes one think of the other use cases. If I where to list "use case areas of interest" - they would be: (a) "my board is a brick - please help me reflash(recover) my board" type GUI interface. Be it "linux" or some other operating system - the board is dead and must be recovered. This is more for the "linux target board developer type". Also WinCE types, ie: "urjtag" type solution, and is more "flash programmer centric" Much of this is External NOR flash,or External NAND flash. What is not - is micro-controller based stuff which is more (d) then (a). Boundary scan method works (ie: the UrJTAG approach) but is slow or the "download helper code" (the OpenOCD approach) faster. (b) How to write a "xlinix flash programer" type solution aka: Much like Xilinx IMPACT, or the Altera equal (I don't know the name). This is more "jtag centric". I guess this is more Dick Holenbeck type centric (he wrote the xsvf support). (c) Boundary Scan - wiggle pins on the jtag chain. People have asked about this... and we have talked about it But there are no "drum beaters" eager to help. (d) Debug & Software Development solutions. Mostly "non-linux-kernel" micro controller centric "uboot" debug falls into this category. === agree? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
On Sunday 07 June 2009, Duane Ellis wrote: > So what should we focus on? > > (A) Wizard type features to help *new*users* get started > > (B) Day to day operational features. > > I think your view is more (A), and mine is more (B). Yet my example of a "flash download" tool seems more like (B) to me. :) Keep in mind also that while some "day to day" users are using GDB-over-JTAG to develop microcontroller software, others have more limited and infrequent demands, like de-bricking or (similar) installing new boot loaders. And I'd say that the former will be getting deeply familiar with command line tools, of necessity ... the latter are the ones most in need of the kind of "low learning overhead" interface which motivates GUIs or turnkey command frameworks. Plus, semi-related, this project is not doing much right now to facilitate even basic task-oriented scripting; so the limits of what can be done without GUIs are not even in sight yet. I notice the "Scripting Overview" (in the Doxygen output, technical primers section) has this disturbing statement right at the top: The scripting support is intended for developers of OpenOCD. It is not the intention that normal OpenOCD users will use tcl scripting extensively, write lots of clever scripts, or contribute back to OpenOCD. Well, why the heck should users *NOT* use the scripting? Or contribute? Color me puzzled. Classically, those are the primary reasons to include scripting. And if users don't contribute scripts, how *do* they help grow support for more systems? And how *could* the developers really understand user requirements? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
duane> [ajax] david> Saying "AJAX" or talking about any other implementation tech feels to me like putting the cart before the horse. Correct, I should have given more examples. What I ment was - 2 parts: 1) the GUI interface (a) could be built-in webserver + javascript (ajax) OR (b) could be built-in webserver + flash OR (c) could be Ecplipse + JAVA OR (d) could be Tcl/Tk app Perhaps the use of "ajax" is/was very premature - I really mean that sort of concept, nothing more. 2) The backend part the above pieces talk to. It responds to commands. = So what should we focus on? (A) Wizard type features to help *new*users* get started ie: Some "build a basic configuration file" tool. That could be *text* - ie: Answer questions, choose from a list. That's not 'inside openocd' - its more of a "text configuration file' Could be as simple as Perl CPAN - text mode Or as simple as Linux Kernel "make config" text mode. (vrs make xconfig, or make menuconfig). (B) Day to day operational features. I think your view is more (A), and mine is more (B). -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
Saying "AJAX" or talking about any other implementation tech feels to me like putting the cart before the horse. I still don't know what problems would expect be solved ... though I can think of three right off the bat that *I* would expect to work: * Eclipse integration. Probably covered for GDB support, but not necessarily for other tasks (and it's not like I can do a useful "apt-get install eclipse" on Ubuntu), like ... * Flash updating. This being very board-specific. "Write this version of U-Boot to that address" ... sometimes with a special header, or needing a "helper" boot loader (e.g. ROM loads helper from NAND to on-chip SRAM, which sets up DRAM and loads U-BOOT from a different part of NAND). * Tell me what's on that JTAG chain, and build an "openocd.cfg" to start out with. Some basic textual or pictorial display; this would need ways to grow and manage a chip database. Plus maybe ways to hint about special features. Also, user interface design skills are rather distinct from hardware interfacing skills. Getting very deeply into that would probably call for a new set of developers. Especially if something like an AJAX based web client were in the cards... But I expect that some simple tools could be written just using TK/Wish. That flash updating thing, for example ... have a look at the "SAM-BA" tool from Atmel, which ISTR is written in TK and talks directly to the ROM boot loader on newer AT91sam chips, using USB or a UART. (Various ARMs from TI could do the same thing; both DaVinci and OMAP3 parts, in particular.) How would such a flash updating thing work? Select interface dongle from a menu; select board (or maybe just chip/target) ditto. Then the board setup file could say "provide these menu commands". Doing all that in TK/Wish *ought* to be really easy... Right now very few boards have much in the way of script support. I mention "write the boot loader" since it's a fairly basic thing that is widely needed, and should thus be easy to approach ... but there will likely be other tasks worth targeting. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Target AJAX like support - User Interface Thread
zach> Duane, Did you write this plan up? Got Links? If not, care to revisit
zach> the vision in a new thread on the list or a patch to The Manual? :)
Nothing wrote up - so I'll put some ideas and concepts here that
could/should be put into the "developer manual"
This is "vision" - nothing is cast in stone, so toss up some ideas.
This is the *USERINTERFACE* part of the discussion.
Another thread will be the *command ideas*.
It 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
I wrote this 'out of my head' tonight, it is not clean. I've been
thinking about this for quite some time.
You know, we *COULD* - have OpenOCD serve out the OpenOCD manual this
way too.
Hmm Interesting
-Duane
== For reference ==
I assume the reader has read:
${OPENOCD_SRC}/doc/manual/server.txt
That is the starting point of this discussion.
Let us assume the user has opened their web browser and points it at the
"openocd built-in-web-server".
What happens?
What is available?
Let's talk about what the user should be able to do.
I want to paint a picture...
Primary
General Experience Goal - Ability Locally Override
Location #1;
The user should always be able to stuff some files in a 'project
local directory'
and serve those files out when the user connects to the built in web
server.
[ie: the directory where OpenOCD runs].
If those files are not found, OpenOCD - searches *standard* places.
Example: My working directory is: "c:\myproject"
the OpenOCD config file is called: "c:\myproject\openocd.cfg"
I should be able to put files in: c:\myproject\openocd\
and override the system.
Remember: there are often lots of html files, to many to clutter the
current directory.
Location #2
Users ${HOME}/.openocd/http directory
Location #3
${INSTALLDIR}/ .
Main "HTML" page - what should "index.html" be?
There should be 2 of them.
(a) the main full featured one.
(b) the "framed header" - that wraps around a users file.
Framed Header EXAMPLE:
If I create a my own "index.html" file.
We should be able to "frame" that with a small title bar with some
links.
sort of like "google image search" - It has the original at the top
of the page.
This should exists so that the user always has an "out" and can get
to the main default openocd page.
Maybe that FRAMED header - is fancy and uses something like this:
http://www.brainjar.com/dhtml/menubar/demo.html
STATIC FILES
We should be able to create some simple html files, for example:
SPECIFICALLY:
These are *directories* where all kinds of kewl things can be put.
What ever you want... the examples here are *directories*
http://localhost:/openocd/static/chip/xilinx/XC3S500E-4FG320C
http://localhost:/openocd/static/target/st/str912
http://localhost:/openocd/static/board/atmel/sam3u-ek
http://localhost:/openocd/static/dongle/xverve/signalizer
Rules should be like Apache.:
First - try the given name.
If the given name is a directory, append "index.html" and try again.
LOCATION
These files should be in the "install" directory, these would be
under openod/httpd/static/
the "httpd" directory should be Parallel to the TCL, and other
directories under install.
REQUIRED FILES
index.html - for static content
or index.tcl- for dynamic content }
OPTIONAL (strongly suggested) various "meta-data.json".
TBD - exact format, style, etc.
TBD - other format, other names.
Example: 'flash.json' - could describe the on-board (or
on-chip) flash.
Example: 'memory.json' could describe the memory map.
Example: 'cpu.json' - could describe the CPU.
The cpu.json file in the *board* or *target* directory might
have an "http-redirect"
example: openocd/static/chip/st/stm32/cpu.json - might "REFER"
to "core/arm/cortex-m3.html"
Likewise, the "pic32" - might *refer* to the "mips/m4k.html"
These "meta-data" files - can be used by some *GENERIC* AJAX like things
that create a *MEMORY* view web page, or a FLASH program page.
Maybe another that can b used to *view/edit/change* cpu registers, or
maybe the ARM co-processor registers.
Imagine a "memoryviewer.java" - application that uses the meta data
file: 'memory.json' as configuration data.
TBD:
Exact format and content of the *details.json* file.
I think JSON is a simple easy to understand and use file format.
It is also easy for
