tsctl was created as a way to ease software development, allow programs developed for one board to be easily re-used on other boards, and provide a way to control boards from any language and operating system that supports TCP/IP.

tsctl has a consistent client API accessible from shell script, Python, Java, C, and the tsctl protocol.

tsctl is object oriented, and currently defines classes for AIO, Bus, CAN, DIORaw, DIO, EDIO, Pin, Time (timekeeping), TWI, and SPI hardware as well as a System class.

tsctl runs as a single (user-space) multi-threaded server instance on each board. Each platform has a tsctl binary compiled specifically for that platform, and configuration files are kept to a minimum. tsctl will run under fastboot or full Debian boot and has a minimum of library dependencies (currently libc, and pthreads, which is statically linked)

tsctl implements the canctl, dioctl, and spictl protocols on top of these objects, replaces those binaries, and supports their command-line parameters when invoked as them (through a symlink to tsctl).

Support is present for several ARM and TS-SOCKET boards with future board support planned for newly developed boards and older boards by customer demand.

The tsctl server is a self-contained binary compiled for a specific Technologic Systems board that runs on that board to provide access to all the tsctl supported features on the board to any client implementing the tsctl protocol to talk to the server.

The tsctl API is a standardized method of writing object-oriented classes in C which encapsulate various hardware features of our boards, such as CAN, DIO, timekeeping, TWI, and SPI in a way that is optimized for the hardware on a specific board while providing a consistent set of function prototypes for each class regardless of the implementation.

The tsctl protocol defines the structure of a byte-stream sent between a client and the tsctl server over TCP/IP which requests functionality from the server and returns status and data back from the server. The tsctl protocol corresponds very closely to the tsctl C API, representing a consistent translation between C function calls and network data structures.

The tsctl client is contained within the same binary that houses the tsctl server. Invoking the binary as a client provides direct command line access to the entire tsctl API, with the only limitations being that only a single object call is permitted per invocation. This invocation implicitly locks and unlocks the resource before and after use (if applicable). Since the server automatically releases and locks a connection holds when it closes, the tsctl command line client can thus not be used to perform more complex operations dealing with locking.

Technologic System develops and manufactures single-board computers. Newly designed boards have features and configuration intended to meet newly emerging needs in the marketplace, as well as to respond to customer feedback concerning what is useful to them. However, over time many boards developed by Technologic Systems share in common certain features such as Ethernet, serial ports, CAN, and so forth. Some of these features are well supported by the Linux operating system which our boards ship with. However some are not, and in other cases the interface to accessing a particular feature has changed over time, sometimes dramatically.

Technologic System products are targeted towards the embedded market. The software development model in this space is often quite different from the rest of the software industry. Embedded devices typically go through a development cycle which terminates in a "frozen" state for all software on the board. Unlike other parts of the industry, upgrades or change of any kind in the state of the software as shipped is undesirable as it represents a high degrees of risk, risk that assumptions other software relies on will no longer be valid resulting in "breakage" of previously working software. As such, it is important that Technologic System provide software for the features on its board which reaches a frozen state quickly, allowing developers using our products to confidently freeze their own software in a timely manner.

At the same time, there are other important, but sometimes conflicting goals. These are:

1. To bring new products to market quickly.

2. To provide software for all the features on the board.

3. To have a uniform interface to each feature allowing code developed for one board to work on another.

The initial attempt to meet these goals was the "TS-SOUL " design. Like TS-SOUL, tsctl does the following:

The tsctl project remedies issues present in TS-SOUL:

In addition tsctl provides the following additional functionality:

The object classes currently defined by tsctl are:

The network protocols supported by tsctl are:

The recommended way of utilizing tsctl is via the network protocol. The tsctl binary supports both client and server operations, thus providing for direct command line access to all objects on any board running tsctl as a server. However for more advanced operation we recommend that you write your own tsctl client per the protocols specifications. This will allow more flexibility: for instance, you can write your client in any language that supports TCP/IP sockets. In addition, certain things cannot be done via the tsctl command line: more specifically, locking and unlocking of objects is done on a connection basis, and therefore it is not possible to hold a lock on an object between invocations of tsctl. Therefore doing this requires writing your own application which acquires the needed locks and holds them while the required operations are performed. The section on locking should be consulted for guidelines to using locks.

Python code implementing the tsctl protocol has been developed for testing purposes, and is available for customer use.  Java code implementing the tsctl protocol has been created for use in an Android app, and is available for customer use.  In general the Python and Java class support may not be as complete as the C implementation (which will always be complete), but it is our goal to eventually provide full support in these languages. 

For more complete control over TS hardware it is possible to utilize the code in tsctl to create a new application. This option is recommended for advanced users only, as TS can only provide limited support to users who take this route. Each object class provides a separation of concerns and tries to minimize platform dependency to its specific function, which is intended to ease reuse of these components in other ways. For instance, a dedicated high performance DIO design might strip down the DIORaw classes and directly embed them as inline functions in other code to avoid the slight overhead of object calls. As these classes already encapsulate the details of how the underlying registers must be manipulated, the developer is freed to concentrate their attention on accessing the DIOs through the API interface.