µTasker Application task

The application task is at the heart of the µTasker demo project and is used as a central task to start up the various demo resources in an orderly manner.
It is scheduled for the first time after a delay of typically 100ms (see TaskConfig.h for the actual configuration) so that the ARP and Ethernet tasks have completed their initialization (since Ethernet support is generally used in the µTasker project) and can then configure and start further modules in the project.

In application.c the configuration of the default parameters (like the network IP setting and other user parameters) are defined (see network_default[] and cParameters[]) and user configured value are retrieved (if used) from the µParameterSystem. Ports are configured, which may be later used as outputs during tests or are controllable by command menu or web browser. Services such as FTP, Telnet, Web Server, DHCP server, UART interface or Real Time Clock (RTC), etc. are all configured (some conditionally on user parameters) so that they are synchronously started.

The application task also manages some local timer events or reads UART inputs, depending on the exact project configuration. UART inputs are generally passed to the command line interpreter (see debug.c). Furthermore, the application.c file is used to perform a variety of quick tests of various peripherals, protocols and modes of operation. These tests can be configured by activating one or more of the various local defines contained at the start of the file. The following quick test defines are available:

#define TEST_MSG_MODE // test UART in message mode
This causes the UART interface to be configured for message mode, rather than the standard character mode. In the message mode the task is woken only when the input is terminated by the defined termination character (a return in this case). The application task then reads a complete message from the input buffer rather than handling individual characters.

#define TEST_MSG_CNT_MODE // test UART in message counter mode
This is a supplementary option to the TEST_MSG_MODE. In this case, the length of the individual message is stored in the serial interface's input buffer and is first collected from the input to determine the exact length of each individual waiting message.

#define TEST_DISTRIBUTED_TX // test some uNetwork messages
This causes several test messages to be sent in a distributed network (requiring SUPPORT_DISTRIBUTED_NODES to be active in the project). The application task receives events in case of frame or synchronization losses, which are counted in local variables ulLost_uNetFrames and ulLost_uNetSync.

#define TEST_GLOBAL_TIMERS // test global timer operation
When global timers are defined in the project (GLOBAL_TIMER_TASK) this test will start several timers with different timeouts. The application task will receive the corresponding timer events and handle them accordingly, to display a pattern on test outputs. This test is described in detail in the document http://www.utasker.com/docs/uTasker/uTaskerTimers.PDF

#define DEMO_UDP // add UDP echo demo
This simple UDP demo installs a UDP listener on port MY_UDP_PORT (default 9999) which will echo back received UDP frames. The callback fnUDPListner() shows several methods of echoing the data, which can be configured in the code, to echo back the data directly from the input LAN buffer (fastest) to copying it first via an intermediate buffer, whose size is limited by UDP_BUFFER_SIZE. The listener also optionally rejects any frames which are not sent from a defined UDP port or a defined IP address.

#define TEST_IIC // test IIC EEPROM
This configures the I²C interface and tests reading and writing an EEPROM connected on the I²C bus.

#define TEST_IIC_INTENSIVE // intensive transmitter test
This intensive I²C test sets the application task to operate in polling mode and sends data as fast as possible to an I²C device. This is used to test the transmission flow control in order to avoid sending more data than the interface can handle.

#define TEST_DS1307 // test DS1307 RTC via IIC bus
The DS1307 is a common I²C connected Real Time Clock (RTC). This checks whether the device is configured, initialises it if necessary, and then reads the present time and data.

The I²C tests are described in detail in the document http://www.utasker.com/docs/uTasker/uTaskerIIC.PDF

#define TEST_TFTP // TFTP test
The TFTP (Trivial File Transfer Protocol) test operates together with DHCP. When the device starts and the DHCP resolve is successful, the application task receives the event DHCP_SUCCESSFUL. On availability of the IP configuration settings the TFTP transaction is started. In fnTransferTFTP() there are three choices of test:

fnStartTFTP_client(tftp_listener, ucTFTP_server_ip, TFTP_GET, "test.txt", '0');
The FTFP client will attempt to GET the file "test.txt" from the remote server at the IP address ucTFTP_server_ip and store it locally in the file '0'.
fnStartTFTP_client(tftp_listener, ucTFTP_server_ip, TFTP_GET_COMPARE, "test.txt", '0');
The FTFP client will attempt to GET the file "test.txt" from the remote server at the IP address ucTFTP_server_ip and compare its content with the local file '0'.
fnStartTFTP_client(tftp_listener, ucTFTP_server_ip, TFTP_PUT, "test1.txt", '0');
The FTFP client will attempt to PUT the local file '0' to the remote server at the IP address ucTFTP_server_ip and store it as "test.txt".

The TFTP lister, tftp_listener(), is used to repeat transactions on TFTP_ARP_RESOLVED event and abort on error conditions. It is also notified of the transfer results by events TFTP_FILE_EQUALITY, TFTP_FILE_NOT_EQUAL, TFTP_TRANSFER_WRITE_COMPLETE or TFTP_TRANSFER_READ_COMPLETE.

#define IRQ_TEST // test IRQ port interrupts
The IRQ test activates one or more port interrupts. The exact type of interrupts depends on the target processor and is generally a rising, falling or both edges on the defined ports. The initialisation routine fnInitIRQ() performs the configuration and enters the corresponding interrupt hanlding routines (such as test_irq_1()). The test interrupt handlers are called from the HW interrupt routine with disabled interrupts but don't need to perform any clearing of the interrupts. The example uses the routine fnInterruptMessage(OWN_TASK, IRQ1_EVENT); to send an event to the local task, which then displays a message on the debug output.

#define RTC_TEST // test RTC function
The RTC test is supported only by processors with internal RTCs. The initialisation routine fnTestRTC() sets a time and date to the RTC using the hardware routine fnConfigureRTC() and then configures periodic interrupts as well as an alarm time. Each time the programmed events occur the defined interrupt handlers are called; they are called from the corresponding HW interrupt routines with disabled interrupts but do not need to perform any clearing of the interrupts. The example routines change LED states so that the timeouts can be seen and reprogram further delays.

#define TEST_SPI_FLASH // simple test of SPI FLASH devices The FLASH test can be enabled to perform a simple test of connected SPI FLASH devices, whereby the exact chip (when multiple are present) can be defined in fnTestSPIFLASH(). The detected devices are displayed on the debug output, as are the results from testing the first page of SPI FLASH memory with a pattern followed by a page delete operation.

Note that this test should be removed for normal work with SPI FLASH since it will otherwise corrupt the first page.

#define TEST_ADC // test ADC operation
The ADC test configures the internal ADC of the device with fnConfigureADC(). Most details are target device dependent due to the varying capabilities of ADC peripherals, but ADC inputs are configured and sampling, or scanning started.
In the case of the Coldfire the test configures interrupt on threshold levels. The interrupt routines are called when the voltage pass these pre-defined values and cause results to be displayed on the debug output. Once the level trigger has been detected a zero crossing trigger is automatically configured.

In the case of the SAM7x various test configurations are available as defined by the following defines:

#define _SAM7X_ADC_TEST1 // software controlled ADC triggering with an interrupt on each channel
#define _SAM7X_ADC_TEST2 // software controlled ADC triggering with a single interrupt on last channel completion
#define _SAM7X_ADC_TEST3 // ADTRG input triggered conversion with a single interrupt on last channel completion
#define _SAM7X_ADC_TEST4 // TIOA2 output triggered conversion with a single interrupt on last channel completion
#define _SAM7X_ADC_TEST6 // Test zero crossing, high and low triggers

In the case of the Luminary-Micro ADC, the ADC mode of operation can be defined to be software-triggered, triggered by a defined edge on port B, bit 4 or to be triggered by a timer. Single-ended and differential inputs are configured. The number of sequencer samples to be collected is defined by ADC_SEQUENCES, where a local result buffer of the required length is also used (usADC_samples[]). When the ADC sequencer has completed, the interrupt adc_samples_ready() sends an event to the application task which displays the sample values and restarts the test after a certain delay.

#define LCD_READ_TEST // test read of LCD content
This define is used in conjunction with the character LCD support (SUPPORT_LCD in config.h). The content of the first character in the LCD (address 0x80) is read after each new text has been written to the LCD in order to test the read process.

#define TEST_PIT // test a user defined periodic interrupt
Devices which contain a PIT (Programmable Interrupt Timer) can be tested. The function fnConfigurePIT() is called to configure the defined timer with certain parameters and delay values. Either single shot or periodic mode can be tested by setting the corresponding define:

#define TEST_PIT_SINGLE
Different delays are programmed and an output toggled on each timeout.
#define TEST_PIT_PERIODIC
A periodic interrupt of 50us period is configured and an output toggled by the interrupt routine.

#define TEST_DMA_TIMER // test a user defined periodic interrupt
This test is specifically for the DMA timers as found in the Coldfire devices. Using fnConfigure_DMA_Timer() it configures a timer interrupt with a user defined delay and toggles an output when it fires. Different timeout values are programmed on after each interval timeout and a second DMA timer then used to generate a frequency on its timer output pin.

#define TEST_GPT // test general purpose timer operation
This test allows the capture function of general purpose timers to be tested.
The number of capture values is programmed by
#define GPT_CAPTURES 5 // when testing captures, collect this many values
Using fnConfigure_GPT() a user definable timer channel is configured to capture a certain number of events. When all events have been captured the interrupt gptimer_int() sends an event CAPTURE_COMPLETE_EVENT to the application task which then displays a list of the capture time values. Note that a capture count value of zero transforms the capture operation into a general purpose edge triggered interrupt.

#define TEST_TIMER // test a user defined timer interrupt
This test allows single-shot and periodic interrupts from a standard timer to be tested. fnConfigure_Timer() is used to configure the timer operation. The following test modes are possible:

#define TEST_SINGLE_SHOT_TIMER // test single-shot mode

timer_int()

#define TEST_PERIODIC_TIMER // test periodic interrupt mode

timer_int()

#define TEST_ADC_TIMER // test periodic ADC trigger mode (Luminary)

Last document update: 4.4.2009