Introduction¶

FastIO is a library which is largely compatible with standard mbed GPIO functions, but which provides superior speed. The code is based on Igor's earlier work (http://mbed.org/users/igorsk/notebook/fast-gpio-with-c-templates/), with three main differences: port functions are currently not available (this might change in the future), it is ported to many more targets than the original, and instead of only DigitalOut, all options from DigitalInOut are implemented.

FastIO uses a template for the pin number which is connected to the FastInOut object instead of an argument to the constructor like the regular DigitalInOut uses. The important difference between those two is that the value of a template is known by the compiler at compile time, while the supplied pin for regular DigitalInOut is only known at run-time. This allows the compiler to add more optimizations. The only limitations this introduces is that you cannot at run-time choose which pin is used (which would be an extremely rare use case).

For supported targets have a look at the table below. Or check it out you can start by trying the test bench , if it doesn't compile for your target, it isn't supported yet :).

Performance¶

The main goal is to have a faster, more efficient alternative to regular mbed GPIO functions, so lets compare that. The comparisons are done with mbed library version 85. Newer versions are going to have extra debug code added; at the moment I write this it isn't known yet if the online compiler is going to support disabling those. This does not influence FastIO, but it will slow done regular mbed functions.

Five different performance figures are measured:

• Fixed write(pin.write(1);)
• Variable write (pin.write(val);)
• Reading the pin state and comparing it (if (pin.read() == 0) break;)
• Toggling a pin using operators (pin= !pin;)
• Switching between input and output (pin.output(); pin.input();)

While there are other use cases, these should cover the most used ones. Storing the read value is not included, but should have a fairly similar result. Just comparing it is an easy way to make sure the operation cannot be (partially) optimized away by the compiler, although it results in a longer time than what is actually used by purely the read operation. The main goal of FastIO is to have fast writing, reading, and toggling between input and output (for bidirectional lines), fast construction and mode switching is preferred, but not as important.

The following table shows the time occupied by fastIO compared to regular DigitalInOut:

Note that these numbers are from the specific testbench, which highly depends on which optimizations the compiler decides to make. So for your situation it can be different, for example I have seen the write speed change after changes to the read code.

Usage¶

The library contains three classes you can use:

FastInOut<PinName> your_name;
FastOut<PinName, initial_state> your_name;
FastIn<PinName, initial_mode> your_name;

Initial_state is by default 0 (so output low) and is optional, initial_mode is by default PullDefault, and is optional. Some examples:

FastOut<LED1> led;             //FastOut object for LED1, will default to output low
FastIn<D5, PullUp> input;    //FastIn object for D5, with by default PullUps enabled

Contrary to regular DigitalIn/DigitalOut, FastIn/FastOut can use all functions available to DigitalInOut/FastInOut. The only difference between the three FastIO classes is the initial conditions: FastInOut doesn't set any initial conditions, and the current state of the uC will be maintained. FastOut sets it as output, either high or low, and FastIn as input, with or without pullups/pulldowns enabled. Afterwards you can change your FastIn to an output using simply .output().

For other examples you can look at the test bench code.