La camara que estoy usando es una cámara que puede dar 120FPS. Pero misteriosamente cuando conecté el extender nomas no queria ni siquiera comenzar la “ISO Transmission”.

Y luego descubri que si la hacia funcionar a propósito mas lento, digamos a 7.5 FPS, entonces sí funcionaba. ¿Que estará pasando?.

Hagamos algunas cuentas. La camara chafona Unibran Fire-i da 30FPS a 640×480 en modo escala de grises de 8 bit, que en realidad es un formato Bayer RGGB que al hacer el demosaic y postprocesarse da una imagen 640×480 en color de 24 bits.

A ver, quede que iba a hacer cuentas y las cuentas son:

640 x 480 x 8 x 30 = 73,728,000

Eso es aproximadamente  70 Mbit/seg.

Ahora, si quiero hacer funcionar la PointGray, digamos a 120 FPS deberá necesitar:

752 x 480 x 12 x 120 = 519,782,400

Eso es muchisimo mas, son poco mas de 500 Mbit/seg. A caray! eso es más de lo que el bus Firewire 400 puede dar (400 Mbit/seg).

Indagando más descubro que la cámara esta funcionando solo a 8bit por pixel y no a 12, y que de alguna manera esta siendo forzada a funcionar a 60 FPS cuando la tengo sin el extender. Eso es 173,260,800 o bien, como 170 Mbit/seg.

Y eso nos da una pista, ¿que hay de diferencia entre 73 Mbit/seg y 170 Mbit/seg? Pues 100Mbit, pero eso no es lo interesante, sino la barrera de 100Mbit que existe en las especificaciones de firewire. En Firewire 400, no siempre tienes garantizados los 400Mbit, algunos dispositivos solo necesitan 200Mbit y otros solamente 100Mbit, por lo que el estandar permite reducir la velocidad y permite a los fabricantes hacer dispositivos que puedan funcionar a velocidades reducidas y aun así conectarse al puerto Firewire 400.

¿Que dice Kramer al respecto? Tengo dos de los TP-300FW,  incluso con el TP-400W no funcionará. Esos nombres son engañosos, esos dos dispositivos unicamente funcionan a 100 Mbit/seg.

Entonces, ¿puedo meter la camara rapida que usa 170 Mbit/s sobre extenders TP-400W que funcionan a 100Mbit/seg? Claramente no. La culpa no era de firewire sino de los extenders, y lo aprendí por las malas, pero para poder llegar a la solución aprendí mucho del protocolo Firewire y mucho más sobre la librería libDC1394 v2.x, sobre el kernel de linux y sobre otras tantas cosas que vistas en retrospectiva, fueron divertidas.

The procedure entry point _Z17qt_message_output9QtMsgTypePKc could not be located in the dynamic link library QtCore4.dll.

Este error me salio cuando instale la version 2010.01 de Qt 4.6 en Windows XP. Lo instalé en C:\Qt como indica por default.

Solucion

El asunto es que al agregar rutas al enlazador, debes usar C:\Qt\2010.01\qt\bin y no como yo: C:\Qt\2010.01\bin\. Al  arreglar esa ruta se arregla el problema.

Recuerda también que las siguientes rutas deben estar en el PATH de windows para ejecutar los binarios sin problemas:

• C:\Qt\2010.01\mingw\bin;
• C:\Qt\2010.01\qt\bin;

Primero, puede que hayas encontrado el conflicto haciendo

$ git svn dcommit

Pero pronto te das cuenta que git svn dcommit realiza un git svn rebase, antes de todo. Así que en realidad el problema es causado por el “rebase”.

Notas:

• Estarás en la rama “no branch” o sea en ninguna rama (no puedes descomponer nada).
• Tal vez haya archivos .dotest, simplemente ignoralos

Técnica de resolución:

• En cualquier momento puedes cancelar con: git rebase --abort
• Para el archivo en cuestión, abrelo (vi?), y corrige el conflicto (Estarán marcados con muchos “mayor que” y “menor que” indicando las versiones). Simplemente elimina uno de los bloques y quita los simbolos.
• Ya que lo corregiste, agrégalo: git add <archivo>
• Despues de agregarlo, continua el “rebase” : git rebase --continue
• Pueden ocurrir que te diga: did you forget to call ‘git add’?. En ese caso tu parche se ha convertido en no-op, o sea no hay cambios. Usa git rebase --skip.
• Repite con cada uno de los archivos del conflicto.

Cada punto es un archivo, los archivos se acercan a su desarrollador, mientras mas brillan mas actividad hay sobre ellos. Si dos desarrolladores trabajan en los mismos archivos se acercan entre ellos y los puntos intentan reflejarlo acercandose o alejandose.

En la visualización se pueden ver los commits iniciales y la rapida evolucion de la API en etapas tempranas como cientos de puntos(archivos) junto a mi nombre, luego se puede ver como Mario se involucra en el desarrollo. Casi al final, apenas se nota, que Mario comienza a trabajar en archivos “lejanos” a los mios, por eso ya se alcanzan a notar 2 anillos distintos, uno para cada quien. Al parecer Mario tiene mucha actividad sobre unos pocos archivos, por eso crecen los puntos.

En realidad el sistema corre muy suave, pero el video quedó muy cortado pues se tomó como a 10FPS, el sistema en la compu logra dar mas de 160FPS.

La solución: Se debe indicar a gcc en donde estan las librerias usando -L<dir>, luego enlazarlas como librerías normales usando -l<name>. Por ejemplo para enlazar la librería /home/user/tmp/libtrompete.a:

gcc -L/home/user/tmp/ -ltrompete main.cpp

Nota que solo se le indica el nombre trompete, porque gcc le agrega lib+trompete = libtrompete. GCC también busca automáticamente si es .o, .so o si es una AR .a.

Es muy útil hacer debugging con std::cerr, y si usas:

#include <iostream>
using namespace std;
main(blabla...){
  cerr << "This is a debug message" << endl;
}

Todo funciona maravillosamente, hasta que tus 20 threads comienzan a vomitar cientos y cientos de mensajes que hacen imposible leer el debug. Para ello lo ideal sería definir “debug levels”. Hay dos formas la forma simple y tonta:

#ifdef DEBUG_N
  cerr << "This is a debug message" << endl;
#endif

Pero esa forma es muy fastidiosa, así que mejor definimos un ‘cerdo‘ (cerdo = cerr debug output). O incluso mejor un cerdo con niveles: cerdo, cerdo2, cerdo3,… , cerdoN. He aqui uno para 3 niveles (donde hacemos que cerdo=cerdo1):

// ----- cerdo.h -----
#ifndef DEBUG
  #define cerdo if(0) cerr
  #define cerdo1 if(0) cerr
  #define cerdo2 if(0) cerr
  #define cerdo3 if(0) cerr
endif
#if (DEBUG==1)
#define cerdo cerr
  #define cerdo1 cerr
  #define cerdo2 if(0) cerr
  #define cerdo3 if(0) cerr
#endif
#if (DEBUG==2)
#define cerdo  cerr
#define cerdo1 cerr
  #define cerdo2 cerr
  #define cerdo3 if(0) cerr
#endif
#if (DEBUG==3)
  #define cerdo  cerr
  #define cerdo1 cerr
  #define cerdo2 cerr
  #define cerdo3 cerr
#endif
// ---- end cerdo.h ----

Ahora solo queda usar los cerdos.

#define DEBUG 2
#include "cerdo.h"
using namespace std;
main(blabla...){
  cerdo << "This is a debuglevel 1 message" << endl;
  cerdo1 << "This is a debuglevel 1 message" << endl;
  cerdo2 << "This is a debuglevel 2 message" << endl;
  cerdo3 << "This is a debuglevel 3 message" << endl;
}

Bye.

Directo del repositorio

$ svn merge -r START:END http://repo/svn/trunk /directorio/branch

De una copia local:

$ svn up /directorio/trunk
$ svn merge -r START:END /directorio/trunk   /directorio/branch

Cualquiera de las dos anteriores te hace un merge a la copia local que está en /directorio/branch.

Para finalmente subir (a la branch) los cambios obtenidos

$ svn ci -m "Merge del trunk a mi branch START:END"  /directorio/branch

Si no se pusieron de acuerdo tus programadores, probablemente salgan conflictos, arreglalos.

Creación automática de un proyecto de KDevelop con CMake

Usaré exactamente lo que se describe en el post anterior. Lo único que debe tenerse precaución es en eliminar todo lo que pudiera quedar dentro del directorio build/ de generaciones pasadas. El directorio build/ debe estar vacío.

$ cd build/
$ cmake -G KDevelop3 ../
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ariel/Documentos/holaMundoCMake/build

Y listo. Nota la opcion “-G KDevelop3“. En el directorio build/ se auto genera un proyecto de KDevelop llamado HELLO.kdevelop pues HELLO es el nombre del proyecto que definimos en CMakeLists.txt. Ahora se puede abrir con KDevelop (C/C++). Project->Open Project y elegimos HELLO.kdevelop.

El proyecto compila, ejecuta y tenemos el arbol de inclusiones. Tambien podemos usar el debugger y el completador de código. Todo lo de KDevelop funciona porque es un proyecto nativo.

Ah, para que el completador de código funcione, debes tener KDevelop 3.5.2 al menos.

CMake es una excelente herramienta para generar Makefiles, y no solo eso tambien genera soluciones de Visual Studio, Code::Blocks, Kdevelop entre muchas otras. Así que me puse a investigar y resulta que CMake es trivial de usar, hasta un newbie como yo lo puede usar (por lo tanto otros newbies también podrían usarlo).

1. Hello World: El código fuente

Usaremos este código que muestra CMake para compilar y enlazar un programa principal con una librería extra generada por nosotros mismos. La siguiente estructura de directorios es la que hay que crear:

holaMundoCMake
|-- CMakeLists.txt
|-- build
`-- src
    |-- hola.cpp
    `-- milib
        |-- CMakeLists.txt
        |-- milib.cpp
        `-- milib.h

La idea aqui es que vamos a generar un pequeño programita a partir del codigo en hola.cpp y de la libreria milib.cpp, el código de hola.cpp es muy sencillo:

hola.cpp:

#include "milib.h"
int main(int argc, char* argv){
printf("\n Hola mundo desde main");
hola(2);
printf("\n");
}

Y lo que hace es cargar el header milib.h que es donde está definida la función hola().

milib.h:

#include <stdio.h>
//Prototipo de funcion
void hola(int);

milib.c:

#include "milib.h"
// Implementacion de la funcion
void hola(int veces){
  int i=0;
  while (i<veces){
    printf("\n [%u] Hola Mundo, desde 'milib'" , i);
    i++;
  }
}

El código es realmente trivial (si no lo comprendes mejor ni sigas leyendo). Hasta este punto no hemos usado nada de CMake ni hemos creado Makefiles ni nada. El código bien podríamos compilarlo a mano.

2. Hello World: Las CMakeLists.txt para CMake

Hay un archivo de CMake en holaMundoCMake/CMakeLists.txt y hay otro en holaMundoCMake/src/milib/CMakeLists.txt, éstos son los archivos clave para CMake. Con los comentarios se explican solos.

holaMundoCMake/CMakeLists.txt:

# El nombre del proyecto "HELLO".
# CMake genera automaticamente una variable llamada
# HELLO_SOURCE_DIR que puede llamarse usando
# ${HELLO_SOURCE_DIR} con la ruta del codigo
# lo mismo con ${HELLO_BINARY_DIR} para binarios

project (HELLO)

# Le decimos donde poner los binarios de librerias y ejecutables
# CMake admite instrucciones partidas en varias lineas
SET (LIBRARY_OUTPUT_PATH    ${HELLO_BINARY_DIR}/bin
	CACHE PATH "Directory for Libraries")
SET (EXECUTABLE_OUTPUT_PATH ${HELLO_BINARY_DIR}/bin
	CACHE PATH "Directory for Executables")

# Decimos a CMake que haga recursion a los siguientes directorios
# en orden de aparicion
add_subdirectory (src/milib)

# Directorios que debe incluir, ademas de los estandar.
include_directories (${HELLO_SOURCE_DIR}/src/milib/)

# Directorios para el enlazador, ademas de los estandar
# Para este ejemplo no los necesitamos ya que la unica libreria
# adicional es 'milib' y ya sabe donde encontrarla pues el mismo
# la genera
#link_directories (aqui pones mas rutas separadas por espacios)

# Decirle que queremos un ejecutable llamado holaMundo
# y le decimos el source para que lo compile
add_executable (holaMundo src/hola.cpp)

# Tenemos una libreria adicional llamada milib, enlazarla
target_link_libraries (holaMundo milib)

El segundo CMakeLists sirve para compilar la libreria “milib” y es mucho mas corto:

holaMundoCMake/src/milib/CMakeLists.txt

# Agregar una libreria llamada milib generada poru un cpp
# se pueden agregar muchas librerias con varios add_library
# Se deben listar todos los archivos fuente
add_library (milib milib.cpp milib.h)

3. Hello World: Generar Makefiles con CMake y compilar

En linux el modo por default es generar Makefiles, así que entramos al directorio build que actualmente está vacío y generamos los Makefiles:

~/Documentos$ cd holaMundoCMake
~/Documentos/holaMundoCMake/$ cd build
~/Documentos/holaMundoCMake/build$ cmake ../
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ariel/Documentos/holaMundoCMake/build

Listo, ya estan los Makefiles generados, ahora a compilar con make:

~/Documentos/holaMundoCMake/build$ make
Scanning dependencies of target milib
[ 50%] Building CXX object src/milib/CMakeFiles/milib.dir/milib.o
Linking CXX static library ../../bin/libmilib.a
[ 50%] Built target milib
Scanning dependencies of target holaMundo
[100%] Building CXX object CMakeFiles/holaMundo.dir/src/hola.o
Linking CXX executable bin/holaMundo
[100%] Built target holaMundo
ariel@surfer:~/Documentos/eclipse/holaMundoCMake/build$ make clean
ariel@surfer:~/Documentos/eclipse/holaMundoCMake/build$ make
[ 50%] Building CXX object src/milib/CMakeFiles/milib.dir/milib.o
Linking CXX static library ../../bin/libmilib.a
[ 50%] Built target milib
[100%] Building CXX object CMakeFiles/holaMundo.dir/src/hola.o
Linking CXX executable bin/holaMundo
[100%] Built target holaMundo

En el directorio build/bin se encuentra el binario holaMundo,

~/Documentos/holaMundoCMake/build$ cd bin/
~/Documentos/holaMundoCMake/build$ ./holaMundo
Hola mundo desde main
[0] Hola Mundo, desde 'milib'
[1] Hola Mundo, desde 'milib'

¡Listo! ¿Quién dijo que habría que generar Makefiles a mano? Generar CMakeLists.txt es mucho mas fácil y mas intuitivo.