Setting up Clang_complete plugin into Linux Mint/Vim

Setting up the Clang_complete plugin everytime I create a fresh Linux installation is a pain in the back, even do I’ve written an instructables for my self. So this is the newest instructables right away I’ve made it work and before I forget the steps I followed.

1 Install the Clang compiler and friends.

sudo apt-get install clang libclang-dev

2 Make a soft link from libclang.so to libclang-x.y-so.1, where x.y is the library’s release.

In my case, as in august 2016, it’s 3.8, so:

cd /usr/lib/x86_64-linux-gnu/

sudo ln -s libclang-3.8-so.1 libclang.so

3 Install the clang_complete plugin.

I’m using pathogen to manage my plugins, so inside the bundle directory download the plugin:

git clone https://github.com/Rip-Rip/clang_complete.git

Then enter into the newest directory and type (doesn’t need to be the root user):

make install

4 Finally, show to VIM where the Clang library is.

In your .vimrc file add these lines:

let g:clang_library_path = '/usr/lib/x86_64-linux-gnu'
let g:clang_c_options = '-std=gnu11'
let g:clang_cpp_options = '-std=c++11 -stdlib=libc++'
let g:clang_complete = 1 "automatically selects the first entry in the popup menu
let g:clang_snippets = 1 "do some snippets magic on code placehorlders like funcion argument, template parameters, etc.
let g:clang_close_preview = 1

Among all those lines the most important one is:

let g:clang_library_path = '/usr/lib/x86_64-linux-gnu'

5 Cross your fingers and test it!

 

Algunas razones por las cuales deberías usar un RTOS en tu siguiente proyecto

El título de esta entrada podría replantearse como ¿porqué no usar siempre un RTOS (Real Time Operating System, o en español, Sistema Operativo de Tiempo Real) en nuestros  proyectos? Algunas respuestas que no aceptaría serían: porque es muy difícil; porque no quiero aprender cosas nuevas; porque soy feliz haciendo las cosas así como las he venido haciendo; porque un RTOS se va a comer los pocos recursos de mi chip; etc. De todas ellas la última sería la más válida. Sin embargo no es del todo cierta ya que existen RTOS para todos los gustos y tamaños.

Continuando con esta entrada, el título original presupone que daré unas cuantas razones para usar un RTOS en nuestros próximos proyectos, aunque consideremos que no es necesario. Y así será. Pero en verdad utilizar un RTOS tiene muchas ventajas para nosotros y para el proyecto en cuestión.

No nos hace daño

Basar nuestros proyectos en un RTOS no le hace daño a nadie; todo lo contrario. El argumento aquel que dice que el RTOS se va a comer todos los recursos no es exactamente cierto. El abaratamiento de la FLASH, la RAM, de la velocidad de procesamiento, y la inclusión de diversos timers, nos permiten incluir un RTOS sin mayor problema y sin sacrificar recursos limitados.

Algunos podrían argumentar “Un RTOS hará más lento a nuestro sistema”. La respuesta es un rotundo NO. Esta respuesta llega directamente del mantra aquel que reza “Hazlo funcionar. Luego límpialo. Y después, si es estrictamente necesario, hazlo más rápido”.

Un RTOS nos hace pensar diferente acerca de la organización lógica de nuestro proyecto

Usar un RTOS implica dividir a nuestro proyecto en tareas o procesos, y en subtareas o subprocesos. De aquí que exista la obligación por parte del diseñador o programador de organizar su código en forma no lineal, ya que deberá encontrar la forma de comunicar un proceso con otro, diferir ciertas acciones, manejar las interrupciones, decidir cuáles tareas son más importantes que otras, etc.

Atacar cada una de estas cuestiones (y otras no mencionadas) nos dará una visión completamente diferente de nuestro proyecto a como la habíamos concebido en un principio. Los resultados son muy interesantes.

Usar un RTOS nos hará mejores diseñadores y programadoes

Debo aceptar que esta afirmación no será del todo cierta en todas las circunstancias pero, derivado de todo lo mencionado hasta este momento, los reto a autocalificarse como diseñadores y programadores antes y después de usar un RTOS en su proyecto más próximo.

Modularidad

Dentro de las ventajas técnicas de usar un RTOS ésta es de las más importantes: nuestros programas se harán más modulares. Y como todos sabemos, un programa modular siempre será más fácil de mantener y actualizar que uno realizado en forma monolítica. Vamos a ser capaces de organizar nuestras ISRs (interrupciones) con sus respectivos drivers (manejadores), y estos a su vez con los procesos que hagan uso de los datos arrojados por las interrupciones. Por otro lado, tendremos que los procesos que consideremos no son tan importantes los hemos de diferir para cuando el CPU esté libre y los activaremos sólo cuando sea necesario. ¡Me lleno de emoción sólo de pensar en este código no lineal!

Liberación del CPU

Una ventaja del RTOS es la facilidad con la que podremos devolver el CPU cuando uno de nuestros procesos no la requiera por el momento. Esta característica tiene mucho que ver con aquella de pensar diferente acerca de nuestro proyecto debido a que tendremos que analizar los momentos en que el proceso deba devolver el CPU.

Otra ventaja es el ahorro de energía para aquellas aplicaciones de batería. Si no hubiera nada por hacer, entonces mandamos al CPU a hibernación. Algún lector anti-RTOS podría decir “El tick del sistema estará despertando al CPU aún cuando no es necesario, por lo que no hay ningún ahorro de energía”. Cierto y falso. Este es un argumento cierto si es que no estamos considerando lo siguiente: los RTOS más populares incluyen una característica conocida como “tick-less scheduler”, es decir, un manejador de tareas que no depende del tick del sistema. De esta manera, el CPU pasará al estado activo solamente cuando una interrupción sea disparada.

Hay que tener en cuenta que en un RTOS el CPU se puede liberar al menos de dos formas: con una instrucción Yield(), o con una instrucción Sleep() (los nombres pueden variar dependiendo del RTOS que hayamos escogido, pero la funcionalidad es la misma).

Múltiples retardos

Esta es mi característica preferida. Si en sus proyectos han tenido que lidiar con diferentes retardos (tiempos diferentes) al mismo tiempo, entonces sabrán que el código puede convertirse en una pesadilla muy rápido. Dividir el proyecto en tareas, y poder mandarlas dormir cuando sea necesario y en forma independiente, nos da una gran flexibilidad en la organización lógica del proyecto.

Palabras finales

Estoy incierto si pude convencer a alguien sobre utilizar un RTOS para sus próximos proyectos, pero me sentiré satisfecho si al menos pude mover un poco de su curiosidad acerca de este tema tan fascinante (tema que no solo es actual, sino que se volverá una tendencia en un tiempo no muy lejano).

Como siempre, pueden dejar sus comentarios para intercambiar ideas.

 

 

Patrón Observador para Sistemas Embebidos, parte I

En esta ocasión voy a exponer una implementación del patrón Observador orientado a sistemas embebidos que carecen de memoria dinámica. En sistemas embebidos con procesadores con hasta 256 KB en RAM es difícil tener un manejador de memoria dinámica, y al mismo tiempo tampoco se tiene una implementación decente (en términos de tamaño) de la STL. El patrón Observador se escribe en forma muy elegante haciendo uso de la STL, pero como lo he mencionado, asumiremos que nuestro sistema no cuenta ni con memoria dinámica ni con dicha librería.

Este patrón requiere una lista de observadores que vamos a implementar con un típico arreglo estático de N elementos. De todos modos es difícil encontrar un escenario para nuestros pequeños procesadores (pequeños en términos de RAM, no de potencia de cálculo) donde tengamos la necesidad de hacer crecer o disminuir la cantidad de elementos del arreglo.

Así, yo llamaría a esta implementación del patrón como “Patrón observador con implementación estática”, que tiene como primer consecuencia que no exista el método Remove () o Detach() para eliminar entradas de la lista de observadores.

El primer uso que le voy a dar a dicha implementación, y por lo cual no requiero el método Remove (), es tener una lista de timers, cada uno independiente de los demás. Se le notificará a los observadores (las tareas que esperan por el transcurso de un intervalo de tiempo) cada vez que se produzca un tick del sistema. Cada timer será una unidad autocontenida.

Esta primera implementación tampoco utiliza clases abstractas. Aún no, porque estoy haciendo una prueba de concepto. En las siguientes partes ya lo haré como lo ordenan los cánones.

En el código presentado a continuación utilicé al flujo cout con fines de depuración únicamente. También el código puede adaptarse fácilmente a usos diferentes del que se me ocurrió.

#include <iostream>

using namespace std;


class Observer
{
public:
    void Update ();


    /*-----------------------------------------------------------------------------
     *  A partir de aquí la clase concreta hace lo que quiera
     *-----------------------------------------------------------------------------*/
    Observer (int newVal = 0);
    void Print () { cout << "Val: " << this->val << endl; }

private:
    int val;
};

void Observer::Update ()
{
    cout << "El observador está siendo notificado ...\n";
    this->val++;
}

Observer::Observer (int newVal) : val (newVal)
{

}


class Subject
{
public:
    Subject ();

    bool Add (Observer * newObserver);
    void Notify ();

private:
    Observer * list[5];
    // lista de observadores
    
    int index;
    // índice a la siguiente entrada disponible en la lista de observadores
};

Subject::Subject () : index (0)
{
    for (int i = 0; i < 5; ++i) {
        this->list[i] = NULL;
    }
}

bool Subject::Add (Observer * newObserver)
{
    if (this->index > 4) { return false; }
    // ya no caben más observadores

    this->list[this->index] = newObserver;
    this->index++;

    return true;
}

void Subject::Notify ()
{
    for (int i = 0; i < 5; ++i) {
        if (this->list[i] == NULL) { continue; }

        this->list[i]->Update ();
        // solamente avisa de una actualización, no envía datos
    }
}

/*
 * Driver program
 */
int main()
{
    Subject sujeto;
    Observer observador1;
    Observer observador2 (10);

    sujeto.Add (&observador1);
    sujeto.Add (&observador2);

    for (int i = 0; i < 6; ++i) {
        sujeto.Notify ();
    }

    observador1.Print ();
    observador2.Print ();

}

Un saludo y quedo a la espera de sus comentarios.

Patrón de diseño Command

Introducción

El patrón de diseño Command es uno de los más útiles en nuestro catálogo de patrones para sistemas embebidos porque nos va a permitir desacoplar al sujeto que genera órdenes del sujeto que las debe llevar a cabo, y donde cada comando (u órden) es un objeto. (Recuerde que en los patrones de diseño todo son objetos, polimorfismo, clases base abstractas y concretas, interfaces, etc.)

Un ejemplo concreto de esto es un teclado de (digamos) tres interruptores. Cada vez que presionamos un interruptor mandamos una órden al sistema, y éste la ejecuta. Un escenario normal (sin usar a este patrón) es que las órdenes que ejecuta cada interruptor son fijas, y cada órden se codifica como función. El patrón Command permite que cambiemos en tiempo de ejecución la acción que cada interruptor debe llevar a cabo, así como la parte de nuestro sistema que ejecuta dicha órden o acción. En otras palabras, en un cierto estado la tecla A aumenta un contador, pero en otro estado la misma tecla A haría las veces de la tecla <Escape> o salir (o de cualquier otra cosa que queramos). El cambio de una funcionalidad a otra de la tecla A la llevamos a cabo en forma dinámica.

También se dice que este patrón es la versión orientada a objetos de una callback, y me parece que este es un buen punto de partida para entenderlo.

Para intentar explicar a este patrón voy a comenzar al revés de lo que normalmente se encontraría uno en la literatura u otros tutoriales: empecemos por nuestro cliente, la función main() y utilizaremos los mismos nombres comunes que se usan para este patrón. (Recuerde que el ‘cliente’ de Z es aquella función, clase o método que declara objetos variables del tipo Z. Y como tampoco soy un genio de los patrones, al final dejaré algunos enlaces en los que me basé para este tutorial):

// Driver program (o nuestro 'cliente')
int main()
{
    Receptor r;
    // r es quien va a ejecutar los comandos (ú ordenes). Por favor noten que r
    // no conoce a su invocador.
    
    ComandoA cmdA (&r);
    // comando A
    // Aquí podemos ver que vinculamos al comando cmdA con el receptor r.
    
    Invocador inv (&cmdA);
    // inv es el sujeto que invoca al comando cmdA. En este punto inv no sabe
    // que el receptor r es quien ejecutará su órden.
    
    inv.Invocar();
    // inv envía el mensaje Invocar(), que a su vez ejecuta el comando cmdA a
    // través del sujeto r.
    // Y he aquí la magia: el sujeto inv ejecuta el comando cmdA sin saber que
    // será el sujeto r el que lo lleve a cabo; y a su vez, el sujeto r no sabrá
    // que el comando cmdA proviene de inv.
}

Veamos los participantes en este patrón:

  1. Cliente. Como ya se mencionó es la parte del código que hace uso de este patrón. En nuestro ejemplo es la función main(), pero también podría ser una clase o un método.
  2. ComandoA. Es el comando que queremos ejecutar. Los comandos están en forma de objeto. En general, cmdA es una instancia de la clase ComandoA que a su vez es una clase heredada (o mejor dicho, clase concreta) de la clase base abstracta Comando (que aún no está representada en nuestro código, pero pronto lo estará).
  3. Invocador. Es el sujeto que quiere ejecutar al comando (o a uno de varios comandos). En un sistema embebido éste sería una tecla, por ejemplo.
  4. Receptor. Es la parte del código que recibe al comando y lo ejecuta.

Estudiando al código anterior podemos deducir varias cosas importantes del patrón Command.

  • Pueden haber tantos receptores (o ejecutores) de comandos como necesitemos.
  • Pueden haber tantos comandos como necesitemos.
  • Pueden haber tantos invocadores como necesitemos.
  • Y lo más interesante de todo: pueden haber tantas combinaciones de lo anterior como sea necesario.

Implementación

Para llevar a cabo la implementación de este patrón lo primero que necesitamos, es por supuesto, los comandos.

Clase base abstracta Comando

Todos los comandos deberán ser instancias de clases que hereden de Comando.

class Comando
{
public:
    virtual void Exec () = 0;
};

 

Comandos u órdenes

Cada comando deberá ser una instancia de alguna de las clases que hereden de la clase base abstracta Comando. En este ejemplo en particular sólo tenemos un comando. La declaración adelantada se necesita porque vamos a hacer referencia a ella dentro de las clases heredadas.

class ComandoA : public Comando
{
private:
    Receptor * r;

public:
    ComandoA (Receptor * _r) : r (_r) { /* nada */ }
    // vinculamos al comando con el receptor

    void SetReceptor (Receptor * _r) { r = _r; }
    // por si más adelante deseamos cambiar al receptor de este comando
    
    void Exec() override { r->Accion (); }
};

Clase Receptor

class Receptor
{
public:
    void Accion () { std::cout << "Comando recibido\n"; }
    // cada vez que el receptor es invocado se ejecuta la 'Accion' asociada a
    // ese comando en este receptor
};

Clase Invocador

class Invocador
{
private:
    Comando * cmd;
    // cmd vincula un comando con una instancia de Invocador

public:
    Invocador (Comando * _cmd) : cmd (_cmd) { /* nada */ }

    void SetComando (Comando * _cmd) { cmd = _cmd; }
    // por si más adelante el invocador desea cambiar de comando

    void Invocar () { cmd->Exec (); }
};

Código completo

Aquí tenemos el código completo de este ejemplo. Es indispensable que el lector tome en cuenta (porque siempre pasa en el diseño con patrones) el órden en que se implementan las clases, porque podría darse el caso de que el código no compile debido a que no encuentre la declaración de una clase utilizada por otra clase, pero que está declarada más adelante. A veces esto se soluciona utilizando declaraciones adelantadas. En nuestro ejemplo no hemos tenido esos inconvenientes, pero aún así el lector debe estar conciente de ello.

#include <iostream>

class Comando
{
public:
    virtual void Exec () = 0;
};

class Receptor
{
public:
    void Accion () { std::cout << "Comando recibido\n"; }
    // cada vez que el receptor es invocado se ejecuta la 'Accion' asociada a
    // ese comando en este receptor
};

class ComandoA : public Comando
{
private:
    Receptor * r;

public:
    ComandoA (Receptor * _r) : r (_r) { /* nada */ }
    // el comando toma a su receptor

    void SetReceptor (Receptor * _r) { r = _r; }
    // por si más adelante deseamos cambiar al receptor de este comando
    
    void Exec () override 
    { 
        r->Accion (); 
    }
    
};


class Invocador
{
private:
    Comando * cmd;
    // cmd vincula un comando con una instancia de Invocador

public:
    Invocador (Comando * _cmd) : cmd (_cmd) { /* nada */ }

    void SetComando (Comando * _cmd) { cmd = _cmd; }
    // por si más adelante el invocador desea cambiar de comando

    void Invocar () { cmd->Exec (); }
};

/*
 * Driver program (o nuestro 'cliente')
 */
int main()
{
    Receptor r;
    // r es quien va a ejecutar los comandos (ú ordenes). Por favor noten que r
    // no conoce a su invocador.
    
    ComandoA cmdA (&r);
    // comando A
    // Aquí podemos ver que vinculamos al comando cmdA con el receptor r.
    
    Invocador inv (&cmdA);
    // inv es el sujeto que invoca al comando cmdA. En este punto inv no sabe
    // que el receptor r es quien ejecutará su órden.
    
    inv.Invocar();
    // inv envía el mensaje Invocar(), que a su vez ejecuta el comando cmdA a
    // través del sujeto r.
    // Y he aquí la magia: el sujeto inv ejecuta el comando cmdA sin saber que
    // será el sujeto r el que lo lleve a cabo; y a su vez, el sujeto r no sabrá
    // que el comando cmdA proviene de inv.
}

Conclusiones

En primera instancia los patrones de diseño parecen (y realmente son) demasiado abstractos. Pero con un poco de tiempo y algún ejemplo que tenga que ver con nuestro trabajo se hace más fácil tanto entenderlos como implementarlos. Lo que sí es indispensable es que el lector tenga sólidos conocimientos tanto de diseño orientado a objetos (abstracción, herencia, polimorfismo, clases abstractas), como del lenguaje en que se implementará el patrón, en nuestro caso, C++.

En una siguiente entrega tendré un ejemplo más concreto (que tenga que ver con sistemas embebidos) para que el lector pueda afianzar sus conocimientos y aplicar el patrón a sus futuros diseños (o reescribir sus diseños actuales).

También, si el lector gusta de los diagramas UML esta entrada de la Wikipedia podría serle útil. (Muchas veces los diagramas UML de los patrones, y la definición formal de los mismos, obscurecen su sencillez, flexibilidad y elegancia.)

 

Fuentes

http://arsenmk.blogspot.mx/2012/07/command-pattern-implementation.html

https://sourcemaking.com/design_patterns/command/cpp/2

https://en.wikibooks.org/wiki/C%2B%2B_Programming/Code/Design_Patterns/Behavioral_Patterns

Y por si a alguien le interesa, aquí dejo una parte de mis anotaciones personales, que básicamente es la transcripción de este tutorial para mi entendimiento personal.

2015-12-14 18.32.51-1