Blogs | Technical Articles | Videos

Storage devices have become an indispensable component of many embedded applications. To select the optimal medium for memory storage, it is essential to consider the specific requirements of your use case. The most prevalent storage mediums for embedded applications are NOR Flash Memory, NAND Flash Memory, SD/MMC Cards, Mass Storage Devices, and RAM.

NOR and NAND flash memory devices are both non-volatile storage mediums, which means they can retain data even without power. MultiMediaCard (MMC) and Secure Digital (SD) cards are flash memory cards that adhere to these standards, and they are also non-volatile memory devices. USB Mass Storage Device Class (USB MSC) is the most commonly used Mass storage device with Cs/FS. USB Drives are also non-volatile memory devices and are recognized by the host device as an external hard drive when connected. RAM storage mediums, on the other hand, are volatile, which means they can't maintain their stored data in the event of a power outage or failure.

Cesium RTOS, a continuation of the popular Micrium µC/ kernels, and FreeRTOS are two popular real-time kernels in the embedded software space. While they are functionally similar and have comparable execution metrics, there are advantages and disadvantages to each of the two product’s APIs. Let’s review some of these differences and make a case for why choosing Cesium RTOS may benefit your project’s overall long-term development and support.

Both µC/TCP-IP and Cs/NET, in accordance with RFC recommendations, are capable of sending probes, or keep-alive segments, over connections that have been idle for an extended period of time.

How long should a quiet TCP connection – meaning one over which no communication is taking place – remain open? The answer to this question, like many answers in the realm of TCP, depends on the network stack(s) being considered. In µC/TCP-IP and Cs/NET, the maximum amount of idle time is a configurable property, and application developers can specify a unique limit for each of their connections.

If the idle-time threshold for a particular connection is reached, µC/TCP-IP and Cs/NET are capable of probing the remote side of the connection by sending segments known as keep-alives. The idea of transmitting such segments is raised by RFC 1122, a "request for comment" that, along with many other RFCs, comprises the documentation for the Internet. 1122 states that developers of network stacks "MAY include 'keep-alives' in their TCP implementations." For stacks that provide this feature, the document specifies that application code must be allowed to turn keep-alives "on or off for each connection, and they MUST default to off."

Applications written around µC/OS-II, µC/OS-III, Cs/OS2, and Cs/OS3 can often use non-kernel-aware ISRs for rapid responses to certain events.

In the previous post in this series, I showed the format of what could be called a "typical" ISR for Micriµm's µC/OS-II, µC/OS-III, and Cesium Cs/OS2, Cs/OS3 kernels. Here, I'll review the format for an alternate type of ISR – one sometimes referred to as "non-kernel-aware." This format involves less overhead than the approach from the first post, but it is not applicable to all ISRs.

The non-kernel-aware format is intended for ISRs that don't require the use of kernel services – routines that, for example, don't place a message in a queue or signal a task using a semaphore. The assumption behind the non-kernel-aware format is that such routines will never result in preemption. In other words, because they don't involve any of the kernel's services, they will never make another task ready to run. ISRs of this type can forgo invoking the kernel routines that would otherwise be needed to facilitate a post-ISR switch to a new task.

For basic embedded network designs, a single Ethernet or Wi-Fi interface will suffice. As projects and consumer expectations grow, more complex connectivity requirements, such as multiple interfaces, become more prevalent. With our network stack, it is possible to meet this project requirement.

If you are familiar with µC/TCP-IP or Cs/NET's API function calls you’ve seen our example start-up code for creating a single interface over Ethernet. When dealing with multiple interfaces it is as simple as calling the same creation and startup process for each desired interface. The following pseudo-code will elaborate on this:

The flowchart shown below details how to setup a multiple-interface initialization for your application. Once the application initializes the core Network stack, a new network interface will be added. With Wi-Fi connections, subsequently scanning for wireless access points to join may be executed. For hidden networks (whose name is known to the application code already) the scan operation could be skipped. Once that is completed, the application must configure the interface for the desired IP host address, subnet mask, and default gateway.