Preparing for Integration

Jump to: navigation, search
<< Integrating Treck
Compile Time Macros >>

To help in making this decision, you will need to ask yourself a few questions.

Am I using a Real-Time Operating System (RTOS)?
Is my processor Big or Little Endian?

I do not have an RTOS/Kernel to Interface to

If you do not have an RTOS/Kernel to which to interface, you will still need a minimum RTOS interface (which we provide). If you decide not to use an RTOS, then remember that most of the calls into the Treck Protocol Stack will be done from a main line loop. The biggest disadvantage in not using an RTOS is that you cannot make blocking calls (i.e. make recv () wait for data), otherwise you will stop all processing in your system. Another disadvantage is that you cannot prioritize events. If you are thinking about this, but are still undecided, we suggest that you look at using uC/OS as your RTOS. This is included with the base Treck protocols. If you are dead set against using an RTOS, then we will help you understand the limitations in the Creating a Kernel Interface section of this chapter.

I have a RTOS/Kernel to Interface to, but it does not allow any blocking/pending calls

An example of this would be an event scheduler with all the calls made from a main loop. This falls into the "I do not have an RTOS/Kernel to interface to" category.

I have a RTOS/Kernel to Interface to

You will need to decide if your RTOS is preemptive or non-preemptive. If you do not know, you can always assume preemptive (which is the safest). Preemptive RTOS/Kernels need to have locking of shared resources.

Note Note: A Preemptive operating system is one where a timer tick or other event causes a context switch to a new task. Tasks may have different priorities. Higher priority tasks may interrupt lower priority tasks. A non-preemptive operating system is one where all tasks have the same priority, run in a round robin fashion, and explicitly give up the CPU through an RTOS call. This is usually called a "Round Robin Scheduler"

Next, you will need to decide how you are going to use Treck Real-Time TCP/IP with your RTOS.

Do you want to have Treck run as its own task or in the context of other tasks as a shared library?

This choice depends on how you want your system to run. Most embedded systems choose to use the protocol stack as a shared library because it gives you the most flexibility on how you want to prioritize the different processes in using a protocol stack. If you decide to use Treck protocols as a single task, then there is also the performance hit of having a thin layer between the application and the protocol stack. Most people, who want to have a separate task, decide to do it to maintain modularity of the protocol stack. In doing so, they allow the protocol stack to be a "plug-in" to an existing application.

Application Task (1)
FTP Client
Application Task (2)
Web Server
Application Task (3)
Turbo Treck/RTOS Shared Library
Device Driver
Fig. 4-1: Example of Using Treck Protocols as a Shared Library

<< Integrating Treck
Compile Time Macros >>