chisl languages

Overview

The purpose of ChISL is to concisely and succinctly describe the properties of commonly used digital interfaces such as I 2C, SPI, 1-Wire, UART, etc. The ChISL interface definition is a meta description that will allow automated source code generation, easy document search and browsing, and also automated testing.

As a very general rule, digital interfaces are based on registers that have specific address and content. For example, the content of a register can be of an informative nature, it may be used to configure the device, or it may trigger some action.

Goals and Requirements

  • Provide a concise, unambiguous, and sufficiently rich syntax

  • Be simple and easily readable, unless above goals require otherwise

  • Describe registers at the bit level, including access mode and default value

  • Support insertion of full documentation

  • Be easily typeable when translating a datasheet or user-manunal into a ChISL definition

  • Allow syntax extension without breaking compatibility

Motivation

lightbulb

Embedded systems drive innovation

smartphone

The semiconductor market continues to grow, fueled by smartphones, automotive systems, and the Internet of Things (IoT) [1]. As growth has shifted from the PC sales to embedded devices, the requirements have also changed:

  • Energy efficiency is crucial in mobile devices and many IoT applications, and the ability to intelligently manage power consumption is generally a key feature;

  • Smartphones, automotive and the IoT require new and better sensors;

  • In many applications wireless connectivity is now a must rather than an option

It is not surprising that an increasing number of products, in particular integrated circuits, is developed to serve these new needs.

At the same time nearly 50 percent of designs are late or never reach market and nearly 30 percent fail after release, according to " Embedded Software Development: Issues and Challenges" [ 1]

Software

cogs

While embedded hardware undergoes rapid change, innvoation in the accompanying software tools is rather sluggish. Many vendors recognize that good software tools can be a "USP" (unique selling point) in a very competitve market. Yet, most vendor libraries are written in C89, not utilizing many of the nice features that have been added in the last 28 years. C++ is gaining some traction thanks to the mbed platform and Arduino. But scripting languages like Python on Javascript are marginal, although they allow very fast protoyping.

Documentation

documentation

Datasheets and user manuals are the key resource when programming ICs. For simple devices a table with register addresses and bit assignments and a few lines of text suffices. But for more complex devices, such as RF transceivers, the digital interface description can stretch hundreds of pages. The documentation is usually distributed in the form of of several pdf files: Data sheet, user manual(s), errata, application notes, etc. Some vendors have very active forums where "breaking news" are published long before a bugfix appears on some errata page. All in all, the information tends to be rather scattered, which makes it hard to quickly find the most up-to-date information.

Enter ChISL

ChISL is a tool that has been used internally for a while. At its core it is a * digital interface definition, and a * parser that can generate source code in different languages/dialects.

This approach frees us from the vendor-provided C89 libraries and allows us to go C99, C++ (98, 03, 11, 14) or even do rapid protoyping on a Raspberry using Python. Code quality is high, because the source code is directly derived from the vendor documentation. The coding style, structuring and naming conventions, are uniform and web-based, well indexed, documentation makes information retrieval much faster. The automatically generated source code also directly contains the vendor documentation, which is very handy when using IDEs with good hinting, such as Eclipse.

Goals

goal

Become language agnostic

One ChISL meta definition generates source code in any programming language. Within one language different standards can be catered for and utilized (e.g. C11 vs. C14). Correctness in one implementation (language) is a very strong indicator for correctness in all implementations.

Faster protoyping, easier porting

Protoyping typically happens on Arduino, Raspberry Pi, or other dev boards. This approach ensures quick initial results, but often it also carries a later cost of porting to the target platform.

  • Consistent source code makes porting to the target platform much easier

  • By using a single meta-description positive results on one the protoyping platform likely translate to positive results on the target platform

Consistent source code

When source code from different contributors/vendors is pulled together naming conventions often clash. Differing coding styles and source code organisation can slow down the development process.

  • Consistent naming simpliefies the development process

  • Name-clashes can be avoided (they are particulalry annoying in C)

Larger datasheets or user manuals are typically navigated via embedded links or a by using the search function. The highly structured meta description allows to better annotate the document with links and gives a much better search functionality.

  • Collaboration can improve the quality of the ChISL meta description, which translates directly into the various implementations (languages).

Collaboration: The many-eyes principle

It is difficult for manufacturers to maintain up-to-date documents that incorparate all feedback and corrections. The release-cycle for documentation is usuall very slow. It is customary to issue addenda or bury updated information in application notes. But users would benefit greatly from a timely and structured dissemination of new information.

  • Datasheets/user manuals are rarely error-free and all users will benefit when findings (e.g. improvements, bug-fixes) are shared quickly.

  • Collaboration improves the quality of the ChISL meta description, which translates directly into the implementations (languages).

  • Improvements can also be made to documentation. Improving Structure, removing ambiguities, filling omissions are better done in a collaboration, following the many-eyes principle.

RTOS, FPGA, etc.

As MCUs become more powerful and also more complex, RTOS offer an interesting option.

FPGAs are often used for filtering sensor input while the MCU or MPU is in sleep mode.

  • A consistent coding style simplifies integration into a RTOS

  • For FPGAs HDL code can also be generated

Transparent licensing

Pulling together source code from various contributors and vendors often means juggling with software licenses.

  • In a multitide of licenses conflicts are possible, and licensing details are not transparen to the average user.

  • All publicly available ChISL-generated source code has one single permissive software license.

  • ChISL meta descriptions may also be made private. In that case threr is complete freedom to choose a license.

Debugging

probe circuit

Bus decoding

With ChISL it is possible to go a step further than what can be accomplished with a logic analyzer:

  • In general it is preferable to to analyze bus communication with decoded, i.e. human-readable content instead of bits and bytes.

  • Existing applications can be debugged by not only decoding the communication on the bit-level, but also on the interface level. I.e. register reads and writes are decoded and shown using the nomenclature in the documentation.

  • Faulty or misconfigured devices can be analyzed by comparing the required responses with the actual ones. Often this is done by dumping all communication to some serial port. In resource-constrained devices this can often not be done, however.

  • Increasingly, complex devices such as IMUs obtain "hub" capabilities: External sensors are managed by the device instead of the MCU (which goes into a sleep mode). These "hubs" usually have very limited debugging options.

Refactoring of legacy software, and hardware

It is often easier to refactor existing source code by monitoring the communication / actions instead of deciphering, unmaintained or sparsely documented source code.

Note
Illegal use of the software, e.g. for reverse-engineering IP, is prohibited by the ChISL Usage Licence.

Testing, verification, formal methods

test

Testing and verification are crucial steps in the software development process. For example, in Test Driven Development (TDD) all features are accompanied by at least one test case. But not all contributors/vendors will adhere to a certain, required process.

  • ChISL can ensure that specified processes are followed.

  • For example test cases for features can be automatically generated.

  • Coding standards such as MISRA-C or SEI CERT are, or can be fulfilled by construction

Language support

languages

C89 ("ANSI C") / C90

C89/90 is the first formal standard of the C language, first ratified by ANSI in 1989 and then by ISO in 1990. Hence "C89", "C90" and "ANSI C" all refer to the same thing. Even today most vendor libraries are written in C89. The reason is, probably, that C89 is the lowest common denominator, supported by all known compilers. Compiler vendors such as Attolic, IAR, Keil, MikroElektronika, etc., usually implement a C89 compliant compiler with optional extensions.

C99

C99 adds new data types like long long, bool and complex number types.

  • Inline functions: The inline keyword instructs the compiler to try to perform optimizations such as function inlining.

  • single-line comments using the C++-style notation //

  • interspersed declarations / statements

  • Designated initializers allow shorter and more expressive syntax: For arrays

int a[6] = { [4] = 29, [2] = 15 };
/* is the same as: */
int a[6] = { 0, 0, 15, 0, 29, 0 };

And for structs

struct point { int x, y; };
struct point p = { some_x, some_y };
/* is the same as: */
struct point p = { y: some_y, x: some_x };
  • flexible array member

  • the inttypes.h header offers standardised names for integers, e.g. uint8_t, int32_t, etc.

Some software guidelines such as MISRA C support C99.

C11

C11 is the current standard for the C language.

  • Improved unicode support

  • Atomic types an be declared using the _Atomic keyword

C++98

C98 is the initially standardised C. It is essentially the same as C++03.

C++03

The only mew feature added is value initialisation, i.e. construction of a variable with emtpy initializer.

A *p = new A();   // empty initializer

C++11

  • lambda functions

  • automatic type inference ( auto syntax)

  • rvalue references

  • cleaner initialisation syntax

  • introduction of nullptr

  • much richer standard library

  • smart pointers shared_ptr and unique_ptr

  • introduction of constexpr, which tells the compiler that an expression is immutable

C++14

  • C++14 relaxes some constexpr restrictions. For example, for and if statements are now allowed in constexpr-declared functions.

  • binary literals ( 0b01010111) and other new ways of writing number literals

C++17

todo

Python2

Although C/C++ is the de facto standard for development on microcontrollers, python running on a Raspberry Pi is becoming a viable alternative for rapid prototyping.

High level programming languages like python usually require a full-blown OS such as Linux. The exception to this rule are lean python implementations such asMicroPython that can run on a micorcontroller. It is clear that this approach aims mostly at prototyping and technology testing.

Prototyping on a full-blown OS using high level programming languages has several clear advantages:

  • Fully funcitional prototypes can be built quickly

  • Technology testing ist faster

  • Proof of concept is easier to achieve

  • The application development phase is reached quicker

Python3

Python3 is not compatible with Python2. For example, print is a function, and many functions such as range that returned lists in Python2 now return iterators.

Javascript

todo

1. J. Krasner, Embedded Market Forecasters, July 2003