Technically none of that code is "necessary". However, if you want to utilize the normal usage and update path for the device it is. The reason it's exposed to the user is sometimes you want to not use certain parts of it.
I'll walk you through what each part does:
InitializeStack();
This starts up the network stack on the device. Without it, you have no tcp/ip stack, meaning no network communications (kind of important to have in a networked controller
)
if (EthernetIP == 0) GetDHCPAddress();
This checks to see if the device has an assigned IP address. If it doesn't (EthernetIP == 0), then it makes a call to GetDHCPAddress. This function launches the DHCP subsystem for the selected network interface (which in this case is the default of '0', or the first one).
OSChangePrio(MAIN_PRIO);
This one's a little less obvious. When the device boots, it launches into main(), which sets up the OS and then starts a task running UserMain. This occurs at a very low task priority number below all other tasks in the system (as in it won't be preempted). If it were to stay at that priority, anything you put in that task would be higher priority than even the ethernet task; let's just say that would be a bad thing. To correct this issue, we need to move the UserMain task much lower in priority, hence the call to OSChangePrio.
EnableAutoUpdate();
This is an example of a function that does what it says on the tin: it enables the use of AutoUpdate to update the application image on the device. Without this call, you'd have to boot into the monitor and use the FLA command to update the application over serial, a much slower and more laborious process.
#ifndef _DEBUG
EnableSmartTraps();
#endif
The call to EnableSartTraps is so that when, not if, you do something that causes the processor to trap (remember this is embedded land), it will give you a nice dump of what tasks were running, what they were doing, and what the tops of the program stacks look like. This is
very useful when trying to figure out what on Earth is breaking in your otherwise beautiful program.
#ifdef _DEBUG
InitializeNetworkGDB_and_Wait();
#endif
This sets up the network debugger on the device. It will then halt the process and wait until the network debugger connects to the device before continuing.
So, in closing: no, none of this is
necessary to use the ADC or DAC components on the MOD5441X, or on any of the boards. They are however necessary for remaining in a good working environment for development.