doc/manual/main.txt

   1 /** @mainpage OpenOCD Reference Manual
   2
   3 Welcome to the OpenOCD Reference Manual -- the developer's resource for
   4 learning about the internal architecture of the OpenOCD project. @par
   5
   6 In addition, this document contains the tactical and strategic plans
   7 and processes that have been developed by and for the OpenOCD community.
   8
   9 Developers that want to contribute to OpenOCD should read the following
  10 sections before starting work:
  11
  12 - The List of @subpage thelist enumerates opportunities for improving or
  13 extending the OpenOCD platform.  If your ideas are on The List, you might
  14 check the mailing list archives to find the status of your feature (or bug).
  15 - The @subpage styleguide provides rules that developers should
  16   follow when writing new code for OpenOCD.
  17 - The @subpage patchguide provides policies that developers should
  18   follow when submitting patches to the project.
  19 - The @subpage bugs page contains the content of the BUGS file, which
  20   provides instructions for submitting bug reports to the maintainers.
  21 - The @subpage releases page describes the project's release process.
  22
  23 @ref primer provide introductory materials for new developers on various
  24 specific topics.
  25
  26 Finally, the @ref oocd pages explain how the code has been organized
  27 into layers of APIs, providing an overview of how they fit together.
  28 These pages attempt to give developers a high-level perspective of the
  29 various code modules provided by OpenOCD.
  30
  31  */
  32
  33 /** @page primer OpenOCD Technical Primers
  34
  35 This pages lists Technical Primers available for OpenOCD Developers.
  36 They seek to provide information to pull novices up the learning curves
  37 associated with the fundamental technologies used by OpenOCD.
  38
  39 - @subpage primerpatches
  40 - @subpage primerdocs
  41 - @subpage primerautotools
  42 - @subpage primertcl
  43 - @subpage primerjtag
  44
  45 These documents should bridge any "ancillary" gaps in contributor
  46 knowledge, without having to learn the complete languages or technology.
  47 They should provide enough information for experienced developers to
  48 learn how to make "correct" changes when creating patches.
  49
  50 In all cases, these Primers should use idiomatic conventions that the
  51 community has agreed are the "right way of doing things".  In this
  52 respect, these documents typically assume some familiarity with the
  53 information contained in one or more @ref styleguide, or they will
  54 directly refer to specific style guides as supplemental reading.
  55
  56 Contributions or suggestions for new Technical Primers are welcome.
  57
  58  */
  59
  60 /** @page oocd OpenOCD Architecture
  61
  62 The OpenOCD library consists of several APIs that build together to
  63 provide the support functionality.  The following list shows how these
  64 modules are stacked in the current implementation (from bottom to top):
  65
  66 - @subpage helperdocs
  67   - @ref helperporting
  68   - @ref helperjim
  69   - @ref helpercommand
  70   - @ref helperlogging
  71 - @subpage jtagdocs
  72   - @ref jtagcore
  73   - @ref jtagtcl
  74   - @ref jtagcmd
  75   - @ref jtagiface
  76   - @ref jtagdriver
  77 - @subpage targetdocs
  78   - @ref targetarm
  79   - @ref targetnotarm
  80   - @ref targetregister
  81   - @ref targetimage
  82   - @ref targettrace
  83 - @subpage flashdocs
  84   - @ref flashcfi
  85   - @ref flashnand
  86   - @ref flashtarget
  87 - @subpage serverdocs
  88   - @ref servergdb
  89   - @ref servertelnet
  90   - @ref serverhttp
  91 - @subpage appdocs
  92
  93 Obviously, there are some nuances to the stack that are not shown by
  94 this linear list of layers.
  95
  96 The List of @ref thelist enumerates opportunities for improving or
  97 extending the OpenOCD platform.
  98
  99  */