Fix old XML docs to FPP and remove deprecated docs (#3062)

docs/documentation/user-manual/cmake/cmake-intro.md

@@ -29,9 +29,6 @@ advantage of the autocoding capabilities of fprime. To add new modules to the CM
 Each of these steps are described in detail below. Further usage documentation on the functions used to perform these
 steps can be found in [API](./cmake-api.md). This document will explain the usage of core F´ CMake functions.
 
-Further discussion regarding the transition from the former make system can be found here:
-[Migration.md](Migration.md)
-
 ## Step 1, Step 2, and Step 3: Define A CMakeList.txt File
 
 The CMakeList.txt file defines the steps needed to build **something** in CMake.  In fprime, we use this file to define the source, autocoder, and module dependencies for modules in fprime. A `register_` function is called to tie into the fprime autocoder environment. This keeps fprime modules simple, although all of CMake's power can be used when needed.

docs/documentation/user-manual/framework/implementation.md → docs/documentation/user-manual/framework/autocoded-functions.md

@@ -1,9 +1,9 @@
-# F´ Implementation Classes
+# F´ Autocoded Functions and Component Classes
 
 > [!NOTE]
 > for a hands-on walk-through of build topologies, please see: [Tutorials](../../tutorials/index.md)
 
-The code generator takes the XML definitions in the previous section and
+The FPP compiler takes the FPP definitions and
 generates C++ base classes. The developer writes classes that derive
 from those base classes and implements the project-specific logic. For
 input ports and commands, the base classes declare pure virtual methods
@@ -31,12 +31,19 @@ Advanced topics:
 - [Initialization Code](#initialization-code)
 
 
+> [!TIP]
+> For all the autocoded functions provided by FPP, your IDE's language support can be quite useful for auto-completing function names and looking up argument types.
+
+> [!TIP]
+> All those functions that are autocoded by FPP are located in the build cache, for example under `build-fprime-automatic-native/Components/MyComponent`
+
+
 ## Ports
 
 ### Input port calls
 
 The pure virtual function to implement a port call is derived from the
-name of the port declaration in the component XML. The function is
+name of the port declaration in the component FPP. The function is
 declared in the protected section of the class and has the following
 naming scheme:
 
@@ -46,38 +53,36 @@ naming scheme:
 where
 
 > \<port name\> = The name given to the port in the name= tag in the
-> port section of the XML.
+> port section of the FPP.
 >
-> portNum = If the XML writer has defined multiple ports, this allows
+> portNum = If the FPP defines a port array instead of a single port, this allows
 > the developer to know which port was invoked. The value is the port
-> instance indexed to zero. In the event the “max\_number” attribute is
-> not specified (i.e., a single input port), this value will be zero.
+> instance indexed to zero. In the event the FPP port is a single input
+> port (i.e. not a port array), this value will be zero.
 >
 > \<argument\_list\> = The list of arguments specified in the args
-> section of the port definition XML.
+> section of the port definition.
 
 ### Output port calls
 
 The base class function for outgoing port calls is derived from the name
-and type of the port declaration in the component XML. The function is
+and type of the port declaration in the component FPP. The function is
 declared in the protected section of the class and has the following
 naming scheme:
 
 > \<port name\>\_out(NATIVE\_INT\_TYPE portNum, \<argument list\>);
 
 where
 
-> \<port name\> = The name given to the port in the name= tag in the
-> port section of the XML.
+> \<port name\> = The name given to the port FPP
 >
-> portNum = If XML writer has defined multiple ports, this allows the
-> developer to specify which port to invoke. The value is the port
-> instance indexed to zero. In the event the “max\_number” attribute is
-> not specified (i.e., a single output port), this value should be set
-> to zero.
+> portNum = If the FPP defines a port array instead of a single port, this allows
+> the developer to know which port was invoked. The value is the port
+> instance indexed to zero. In the event the FPP port is a single input
+> port (i.e. not a port array), this value will be zero.
 >
 > \<argument\_list\> = The list of arguments specified in the args
-> section of the port definition XML.
+> section of the port definition.
 
 The call will invoke the port methods defined on whatever component the
 component in consideration is interconnected with. If those ports are defined as
@@ -99,20 +104,19 @@ available. The method has the following naming scheme:
 
 where
 
-> \<port name\> = The name given to the port in the name= tag in the
-> port section of the XML.
+> \<port name\> = The name given to the port in the FPP.
 >
 > \<direction\> = The direction of the port, Input or Output.
 
 The developer can use this to automatically scale the code to the number
-of ports specified in the XML. If the port output function is called
+of ports specified in the FPP. If the port output function is called
 with a portNum value greater than the number of ports minus one, the
 code will assert.
 
 ## Commands
 
 The pure virtual function to implement a command is derived from the
-mnemonic in the command declaration in the component XML. The function
+mnemonic in the command declaration in the component FPP. The function
 is declared in the protected section of the class and has the following
 naming scheme:
 
@@ -121,11 +125,9 @@ naming scheme:
 
 where
 
-> \<mnemonic\> = The mnemonic string of the command given in the
-> mnemonic= tag in the command section of the XML.
+> \<mnemonic\> = The mnemonic string of the command given in the component FPP definition.
 >
-> \<argument\_list\> = The list of arguments specified in the args
-> section of the command definition XML.
+> \<argument\_list\> = The list of arguments specified the FPP command definition.
 
 When the command has been completed, a command response method must be
 called in the base class to inform the dispatcher of the command that it
@@ -136,7 +138,7 @@ has completed. That function call is as follows:
 
 The opcode and cmdSeq values passed by the function should be passed to
 the command response function as well as a status indicating the success
-or failure of a command. The opcode is specified in the XML, and cmdSeq
+or failure of a command. The opcode is specified in the FPP, and cmdSeq
 will be set by the command dispatcher to track where the command is in a
 sequence of commands. If more information about a failure is needed, an
 event should be specified and called with the additional information
@@ -151,19 +153,17 @@ A telemetry channel is intended to be used for periodically measured
 data. It is a snapshot in time, and all values may not be permanently
 recorded and sent to the command and data handling software. The code
 generator generates a base class function for each telemetry channel
-defined in the XML. The developer calls this to write a new value of the
+defined in the FPP. The developer calls this to write a new value of the
 telemetry being stored. The function is declared in the protected
 section of the class and has the following naming scheme:
 
 > tlmWrite\_\<channel name\>(\<type\>& arg);
 
 where
 
-> \<channel name\> = The name given to the port in the name= tag in the
-> channel section of the XML.
+> \<channel name\> = The name given to the channel in the component FPP
 >
-> \<type\> = The non-namespace qualified type of the channel as
-> specified in the data\_type= tag in the XML.
+> \<type\> = The type of the channel.
 
 The argument is always passed by reference to avoid copying. The call
 internally adds a timestamp to the value. There is a method getTime() in
@@ -174,19 +174,18 @@ purposes.
 
 Events are intermittent and are all recorded to reconstruct a series of
 actions or events after the fact. The code generator generates a base
-class function for each event defined in the XML. The developer calls
+class function for each event defined in the FPP. The developer calls
 whenever the event to be recorded happens. The function is declared in
 the protected section of the class and has the following naming scheme:
 
 > log\_\<severity\>\_\<event name\>(\<event arguments\>);
 
 where
 
-> \<severity\> = The value of the severity attribute in the XML for the
-> event.
+> \<severity\> = The value of the severity attribute in the FPP for the event.
 >
 > \<event name\> = The name of the event given in the name attribute in
-> the XML.
+> the FPP.
 >
 > \<event arguments\> = The argument list of the event.
 
@@ -201,7 +200,7 @@ influence the behavior of the software without requiring software
 updates. During initialization, the parameters are retrieved and stored
 in the component base class for later use be the developer’s derived
 class. If for some reason the parameters cannot be retrieved, the
-default value specified in the XML is returned. The function is declared
+default value specified in the FPP is returned. The function is declared
 in the protected section of the class and has the following naming
 scheme:
 
@@ -211,10 +210,10 @@ scheme:
 where
 
 > \<parameter type\> = The type of the parameter specified by the
-> data\_type tag in the XML.
+> data\_type tag in the FPP.
 >
 > \<parameter name\> = The name of the parameter given in the name
-> attribute in the XML.
+> attribute in the FPP.
 
 The parameter value is returned by reference to avoid copying the data.
 The valid value should be checked after the call to see what the status
@@ -241,7 +240,7 @@ value is updated. It is called each time a parameter is updated.
 
 ## Internal Interfaces
 
-When internal interfaces are specified in the component XML, a function
+When internal interfaces are specified in the component FPP, a function
 is generated that can be called by implementation code to dispatch a
 message for a message loop. The function has the following name:
 

docs/documentation/user-manual/framework/building-topology.md

@@ -62,7 +62,7 @@ Get input port pointer:
 where
 
 > \<PortType\> = The full port type specified in the data\_type
-> attribute in the definition of the port in the component XML.
+> attribute in the definition of the port in the component FPP.
 >
 > \<port name\> = The name of the port in the name attribute of the port
 > definition.
@@ -81,7 +81,7 @@ section is given to an output port of the same type by calling:
 where
 
 > \<PortType\> = The full port type specified in the data\_type
-> attribute in the definition of the port in the component XML.
+> attribute in the definition of the port in the component FPP.
 >
 > \<port name\> = The name of the port in the name attribute of the port
 > definition.

docs/documentation/user-manual/framework/configuring-fprime.md

@@ -338,7 +338,7 @@ are less restrictive in size.
 
 Event functions that are called are turned into two output port calls. One is a binary port that is used to store the
 event to be transported to ground software or a testing interface external to the software. The component also takes
-the format string specified in the XML and populates it with the event arguments, and calls an output port with a
+the format string specified in the FPP and populates it with the event arguments, and calls an output port with a
 readable text version of the event. This is meant to be used for a console interface so the user can see, in text form,
 the same events being stored for transmission. A component with the text logging input port can be used to display the
 text. A very simple implementation of this can be seen in `Svc/PassiveConsoleTextLogger`. In a resource-constrained

docs/documentation/user-manual/overview/gds-introduction.md

@@ -93,7 +93,7 @@ deployment directory.  The user can simply specify the `--dictionary` for basic
 be placed in the user's home directory when the `-d`/`--deploy` flag isn't set.
 
 ```bash
-$ fprime-gds -n --dictionary path/to/dictionary/xml
+$ fprime-gds -n --dictionary path/to/dictionary/
 ```
 
 **Note:** `-n` is described below.