Programar para Dingux

[enkonsierto]

Programar nativamente para dingoo creo que es más dificil y sale más a cuenta hacerlo en dingux directamente, verdad?
Si esto es así, entonces para programar en dingux hay un sdk específico? Vale con hacerlo como si fuera para linux y después compilar con otro compilador?

Saludos.

[^MiSaTo^]

Mira, a mi también me interesa el hilo así que me suscribo!

[otto_xd]

Que se pase a600 para ilustrarnos, pero creo que se programa igual que para linux, pero el toolchain?? es especifico de dingoo.

Lo que ya no se es si hay sdl para programar juegos o portar cositas.

Saludos

[Kiwiz]

creo que booboo publicó como hay que compilar los programas (una línea de comandos al final del programa, creo). Así que supongo que hay que programar para linux y luego poner esa sentencia. Pero vamos, no me hagas mucho caso.




Lo que ya no se es si hay sdl para programar juegos o portar cositas.


Las sdl no están portadas a Dingoo no ??

[^MiSaTo^]

http://code.google.com/p/dingoo-linux/downloads/list
Ahí he encontrado la toolchain. No he probado ni a bajarla porque ahora mismo no puedo, pero lo he sacado de la web "oficial" de dingux. (o eso parecia) xD

[otto_xd]

Por lo que he leido en la pagina de booboo si que trae sdl, asi que un punto mas a su favor.

[Gocho]

Es más fácil portar algo que ya existe en Linux a Dingux que programarlo desde 0 o portarlo al SDK de Dingoo, simplemente.

[enkonsierto]

Es más fácil portar algo que ya existe en Linux a Dingux que programarlo desde 0 o portarlo al SDK de Dingoo, simplemente.
Y cuando llueve caen gotas desde el cielo, no te digo...

[^MiSaTo^]

No te digo na, y te lo digo to!

[Uncanny]

http://code.google.com/p/dingoo-linux/downloads/list
Ahí he encontrado la toolchain. No he probado ni a bajarla porque ahora mismo no puedo, pero lo he sacado de la web "oficial" de dingux. (o eso parecia) xDExacto, es el que se está usando ahora mismo (solo para desarrollar desde Linux), aunque cada uno puede construirse la suya propia con Buildroot, lo ideal es usar esta que ha sido preconstuida por booboo y va actualizándolo cuando le aplica algún parche o para añadir alguna biblioteca extra, pues es con la que el mismo construye el sistema base GNU junto al kernel Linux de Dingux, con lo que las bibliotecas dinámicas del sistema (*.so) son las mismas y al incluirlas el sistema base de Dingux permite que podamos compilar y luego enlazar dinámicamente nuestros programas, con el consiguiente ahorro en espacio y en memoria que si lo hiciéramos estáticamente (con se hace por lo general con las aplicaciones para GP2X por ejemplo), aunque por supuesto se puede enlazar estáticamente si se desea.

Básicamente se puede programar igual que para GP2X, es decir, con C o C++ y la librería SDL por ejemplo, en el toolchain, que es para la plataforma MIPSel (http://www.debian.org/ports/mips/) (MIPS Little Endian, puesto que el procesador de Dingoo es de arquitectura MIPS), está incluida, y ha sido construida, como he dicho antes, usando Buildroot (http://buildroot.uclibc.org/), en la uClibc en lugar de Glibc (siendo la primera más ideal para sistemas embebidos), que es la diferencia principal en la construcción base del toolchain con respecto a la que se usa en la GP2X, por compararla con algo conocido, pero a la hora de programar esta diferencia no influye en nada al programador.

La instalación del toolchain es sencilla, prácticamente es lo mismo que en GP2X, solo que en vez de un toolchain para plataforma ARM es para MIPSel, podemos descomprimirla por ejemplo en /opt por y ya es lo cuestión de añadir las rutas a la variable de entorno $PATH y/o crear/modificar un Makefile cuando se trata de programas grandes o de un port de alguno existente.

Lo bueno de la Dingoo con Dingux es que booboo ha incluido soporte para USBNet via CDC Ethernet, es decir, que al conectar por USB la Dingoo esta crea una conexión por USB (como en la GP2X F100) y tiene activados varios servicios, en especial Telnet, con lo que facilita mucho las cosas al programar para lanzar aplicaciones sin necesidad de usar alguna aplicación de tipo menú (como dmenu, a la cual hay que editar su configuración para añadir la aplicación) o ver la salida de la linea de comandos al lanzar un programa.

Si alguien cree que le puede ser de utilidad puedo poner una especie de mini-tuto para tener el toolchain listo para desarrollar o portar aplicaciones, pero vamos, es sencillo y más para quienes hayáis programado con GP2X.

[Nathrezim]

Aqui hay un tutorial para instalar la plataforma para compilar para el MIPS que lleva, aunque está para Visual 2008, y por tanto para windows.

http://a320.freeforums.org/s2dsdk-installation-guide-t299.html

[^MiSaTo^]

...TOCHO...
Te tengo mucho aprecio Uncanny, pero lo de Uncannypedia es por algo xDD
Vaya tocho macho xDDD

[Uncanny]

Aqui hay un tutorial para instalar la plataforma para compilar para el MIPS que lleva, aunque está para Visual 2008, y por tanto para windows.

http://a320.freeforums.org/s2dsdk-installation-guide-t299.htmlEl "problema" es que ese tuto al que referencias está orientado a usar el firmware oficial y no para Dingux :)
Te tengo mucho aprecio Uncanny, pero lo de Uncannypedia es por algo xDD
Vaya tocho macho xDDDY eso que he intentado resumirlo lo máximo posible xDDD

[dj syto]

Es más fácil portar algo que ya existe en Linux a Dingux que programarlo desde 0 o portarlo al SDK de Dingoo, simplemente.

EXELENTE HAPORTE TE PASASTE fin

[enkonsierto]

Si alguien cree que le puede ser de utilidad puedo poner una especie de mini-tuto para tener el toolchain listo para desarrollar o portar aplicaciones, pero vamos, es sencillo y más para quienes hayáis programado con GP2X.
A mi me parece que me sería de utilidad. No me importa win o lin.

[Ruxy]

A mi tambien me gustaria que explicaseis como dejarlo listo para programar, y ademas, si alguien se anima a explicar, o mejor, dejar unos ejemplos practicos de como dibujar en pantalla, y cosas similares, que como mas se aprende es mirando ejemplo hechos (se que hay algunos, pero creo que no son para programar para dingux, creo que son para el menu de la maquina).

Ah, y si la explicación es en linux mejor , así de paso se puede ir trasteando con linux.

[Kiwiz]

Ruxy, prueba a mirarte ejemplos de GP2X, ya que se programa de forma parecida.

En cuanto a lo del tutorial del toolchain a mi me interesa en win.

Saludos.

[Uncanny]

Bien, lo voy a enfocar en el desarrollo desde una distro de Linux porque el toolchain está construido para Linux, aunque si usáis Windows podéis optar por instalar andLinux (http://www.andlinux.org/), una distro cuyo kernel Linux, coLinux, ha sido portado a Win32 para funcionar junto con Windows, como un servicio o aplicación del mismo (para entenderlo mejor podeis ver el video de esta (http://www.tinkernut.com/archives/45) página), eso si, no puedo garantizar de que de esta forma funcione todo perfectamente puesto que no tiendo a usar mucho Windows.

Intentaré ser lo más directo y breve posible, esto le será más facil de entender a quien tenga nociones de programación en Linux, especialmente si ha desarrollado algo para GP2X, a quienes no puede les cueste más entender algún paso, si es así podría desarrollar un tutorial ya sea por aquí o en un documento tipo PDF que sea más elaborado y detallado que este con algunos conceptos más. Al grano, empecemos:

Mini-Tutorial para empezar a portar/desarrollar aplicaciones y/o juegos para Dingux.

Para empezar lo que debemos hacer es descargar (http://code.google.com/p/dingoo-linux/downloads/list) el paquete con el toolchain y las bibliotecas de desarrollo (incluida SDL) para Dingux. En el momento de escribir este documento se encuentra disponible esta versión del toolchain dingux-toolchain-20090728.tar.bz2.

Abrimos una sesión del emulador terminal que prefiramos y procedemos a su descarga, en nuestro /home de usuario mismo:


wget -c http://dingoo-linux.googlecode.com/files/dingux-toolchain-20090728.tar.bz2

Una vez descargado lo descomprimimos en /opt:


sudo tar xvjf dingux-toolchain-20090726.tar.bz2 -C /opt

Si queremos poder modificar el toolchain (p.e: compilando y añadiendo más bibliotecas a posteriori) sin necesidad de anteponer sudo o autentificarse como root, podemos darle permisos a ese directorio que acabamos de descomprimir para que nuestro usuario actual sea el dueño de dicho directorio y pueda realizar modificaciones sobre él:


sudo chown -R $USER /opt/mipsel-linux-uclibc/

Ahora añadimos el directorio de binarios que contienen las herramientas del toolchain (compilador, ensamblador, enlazador, etc, toda la pesca para desarrollar aplicaciones) a la variable de entorno PATH:


export DINGUX_TOOLCHAIN=/opt/mipsel-linux-uclibc
export DINGUX_TOOLCHAIN_PREFIX=$DINGUX_TOOLCHAIN/usr
export PATH=$PATH:$DINGUX_TOOLCHAIN/usr/bin

Hemos creado una variable de entorno llamada $DINGUX_TOOLCHAIN que contiene la ruta al directorio /bin del toolchain y luego hemos añadido dicha variable de entorno a la de $PATH, el objetivo de todo esto es tener accesibles, desde linea de comandos y en la sesión actual del emulador de terminal, las herramientas del toolchain sin necesidad de usar toda la ruta. Podemos comprobar que funciona de esta forma:


mipsel-linux-gcc -v

Debemos ver que nos devuelve la salida del mismo, algo así:


Using built-in specs.
Target: mipsel-linux-uclibc
Configured with:
[...]
Thread model: posix
gcc version 4.3.3 (GCC)

El inconveniente de este método que es siempre tendremos que escribir estos “export” cada vez que quisiéramos tener disponibles las herramientas del toolchain directamente sin necesidad de usar las rutas absolutas. Una forma sencilla de solventarlo es hacer que estas variables se inicialicen siempre que iniciemos nuestra sesión de usuario (en este caso del actual) de esta forma:


echo '' >> ~/.profile
echo 'export DINGUX_TOOLCHAIN="/opt/mipsel-linux-uclibc' >> ~/.profile
echo 'export DINGUX_TOOLCHAIN_PREFIX=$DINGUX_TOOLCHAIN/usr' >> ~/.profile
echo 'export PATH=$PATH:$DINGUX_TOOLCHAIN/usr/bin' >> ~/.profile
source ~/.profile

De esta forma podemos "compilar" nuestros programas en código fuente desde la linea de comandos, imaginando que tenemos el típico "Hola Mundo" en un programa simple en C (ni SDL ni nada, con un simple printf()), llamado hola_mundo.c, compilarlo sería tan sencillo como:


mipsel-linux-gcc -o hola_mundo.dge hola_mundo.c

La extensión ".dge" es totalmente opcional, como si ponemos cualquier otra o ninguna, Dingux está basado en Linux y este no distingue un archivo por su extensión como en Windows, pero puede sernos de utilidad para distinguirlo nosotros como ejecutable para Dingux. Si hacemos un file del archivo hola_mundo.dge veremos que es correcto:


file hola_mundo.dge
hola_mundo.dge: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Ya solo queda copiar este archivo en nuestra miniSD (por ejemplo en /local/bin) después de hacerlo la insertamos en nuestra Dingoo y arrancamos Dingux. Una vez que Dingux ha arrancado, conectamos el cable USB a la Dingoo, con lo que se debería iniciar una conexión de USBNet por la interfaz usb0 o similar (un ifconfig -a nos lo mostrará), solo tenemos que conectarnos a la IP de la Dingoo por Telnet:


telnet 10.1.0.2
cd /usr/local/bin/
./hola_mundo.dge

Debería verse un "Hola Mundo" en la salida del programa desde el emulador de terminal, lo que indica que todo funciona correctamente.

Por último, un par de "tips" o consejos a tener en cuanta a la hora de compilar programas, ya sean nuestros o un port de algún otro existente. Lo primero, cuando hacemos uso de alguna biblioteca en nuestros programas (como SDL) es necesario indicarle las rutas, tanto de cabeceras (usando la opción -I/ruta/a/include) como de las bibliotecas (con -L/ruta/a/lib), ya sea el enlazado dinámico o estático, listándolas por su nombre (todas empiezan por lib es decir libNombre y se usa la opción -lNombreBiblioteca sin el "lib" para referirse a ellas, p.e: libNombre.so / libNombre.a -> -lNombre). Es importante para el enlazador el orden en el que dispongan (ya sea en la linea de comandos o en un Makefile) ya que en el momento de resolver simbolos habrá dependencias entre algunas de ellas (por ejemplo, libSDL_image depende libjpeg y libpng, y ante todo depende depende libSDL -> -lSDL -lSDL_image -ljpeg -lpng) y si están incorrectamente dispuestas o falta alguna puede dar un error de enlazado aunque todo se haya compilado y ensamblado correctamente. Un ejemplo de un posible programa en SDL, llamemosle Hola_SDL.c:


mipsel-linux-gcc Hola_SDL.c \
-o Hola_SDL.dge \
-I$DINGUX_TOOLCHAIN_PREFIX/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT \
-L$DINGUX_TOOLCHAIN_PREFIX/lib -lSDL -lpthread

Hay otro consejo a tener en cuenta, en especial cuando queremos portar aplicaciones o juegos cuyo código fuente está organizado con las GNU Autotools (Autoconf, Automake, etc), que son los típicos donde no hay un Makefile directamente, sino que se genera el Makefile una vez ejecutamos un script llamado "configure". Para estos programas con el código fuente organizado con autotools hay que pasarle un parámetro que es determinante cuando realizamos una compilación cruzada, "--host", que le indicará para que arquitectura y sistema operativo se va construir el programa, así como el prefijo para GCC y Binutils debe usar (el de nuestro toolchain, mipsel-linux-*) y ciertas variables de entorno que se deberían anteponer para generar un Makefile lo más correcto posible para compilarlo para Dingux:


CFLAGS="-I$DINGUX_TOOLCHAIN/usr/include" \
CXXFLAGS="-I$DINGUX_TOOLCHAIN/usr/include" \
LDFLAGS="-L$DINGUX_TOOLCHAIN/usr/lib" \
CC="mipsel-linux-gcc" \
CXX="mipsel-linux-g++" \
./configure --host=mipsel-linux --prefix=$USER/tu_programa

Ya solo es cuestión de hacer un make y si todo es correcto obtendremos el archivo binario y ejecutable para Dingux, sería solo cuestión de copiarlo a la miniSD donde prefiramos (junto con los archivos necesarios, datos como imagenes, sonidos, etc.). Si queremos, además, podemos realizar un make install, esto haría que todo lo necesario se copiase a la una ruta que hemos puesto al parámetro "--prefix" (en el ejemplo, en tu home de usuario, en un directorio llamado tu_programa), así, con copiar dicho directorio en la miniSD y lanzándolo en Dingux (ya sea por el dmenu o por Telnet) debería funcionar correctamente.

Bueno, creo que como base es suficiente para empezar, no he tocado temas como crear Makefiles o detalles más complejos porque no es el objeto de este mini-tuto, como he dicho podría pensar en hacer un documento más completo que trate temas como estos, pero me llevará algo de tiempo. Si teneis alguna duda o veis algún fallo decidlo por aquí :)

[balrogsoft]

Muy util la guia, muchas gracias. Ya tengo instalado el toolchain, pero me encuentro con una dependencia, no encuentra, glibc 2.8, estoy intentando compilar el UAE4ALL ya he modificado el Makefile, creo que correctamente, y me da este error con el primer fichero:

/opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus: /lib32/libc.so.6: version `GLIBC_2.8' not found (required by /opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus)
make: *** [src/audio.o] Error 1

¿Es posible que falte en el paquete del toolchain de Dingux o hay algún motivo por el que puede dar este error?

[Uncanny]

Muy util la guia, muchas gracias. Ya tengo instalado el toolchain, pero me encuentro con una dependencia, no encuentra, glibc 2.8, estoy intentando compilar el UAE4ALL ya he modificado el Makefile, creo que correctamente, y me da este error con el primer fichero:

/opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus: /lib32/libc.so.6: version `GLIBC_2.8' not found (required by /opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1plus)
make: *** [src/audio.o] Error 1

¿Es posible que falte en el paquete del toolchain de Dingux o hay algún motivo por el que puede dar este error?Como expliqué en un post anterior de este mismo hilo, el toolchain de Dingux, así como el propio sistema del mismo, kernel incluido, está construido con Buildroot (http://buildroot.uclibc.org/) y este está basado en la biblioteca uClibc (http://uclibc.org/) en lugar de GNU Glibc, así que obviamente no vas a encontrar Glibc dentro del toolchain. Ambas son bastante compatibles en lo que respecta a su API, pero hay algunas diferencias (http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt) y puede darse un problema de incompatibilidad con algún programa, ya sea por como está programado o según que bibliotecas se usen en el mismo.

No se me ocurre ahora mismo una posible causa del error de incompatibilidad o de dependencia de GLibc, revisa el Makefile para ver contra que bibliotecas se debe enlazar y si hay alguna que necesariamente use Glibc, así como el código fuente basándote en el documento de diferencias entre las dos bibliotecas (viendo el error, podrías revisar el archivo fuente del que se genera src/audio.o), puede ser un buen punto de partida. En un mal caso siempre puedes crearte otro toolchain basado en Glibc con Crosstool-NG (http://ymorin.is-a-geek.org/dokuwiki/projects/crosstool) por ejemplo, eso si, posiblemente tendrías que enlazar estáticamente el UEA4ALL para que funcionara en Dingux, porque dinámicamente sería complicado y es posible que no funcionara incluso aunque hicieras un apaño con un script y forzaras el uso (con variables como LD_LIBRARY_PATH) de las bibliotecas dinámicas de ese toolchain incluyendolas junto al port.

[enkonsierto]

Gracias por el mini-tuto!!! Espero ponerlo en práctica.

[frankitu]

hola! soy nuevo en el foro! me registre para comentaros una experiencia similar a la de balrogsoft que me ha traido de cabeza un par de dias...
siguiento los pasos de Uncanny decidi probar y compilar un "hola mundo" para dingux, pero mi sorpresa vino al recibir el siguiente mensaje:
/opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1: /lib32/libc.so.6: version `GLIBC_2.8' not found (required by /opt/mipsel-linux-uclibc/usr/bin/../libexec/gcc/mipsel-linux-uclibc/4.3.3/cc1)

intente compilar mas cosas, pero siempre obtenia errores similares y no encontre nada por internet que me ayudara a aclarar mi problema.
al final decidi probar con otra maquina virtual de linux y funciono
inicialmente use un Ubuntu 8.04 64 bits (la maquina conflictiva), luego probe con Fedora 9 32 bits y Ubuntu 9.04 de 32 bits que funcionaron sin problemas

aunque no he realizado mas pruebas, mi deduccion fue que la toolchain esta preparada para distros de 32 bits
espero que esto ayude a otras personas con el mismo caso
un saludo