gnu-media » Gentoo

Arduino 017 en linux 64 bits

Sergio Esteban — Wed, 24 Feb 2010 04:12:55 +0000

Actualizando mi instalación de arduino, armé unas versiones para protoboard con la tarjeta ft232 que se consigue aquí en Colombia en Sigma Electrónica, (más adelante postearé los esquemas e imágenes).

Siguiendo con la actualización bajé la última versión de arduino para la fecha la 0017, e hice la instalación normal para gentoo amd64 que normalmente realizaba, como lo describen en la página oficial. Y finalmente reemplazé el avrdude y el librxtxSerial.so que trae el arduino que son compilados para 32bits, por los instalados en mi sistema.

Pero aquí comenzaron los problemas, al iniciar arduino e intentar bajar el sketch a la board aparecía el error :

avrdude: stk500_recv():

El stk500 es un tipo de programador para avr, que es el que “imita”, por así decirlo, el arduino. Así que lo primero que intenté fué tomar el .hex generado y con avrdude tratar de bajarlo desde la consola, pero devolvió el mismo error.

Al averiguar encontré aquí una frase bastante diciente:

But in any ways, DON’T USE AVRDUDE FROM YOUR DISTRO! because the one provided with the Arduino tools is a patched version.

Ajá! el avrdude que trae arduino viene parchado, así que no puede ser reemplazado como antes, revisado el asunto procedo a dejar el avrdude original y pruebo el programa y para mi sorpresa funcionó.

Pero no todo son alegrías, seguí revisando aquella página y encontré que podía haber un error en la monitorización del serial, así que hago una prueba y efectivamente el programa se cerró, revisando en la consola el reporte que generó fué el siguiente:

A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8385124803, pid=11115, tid=140202839185680
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode linux-amd64 )
# Problematic frame:
# C [librxtxSerial-2.1-7.so+0x8803] read_byte_array+0×43
#
# An error report file with more information is saved as:
# /opt/arduino-0017/hs_err_pid11115.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
./arduino: line 20: 11115 Abortado java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel processing.app.Base

bueno pues finalmente la solución la postean en la misma fuente: Bajar el paquete rxtx-2.2pre2-bins, desempaquetarlo y copiar los archivos RXTXcomm.jar y x86_64-unknown-linux-gnu/librxtxSerial.so dentro del directorio /lib del arduino reemplazando los archivos ya existentes.

Processing 1.0.9 + OpenGL + GSVideo 0.6 + GNU/Linux AMD64

Sergio Esteban — Thu, 31 Dec 2009 20:38:57 +0000

Holas, pues me armé un nuevo computador!!
Y aprovechando la nueva adquisición, actualizo la información sobre la instalación de Processing en distribuciones de 64bits, para el caso: Gentoo amd64 (aunque es válido para otras distribuciones).

Como recordarán para que funcionara processing en 64bits antiguamente teníamos que hacer una par de cosas, primero tocaba instalar jikes y reemplazar el que incluía processing con éste, esto ya no es necesario. Posteriormente tocaba reemplazar el java que venía incluído con uno nativo, cosa que permite usar el sun-jdk o el open-jdk, como lo mecioné anteriormente.

Ahora si descargas processing, que a la fecha su versión es la 1.0.9, verás que funciona perfectamente sin hacerle ningún cambio, lo cual es una muy buena noticia. Pero, como parte del combo yo instalo la librería GSVideo, verás que comienzan los problemas.

GSVIDEO 0.6

Al descargar e instalar la última versión (gsvideo-0.6-pre0.zip a la fecha), verás que processing nos vota un error del tipo:

Exception in thread “Animation Thread” java.lang.UnsatisfiedLinkError: Unable to load library ‘gstreamer-0.10′: /usr/lib/libgstreamer-0.10.so.0.22.0: wrong ELF class: ELFCLASS64

Como bien lo dice (o podrán intuir) el problema radica en la arquitectura de 64bits. Pero ¿porqué presenta este problema si GSVideo es una librería multiplataforma?, la respuesta es simple, en realidad el problema está en que gsvideo requiere de gstreamer instalado, es decir nativo, de 64bits, y cuando es llamado por processing lo procesa dentro de un java de 32bits lo cual genera la incompatibilidad.

Para solucionarlo volvemos a la opción de instalar un jdk y reemplazar el existente en processing por este. Para esto podemos seguir las instrucciones que escribí aquí. Tengan en cuenta que aunque las instrucciones son para el open-jdk, también son válidas para el sun-jdk si es de su preferencia.

Con esto volvemos a ejecutar nuestros ejemplos de GSVideo en processing y ya no tendremos ningún problema.

OpenGL

Podríamos pensar que ya está listo nuestro processing para trabajar, pero no es así, si volvemos a probar todo encontraremos un nuevo problema: lo que antes probamos con la librería OpenGL ya no funciona, ¿porqué?.

Si nos fijamos el error que ahora vota es muy similar al anterior de GSVideo:

Exception in thread “Animation Thread” java.lang.UnsatisfiedLinkError: /opt/processing-1.0.9/libraries/opengl/library/libgluegen-rt.so: /opt/processing-1.0.9/libraries/opengl/library/libgluegen-rt.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)

Como podremos observar es un error nuevamente de arquitectura, pero esta vez nos dice “wrong ELF class: ELFCLASS32″, es decir, que la librería que encontró (libgluegen-rt.so), es de 32 bits y que eso es incorrecto. Pues si analizamos el cambio que hicimos nos daremos cuenta fácilmente del problema, al reemplazar el java que traía processing que era de 32 bits por el que nosostros instalamos que es de 64bits, generó la incompatibilidad con el opengl de 32bits que traía processing.

Entonces ¿cómo lo solucionamos?, pues de un modo similar al caso anterior, instalamos el paquete de opengl para java que es llamado jogl, y reemplazamos los archivos de processing/libraries/opengl/library/* con estos.

Para el caso de gentoo el paquete jogl se encuentra en el java-overlay, para las demás distribuciones no sabría decirles si existe un paquete precompilado, pero googleando se darán cuenta o en último caso está la posibilidad de compilarlo desde las fuentes.

Yo manejo los overlays con layman, así que estos fueron mis pasos:
layman -a java-overlay echo "dev-java/jogl ~amd64" >> /etc/portage/package.keywords echo "dev-java/gluegen ~amd64" >> /etc/portage/package.keywords emerge -av jogl

Con esto ya tengo instalado jogl en mis sistema, lo cual generó los archivos:

/usr/lib64/gluegen/libgluegen-rt.so
/usr/share/gluegen/lib/gluegen.jar
/usr/share/gluegen/lib/gluegen-rt.jar
para dev-java/gluegen, que instaló como dependencia, y:

/usr/lib64/jogl/libjogl_awt.so
/usr/lib64/jogl/libjogl.so
/usr/share/jogl/lib/jogl.jar
para dev-java/jogl.

Ahora lo único que tendremos que hacer es copiar estos archivos a processing-1.0.9/libraries/opengl/library/ reemplazando los que se encuentren allí.

Con esto ya deberíamos tener funcionando processing completo sobre amd64.

Instalando MySQL-workbench en linux

Sergio Esteban — Thu, 27 Nov 2008 04:52:00 +0000

Actualización:
La página de mysql developer ya ofrece los paquetes estables para varias plataformas como Fedora, Ubuntu, Suse, Red Hat, o en su defecto las fuentes para compilarlo, ya no es necesario descargar versiones alfa, y en la mayoría de los casos ni siquiera compilarlo.

http://dev.mysql.com/downloads/workbench/

MySQL workbench es un programa multiplataforma, para el modelado visual de bases de datos mysql. Se le denomina como el sucesor del proyecto DBDesigner4.

A continuación describo los pasos que hize para lograr la instalación sobre un sistema Sabayon Linux 3.5 i386.

Bien, partí descargando las fuentes de la sección de descargas de la página oficial, versión que a la fecha es la 5.0.27, descomprimiendo el paquete y leyendo el README y el INSTALL (algo que siempre se debe hacer), y de acuerdo a eso empezé desde consola.

./autogen.sh

el primer problema que marcó fué acerca del paquete google-ctemplate, como no estaba en el arbol portage lo descargé de la página http://code.google.com/p/google-ctemplate/ y procedí del mismo modo, LEER EL README Y EL INSTALL, a lo cual el procedimiento era de lo más normal, y todo sin problemas.

./configure
make
make install

Luego de intentar nuevamente con el script auntogen.sh de mysql-workbench, tuve el segundo error, esta vez con el paquete lua5.1, para conseguir instalarlo desde portage antes tuve que actualizar libtool

emerge -u libtool
emerge -av lua

Pero para mi sorpresa luego de aparecer un lindo mensajito que indicaba estar listo para el make, cuando lo compilé produjo un error que no logré relacionar con ningún paquete, pues he aquí donde hallé la solución: http://dev.mysql.com/workbench/?p=158

Está explicada la instalación para Ubuntu y supongo funciona con debian y derivados, con un repositorio para instalarlo desde deb’s. En la parte de abajo está lo que buscaba, para usuarios no-ubuntu (palabras casi textuales), se puede intentar compilar desde las fuentes (es lo que estaba haciéndo) , pero recomiendan descargar el siguiente paquete:

ftp://ftp.mysql.com/pub/mysql/download/gui-tools/mysql-workbench-5.1.3-alpha.tar.gz

Como pueden ver es una versión alfa, pero no tiene problemas para compilarlo (solo tuve que instalar libzip), y según comentarios funciona también en distros amd64., el binario lo genera por defecto en /usr/local/bin pero se le puede cambiar especificándole al autogen.

Para compilarlo en distribuciones debian o derivados (sin usar los paquetes deb que mencioné antes) las instrucciones de la construcción en linux funcionan bien.

Openframeworks 0.05 + codeblocks

Sergio Esteban — Sat, 12 Jul 2008 03:04:00 +0000

made with openFrameworks from openFrameworks on Vimeo.

Para los que no conocen OF (Openframeworks), es una librería para C++ para facilitar la creación de aplicaciones multimediales, con una sintaxis similar a processing, diseñada para trabajar con openGL , rtAudio, freeType, freeImage, y quicktime.

Como es una librería de C++, indagué primero por las IDE’s recomendadas entre las que se encuentran Eclipse y Codeblocks, ya conocía la primera, así que prové codeblocks y me pareció una excelente opción, es una IDE completa y liviana, así que dejaremos el eclipse para java.

Para probarlo simplemente se descarga de la página, se descomprime y ya, los ejemplos vienen con el proyecto en codeblocks así que simplemente abrimos un proyecto y ya tenemos todo importado con la jerarquía que necesitamos para trabajar openframeworks.

Para poder ejecutar las aplicaciones deberíamos tener instalado:
freeglut3-dev libasound2-dev libxmu-dev libxxf86vm-dev g++ libgl1-mesa-dev libglu1-mesa-dev libraw1394-dev
Para mi caso en gentoo instalé media-libs/glut, en vez de freeglut que me dió problemas.

A la hora de provarlo hasta el momento no ha funcionado en 64bits, me bota el error

Linking console executable: bin/imageLoaderExample_debug
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible ../../../libs/fmodex/lib/libfmodex.so when searching for -lfmodex
../../../libs/ffmpeg/libavcodec/libavcodec.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings

Leyendo tenía dos opciones la jaula de 32 bits o construir openframeworks con las versiones de 64bits de la librerías de las que depende. Como tengo una jaula de 32 bits primero probé ahí.

En la jaula de 32bits, inicialmente botaba errores de compilación, chequeándo en el foro encontré que el problema radica en que codeblocks cuando la salida del gcc no está en inglés cree que todos los warnings son errores, la respuesta la encontré aquí, simplemente ejecutamos export LC_ALL=C y en la misma consola llamamos a codeblocks.

Por fin openframeworks trabajando!!!!

Ahora vamos a tratar la segunda opción, trabajar con las librerías de 64 bits.

Para esto vamos a nuestro directorio de descarga de openframework desde la consola, e ingresamos a libs/, empezaremos en orden así que vamos a ffmpeg/libavcodec/ allí encontraremos 4 archivos que deberemos borrar, mover o renombrar, y reemplazarlos por los del sistema (naturalmente debes tener instalado ffmpeg), yo decidí moverlo y luego hacer un enlace simbólico a la ruta que encontré en el sistema gracias al comando locate.

ln -s /usr/include/ffmpeg/avcodec.h ./
ln -s /usr/lib64/libavcodec.a ./
ln -s /usr/lib64/libavcodec.so ./
ln -s /usr/lib64/libavcodec.so.51 ./
recuerden estar parados en of-path/libs/ffmpeg/libavcodec/

Nos devolvemos a libs/ffmpeg y seguimos de la misma manera con las otras dos carpetas libavformat y libavutil.

oceano libavcodec # cd ..
oceano ffmpeg # cd libavformat/
oceano libavformat # ln -s /usr/include/ffmpeg/avformat.h ./
oceano libavformat # ln -s /usr/lib64/libavformat.so.51 ./
oceano libavformat # ln -s /usr/lib64/libavformat.so ./
oceano libavformat # ln -s /usr/lib64/libavformat.a ./
oceano libavformat # cd ..
oceano ffmpeg # cd libavutil/
oceano libavutil # ln -s /usr/lib64/libavutil.a ./
oceano libavutil # ln -s /usr/lib64/libavutil.so ./
oceano libavutil # ln -s /usr/lib64/libavutil.so.49 ./
oceano libavutil # ln -s /usr/include/ffmpeg/avutil.h ./
oceano libavutil # ln -s /usr/include/ffmpeg/common.h ./
oceano libavutil # ln -s /usr/include/ffmpeg/integer.h ./
oceano libavutil # ln -s /usr/include/ffmpeg/intfloat_readwrite.h ./
oceano libavutil # ln -s /usr/include/ffmpeg/mathematics.h ./
oceano libavutil # ln -s /usr/include/ffmpeg/rational.h ./
oceano libavutil # ln -s /usr/include/ffmpeg/log.h ./

Terminamos ffmpeg, seguimos con fmodex, para esto necesitamos instalado fmod, y repetimos el procedimiento:

oceano libavutil # cd ..
oceano ffmpeg # cd ..
oceano libs # cd fmodex/inc/
oceano inc # ln -s /usr/include/fmodex/fmod_codec.h
oceano inc # ln -s /usr/include/fmodex/fmod_dsp.h
oceano inc # ln -s /usr/include/fmodex/fmod_errors.h
oceano inc # ln -s /usr/include/fmodex/fmod.h
oceano inc # ln -s /usr/include/fmodex/fmod.hpp
oceano inc # ln -s /usr/include/fmodex/fmod_output.h
oceano inc # cd ..
oceano fmodex # cd lib/
oceano lib # ln -s /usr/lib64/libfmodexp.so ./
oceano lib # ln -s /usr/lib64/libfmodexp.so.4.11.03 ./libfmodexp.so.4.08.00
oceano lib # ln -s /usr/lib64/libfmodex.so ./
oceano lib # ln -s /usr/lib64/libfmodex.so.4.11.03 ./libfmodex.so.4.08.00

en la carpeta plugins todos los que encontrarás en el sistema terminan en 64 así que hay que renombrarlos, y no encontré los archivos codec_flac, codec_vag y dsp_lowpass_simple en el sistema así que le dejé los originales.

oceano lib # cd ..
oceano fmodex # cd plugins/
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_aiff64.so ./codec_aiff.sooceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_cdda64.so ./codec_cdda.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_dls64.so ./codec_dls.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_fsb.so ./
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_it64.so ./codec_it.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_midi64.so ./codec_midi.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_mod64.so ./codec_mod.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_mpeg64.so ./codec_mpeg.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_oggvorbis64.so ./codec_oggvorbis.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_playlist64.so ./codec_playlist.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_raw64.so ./codec_raw.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_s3m64.so ./codec_s3m.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_sf264.so ./codec_sf2.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_tag64.so ./codec_tag.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_wav64.so ./codec_wav.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/codec_xm64.so ./codec_xm.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_chorus64.so ./dsp_chorus.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_compressor64.so ./dsp_compressor.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_distortion64.so ./dsp_distortion.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_echo64.so ./dsp_echo.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_flange64.so ./dsp_flange.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_highpass64.so ./dsp_highpass.so
oceano plugins # ln -s /usr
/lib64/fmodex/plugins/dsp_itecho64.so ./dsp_itecho.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_lowpass264.so ./dsp_lowpass2.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_lowpass64.so ./dsp_lowpass.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_normalize64.so ./dsp_normalize.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_oscillator64.so ./dsp_oscillator.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_parameq64.so ./dsp_parameq.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_pitchshift64.so ./dsp_pitchshift.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_reverb64.so ./dsp_reverb.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/dsp_sfxreverb64.so ./dsp_sfxreverb.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/output_alsa64.so ./output_alsa.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/output_esd64.so ./output_esd.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/output_nosound64.so ./output_nosound.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/output_oss64.so ./output_oss.so
oceano plugins # ln -s /usr/lib64/fmodex/plugins/output_wavwriter64.so ./output_wavwriter.so

el proceso se repite sucesivamente para el resto de librerías.

Agrego: al tiempo que estaba haciéndo esto encontré que arturo y muchos otros ya lo habían hecho, pero arturo tuvo la amabilidad de subirlo y compartirlo listo para usar. Les dejo el link de descarga y en enlace al post donde encontré el enlace.

descarga of_64bits

jahshaka en gentoo

Sergio Esteban — Thu, 03 Jan 2008 02:15:00 +0000

Aquí hay un artículo breve sencillo y fácil, con los links a los ebuilds y las explicaciones de cómo instalar jahshaka sobre gentoo.

Además ésta misma página nos trae mucha información sobre software de linux para manipulación de sonido y video, creo que está enfocada a vj’s pero igual es de mucha utilidad, y aunque esté en inglés es muy sencillo de entender.

Gracias tikiwiki!!

Instalación de pd-extended en Gentoo

Sergio Esteban — Wed, 02 Jan 2008 20:52:00 +0000

Editado: en la página de pd-overlays se encuentran todos los paquetes incluídos plugins y se baja de una manera más fácil ver aquí.

Gracias los ebuilds ofrecidos en la página:
http://gentoo-overlays.zugaina.org/
Nuestra intalación de pd o pd-extended es muy simple, solo descarga el ebuild de aquí y agrégalo al portdir.

Para eso hacemos lo siguiente creamos el directorio /usr/local/portage (en caso que no exista).

#mkdir /usr/local/portage

luego creamos los directorios media-sound y pd-extended (o pd)

#mkdir /usr/local/portage/media-sound
#mkdir /usr/local/portage/media-sound/pd-extended

mueva el archivo que descargó en el primer paso a este directorio

#mv /home/usuario/Desktop/pd-extended-999.ebuild /usr/local/portage/media-sound/pd-extended/

luego construya el ebuild

#ebuild /usr/local/portage/media-sound/pd-extended/pd-extended-9999.ebuild digest

y agrege este nuevo directorio al archivo make.conf

#nano /etc/make.conf

agrege la siguiente línea
PORTDIR_OVERLAY=”/usr/local/portage”

ahora permita la instalación del paquete ya que está enmascarado

# echo media-sound/pd-extended ~* * >> /etc/portage/package.keywords

finalmente instale

#emerge -va pd-extended

PD: los mismos pasos son para el pd solo baje el ebuild correpondiente, sobre amd64 solo me ha funcionado el pd, el extended bota errores en la compilacion.

instalando arduino serial en gentoo amd64

Sergio Esteban — Wed, 26 Dec 2007 05:41:00 +0000

Para empezar las instrucciones de la página oficial van muy bien.

Ahora echémosle un vistazo:

primero instalar las dependencias necesarias: blackdown-jre, crossdev, jikes, uisp, rxtx.

Entonces la máquina virtual libre (blackdown-jre) para la interfaz del software del arduino, crossdev nos ayudará a compilar el paquete avr para travajar con los chips Atmega, jikes es el compilador de java libre, uisp es la utilidad de programación de Atmel y rxtx administra los puertos serial.

Lo primero es agregar el paquete uisp enmascarado por ~amd64 al package.keywords para poder instalarlo

#echo dev-embedded/uisp ~amd64 >> /etc/portage/package.keywords

Proceder a instalar las dependencias

#emerge -av –noreplace blackdown-jre crossdev jikes uisp rxtx

Una vez finalizado agregar el o los usuarios al grupo uucp, para que tengan acceso al puerto serial, si ya a trabajado con piKdev u otra interfaz de programación de chips por puerto serial o paralelo esto no será necesario

#usermod -aG uucp nombreUsuario

o bien editar el archivo /etc/group y agregar los usuarios correspondientes al grupo uucp.

Segundo compilar el paquete avr

#crossdev -t avr -s4

Este es un proceso lento que actualiza ciertos paquetes desenmascarándolos (puedes revisar el package.keywords después de esto), puedes tomar unas onces mientras termina.

Y tercero hacer los links simbólicos

Ahora si, bajar el programa, descomprimirlo y hacer los links simbólicos a las dependencias que acabamos de instalar.

como siempre recomiendo poner el paquete descomprimido en /usr/local, una vez ahi crear los links

#ln -s /usr/lib/binutils/avr/2.XX/ldscripts/ /usr/local/arduino-XXX/ldscripts

la carpeta ldscripts dentro de arduino no debe existir.

Los siguientes pasos son para usar el conversor USB a serial, que en mi caso no uso ya que tengo puerto serial, y la explicación del arduino USB, pero tampoco lo voy a explicar ya que uso el serial v2. Pero es importante aclarar que el kernel debe tener soporte para estos puertos, yo siempre activo el soporte tanto de serial como de paralelo.

Hasta quí las instrucciones de la página oficial, pero si lo intentas ejecutar ahora te darás cuenta que no corre y vota
Exception in thread “main” java.lang.NoClassDefFoundError: processing/app/Base

Pues vamos a solucionar esto con mas links simbólicos.
Primero borra el archivo /usr/local/arduino_XXX/tools/uisp y reemplázalo por un link simbólico a /usr/bin/uisp

#rm /usr/local/arduino_XXX/tools/uisp
#ln -s /usr/bin/uisp /usr/local/arduino_XXX/tools/

lo mismo para la librería rxtx

#rm /usr/local/arduino_XXX/lib/librxtxSerial.so
#ln -s /usr/lib64/rxtx-2/librxtxSerial.so /usr/local/arduino_XXX/lib/

Ahora el paquete rxtx y java. Modifique el script de arranque /usr/local/arduino_XXX/arduino, ingresándole los paths de los archivos jikes y RXTXcomm.jar, librerías rxtx y librerias y ejecutables de la máquina virtual que esté ejecutándo, le debería quedar más o manos así:

#!/bin/sh
CLASSPATH=/opt/blackdown-jdk-1.4.2.03/jre/bin:/opt/blackdown-jdk-1.4.2.03/jre/lib/rt.jar:
java/lib/rt.jar:lib:lib/build:lib/pde.jar:lib/core.jar:lib/antlr.jar:lib/oro.jar:
lib/registry.jar:lib/mrj.jar:lib/RXTXcomm.jar:usr/lib/arduino
export CLASSPATH

# put the directory where this file lives in the front of the path, because
# that directory also contains jikes, which we will need at runtime.
PATH=`pwd`/tools:/usr/bin:${PATH}
export PATH

# put the directory with the native RXTX libs in the library path
LD_LIBRARY_PATH=`pwd`/lib:/usr/share/rxtx-2/lib:/usr/lib64/rxtx-2:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH

export DIRAVR=/usr/bin

java processing.app.Base

Lo que está en negrita es lo que le agregé. Para ejecutar arduino es de aclarar que no se puede ejecutar de la siguiente manera
$ /usr/local/arduino-XXX/arduino
sino
$ cd /usr/local/arduino_XXX && ./arduino

téngalo presente a la hora e agregarlo al menú o elaborar un sript de arranque.

Nota: Esto fué provado con arduino-0007, espero funcione para las demás versiones.

Processing en Linux amd64

Sergio Esteban — Tue, 25 Dec 2007 22:24:00 +0000

Para los que han usado processing, sabrán que su instalación es muy sencilla, basta con descargar el programa de la página del proyecto, descomprimirlo y ejecutar el archivo processing.sh (generalmente).

Pero qué sucede si usamos una distribución de 64bits?, vemos que el programa no corre ya que usa binarios de 32, pero no hay que preocuparse la solución es muy sencilla.

Primero descomprimimos la carpeta processing-XXX.tar.gz, luego yo prefiero moverla a /usr/local que es donde normalmente se instalan los programas que funcionan “independientemente” del sistema (es decir sin usar paquetes del sistema, sin dependencias), y la cual tiene permisos de ejecución para todos los usuarios. Esto evita que cualquier usuario pueda borrar o modificar accidentalmente los ficheros del programa.

$ tar xvzf ~/Desktop/processing-XXX.tar.gz
$ rm ~/Desktop/processing-XXX.tar.gz

lo siguiente como root o con sudo
#mv ~/Desktop/processing-XXX /usr/local/

digo Desktop porque es generalmente donde se descargan, pero cámbialo por la dirección donde lo descargaste y descomprimiste, y las XXX representan la versión

Seguido eliminamos el fichero del problema, que no es más que el compilador jikes

#rm /usr/local/processing-XXX/jikes

instalamos jikes con nuestro administrador de paquetes, llámese aptitude, synaptic, yast, emerge, etc…

#emerge jikes

y finalmente creamos un link hacia la carpeta de processing

#cd /usr/local/processing-XXX
#ln -s /usr/bin/jikes ./

y listo!!!
ya tenemos nuestro processing corriendo en distros x86_64!!!

puébalo como usuario con

$ /usr/local/processing-XXX/processing.sh
si devuelve command no found
$ chmod 777 /usr/local/processing-XXX/processing.sh

ahora solo créale una entrada en tu menú o hazle un acceso directo desde tu escritorio, o si lo prefieres accede siempre desde el terminal.

Nota: Esto fué provado con processing 0125 y 0135.