On Sunday 03 January 2010, morten opprud jakobsen wrote: > I you compile using the -g3 option, you can acces *raw* special > function registers (SFR's), when highlighting them in eclipse.
I'd just call those "registers", not SFRs, since they're just regular parts of the data address space: there's nothing "special" about memory-mapped peripherals. In fact it's the norm nowadays... In my experience, SFRs are special pains in the posterior since they live in yet another address space ... and need either compiler extensions to address (which makes most 8051 "C" compilers aggressively nonstandard) if pointers make sense with them, or else something on the lines of a set of inlined assembly language accessors. > This is ok, but a bit rough around the edges since : > > . Some registers are cleared on read > > . Formatting is default decimal > > . No bit-field decoding can be done, the raw value > must be decrypted into single or groups of bits. Yes, tools that support microcontroller developers tend to have GUIs for such stuff. Many Eclipse-based examples exist, I'm told. And non-Eclipse ones too; like Atmel's AVR Studio. > I have access to a lauterbach debugger as well, but it's quite expensive, a > not really well integrated w. eclipse. > > The lauterbach trace32 tools have a great peripheral / SFR browser, that > loads a <cpu_fam>.per file, which describes the cpu internals, bitfields, > which registers are cleared on read etc.. (don't actually know if the *.per > files are written using some standard programming linguo / formatting > standard?) Freddie's example (http://sourceforge.net/projects/embsysregview/) seems to have some XML based format. But it looked at first glance like not a very good one ... most of those Stellaris parts share the same register structure, but it doesn't have ways to express that! And I didn't see bitfield support there either. There was another sourceforge project like that, which I saw at some point. I think an XML format is a fine assumption. GDB includes an XML parser for chip definitions, and such stuff is easy to work with. For example, if OpenOCD had XML chip definitions, it could deliver them to GDB ... or use them internally to spit out the HTML that Øyvind wants to see. Or even just have ways to dump them to the Tcl command line. > I know that embedded artists and code red have released some LPC-expresso > tool, that claims to have a SFR browser on board, but this is tied up on > some licences. Those LPC-expresso things are pretty new. Summary: $US 30 for a combination JTAG/SWD adapter plus a Cortex-M3 or Cortex-M0 eval board, with some kind of size-limited CodeRed GDB/Eclipse package. One deduces a significant subsidy from NXP! As if they want to make sure it's easy for folk to start developing with their new Cortex-M chips ... It's DOS-only for now, though; no Linux support. It might be nice to get an OpenOCD driver for that adapter, but I suspect they won't be keen on exposing its protocol. Worth IMO someone evaluating the package for the OpenOCD project, to help identify current OpenOCD weaknesses. (Likewise with other Eclipse-based JTAG-aware toolsets. Atmel's AVR32 Studio, TI's Code Composer Studio, and the CodeSourcery product all come quickly to mind ... and I'm sure there are more.) If it doesn't currently have one, I'd say that Eclipse should have some standardized solution for peripheral register viewing. Maybe one of the existing products can be the basis for that. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
