On Sunday 17 May 2009, Duane Ellis wrote: > FYI - I wrote the original JimTCL memory functions here last year, sadly > my documentation level sort of sucks eh?
Documentation? Didn't even know that tcl/* stuff existed. :) There aren't even any users of the tcl/* stuff in any of the existing cfg files. And as we know, examples are all too often substitutes for documentation. > The intent was to *NEVER* really expose "ocd_mem2array" that was a > builder function. Based on my quick read of what you are doing you > should source the file "memory.tcl" or mmr_helpers.tcl > > Do this in your CONFIGURE script: > > source [find tcl/memory.tcl] > > That file has a number of functions like: "memread32 ADDRESS" Hmm, I asked about this sort of thing not long ago: https://lists.berlios.de/pipermail/openocd-development/2009-May/006340.html Nobody knew about "memread32" as an answer... > By design, it handles various errors. Everyone seems to be using mw{b,h,w} instead of memwrite{8,16,32} and I was the first to seem to notice that the md{b,h,w} siblings were useless for scripting purposes. There are also various arm-specific utilities, some to work with physical addressese (vs, I guess, "whatever the current MMU context or non-context delivers"). These seem like the sorts of things that ought to be builtins, not library layers... > You might also take a look around find the files: "stm32_regs.tcl" - > and some sam7 versions. Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example) defines a global AT91C_ID ... which strongly presumes that there's only one at91 family chip, since those IDs vary between chips. What I had started to do with some DaVinci stuff is define a dictionary with various chip-specific symbols, then have the utlities use the relevant dictionary. Now, I *like* the idea of having a way to grow libraries of reusable Jim code to help work with chips, and symbolic names for registers (or at least controllers) seems essential to that. But I'm not sure that's quite the right way to start. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
