This project page provides useful resources for the Embedded TransferJet CNL (Connection Layer) Project. The purpose of this project is to create a small, lightweight CNL code base that can be more easily and readily ported to a range of small embedded microcontrollers.
Toshiba provides a reference implementation and device drivers for their own TransferJet SDIO module. The baseline software provided by Toshiba has a number of architectural complexities that make it unsuitable for direct usage on a small embedded processor. The main issues are:
Reliance on operating system primitives for threading, synchronization and memory management making bare metal implementations difficult.
Core code is tightly coupled with Linux kernel module framework with some redundant layering of software and difficult to break module inter-dependencies.
Tight coupling with Linux SDIO driver framework, especially for interrupt processing, assuming that SDIO interrupts are processed from an OS task rather than ISR.
Although the CNL is just one part of the overall software stack (i.e., the PCL and PCL adapters form the other parts of the stack) it is the one mandatory component needed to be able to use TransferJet. It is therefore the CNL that is the focus of this project, although in future other parts of the stack could be considered to be added.
To help overcome some of these issues, a clear partitioning of software components is established from the outset in this project that ensures that code that is platform or chipset specific is kept separate from "core" code that is portable. This is illustrated in the following figure:
A more detailed summary of the software architecture and partitioning can be found at Embedded CNL Software Architecture (for registered users only).
The project is comprised of a number of different repositories hosted at http://support.icoteq.com:9000/groups/tjet-embedded as follows:
Embedded CNL Core
The core software comprises the CNL, a very small OS adaptation layer and stubs for the SDIO interface. The code is written to be OS, chipset and platform independent and can therefore be easily ported to an embedded processor.
The code is adapted from the Toshiba GitHub project with a number of important changes. Further to creating a clearer boundary between the CNL code modules, and their purpose, parts of the CNL have been modified or removed in order to reduce the number of OS (CMN) layer dependencies. As such, the CNL software depends on only a fixed memory pool concept for dynamic allocation of fixed sized data structures. Moreover, it is only necessary to provide a pointer to a small heap area for all memory management functionality i.e., no malloc() or free() is needed - this is all handled within the generic CMN library implementation provided.
The CNL also no longer relies on threading, instead the CNL task is replaced with a "device signaled" callback and CNL task iterator. The main application software state-machine need only call the CNL task iterator when it is signalled to do so via a callback.
The software is maintained at the public repository http://support.icoteq.com:9000/tjet-embedded/cnl-embedded. Access to this software is open to anybody and provided under a GPLv2 software license.
Icoteq has developed a test framework with reference test vectors which can be run on any Linux distribution to verify the Embedded CNL Core using the CNL API and a mocked SDIO driver. A number of 3rd party tools, all of which are open source tools, are used in order to verify the software:
CMock and the bits of Unity that it depends upon - more information at http://www.throwtheswitch.org
- We use CMock to mock the SDIO driver for testing the CNL without target hardware
GoogleTest v1.7.0 - more information at https://code.google.com/p/googletest
- Although this is a C++ test framework, it is actually broadly applicable for also testing C code using C++ test fixtures
GNU tools such as g++, gcc, configure and automake and make - more information at http://www.gnu.org
Embedded CNL Tools
Icoteq has developed a CNL trace parser in Python which can be used to aid debugging of the CNL core. The CNL trace parser can also be used to generate test vectors which may be subsequently fed back into the test framework for verification purposes.
A set of pre-generated test vectors, in human readable form, are part of this package which have been captured from our IMX6Q/Linux TransferJet reference platform.
The software is maintained at the private repository http://support.icoteq.com:9000/tjet-embedded/cnl-tools. Access to this software requires a software license.
Embedded CNL Sample Application
The Embedded CNL Sample Application (TJ_DEMO) provides a platform-independent sample application with a single entry point called TJET_Demo(). The demo application makes use of a library of CNL wrapper functions (CNLAPP) that simplifies the process of using the CNL core. The CNL wrapper also "hides" the specifics of how TransferJet IRQs, API completions and API events are all handled.
The software is maintained at the private repository http://support.icoteq.com:9000/tjet-embedded/cnl-application. Access to this software requires a software license.
Windows PC CNL Test Tool (
Refer to Embedded TransferJet CNL Home for more information about this test tool.
The software is maintained at the private repository http://support.icoteq.com:9000/tjet-embedded/windows-cnl-test-tool. Access to this software requires a software license.
The Embedded CNL Core software defines a number of stub API functions that are required to be implemented for a given chipset. This is predominantly the SDIO driver, however, this may in turn depend upon other chipset drivers such as DMA and RTC. Also if you need to build with debug enabled you will need a suitable debug output driver e.g., UART.
The chipset drivers are typically provided by the microprocessor vendor but, in many cases, the SDIO drivers are not optimized for I/O cards but rather designed for MMC style devices. Icoteq provides adaptations and extensions to the core vendor device drivers to ensure they are suitable for usage with the Toshiba TransferJet SDIO module. Examples of optimizations that are provided are:
- Fast register access for read/write functions via IO_RW_DIRECT and IO_RW_EXTENDED
- Block mode transfer variant using IO_RW_EXTENDED
- Incorporation of chipset DMA engine into IO_RW_EXTENDED block mode variant to reduce CPU overhead
- Card IRQ detection and propagation
Sample application builds
For each supported hardware platform it is necessary to create a top-level build which pulls-in all the build tools and code dependencies for the software to run on a given target platform. A sample application for the Embedded CNL core is also provided and demonstrates the main use-cases of the CNL API.
Access to a platform solution requires a software license for a given platform. Refer to Embedded Platform Solutions for a list of currently supported platforms with available solutions.
|Embedded CNL Core & Verification Suite||Public||GPLv2|
|Embedded CNL Tools||http://support.icoteq.com:9000/tjet-embedded/cnl-tools||Private||Proprietary|
|Embedded CNL Sample Application||http://support.icoteq.com:9000/tjet-embedded/cnl-application||Private||Proprietary|
|Windows PC CNL Test Tool||http://support.icoteq.com:9000/tjet-embedded/windows-cnl-test-tool||Private||Proprietary|
|Platform Solutions||Platform specific repository||Private||Proprietary|
Vendor Chipset Support
|Vendor||Chipset||SDIO Capability||SDIO Clock||Customized|
SDIO Driver Available
|SDIO DMA||SDIO IRQ||Platform Solution|
Windows PC +
USB dongle (Gen2)
50 MHz HS
|Yes||Yes||Yes||~180 Mbps||~180 Mbps as initiator/responder|
48 MHz HS
|Yes||Yes||No||~150 Mbps||~150 Mbps as initiator/responder|
|Yes||Yes||Yes||~370 Mbps||~240 Mbps as initiator|
~200 Mbps as responder
Please contact Icoteq via firstname.lastname@example.org for any questions you have concerning the feasibility of using other vendor chipsets.
Icoteq has existing solutions for the following platforms:
Please contact Icoteq via email@example.com for any questions you have concerning other hardware platforms.
Using an RTOS
The available platform solutions do not require or use an embedded RTOS. However, it is possible to incorporate the software into an application framework that uses an RTOS if needed. Please contact Icoteq via firstname.lastname@example.org for any questions you have concerning specific RTOS support.