research application on sending data to headend

Dependencies:   DataStore JobScheduler NetworkServices W5500Interface nanopb protocol

See "main.cpp" documentation on "API Documentation" tab for details about application.

Revision:
23:1976f83da84e
Parent:
22:3af582d8e227
Child:
24:62ca1f410862
--- a/source/main.h	Fri Aug 04 21:08:49 2017 +0000
+++ b/source/main.h	Fri Aug 04 21:10:31 2017 +0000
@@ -29,19 +29,17 @@
 
 In general failure to create a service object results in application termination as it results in cascading failure effect.
 
-@subsection Application Lifetime
+@subsection do_application_lifetime Application Lifetime
 
 Once service objects are created, job scheduler is started on the main application thread.  Main thread is then blocked by waiting for scheduler to quit.  Unless there is a job that explicitly requests scheduler termination, the main thread will never unblock. 
 
 If scheduler stops, then main thread proceeds to the final stage of the application.  At this stage it is guaranteed that no job will be started, because scheduler has been stopped.  Thus, environment is fully under main function control and drastic changes can be applied such as firmware upgrades.
 
-@subsection Running of Other Parallel Threads
+@subsection do_parallel_to_jobs Running of Other Parallel Threads
 
 The job is just another C function and thus there is nothing to stop function from creating its own thread after execution ends.  This is not denied, but a high level impact needs to be considered.
 
 For example, a receiving thread can be started for the life time of the socket.
 
 One consequence to consider is that creation of long running threads that go beyond job lifetime will make it more difficult to manage power consumption.  The recommended solution is to schedule another job through application scheduler from the job function itself. This way a single task at a time concept is not impacted and there is no concurrency complication.
-
-
 */ 
\ No newline at end of file