Blogs | Technical Articles | Videos

µC/FS includes several configuration files that allow you to customize for your application design.

This article will focus on the top-level configuration file of µC/FS. The others are specifically geared towards the inner layers of the file system and are not needed for all projects, such as SD Card, NAND device, etc. We will discuss the configuration file fs_cfg.h. The file systems configurable behavior is controlled by how the developer defines the following configuration values to reflect the application's needs.

It helps to ask yourself a few questions about your application:

  • What type of file system do I need? Do I need an embedded-sized File System or a full-sized FS line Linux, Windows, MAC, etc. Do I need a FAT File System? Transactional File System?
  • How much data am I looking to store and transfer around? If your embedded device is looking to handle more data than a FAT 32 file system can store you may have some difficulties.
  • Do I need to restrict access to the file system? Read-only or Read-Write functionality.
  • What device do I intend to run my file system on? SD Card, NAND or NOR Chip, RAMDisk implementation?

In Part I, we looked at setting up a UDP server. Now we will cover setting up a socket for a UDP server. 

The process for setting up a TCP server, although considerably more complex than a typical application using UDP as the underlying protocol, can be broken down into five steps.

In part one of this series, we examined the function calls necessary to set up a socket for a UDP server. In part I, we looked at the UDP half of the transport-layer protocols. Now we will consider the other protocol, TCP. The typical sequence followed in establishing TCP communication in a server application begins similarly to UDP. Where it deviates will be the focus of part II as we cover the new API’s.

Perhaps the most notable difference between a server based on UDP and one that relies on TCP is the latter typically requires a minimum of two sockets, whereas the former, requires the creation of one. At least two sockets for TCP is a result of this protocol's robust feature set; while UDP is often described as a "connection-less" protocol, TCP is best described as "connection-oriented". The creation of a data connection (essentially, state information for a sender and receiver) is maintained by two communicating devices. Thus, before a TCP client can communicate with a server, it must establish a connection. In application code, this process typically unfolds as illustrated below.

When designing a µC/TCP-IP based application, setting up a socket for a UDP server can be accomplished with a straightforward sequence of function calls.

When utilizing Micrium's network stack µC/TCP-IP to establish connections, you'll likely end up writing sockets code. Sockets, in networking jargon, represent a medium for sending and receiving data. Many basic Micrium examples are devoid of socket call implementation — this is due to stacks like µC/TCP-IP that carrying out a variety of basic operations, including the creation of responses to pings (or echo requests) automatically. As a developer, your own designs will typically require more than the basics. After establishing that your project has the essentials needed for network development, pinging your board for instance, sockets will be your vehicle for transmitting and receiving data.

When writing your application code around µC/TCP-IP, there’s a basic sequence to follow when setting up and initializing a socket. The variation between socket setup is dependent on which transport-layer protocol your socket is utilizing. There are two options provided by the TCP/IP protocol suite that constitute the foundation for transport-layer communication—UDP and TCP—each offering their own unique set of services. This article will focus on the initialization of UDP sockets, specifically, utilizing UDP sockets to implement the server side of a client-server application. In Part II, we'll discuss the analogous code for a TCP server.


This is the second entry in a series on Dynamic Tick Mode for µC/OS-III V3.07 and above. If you have not done so, please read the first part “Dynamic Tick on µC/OS-III - Part 1: Getting Started”. This document assumes that the reader is familiar with the concepts described in Part 1.