Parche apio para docker

[1138-4EB]

Como no me gusta llenar el equipo de librerías, especialmente cuando es compartido, intento mantener la mayoría de los grupos de herramientas en contenedores docker. Para quien no conozca la herramienta, docker permite hacer "imágenes": un fichero comprimido compuesto por capas. Cada capa son un conjunto de ficheros, librerías, documentos y órdenes (como instalar/ejecutar algo, establecer variables de entorno, configurar puertos...). Lo interesante es que cuando queremos utilizar el contenido, se crea un contenedor a partir de la imagen. Este contenedor se ejecuta en nuestro ordenador, y es un proceso aislado con un sistema de archivos independiente: una sandbox.

El hecho de que sea independiente, permite tener mútiples versiones de las mismas librerías corriendo en paralelo, sin que haya colisiones. Tanto es así que se pueden ejecutar, por ejemplo, un contenedor con fedora y otro con ubuntu al mismo tiempo, independientemente de cual sea el sistema de nuestro equipo (GNU/Linux, macOS o Windows). Docker también funciona en ARM, y por lo tanto, Raspberry Pi.

La prueba más sencilla para ver cómo funciona es, suponiendo que docker esté instalado y el servicio arrancado, en dos terminales diferentes:

docker run -it fedora bash

docker run -it ubuntu bash

Podremos usar herramientas propias de cada distribución, hacer los cambios deseados, compilar algún programa de prueba, ejecutar alguna simulación, etc. Cuando terminemos, podremos guardar toda la historia o simplemente desecharla.

Nótese que hay una diferencia muy importante con respecto a la "compilación cruzada" entre sistemas operativos: se crea una imagen docker con, digamos, ubuntu como base; se compilan los programas una sola vez con una sola versión de las librerías; esa misma imagen se ejecuta igual en todos los sistemas operativos. Todavía es necesaria la compilación cruzada si la arquitectura es diferente (x86 vs ARM), pero sin duda reduce notablemente el número de compilaciones a realizar.

Docker no trae interfaz gráfica de por sí, pero hay varias soluciones. A mí personalmente, me gusta portainer.io, que es tan fácil de utilizar como:

docker run -d --name portainer -p 9000:9000 -v "/var/run/docker.sock:/var/run/docker.sock" portainer/portainer

A través de localhost:9000 podremos establecer la contraseñar de administrador y acceder a la interfaz. Cualquier cambio que hagamos a través de cualquiera de las terminales se reflejará ahí. Opcionalmente, podremos arrancar, parar y borrar contenedores sin necesidad de utilizar la terminal.

[1138-4EB]

APIO EN DOCKER

En vista de las ventajas, me he dispuesto a probar apio en un contenedor. Como parece que Ubuntu es la distribución de referencia, he utilizado la misma y este vídeo como base para elaborar el siguiente fichero Dockerfile:

FROM ubuntu:latest

WORKDIR /root

RUN apt-get update && apt-get install -y python python-pip \
 && pip install -U pip apio \
 && apio drivers --enable \
 && apio install --all

Jesús, posible bug: el paso de habilitar los drivers da el siguiente error:

# apio drivers --enable
Configure FTDI drivers for FPGA
Traceback (most recent call last):
  File "./root/.local/bin/apio", line 11, in <module>
    sys.exit(cli())
  File "/root/.local/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/root/.local/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/root/.local/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/root/.local/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/root/.local/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/root/.local/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/root/.local/lib/python2.7/site-packages/apio/commands/drivers.py", line 24, in cli
    exit_code = Drivers().enable()
  File "/root/.local/lib/python2.7/site-packages/apio/managers/drivers.py", line 52, in enable
    return self._enable_linux()
  File "/root/.local/lib/python2.7/site-packages/apio/managers/drivers.py", line 78, in _enable_linux
    self.rules_local_path, self.rules_system_path])
  File "/usr/lib/python2.7/subprocess.py", line 523, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

¿Es posible que esa opción sólo sea necesaria en Windows? En el README así se indica, pero no en la documentación (http://apiodoc.readthedocs.io/en/stable/source/installation.html). Interpreto que, en caso de hacer algo en GNU/Linux, es esto:

$ sudo cp 80-icestick.rules /etc/udev/rules.d/
$ sudo service udev restart

Por lo tanto, el posible 'bug' es que no se comprueba la existencia de la carpeta. Es razonable para cualquier sistema completo, pero las imágenes de docker no tienen esa carpeta, ya que dependen del Host para ello. Aun así, he creado la carpeta para que exista y sigue dando el mismo error.

Compruebo en managers/drivers.py que se asume la necesidad de utilizar sudo:

def _enable_linux(self):

click.secho('Configure FTDI drivers for FPGA')

if not isfile(self.rules_system_path):

subprocess.call(['sudo', 'cp',

self.rules_local_path, self.rules_system_path])

subprocess.call(['sudo', 'service', 'udev', 'restart'])

En docker el usuario por defecto es root en el contenedor, por lo que no existe sudo. Además, como el proceso se puede ejecutar en segundo plano o en remoto, tiene que ser batch (sin interacción). Así, creo que hay tres posibilidades para esta segunda parte del bug:

• Solución fácil: indicar en la documentación que este comando en concreto hay que ejecutarlo precedido de sudo.
• Solución media: comprobar al inicio del script si se dispone de permisos, y devolver un mensaje indicando la necesidad.
• Solución completa: comprobar si se dispone de permisos, si no comprobar si existe sudo y en caso positivo utilizar el código actual.
  

--------

En cualquier caso, por el momento podemos ignorar los drivers y considerarlo sólo una imagen para simulación, síntesis y P&R. Comentando la línea
que da error, la imagen se construye de forma satisfactoria:

$ mkdir tmpdir && cd tmpdir
$ wget https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-apiobase
$ docker build -t apiobase .

El resultado es que de 130 MB que ocupa 'ubuntu:latest', la instalación completa asciende a 550MB. ¿Qué es lo que ocupa tanto?

551M /
350M /usr
114M /root
47M  /var
26M  /lib
7.8M /bin
4.6M /sbin
2.2M /etc
...

208M   /usr/lib


76M    /usr/share
34M    /usr/bin
20M    /usr/include

13M    /usr/local
1.8M   /usr/sbin
...

208M   /usr/lib/
80M    /usr/lib/gcc
63M    /usr/lib/python2.7
62M    /usr/lib/x86_64-linux-gnu
1.7M   /usr/lib/locale
...

2.3M    /root/.cache
111M    /root/.apio
114M    /root

3.1M    /root/.apio/packages/tools-system
14M    /root/.apio/packages/toolchain-iverilog
92M    /root/.apio/packages/toolchain-icestorm
3.1M    /root/.apio/packages/tool-scons
504K    /root/.apio/packages/examples
111M    /root/.apio/packages/

Los requisitos de apio en general son bastante comedidos (111MB sobre los 106 que ocupan icestorm y iverilog). Pero la prevalencia de Python y GCC (143MB entre ambos) duplica los requerimientos. Sería interesante poder prescindir de ellos y tener una imagen de 400MB.

Jesús,

• ¿apio depende de python y gcc para su ejecución o sólo para la instalación?
• Si depende de ellos, ¿habría alguna posibilidad de distribuir las partes de python compiladas o de compilarlas durante la instalación?
• ¿yosys o arachne dependenden de GCC para su ejecución?
  

--------

Como existe la posibilidad de utilizar los paquetes de fpgalibre, he hecho la prueba para comparar el resultado:

FROM ubuntu:latest

WORKDIR /root

RUN apt-get update && apt-get install curl \
 && curl -sSL http://fpgalibre.sf.net/debian/go | sh \
 && apt-get install -y apio \
 && apt-get install -y apio-scons apio-icestorm apio-iverilog apio-examples apio-system

$ mkdir tmpdir && cd tmpdir
$ wget https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-apiodebbase
$ docker build -t apiodebbase .

En principio, instala exactamente lo mismo que la solución de python. Sin embargo, en lo que respecta al espacio son 130MB menos:

428M    /
340M    /usr
50M    /var
26M    /lib
7.2M    /bin
3.5M    /sbin
2.5M    /etc

152M    /usr/lib
131M    /usr/share
56M    /usr/bin
1.8M    /usr/sbin

84M    /usr/lib/x86_64-linux-gnu
34M    /usr/lib/python2.7
24M    /usr/lib/python3.5
4.1M    /usr/lib/scons
1.7M    /usr/lib/locale

La diferencia principal es que aquí no hay GCC, y la versión de python2.7 ocupa la mitad (aunque incluye también python3). Entiendo por ello que se podría hacer alguna "limpieza" después de instalar el apio con python, para dejar algo equivalente a esta imagen. ¿Quizá eliminar pip?

[Unai Martinez]

icestorm + arachne-pnr + yosys + iverilog + graphviz EN DOCKER (ubuntu | fedora)

Siguiendo con las pruebas, mientras Jesús echa un ojo a los mensajes anteriores, he probado a instalar las herramientas directamente desde las fuentes en el contenedor de docker, y después limpiar el rastro. No es el mejor procedimiento, ya que se recomienda extraer los productos de la compilación y crear un nuevo contenedor sólo con estos. Pero es un primer paso.

$ mkdir tmpdir && cd tmpdir
$ wget https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-ubuntubase
$ docker build -t ubuntubase .

Como podéis ver en el fichero, se instalan y mantienen icestorm + arachne-pnr + yosys + iverilog + graphviz + xdot. Y el tamaño final son "sólo" 449M. He de admitir que en este caso se borra la caché de apt en /var/apt/lists, por lo que se ahorran 40M muy preciados, que también podrían quitarse de los anteriores (de hecho, he editado los ficheros en el repo). Ahora apio ocupa 512M, y apiodeb 390M.

No obstante, hay una cuestión bastante llamativa, y es que esta es la diferencia de la carpeta de binarios después de la instalación (arriba apio y debajo ubuntu desde fuentes):

$ ls .apio/packages/toolchain-icestorm/bin/
arachne-pnr  icemulti  icepll   icetime  yosys-abc
icebram      icepack   iceprog  yosys

$ls /usr/local/bin/
arachne-pnr     icebox_html  icemulti   yosys
icebox.py       icebox_maps  icepack    yosys-abc
icebox_chipdb   icebox_stat  icepll     yosys-config
icebox_colbuf   icebox_vlog  iceprog    yosys-filterlib
icebox_diff     iceboxdb.py  icetime    yosys-smtbmc
icebox_explain  icebram      iceunpack

Más aún, en la imagen apiodeb, tenemos:

-rwxr-xr-x 1 root root     571432 Oct 25 16:29 arachne-pnr
lrwxrwxrwx 1 root root         43 Oct 24 13:23 icebox_chipdb -> ../share/fpga-icestorm/python/icebox_chipdb
lrwxrwxrwx 1 root root         43 Oct 24 13:23 icebox_colbuf -> ../share/fpga-icestorm/python/icebox_colbuf
lrwxrwxrwx 1 root root         41 Oct 24 13:23 icebox_diff -> ../share/fpga-icestorm/python/icebox_diff
lrwxrwxrwx 1 root root         44 Oct 24 13:23 icebox_explain -> ../share/fpga-icestorm/python/icebox_explain
lrwxrwxrwx 1 root root         41 Oct 24 13:23 icebox_html -> ../share/fpga-icestorm/python/icebox_html
lrwxrwxrwx 1 root root         41 Oct 24 13:23 icebox_maps -> ../share/fpga-icestorm/python/icebox_maps
lrwxrwxrwx 1 root root         41 Oct 24 13:23 icebox_vlog -> ../share/fpga-icestorm/python/icebox_vlog
-rwxr-xr-x 1 root root      34768 Oct 24 13:23 icebram
-rwxr-xr-x 1 root root      14288 Oct 24 13:23 icemulti
-rwxr-xr-x 1 root root      55248 Oct 24 13:23 icepack
-rwxr-xr-x 1 root root      10104 Oct 24 13:23 icepll
-rwxr-xr-x 1 root root      22392 Oct 24 13:23 iceprog
-rwxr-xr-x 1 root root     297000 Oct 24 13:23 icetime
lrwxrwxrwx 1 root root          7 Oct 24 13:23 iceunpack -> icepack
-rwxr-xr-x 1 root root    5163120 Oct 25 12:56 yosys
lrwxrwxrwx 1 root root         12 Oct 25 12:56 yosys-abc -> berkeley-abc
-rwxr-xr-x 1 root root      31176 Oct 25 12:56 yosys-filterlib
-rwxr-xr-x 1 root root      25013 Oct 25 12:56 yosys-smtbmc

Diría que en la versión compilada de las fuentes todos binarios se han compilado. En la versión de Salvador algunos están compilados y otros se mantienen como enlaces simbólicos a scripts de python. Mientra que en apio, esos binarios/scripts adicional no están, o están integrados en apio en sí, de alguna otra manera. Jesús, ¿podrías confirmarlo?

Cambiando la imagen base de ubuntu a fedora, y manteniendo todas las herramientas (incluido graphviz):

$ mkdir tmpdir && cd tmpdir
$ wget https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-fedorabase
$ docker build -t fedorabase .

Ya de por sí la imagen base ocupa 230M frente a los 130M, pero el resultado es más desastroso: 905M. Resulta que fedora no es capaz de borrar los paquetes debidamente, y gran parte del contenido descargado al instalar se queda en el sistema. Vía muerta, por tanto.

icestorm + arachne-pnr + yosys + iverilog EN ALPINE

Otra distribución muy popular para su uso tanto en docker como en SBC (léase Rapberry Pi) es Alpine Linux. La razón principal es que es un sistema GNU/Linux que ocupa... 4M! Bueno "a partir de 4M". Por ejemplo, la imagen para la SD de la RPi, ocupa 60M: https://alpinelinux.org/downloads/

Así, me he dispuesto a probar a compilar las herramientas en un contenedor alpine. Con icestorm, arachane-pnr e iverilog no he tenido ningún problema. Sin embago, yosys se ha resistido un poco. La razón es que Alpine no utiliza glibc, sino musl. Por lo tanto, hay ciertas funciones que no están implementadas, o no de igual manera. Por suerte, he identificado bastante rápido el origen y clifford lo ha subsanado más rápido aún (#334).

Por un lado, he abierto un PR en icestorm (#77) con las instrucciones (dependencias) para instalar la toolchain en Alpine. Como es HTML puro, podéis descargar el fichero y verlo directamente en el navegador. Como comentabais en algún otro hilo que la RPi está un poco justa de fuerza para síntesis, sería interesante, si alguien tiene una, probar si se nota alguna diferencia con respecto a raspbian + apio (que supongo será la opción por defecto). Las instrucciones están aquí: https://wiki.alpinelinux.org/wiki/Raspberry_Pi

No he entendido del todo bien cómo funciona apio, por lo que no sé hasta qué punto harán falta adaptaciones para que funcione en alpine. Supongo que, si todo se compila en local, con las instrucciones indicadas anteriormente es suficiente para cambiar los paquetes a descargar/instalar. Pero, en caso de que la compilacion cruzada se realice en travis y apio sólo descarguen los binarios precompilados, habría que averiguar cómo hacer compilación cruzada con musl. Para eso, igual sería más útil hacer la compilación en un contenedor docker dentro de travis (como hacemos en GHDL, por ejemplo). Jesús, ¿podrías aclarar el procedimiento?

icestorm + arachne-pnr + yosys + iverilog + graphviz + gtkwave EN DOCKER (alpine)

Con el parche de clifford aplicado, las herramientas básicas + iverilog + graphviz han compilado bien. Me he animado a incluir GtkWave también. Es bastante más pesado, porque requiere gtk, pero una solución completa portable ("multiplataforma") es muy tentadora :D. Además, en cierta manera compensamos el "exceso" de gtk con los 130M que nos ahorramos al cambiar la base de ubuntu a alpine.

$ mkdir tmpdir && cd tmpdir
$ wget https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-alpinebase
$ docker build -t alpinebase .

El resultado son 406.2M. No está mal.

Siguientes pasos: verificación, programación, GUI y licencia
Los siguientes pasos son:

• Preparar/seleccionar varios diseños de prueba para utilizar todas las funcionalidades de las herramientas.
• Comprobar que no se necesita ninguno de los paquetes borrados. En su caso, no borrarlo.
• Comprobar si se necesita alguno de los que se mantienen. Si no, borrarlo.
• El contenedor, por defecto, no tiene acceso a los puertos USB del host. Por lo tanto, para programar las placas hay que averiguar cómo permitirlo. Esta es una opción adicional que se incluye al ejecutar el contenedor, y en principio no afecta a las imágenes (ficheros Dockerfile-*):
  --device=/dev/bus/usb/001/007

  --device=/dev/ttyUSB0

  http://stackoverflow.com/questions/24225647/docker-any-way-to-give-access-to-host-usb-or-serial-device
• Al igual que con los puertos USB, para poder ver las aplicaciones con GUI es necesario compartir el servidor X del host. En linux es directo. En windows, sin embargo hay que ejecutar uno: https://sourceforge.net/projects/xming/
• Para poder distribuir las imágenes ya contruidas a través de docker-hub, creo que habría que revisar el tema de las licencias. Al fin y al cabo se está distribuyendo software libre en su forma binaria sin ningún tipo de fuente ni licencia. Aunque no se incluyan las fuentes, creo que una copia de la licencia y un enlace a las mismas sí podría ser necesario. Por otro lado, el fichero Dockerfile es autoexplicativo, y no se hace nada más que instalarlas mediante un proceso automatizado.
  

Contribuciones
Naturalmente, además de las aclaraciones de Jesús, cualquier contribución es bienvenida. Ya sea en este hilo, o en forma de pull request en el repo.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/LEjvbrymcrA/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/31cd9e69-4a79-4755-89e9-22a29ce109af%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Salvador Eduardo Tropea]

Hola Unai:

El 27/03/17 a las 19:55, 1138-4EB escribió:

> En principio, instala exactamente lo mismo que la solución de python.
> Sin embargo, en lo que respecta al espacio son 130MB menos:

Tené en cuenta que los paquetes Debian que armé contienen binarios
enlazados dinámicamente, eso reduce bastante.
En este momento no estoy actualizando los paquetes Debian porque estuve
con varias cosas personales (vacaciones, una operación, etc.), cosas del
trabajo y haciendo andar la Kéfir I como un Arduino. Cuando tenga más
resuelto esto último actualizaré los paquetes. Creo que sería muy simple
que armes una imágen docker basada en un Debian oficial y los paquetes
estos.

Como comentario adicional a lo de Arduino: Ya logré que la IDE de
Arduino transfiera algunos programas básicos a la iCE40, están
funcionando todos los pines de I/O digital del Arduino UNO, también los
6 PWMs y funcionan bien las rutinas de demora (ms y µs). El mayor
problema que veo es que la HX4K tiene sólo 80 kib de memoria embebida,
lo cual me está limitando mucho a cuanta memoria de programa le queda al
Arduino. Para fines didácticos parece que no va a haber problemas, pero
para un uso más pesado si.

Saludos, Salvador
--

Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

[Juan Gonzalez Gomez]

Wow! Salvador! Eso es... Brutal!! Para temas educativos es muy interesante! Mantennos informados :-)

Saludos, Obijuan

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-lib...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver este debate en la Web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/edfa3fec-b6f0-4361-32eb-314757f3cdea%40inti.gob.ar.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[1138-4EB]

Buenos días Salvador,

En primer lugar, muchas gracias por el interés.

 

Tené en cuenta que los paquetes Debian que armé contienen binarios
enlazados dinámicamente, eso reduce bastante.

Entiendo que eso reduce el tamaño del paquete deb en sí, ya que utiliza otros binarios/librerías instalados. Pero, independientemente de eso, lo que estoy comprobando es el tamaño de "la partición" después de instalarlo todo. Es decir, anque estén enlazados de forma dinámica o estática, al final el mismo contenido debe estar instalado.

¿Quieres decir que estoy olvidando instalar algunos de esos paquetes adicionales? ¿No son dependencias de tu deb?
 

En este momento no estoy actualizando los paquetes Debian porque estuve
con varias cosas personales (vacaciones, una operación, etc.), cosas del
trabajo y haciendo andar la Kéfir I como un Arduino. Cuando tenga más
resuelto esto último actualizaré los paquetes.

Si quieres, puedo proveerte una imagen en la que realizar la compilación previa y el empaquetado. De esta forma sólo con ejecutar el contenedor el paquete deb se actualizará automáticamente a partir de las fuentes (repositorios de github).

Lo que pasa es que personalmente nunca he empaquetado ninguna aplicación para una distro (ni deb, ni rpm), por lo que necesitaría una mano para el último paso.
 

Creo que sería muy simple que armes una imágen docker basada en un Debian oficial y los paquetes estos.

¿Te refieres a una imagen equivalente a cualquiera de las que enlace en los mensajes anteriores? Es decir, ¿pensada para el usuario final? ¿O a la que he mencionado en el párrafo anterior, dirigida a desarrolladores?
 

Como comentario adicional a lo de Arduino: Ya logré que la IDE de Arduino transfiera algunos programas básicos a la iCE40, están
funcionando todos los pines de I/O digital del Arduino UNO, también los 6 PWMs y funcionan bien las rutinas de demora (ms y µs). El mayor
problema que veo es que la HX4K tiene sólo 80 kib de memoria embebida, lo cual me está limitando mucho a cuanta memoria de programa le queda al Arduino. Para fines didácticos parece que no va a haber problemas, pero para un uso más pesado si.

¿Tienes alguna referencia sobre cuánto ocupa "Arduino UNO" (en número de celdas y registros)? Quiero decir que no es lo mismo implementar un AVR en verilog, u otro uC que tenga el mismo número de periféricos pero requiera menos recursos. Se me ocurre algo parecido al PicoBlaze.

Por otro lado, puesto que ya existe un mecanismo de "bootloader" externo, se puede modificar el contenido de la memoria directamente en el bitstream, de forma que os ahorráis esa parte de código. Esto supongo que ya lo estaréis haciendo.
 
Saludos

[1138-4EB]

Salvador, acabo de comprobar:

https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-ubuntubase

Cambiando la primera línea, "FROM ubuntu:latest", por "FROM debian:testing", y funciona sin ningún cambio adicional. El resultado final es prácticamente el mismo (menos de 10M de diferencia).

Con "debian:latest" (que es jessie), no encuentra libftdi1-dev, hay que utilizar libftdi-dev en su lugar. Por lo demás, el resultado es correcto. El tamaño final de la imagen es también equivalente.

Por último, "stretch-slim" (9.0 versión compacta). También funciona sin mayor cambio que la primera línea y el tamaño es el mismo que alpine, muy por encima de apiodeb.

Puedes ver más versiones de debian con las que hacer pruebas aquí: https://hub.docker.com/_/debian/

----

Después he probado con:

https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-apiodebbase

(nótese que no incluye graphviz, creo)

"debian:latest": funciona sin problema añadiendo --allow-unauthenticated a linea en la que se instala apio -> "apt-get install -y --allow-unauthenticated apio". El tamaño es ligeramente superior a alpine.

"debian:testing" y "debian:stretch-slim": hay que añadir "--allow-unauthenticated". Aun así:

...
Reading package lists...
Building dependency tree...
Reading state information...
apio-scons is already the newest version (2.3.1-2).
apio-scons set to manually installed.
apio-iverilog is already the newest version (1.0.0-4).
apio-iverilog set to manually installed.
apio-system is already the newest version (1.0.0-2).
apio-system set to manually installed.
apio-examples is already the newest version (0.0.8-2).
apio-examples set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 apio-icestorm : Depends: arachne-pnr but it is not going to be installed
                 Depends: yosys but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


Por lo tanto, es razonable pensar que stretch introduce alguna actualización de GCC u otras librerías que hace los binarios incompatibles. No obstante, por las primeras pruebas de este mensaje, Dockerfile-ubuntubase contiene esos binarios en su versión adecuada. Así, lo único que hay que hacer es empaquetarlos por si alguien quiere descargarlos de forma independiente (con apt-get).

Saludos


[Salvador Eduardo Tropea]

El 28/03/17 a las 10:03, 1138-4EB escribió:

> Buenos días Salvador,
>
> En primer lugar, muchas gracias por el interés.
>
> Tené en cuenta que los paquetes Debian que armé contienen binarios
> enlazados dinámicamente, eso reduce bastante.
>
>
> Entiendo que eso reduce el tamaño del paquete deb en sí, ya que
> utiliza otros binarios/librerías instalados. Pero, independientemente
> de eso, lo que estoy comprobando es el tamaño de "la partición"
> después de instalarlo todo. Es decir, anque estén enlazados de forma
> dinámica o estática, al final el mismo contenido debe estar instalado.

No necesariamente, si enlazás dinámicamente "compartís" las bibliotecas,
si enlazás estáticamente las "copiás"

>
> ¿Quieres decir que estoy olvidando instalar algunos de esos paquetes
> adicionales? ¿No son dependencias de tu deb?
>
> En este momento no estoy actualizando los paquetes Debian porque
> estuve
> con varias cosas personales (vacaciones, una operación, etc.),
> cosas del
> trabajo y haciendo andar la Kéfir I como un Arduino. Cuando tenga más
> resuelto esto último actualizaré los paquetes.
>
>
> Si quieres, puedo proveerte una imagen en la que realizar la
> compilación previa y el empaquetado. De esta forma sólo con ejecutar
> el contenedor el paquete deb se actualizará automáticamente a partir
> de las fuentes (repositorios de github).
>
> Lo que pasa es que personalmente nunca he empaquetado ninguna
> aplicación para una distro (ni deb, ni rpm), por lo que necesitaría
> una mano para el último paso.
>
> Creo que sería muy simple que armes una imágen docker basada en un
> Debian oficial y los paquetes estos.
>
>
> ¿Te refieres a una imagen equivalente a cualquiera de las que enlace
> en los mensajes anteriores? Es decir, ¿pensada para el usuario final?
> ¿O a la que he mencionado en el párrafo anterior, dirigida a
> desarrolladores?

A lo que me refiero es que el script de docker es mucho más simple y
claro, lo que agregás es un par de líneas que instalan los paquetes. De
hecho con instalar uno o dos paquetes alcanza, las dependencias traen el
resto. De otra manera hay que instalar y limpiar varias cosas.

> Como comentario adicional a lo de Arduino: Ya logré que la IDE de
> Arduino transfiera algunos programas básicos a la iCE40, están
> funcionando todos los pines de I/O digital del Arduino UNO,
> también los 6 PWMs y funcionan bien las rutinas de demora (ms y
> µs). El mayor
> problema que veo es que la HX4K tiene sólo 80 kib de memoria
> embebida, lo cual me está limitando mucho a cuanta memoria de
> programa le queda al Arduino. Para fines didácticos parece que no
> va a haber problemas, pero para un uso más pesado si.
>
>
> ¿Tienes alguna referencia sobre cuánto ocupa "Arduino UNO" (en número
> de celdas y registros)?

Lo que tengo actualmente está incompleto y usa periféricos "custom".
En la actualidad estoy en 445 FF y 1572 LUTs. La CPU es un AVR de 2da
generación (avr25 en términos de gcc) con 256 B de RAM y 4 kiB de "flash"
Antes de agregar los periféricos y demás detalles estaba en 183 FFs y
976 LUTs.
Los periféricos actuales son:
- Contador de microsegundos y contador de milisegundos (no existen en el
AVR, el Arduino lo hace con interrupciones del timer 0)
- Demora configurable de microsegundos (en el código de Arduino lo hace
de forma muy artesanal, acá lo hace el periférico, sirve para demoras
cortas)
- 6 PWMs (en el código de Arduino lo hace con los 3 timers, acá son más
simples)
- Todos los puertos de I/O necesarios para cubrir el Arduino UNO y algún
pin extra para el LED interno (son 100% compatibles con los del AVR)

> Quiero decir que no es lo mismo implementar un AVR en verilog, u otro
> uC que tenga el mismo número de periféricos pero requiera menos
> recursos. Se me ocurre algo parecido al PicoBlaze.

El tema con el PicoBlaze (o similar) sería que la arquitectura Arduino
necesita una CPU soportada por el gcc, preferentemente por el avr-gcc
(que ya viene incluido).
Los AVR (2da generación y posteriores) son razonablemente buenos para el
código C. CPUs como el x51 o los PICs (16x, 18x, etc.) son catastróficos
para el uso de lenguaje C.

>
> Por otro lado, puesto que ya existe un mecanismo de "bootloader"
> externo, se puede modificar el contenido de la memoria directamente en
> el bitstream, de forma que os ahorráis esa parte de código. Esto
> supongo que ya lo estaréis haciendo.

La idea es que el uso se parezca lo más posible al de una placa de Arduino.
No descarto mecanismos "especiales", pero de momento la IDE de Arduino
cree que está usando una variante de Arduino, es decir que se comunica
con el bootloader usando avrdude y compila el código usando avr-gcc.
Como los periféricos son custom necesita de un directorio separado con
la implementación de la API retocada.

No sería muy difícil hacer que una herramienta modifique el contenido de
los bloques de memoria en el bitstream y vuelva a configurar la FPGA,
pero entonces se necesitaría de soft adicional. Como están las cosas
actualmente lo único que se necesita es instalar una placa extra en la
IDE, cosa que es normal para cualquier placa que no sea Arduino oficial.
El resto funciona idéntico.

[Salvador Eduardo Tropea]

El 28/03/17 a las 11:46, 1138-4EB escribió:

> Salvador, acabo de comprobar:
>
> |https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-ubuntubase

> <https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-apiodebbase>

>
> Cambiando la primera línea, "FROM ubuntu:latest", por "FROM
> debian:testing", y funciona sin ningún cambio adicional. El resultado
> final es prácticamente el mismo (menos de 10M de diferencia).
> |

Yo decía debian no tanto por el tamaño, sino porque así es lo mismo que
se usó para compilar los paquetes.

> |
> Con "debian:latest" (que es jessie), no encuentra libftdi1-dev, hay
> que utilizar ||libftdi-dev en su lugar. Por lo demás, el resultado es
> correcto. El tamaño final de la imagen es también equivalente.
> |

Esto es raro, suena a alguna mezcla. Mi sistema es Jessie y los paquetes
no dependen de |libftdi1-dev (que tampoco tengo).

|
> |
> Por último, "stretch-slim" (9.0 versión compacta). También funciona
> sin mayor cambio que la primera línea y el tamaño es el mismo que
> alpine, muy por encima de apiodeb.
>
> Puedes ver más versiones de debian con las que hacer pruebas aquí:
> https://hub.docker.com/_/debian/
>
> ----
>
> Después he probado con:
> |
> ||https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-apiodebbase
> <https://raw.githubusercontent.com/1138-4EB/elide/master/Dockerfile-apiodebbase>|
> |
> ||(nótese que no incluye graphviz, creo)
>
> |||||"||debian:latest": funciona sin problema añadiendo
> |||--allow-unauthenticated ||||||||a linea en la que se instala apio

> -> "apt-get install -y --allow-unauthenticated apio". E|l tamaño es
> ligeramente superior a alpine.
> |||


Creo que es más seguro dejar que autentifique los paquetes.
Una forma de agregar las claves necesarias es corriendo (como root)

# curl -sSL http://fpgalibre.sf.net/debian/go | sh

[1138-4EB]

No necesariamente, si enlazás dinámicamente "compartís" las bibliotecas,
si enlazás estáticamente las "copiás"

Es decir, las librerías que están enlazadas dinámicamente sólo tienen que estar presentes una vez. Mientras que en los binarios estáticos el contenido de las mismas se copia dentro de cada uno. Entiendo que por eso tu versión ocupa menos.

Sin embargo, no me queda claro cuáles son esas librerías. ¿Implica que hay que dejar instalado algún paquete adicional? ¿O se instala una sola copia de las librerías con tu deb de apio?

A lo que me refiero es que el script de docker es mucho más simple y
claro, lo que agregás es un par de líneas que instalan los paquetes. De
hecho con instalar uno o dos paquetes alcanza, las dependencias traen el
resto. De otra manera hay que instalar y limpiar varias cosas.

 ¿Cuáles de estos paquetes son esos "uno o dos" necesarios?

build-essential clang bison flex libreadline-dev gawk tcl-dev libffi-dev git mercurial iverilog pkg-config python python3 libftdi1-dev graphviz xdot

Lo que tengo actualmente está incompleto y usa periféricos "custom".
En la actualidad estoy en 445 FF y 1572 LUTs. La CPU es un AVR de 2da
generación (avr25 en términos de gcc) con 256 B de RAM y 4 kiB de "flash"
Antes de agregar los periféricos y demás detalles estaba en 183 FFs y
976 LUTs.
Los periféricos actuales son:
- Contador de microsegundos y contador de milisegundos (no existen en el
AVR, el Arduino lo hace con interrupciones del timer 0)
- Demora configurable de microsegundos (en el código de Arduino lo hace
de forma muy artesanal, acá lo hace el periférico, sirve para demoras
cortas)
- 6 PWMs (en el código de Arduino lo hace con los 3 timers, acá son más
simples)
- Todos los puertos de I/O necesarios para cubrir el Arduino UNO y algún
pin extra para el LED interno (son 100% compatibles con los del AVR)

Tiene un aspecto muy interesante. Si no para la HX4K, sí para otras FPGA mayores. ¿Hay algún enlace donde pueda consultar más información?

El tema con el PicoBlaze (o similar) sería que la arquitectura Arduino
necesita una CPU soportada por el gcc, preferentemente por el avr-gcc
(que ya viene incluido).

Entiendo que no queráis meteros en definir una nueva arquitectura para gcc. Creía que había más CPUs tipo PicoBlaze soportadas, pero acabo de ver que no. Muchas tienen compiladores específicos para ensamblador.

Ahora me queda la duda. ¿Cómo reemplazáis las llamadas a ms() y us() sin el Timer0? Supongo que reemplazaréis el software para que escriba en las direcciones de memoria correspondientes a vuestro periférico. ¿Es así?
 

Los AVR (2da generación y posteriores) son razonablemente buenos para el
código C. CPUs como el x51 o los PICs (16x, 18x, etc.) son catastróficos
para el uso de lenguaje C.

Soy consciente. Cuando empecé con los uC conocí el C517 y varios PIC, pero el primer proyecto lo hice con AVR justamente porque quería programar en C y no en ensamblador.

Disculpa si se ha entendido que la elección de AVR no era acertada. Nada más lejos de mi intención. Simplemente quería indagar para ver hasta qué punto estáis modificando las herramientas. Ahora entiendo que no es un "nuevo AVR", sino que tratáis de reutilizar la parte de la compilación al máximo, para centraros en aplicación y periféricos.
 

La idea es que el uso se parezca lo más posible al de una placa de Arduino.
No descarto mecanismos "especiales", pero de momento la IDE de Arduino
cree que está usando una variante de Arduino, es decir que se comunica
con el bootloader usando avrdude y compila el código usando avr-gcc.
Como los periféricos son custom necesita de un directorio separado con
la implementación de la API retocada.

Entiendo. Efectivamente, cualquier otra opción requeriría adaptar ligeramente el IDE para que ejecutara otra orden al pulsar el botón.

 

> Con "debian:latest" (que es jessie), no encuentra libftdi1-dev, hay
> que utilizar ||libftdi-dev en su lugar. Por lo demás, el resultado es
> correcto. El tamaño final de la imagen es también equivalente.

Esto es raro, suena a alguna mezcla. Mi sistema es Jessie y los paquetes
no dependen de |libftdi1-dev (que tampoco tengo).

Ese comentario era en referencia a la instalación desde las fuentes. En tu sistema, y los paquetes, el driver ftdi se instala a través de apio, por lo que se descarga en versión precompilada. Concretamente, este es el repositorio en el que están: https://github.com/FPGAwars/tools-system
 

Creo que es más seguro dejar que autentifique los paquetes.
Una forma de agregar las claves necesarias es corriendo (como root)

# curl -sSL http://fpgalibre.sf.net/debian/go | sh

 Tienes razón, algo debí tocar. He vuelto a probarlo y funciona sin problemas.

Saludos y muchas gracias

[Salvador Eduardo Tropea]

Hola Unai:

El 29/03/17 a las 00:13, 1138-4EB escribió:

>
> No necesariamente, si enlazás dinámicamente "compartís" las
> bibliotecas,
> si enlazás estáticamente las "copiás"
>
>
> Es decir, las librerías que están enlazadas dinámicamente sólo tienen
> que estar presentes una vez. Mientras que en los binarios estáticos el
> contenido de las mismas se copia dentro de cada uno. Entiendo que por
> eso tu versión ocupa menos.

Exacto.

>
> Sin embargo, no me queda claro cuáles son esas librerías. ¿Implica que
> hay que dejar instalado algún paquete adicional? ¿O se instala una
> sola copia de las librerías con tu deb de apio?

Muchas son bibliotecas normales del sistema, para que veas un poco a que
me refiero. Esto es lo que me da el toolchain-icestorm (versión estática
instalada por apio en el home):

$ ls -la
total 83M
drwxrwxr-x 2 salvador salvador 4,0K oct 31 12:52 .
drwxrwxr-x 5 salvador salvador 4,0K oct 31 12:52 ..
-rwxrwxr-x 1 salvador salvador 2,9M ago 23 2016 arachne-pnr
-rwxrwxr-x 1 salvador salvador 2,6M ago 23 2016 icebram
-rwxrwxr-x 1 salvador salvador 2,6M ago 23 2016 icepack
-rwxrwxr-x 1 salvador salvador 926K ago 23 2016 icepll
-rwxrwxr-x 1 salvador salvador 1,6M ago 23 2016 iceprog
-rwxrwxr-x 1 salvador salvador 5,2M ago 23 2016 icetime
-rwxrwxr-x 1 salvador salvador 7,9M ago 23 2016 yosys
-rwxrwxr-x 1 salvador salvador 60M ago 23 2016 yosys-abc

Fijate que de los 83 M el "abc" es lo más pesadito, con 60 M. Con los
paquetes debian se instala el abc que está compilado por el maintainer
de Debian:

$ ls -la /usr/bin/berkeley-abc
-rwxr-xr-x 1 root root 13M oct 13 14:02 /usr/bin/berkeley-abc

¡Son 47 M menos!
Si le preguntamos al linker dinámico dice:

$ ldd /usr/bin/berkeley-abc
linux-vdso.so.1 (0x00007ffcafdf8000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6
(0x00007f0a98a3a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f0a9881d000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0a98619000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x00007f0a98409000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0a981ee000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0a97fe6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0a97ce5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a9793a000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
(0x00007f0a97710000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0a99df1000)

Son bibliotecas normales del sistema, son necesarias para que funcionen
otros binarios básicos.
Y para el de apio:

$ ldd yosys-abc
no es un ejecutable dinámico

Eso quiere decir que hay 47 M repetidos. El binario de "abc" no depende
de nada especial:

Depends: libbz2-1.0, libc6 (>= 2.14), libreadline6 (>= 6.0), zlib1g (>=
1:1.1.4)

Para darte una idea:
1) libc6: *TODO* el sistema la usa.
2) libbz2-1.0 y zlib1g: Son las bibliotecas de compresión más comunes,
algunos comandos que las usan file, gnupg, etc.
3) libreadline6: la usa el comando bc, el ftp, el gnupg, y el mismísimo
yosys

Fijate que incluso se repiten con otras cosas que necesita apio, por
ejemplo, el paquete iverilog depende de:

Depends: libbz2-1.0, libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libreadline6
(>= 6.0), libstdc++6 (>= 4.9), zlib1g (>= 1:1.2.0)

>
> A lo que me refiero es que el script de docker es mucho más simple y
> claro, lo que agregás es un par de líneas que instalan los
> paquetes. De
> hecho con instalar uno o dos paquetes alcanza, las dependencias
> traen el
> resto. De otra manera hay que instalar y limpiar varias cosas.
>
>
> ¿Cuáles de estos paquetes son esos "uno o dos" necesarios?
>
> |
> build-essential clang bison flex libreadline-dev gawk tcl-dev
> libffi-dev git mercurial iverilog pkg-config python python3
> libftdi1-dev graphviz xdot
> |
>

Estas dependencias son para *crear* los paquetes debian, no los necesita
el usuario final.
A lo que me refiero es que:
1) Si querés usar apio basta con instalar apio, eso automáticamente
instala apio-examples, apio-icestorm, apio-scons, apio-iverilog,
apio-system. Esto implica que también instala el toolchain de IceStorm y
el Icarus Verilog.
2) Si querés usar apio desde la IDE basta con instalar apio-ide y atom,
eso automáticamente instala todo lo de (1)
3) Si querés usar icestudio basta con instalar icestudio, eso
automáticamente instala todo lo de (1)

> Lo que tengo actualmente está incompleto y usa periféricos "custom".
> En la actualidad estoy en 445 FF y 1572 LUTs. La CPU es un AVR de 2da
> generación (avr25 en términos de gcc) con 256 B de RAM y 4 kiB de
> "flash"
> Antes de agregar los periféricos y demás detalles estaba en 183 FFs y
> 976 LUTs.
> Los periféricos actuales son:
> - Contador de microsegundos y contador de milisegundos (no existen
> en el
> AVR, el Arduino lo hace con interrupciones del timer 0)
> - Demora configurable de microsegundos (en el código de Arduino lo
> hace
> de forma muy artesanal, acá lo hace el periférico, sirve para demoras
> cortas)
> - 6 PWMs (en el código de Arduino lo hace con los 3 timers, acá
> son más
> simples)
> - Todos los puertos de I/O necesarios para cubrir el Arduino UNO y
> algún
> pin extra para el LED interno (son 100% compatibles con los del AVR)
>
>
> Tiene un aspecto muy interesante. Si no para la HX4K, sí para otras
> FPGA mayores. ¿Hay algún enlace donde pueda consultar más información?

Por ahora no, es todo WIP.

>
> El tema con el PicoBlaze (o similar) sería que la arquitectura
> Arduino
> necesita una CPU soportada por el gcc, preferentemente por el avr-gcc
> (que ya viene incluido).
>
>
> Entiendo que no queráis meteros en definir una nueva arquitectura para
> gcc. Creía que había más CPUs tipo PicoBlaze soportadas, pero acabo de
> ver que no. Muchas tienen compiladores específicos para ensamblador.
>
> Ahora me queda la duda. ¿Cómo reemplazáis las llamadas a ms() y us()
> sin el Timer0? Supongo que reemplazaréis el software para que escriba
> en las direcciones de memoria correspondientes a vuestro periférico.
> ¿Es así?

Si. Cada vez que se compila un "sketch" de Arduino automáticamente se
recompilan los fuentes de la API que implementan las funciones usadas.
Esa API va en un directorio, hay una API que cubre a todos los Arduino
oficiales, es un infierno el código porque tiene que soportar toda la
variedad de AVRs usados. Yo trabajo en un directorio separado. Para
darte una idea, el código de la API por defecto para leer el A/D es:

int analogRead(uint8_t pin)
{
uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
pin = analogPinToChannel(pin);
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) ||
defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) ||
defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif

#if defined(ADCSRB) && defined(MUX5)
// the MUX5 bit of ADCSRB selects whether we're reading from channels
// 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif

// set the analog reference (high two bits of ADMUX) and select the
// channel (low 4 bits). this also sets ADLAR (left-adjust result)
// to 0 (the default).
#if defined(ADMUX)
#if defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) ||
defined(__AVR_ATtiny85__)
ADMUX = (analog_reference << 4) | (pin & 0x07);
#else
ADMUX = (analog_reference << 6) | (pin & 0x07);
#endif
#endif

// without a delay, we seem to read from the wrong channel
//delay(1);

#if defined(ADCSRA) && defined(ADCL)
// start the conversion
sbi(ADCSRA, ADSC);

// ADSC is cleared when the conversion finishes
while (bit_is_set(ADCSRA, ADSC));

// we have to read ADCL first; doing so locks both ADCL
// and ADCH until ADCH is read. reading ADCL second would
// cause the results of each conversion to be discarded,
// as ADCL and ADCH would be locked when it completed.
low = ADCL;
high = ADCH;
#else
// we dont have an ADC, return 0
low = 0;
high = 0;
#endif

// combine the two bytes
return (high << 8) | low;
}

En mi implementación es:

int analogRead(uint8_t pin)
{
uint8_t low, high;

/* Set the channel and start a new conversion */
WB_ADR=AD_BASE+1;
WB_DAT=pin;
/* Wait until the conversion ends */
loop_until_bit_is_clear(WB_DAT,7);
/* Read the result */
high=WB_DAT;
WB_ADR=AD_BASE;
low=WB_DAT;
/* Combine both bytes */
return (high<<8)|low;

}


> Los AVR (2da generación y posteriores) son razonablemente buenos
> para el
> código C. CPUs como el x51 o los PICs (16x, 18x, etc.) son
> catastróficos
> para el uso de lenguaje C.
>
>
> Soy consciente. Cuando empecé con los uC conocí el C517 y varios PIC,
> pero el primer proyecto lo hice con AVR justamente porque quería
> programar en C y no en ensamblador.
>
> Disculpa si se ha entendido que la elección de AVR no era acertada.
> Nada más lejos de mi intención. Simplemente quería indagar para ver
> hasta qué punto estáis modificando las herramientas. Ahora entiendo
> que no es un "nuevo AVR", sino que tratáis de reutilizar la parte de
> la compilación al máximo, para centraros en aplicación y periféricos.

Exacto.

> La idea es que el uso se parezca lo más posible al de una placa de
> Arduino.
> No descarto mecanismos "especiales", pero de momento la IDE de
> Arduino
> cree que está usando una variante de Arduino, es decir que se
> comunica
> con el bootloader usando avrdude y compila el código usando avr-gcc.
> Como los periféricos son custom necesita de un directorio separado
> con
> la implementación de la API retocada.
>
>
> Entiendo. Efectivamente, cualquier otra opción requeriría adaptar
> ligeramente el IDE para que ejecutara otra orden al pulsar el botón.

Es bastante configurable, pero si me pongo a agregar binarios implica
que tengo que tener los binarios para cada plataforma.

>
> > Con "debian:latest" (que es jessie), no encuentra libftdi1-dev, hay
> > que utilizar ||libftdi-dev en su lugar. Por lo demás, el
> resultado es
> > correcto. El tamaño final de la imagen es también equivalente.
>
> Esto es raro, suena a alguna mezcla. Mi sistema es Jessie y los
> paquetes
> no dependen de |libftdi1-dev (que tampoco tengo).
>
>
> Ese comentario era en referencia a la instalación desde las fuentes.
> En tu sistema, y los paquetes, el driver ftdi se instala a través de
> apio, por lo que se descarga en versión precompilada. Concretamente,
> este es el repositorio en el que están:
> https://github.com/FPGAwars/tools-system
>
> Creo que es más seguro dejar que autentifique los paquetes.
> Una forma de agregar las claves necesarias es corriendo (como root)
>
> # curl -sSL http://fpgalibre.sf.net/debian/go
> <http://fpgalibre.sf.net/debian/go> | sh
>
>
> Tienes razón, algo debí tocar. He vuelto a probarlo y funciona sin
> problemas.

[1138-4EB]

Salvador, muchas gracias por todos los comandos de ejemplo para analizar las dependencias y su ocupación. He comprobado que, como indicas, la imágenes docker tanto ubuntu como debian incluyen /lib/x86_64-linux-gnu/. También he comprobado que todos los binarios instalados desde los deb están enlazados de forma dinámica, mientras que en la instalación a través de python no.

Me surge la duda de en que momento indicas que quieres compilarlos de forma dinámica? He hecho un fork de tu repositorio apio-debian, pero no soy capaz de encontrar ninguna orden de compilación, sólo de instalación. ¿Es tan sencillo como que tú no compilas nada y utilizas directamente los paquetes ya existentes en los repos para todo?

# apt-cache search arachne icestorm abc
arachne-pnr - Place and route tool for iCE40 family FPGAs
arachne-pnr-chipdb - Chip db files for arachne-pnr
# apt-cache search icestorm                  
fpga-icestorm - Tools to handle the bitstream format of Lattice iCE40 FPGAs
fpga-icestorm-chipdb - Chip database files for fpga-icestorm
...
# apt-cache search abc    
...
berkeley-abc - ABC - A System for Sequential Synthesis and Verification
...
# apt-cache search yosys
yosys - Framework for Verilog RTL synthesis
yosys-dev - Framework for Verilog RTL synthesis (development files)
yosys-doc - Documentation for Yosys

¿Es tu paquete prácticamente equivalente a la siguiente orden?

apt-get install arachne-pnr arachne-pnr-chipdb fpga-icestorm fpga-icestorm-chipdb berkley-abc yosys

Entiendo que el deb, además crea enlaces simbólicos para apio y copia los scripts de apio en sí. Pero tengo la sensación de que no utilizas los binarios en https://github.com/FPGAwars/toolchain-icestorm, ¿es así?

 

Para darte una idea:
1) libc6: *TODO* el sistema la usa.
2) libbz2-1.0 y zlib1g: Son las bibliotecas de compresión más comunes,
algunos comandos que las usan file, gnupg, etc.
3) libreadline6: la usa el comando bc, el ftp, el gnupg, y el mismísimo
yosys

Fijate que incluso se repiten con otras cosas que necesita apio, por
ejemplo, el paquete iverilog depende de:

Depends: libbz2-1.0, libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libreadline6
(>= 6.0), libstdc++6 (>= 4.9), zlib1g (>= 1:1.2.0)

Sin duda esto va a resultarme muy útil para la versión Alpine. En ese caso, todas estas librerías no vienen por defecto, por lo que tendré que indicarlas como dependencias.
 

Estas dependencias son para *crear* los paquetes debian, no los necesita
el usuario final.
A lo que me refiero es que:
1) Si querés usar apio basta con instalar apio, eso automáticamente
instala apio-examples, apio-icestorm, apio-scons, apio-iverilog,
apio-system. Esto implica que también instala el toolchain de IceStorm y
el Icarus Verilog.
2) Si querés usar apio desde la IDE basta con instalar apio-ide y atom,
eso automáticamente instala todo lo de (1)
3) Si querés usar icestudio basta con instalar icestudio, eso
automáticamente instala todo lo de (1)

Como mi propósito final es hacerlo desde las fuentes, mi duda era cuáles necesita el usuario final si no utiliza el deb. Es decir:

• Creo una imagen con todas las dependencias para "crear" los binarios.
• Con cada nueva versión de las herramientas, arranco un contenedor basado en la imagen anterior, y compilo todos los binarios desde las fuentes.
• Extraigo únicamente los resutados de compilación y elimino el contenedor.
• Creo una nueva imagen sin ninguna dependencia en absoluto y copio los resultados de compilación.
  

Me has aclarado que si la compilación es estática, los pasos anteriores son suficientes. Sin embargo, si es dinámica, esa última imagen deberá incluir también las dependencias de ejecución (que son menos que las de instalación y sin el sufijo '-dev'). Estas dependencias son irrelevantes en Debian/Ubuntu, porque como has comentado son parte del sistema base. Pero creo que no es así en Alpine.

int analogRead(uint8_t pin)
{
  uint8_t low, high;

  /* Set the channel and start a new conversion */
  WB_ADR=AD_BASE+1;
  WB_DAT=pin;
  /* Wait until the conversion ends */
  loop_until_bit_is_clear(WB_DAT,7);
  /* Read the result */
  high=WB_DAT;
  WB_ADR=AD_BASE;
  low=WB_DAT;
  /* Combine both bytes */
  return (high<<8)|low;
}

Deduzco por los nombres que utilizas Wishbone para la comunicación con los periféricos. ¿Qué versión?
 

Es bastante configurable, pero si me pongo a agregar binarios implica
que tengo que tener los binarios para cada plataforma.

Yo actualmente estoy bastante contento con Golang para estas tareas. Utilizo esta imagen como entorno donde compilar de forma cruzada: https://github.com/1138-4EB/go/blob/golang-alpine/Dockerfile Concretamente, hay 10 plataformas:

darwin;386 darwin;amd64 freebsd;386 freebsd;amd64 freebsd;arm linux;386 linux;amd64 linux;arm windows;386 windows;amd64

Después, cada vez que quiero compilar un proyecto para todas, ejecuto esto: https://github.com/1138-4EB/elide/blob/master/travis/travis-ci.sh

Entiendo que esto queda bastante adelante en el roadmap, si es que en algún momento entra. Pero te lo dejo como referencia por ser una solución genérica para cualquier proyecto. No es la solución óptima, porque se generan binarios estáticos, pero evitar tener que conocer las particularidades de cada plataforma. En caso de querer compilar de forma dinámica, existe la opción, pero es muy parecida a hacerlo directamente en C.

Muchas gracias de nuevo por tu paciencia y la información.

Saludos

[Jesús Arroyo]

Buenas,

Apio drivers

No creo que tenga mucho sentido configurar los drivers en una máquina virtual. Ese comando sólo tiene sentido ejecutarlo en una máquina real y completa. (PD: aunque el user sea root puede ejecutar comandos con sudo). Ejecutar apio como sudo tampoco tendría sentido ya que se estaría invocando otro binario, ésto sólo se haría si el usuario quiere instalar apio en root.
Python es un intérprete y por lo tanto es necesario para ejecutar los scripts. GCC es el compilador y por lo tanto sólo es necesario para la fase de compilación, no de ejecución.

Icestorm + ...

Como comenta Salvador, los paquetes compilados para debian suelen estar enlazados dinámicamente por lo tanto ocupan menos. Todos los paquetes de Apio (toolchain-icestorm, toolchain-iverilog, etc.) están compilados en estático en su mayoría para garantizar que funcionan correctamente en cualquier distro y cualquier versión, pero como contra ocupan más. PD: en las últimas versiones de las toolchains se ha optimizado bastante el tamaño con ahorros del 35% y >70% respectivamente ya que he eliminado, entre otras cosas, las referencias al debugger.
Las incompatibilidades del apt vienen generadas porque no encuentra de dónde descargar el .deb, esto se soluciona añadiéndolo a las sources.list, en vez de por problemas con GCC. Hay que tener en cuenta que hay varias distribuciones de las herramientas de Icestorm: toolchain-icestorm (en estático y con estructura compatible apio), debian de fpgalibre (dinámico y con estructura compatible con apio), debian (dinámico y estándar). Para trabajar con Apio hay que utilizar las dos primeras, o la tercera activando el modo "native".

Arduino en iCE40

Salvador esto es brutal! Yo tengo dos placas iCE40 con HX8K. Una de ellas es la icoBOARD que viene con memoria externa. En su momento estuve probando compilar para el micro picorv32 dentro de la FPGA: https://github.com/Jesus89/picorv32-c-examples.
Si quieres que probemos algo de lo que estés desarrollando coméntanos (yo personalmente estaré encantado de tener un miniAVR sintetizado).

Un saludo.

[Xoan Sampaiño]

Quizá sea un poco offtopic, pero apio se podría instalar sin problemas dentro de un entorno virtual de Python (python-virtualenv), ¿no?

Yo uso Arch Linux, y mezclar pip con pacman nunca es bueno.

Le tengo que dar una vuelta, limpiar lo que instaló automáticamente y hacerlo de forma limpia con «venv» para documentarlo.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/617bc1e9-e282-4372-95e8-7fec9388699b%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Salvador Eduardo Tropea]

Hola Unai:

El 29/03/17 a las 17:19, 1138-4EB escribió:

> Salvador, muchas gracias por todos los comandos de ejemplo para
> analizar las dependencias y su ocupación. He comprobado que, como
> indicas, la imágenes docker tanto ubuntu como debian incluyen
> /lib/x86_64-linux-gnu/. También he comprobado que todos los binarios
> instalados desde los deb están enlazados de forma dinámica, mientras
> que en la instalación a través de python no.

Exacto. Los binarios de APIO son estáticos para que funcionen en más
variedad de sistemas.

> Me surge la duda de en que momento indicas que quieres compilarlos de
> forma dinámica?

Es el método normal.

> He hecho un fork de tu repositorio apio-debian, pero no soy capaz de
> encontrar ninguna orden de compilación, sólo de instalación. ¿Es tan
> sencillo como que tú no compilas nada y utilizas directamente los
> paquetes ya existentes en los repos para todo?

Más o menos, los paquetes que verdaderamente contienen las herramientas
van por separados. La mayoría ya existen en Debian, sin embargo en
FPGALibre hay versiones más nuevas.
La idea en general es mantener el espíritu de los paquetes. Lo que hace
APIO es muy conveniente para gente que usa sistemas operativos caóticos
que no poseen el concepto de paquetes (me refiero a esa cosa que sigue
dándole plata a la empresa de Redmond). Para sistemas operativos como
Debian es una locura. Pensá que tenés una máquina que la usan 6
personas, 3 quieren usar IceStorm, pero sin APIO y 3 quieren usarlo,
pero con APIO. Sin usar los paquetes que yo armé terminás con 4 copias
de IceStorm, una enlazada dinámicamente e instalada a nivel de sistema,
y 3 copias enlazadas estáticamente e instaladas en el home de cada
usuario. Ni hablar que las 4 pueden hasta ser diferentes versiones, con
lo que es un caos reproducir errores. Con los paquetes Debian se
soluciona, hay una única copia que usan todos.

>
> |
> # apt-cache search arachne icestorm abc
> arachne-pnr -Placeandroute tool foriCE40 family FPGAs
> arachne-pnr-chipdb -Chipdb files forarachne-pnr
> # apt-cache search icestorm

> fpga-icestorm -Toolsto handle the bitstream format of LatticeiCE40 FPGAs

> fpga-icestorm-chipdb -Chipdatabase files forfpga-icestorm
> ...
> # apt-cache search abc
> ...
> berkeley-abc -ABC -A SystemforSequentialSynthesisandVerification
> ...
> # apt-cache search yosys
> yosys -FrameworkforVerilogRTL synthesis
> yosys-dev -FrameworkforVerilogRTL synthesis (development files)
> yosys-doc -DocumentationforYosys
>
> |
>
> ¿Es tu paquete prácticamente equivalente a la siguiente orden?
>
> |

> apt-getinstall arachne-pnr arachne-pnr-chipdb fpga-icestorm
> fpga-icestorm-chipdb berkley-abc yosys
> |
>

Es que son muchos paquetes, las dependencias hacen la magia.

apio recomienda apio-examples, apio-icestorm, apio-scons, apio-iverilog,
apio-system
apio-icestorm depende de apio, arachne-pnr, yosys, fpga-icestorm
arachne-pnr depende de arachne-pnr-chipdb, yosys, fpga-icestorm
yosys depende de berkeley-abc
fpga-icestorm recomienda yosys, fpga-icestorm-chipdb
apio-iverilog depende de apio, iverilog, gtkwave
...
Por lo que si instalás APIO estás instalando todo lo necesario para
trabajar con APIO, no sólo el script. Los componentes de APIO, como
apio-iverilog no instalan un Icarus Verilog propio, instala *el* Icarus
Verilog y lo usa.
En el repo de FPGALibre hay un iverilog mucho más nuevo que el que está
en Jessie. Por eso es que va a instalar *ese* paquete y no el que está
en los servidores de Debian.

> Entiendo que el deb, además crea enlaces simbólicos para apio y copia
> los scripts de apio en sí. Pero tengo la sensación de que no utilizas
> los binarios en https://github.com/FPGAwars/toolchain-icestorm, ¿es así?

Exactamente, sería una locura hacerlo.

> Para darte una idea:
> 1) libc6: *TODO* el sistema la usa.
> 2) libbz2-1.0 y zlib1g: Son las bibliotecas de compresión más
> comunes,
> algunos comandos que las usan file, gnupg, etc.
> 3) libreadline6: la usa el comando bc, el ftp, el gnupg, y el
> mismísimo
> yosys
>
> Fijate que incluso se repiten con otras cosas que necesita apio, por
> ejemplo, el paquete iverilog depende de:
>
> Depends: libbz2-1.0, libc6 (>= 2.14), libgcc1 (>= 1:4.1.1),
> libreadline6
> (>= 6.0), libstdc++6 (>= 4.9), zlib1g (>= 1:1.2.0)
>
>
> Sin duda esto va a resultarme muy útil para la versión Alpine. En ese
> caso, todas estas librerías no vienen por defecto, por lo que tendré
> que indicarlas como dependencias.

No conozco Alpine, pero estas bibliotecas las usan los comandos más
básicos del OS. Salvo cosas hechas para embebidos lo normal es que estén.

> Estas dependencias son para *crear* los paquetes debian, no los
> necesita
> el usuario final.
> A lo que me refiero es que:
> 1) Si querés usar apio basta con instalar apio, eso automáticamente
> instala apio-examples, apio-icestorm, apio-scons, apio-iverilog,
> apio-system. Esto implica que también instala el toolchain de
> IceStorm y
> el Icarus Verilog.
> 2) Si querés usar apio desde la IDE basta con instalar apio-ide y
> atom,
> eso automáticamente instala todo lo de (1)
> 3) Si querés usar icestudio basta con instalar icestudio, eso
> automáticamente instala todo lo de (1)
>
>
> Como mi propósito final es hacerlo desde las fuentes, mi duda era
> cuáles necesita el usuario final si no utiliza el deb. Es decir:
>

> * Creo una imagen con todas las dependencias para "crear" los binarios.
> * Con cada nueva versión de las herramientas, arranco un contenedor

> basado en la imagen anterior, y compilo todos los binarios desde
> las fuentes.

> * Extraigo únicamente los resutados de compilación y elimino el
> contenedor.
> * Creo una nueva imagen sin ninguna dependencia en absoluto y copio

> los resultados de compilación.
>
> Me has aclarado que si la compilación es estática, los pasos
> anteriores son suficientes. Sin embargo, si es dinámica, esa última
> imagen deberá incluir también las dependencias de ejecución (que son
> menos que las de instalación y sin el sufijo '-dev'). Estas
> dependencias son irrelevantes en Debian/Ubuntu, porque como has
> comentado son parte del sistema base. Pero creo que no es así en Alpine.

Tendrías que investigar caso por caso. En lineas generales son
bibliotecas muy básicas, el problema va a aparecer si querés poner algo
gráfico. Ahí la cosa se complica.

>
> int analogRead(uint8_t pin)
> {
> uint8_t low, high;
>
> /* Set the channel and start a new conversion */
> WB_ADR=AD_BASE+1;
> WB_DAT=pin;
> /* Wait until the conversion ends */
> loop_until_bit_is_clear(WB_DAT,7);
> /* Read the result */
> high=WB_DAT;
> WB_ADR=AD_BASE;
> low=WB_DAT;
> /* Combine both bytes */
> return (high<<8)|low;
> }
>
>
> Deduzco por los nombres que utilizas Wishbone para la comunicación con
> los periféricos. ¿Qué versión?

Si, uso WISHBONE, ¿versión? ni idea, lo uso desde hace más de 10 años ;-)

> Es bastante configurable, pero si me pongo a agregar binarios implica
> que tengo que tener los binarios para cada plataforma.
>
>
> Yo actualmente estoy bastante contento con Golang para estas tareas.
> Utilizo esta imagen como entorno donde compilar de forma cruzada:
> https://github.com/1138-4EB/go/blob/golang-alpine/Dockerfile
> Concretamente, hay 10 plataformas:
>
> |
> darwin;386darwin;amd64 freebsd;386freebsd;amd64 freebsd;arm

> linux;386linux;amd64 linux;arm windows;386windows;amd64

> |
>
> Después, cada vez que quiero compilar un proyecto para todas, ejecuto
> esto: https://github.com/1138-4EB/elide/blob/master/travis/travis-ci.sh
>
> Entiendo que esto queda bastante adelante en el roadmap, si es que en
> algún momento entra. Pero te lo dejo como referencia por ser una
> solución genérica para cualquier proyecto. No es la solución óptima,
> porque se generan binarios estáticos, pero evitar tener que conocer
> las particularidades de cada plataforma. En caso de querer compilar de
> forma dinámica, existe la opción, pero es muy parecida a hacerlo
> directamente en C.
>
> Muchas gracias de nuevo por tu paciencia y la información.

No hay porque.

[Salvador Eduardo Tropea]

El 30/03/17 a las 11:58, Jesús Arroyo escribió:
> Buenas,
>
> *Apio drivers
>
> *No creo que tenga mucho sentido configurar los drivers en una máquina
> virtual.

Ojo, Unai está usando Docker, si corrés un Linux dentro de otro Linux no
hay máquina virtual involucrada.
Podés correr Ubuntu en Debian (o Fedora o Alpine o ...) con Docker,
ambos operativos terminan usando el mismo kernel. Sólo que cada uno
queda aislado del otro, no comparten memoria, ni file handles ni nada.

> Ese comando sólo tiene sentido ejecutarlo en una máquina real y
> completa. (PD: aunque el user sea root puede ejecutar comandos con
> sudo). Ejecutar apio como sudo tampoco tendría sentido ya que se
> estaría invocando otro binario, ésto sólo se haría si el usuario
> quiere instalar apio en root.

Ojo con sudo, en Debian sudo no se configura por defecto de la manera
que lo hace Ubuntu, nadie puede usarlo hasta que el root decida darle
permisos. Lo que hace Ubuntu es para que los usuarios acostumbrados a
OSs donde el usuario hace lo que quiera no se sientan perdidos, pero es
muy peligroso.

> Python es un intérprete y por lo tanto es necesario para ejecutar los
> scripts. GCC es el compilador y por lo tanto sólo es necesario para la
> fase de compilación, no de ejecución.
>

> *Icestorm + ...*

>
> Como comenta Salvador, los paquetes compilados para debian suelen
> estar enlazados dinámicamente por lo tanto ocupan menos. Todos los
> paquetes de Apio (toolchain-icestorm, toolchain-iverilog, etc.) están
> compilados en estático en su mayoría para garantizar que funcionan
> correctamente en cualquier distro y cualquier versión, pero como
> contra ocupan más. PD: en las últimas versiones de las toolchains se
> ha optimizado bastante el tamaño con ahorros del 35% y >70%
> respectivamente ya que he eliminado, entre otras cosas, las
> referencias al debugger.
> Las incompatibilidades del apt vienen generadas porque no encuentra de
> dónde descargar el .deb, esto se soluciona añadiéndolo a las
> sources.list, en vez de por problemas con GCC. Hay que tener en cuenta
> que hay varias distribuciones de las herramientas de Icestorm:
> toolchain-icestorm (en estático y con estructura compatible apio),
> debian de fpgalibre (dinámico y con estructura compatible con apio),
> debian (dinámico y estándar). Para trabajar con Apio hay que utilizar
> las dos primeras, o la tercera activando el modo "native".
>

> *Arduino en iCE40*

>
> Salvador esto es brutal! Yo tengo dos placas iCE40 con HX8K. Una de
> ellas es la icoBOARD que viene con memoria externa. En su momento
> estuve probando compilar para el micro picorv32 dentro de la FPGA:
> https://github.com/Jesus89/picorv32-c-examples.
> Si quieres que probemos algo de lo que estés desarrollando coméntanos
> (yo personalmente estaré encantado de tener un miniAVR sintetizado).

Muchas gracias por el ofrecimiento.
Por ahora sigo trabajando en tener una plataforma razonablemente funcional.
Ya funcionan las entradas analógicas.
Ahora estoy trabajando en los recursos que necesitan interrupciones:
- Generador de tonos
- UART
- Interrupciones por pines externos

Ya identifiqué 5 vectores de interrupción y estoy comenzando a
implementarlos, junto con los registros asociados para enmascararlas y
demás.

[Jesús Arroyo]

Efectivamente Xoan,

Los virtualenv se puede utilizar para tener múltiples versiones de Python y múltiples versiones de una misma aplicación en un mismo sistema. En Icestudio se utiliza precisamente un virtualenv para instalar apio y que no interfiera con otras posibles versiones.

Los únicos problemas que he tenido con Virtualenv han sido en Windows con rutas no-ASCII.

[Jesús Arroyo]

Correcto con Docker, aunque yo me suelo referir normalmente al caso general multiplataforma (Linux en Windows, etc). De todas formas siempre se trata de un sistema aislado.

Lo dicho, cuando lo necesites estamos de betatesters para el AVR FPGA. La verdad es que suena muy bien :)

[1138-4EB]

Hola Jesús, Xoan y Salvador,
 
A Jesús:

Apio drivers
No creo que tenga mucho sentido configurar los drivers en una máquina virtual. Ese comando sólo tiene sentido ejecutarlo en una máquina real y completa.

#127

An interesting feature of docker images is that a command (or sequence of commands) can be executed as soon as a container is started. Therefore, the content in /etc/udev/rules.d can be copied from the container to the host and execute then service udev restart.

 
----

(PD: aunque el user sea root puede ejecutar comandos con sudo). Ejecutar apio como sudo tampoco tendría sentido ya que se estaría invocando otro binario, ésto sólo se haría si el usuario quiere instalar apio en root.

En docker no existe 'sudo' (no está instalado el programa). Se puede hacer, pero para ello se recomienda gosu:

 

https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#user 

You should avoid installing or using sudo since it has unpredictable TTY and signal-forwarding behavior that can cause more problems than it solves. If you absolutely need functionality similar to sudo (e.g., initializing the daemon as root but running it as non-root), you may be able to use “gosu”.

 
Por ello, en lo que respecta al 'bug', los cambios necesarios en apio son los mismos: no utilizar sudo por defecto, sino evaluar cúando hacerlo y ofrecer más de una opción.

No obstante, como se ejecuta con el usuario root, no es necesario ni sudo ni gosu. De ahí que mi propuesta fuera sólo eliminar 'sudo' (hacerlo opcional).

----

Python es un intérprete y por lo tanto es necesario para ejecutar los scripts. GCC es el compilador y por lo tanto sólo es necesario para la fase de compilación, no de ejecución.

Gracias por aclarar lo de Python . ¿Sería posible compilar esos scripts para que no sean necesarias todas las librerías de Python y pip?

En cuanto a GCC, la duda más específica es que tanto iverilog como GHDL son compiladores (por eso la síntesis es tan complicada). Por lo tanto, no sé si son autónomos o necesitan un backend en tiempo de ejecución. Supongo que conforme vaya haciendo pruebas utilizando más funcionalidades en sistemas más ligeros iré viendo carencias.
 

Icestorm + ...

Como comenta Salvador, los paquetes compilados para debian suelen estar enlazados dinámicamente por lo tanto ocupan menos. Todos los paquetes de Apio (toolchain-icestorm, toolchain-iverilog, etc.) están compilados en estático en su mayoría para garantizar que funcionan correctamente en cualquier distro y cualquier versión, pero como contra ocupan más. PD: en las últimas versiones de las toolchains se ha optimizado bastante el tamaño con ahorros del 35% y >70% respectivamente ya que he eliminado, entre otras cosas, las referencias al debugger.

Muchas gracias por la aclaración. Ahora qure lo reviso, la palabra static está en el primer párrafo del README, pero no me fijé :S. Quizá sería interesante añadir un párrafo con esto mismo que me indicas: el hecho de que sea estático es para garantizar que funcionan correctamente en cualquier sistema, independientemente de qué librerías estén instaladas. También facilita enormemente la distribución y actualización porque son muchos menos ficheros.

En caso de hacerlo, creo útil también indicar lo que comentas sobre la optimización. Un 70% merece un mensaje para que quien tenga una versión vieja actualice :D. Asimismo, puesto que se hace referencia a los deb, y en vista de lo comentado en este hilo, quizá podríais considerar recomendar la opción nativa en los sistemas con recursos más limitados. O incluso que la opción nativa sea la utilizada por defecto, y salte a los estáticos si no existe.

Hay que tener en cuenta que hay varias distribuciones de las herramientas de Icestorm: toolchain-icestorm (en estático y con estructura compatible apio), debian de fpgalibre (dinámico y con estructura compatible con apio), debian (dinámico y estándar). Para trabajar con Apio hay que utilizar las dos primeras, o la tercera activando el modo "native".

 

En esta misma línea, ¿podrías confirmar que los binarios estáticos incluyen los icebox_*?

$ ls .apio/packages/toolchain-icestorm/bin/
arachne-pnr  icemulti  icepll   icetime  yosys-abc
icebram      icepack   iceprog  yosys

$ls /usr/local/bin/
arachne-pnr     icebox_html  icemulti   yosys
icebox.py       icebox_maps  icepack    yosys-abc
icebox_chipdb   icebox_stat  icepll     yosys-config
icebox_colbuf   icebox_vlog  iceprog    yosys-filterlib
icebox_diff     iceboxdb.py  icetime    yosys-smtbmc
icebox_explain  icebram      iceunpack

 

Las incompatibilidades del apt vienen generadas porque no encuentra de dónde descargar el .deb, esto se soluciona añadiéndolo a las sources.list, en vez de por problemas con GCC.

¿Te refieres a que los deb sólo estań en los repositorios de jessie? No deberían testing y stectch mirar en repositorios de versiones anteriores cuando no encuentren en la última?
 
A Xoan:

Quizá sea un poco offtopic, pero apio se podría instalar sin problemas dentro de un entorno virtual de Python (python-virtualenv), ¿no?

Yo uso Arch Linux, y mezclar pip con pacman nunca es bueno.

Le tengo que dar una vuelta, limpiar lo que instaló automáticamente y hacerlo de forma limpia con «venv» para documentarlo.

Esa es la idea por la que estoy trabajando con docker. Concretamente estoy en 4.10.6-1-ARCH. Puedes echar un ojo a https://github.com/1138-4EB/elide#run-toolchain-in-a-docker-image Para una prueba rápida, simplemente instala docker y arranca el servicio:

sudo pacman -S docker
sudo systemctl start docker

Para lanzar un contenedor con icestorm + arachne-pnr + yosys + iverilog + graphviz + gtkwave + python-3.6.1, simplemente ejecuta:

sudo docker run --rm -it \
>  -v /tmp/.X11-unix/:/tmp/.X11-unix \
>  -e DISPLAY=unix$DISPLAY \
>  11384eb/elide:alpine-run sh

Nota: para no tener que usar sudo puedes crear un grupo de usuarios llamado 'docker' y añadirte al mismo: https://docs.docker.com/engine/installation/linux/linux-postinstall/

Una vez ejecutado, verás que la prompt cambia a '/work # '. A partir de ahí todos los comandos que ejecutes estarán en un entorno virtual basado en Alpine Linux 3.5. Las líneas 2-3 de la orden son para poder lanzar aplicaciones con GUI a través de tu servidor X11 (supongo que no utilizas wayland todavía), por lo que puedes ejecutar 'gtkwave'. Cuando termines de utilizar las herramientas, exit y volverás a tu Arch.

Nota: no sé por qué, la primera vez que ejecutas gtkwave los iconos no se cargan correctamente (las fuentes sí). Simplemente cierra la ventana (la de gtkwave, no la terminal) y vuelve a lanzarlo. Esto es sólo la primera vez que inicias el contenedor, después se mantiene la configuración. En estas dos imágenes se ve a qué me refiero:

   

Observése que el tema del borde de las ventanas es el de Arch, mi host, no el del contenedor, pero los iconos y el tipo de fuente están definidos en el contenedor (Alpine).

En el repositorio puedes encontrar más detalles, así como otros contenedores basados en fedora, debian y ubuntu. Algunos con apio, y otros instalados desde las fuentes.

A Salvador:

 

sistemas operativos caóticos que no poseen el concepto de paquetes (me refiero a esa cosa que sigue dándole plata a la empresa de Redmond).

XD
 

Para sistemas operativos como Debian es una locura. Pensá que tenés una máquina que la usan 6
personas, 3 quieren usar IceStorm, pero sin APIO y 3 quieren usarlo, pero con APIO. Sin usar los paquetes que yo armé terminás con 4 copias
de IceStorm, una enlazada dinámicamente e instalada a nivel de sistema, y 3 copias enlazadas estáticamente e instaladas en el home de cada
usuario. Ni hablar que las 4 pueden hasta ser diferentes versiones, con lo que es un caos reproducir errores. Con los paquetes Debian se
soluciona, hay una única copia que usan todos.

Muchas gracias, de nuevo, por la claridad en la explicación. Me ha servido para percatarme de que mi solución actual (el contenedor basado en Alpine que le he comentad a Xoan) no es todo lo óptima que podría. Está basado en librerías enlazadas dinámicamente, que como has indicado un par de párrafos atrás, es la opción por defecto. Esto es un ahorro con respecto a la compilación estática, porque varios programas en el mismo contenedor comparten las mimas librerías básicas (que me explicitaste en un mensaje anterior). En general, estoy bastante satisfecho con haber metido todo lo indicado en un fichero que ocupa 146M comprimido.

Sin embargo, si se lanzan varios contenedores al mismo tiempo (uno para cada usuario), se estarán realizando múltiples copias de todo. Por ello, creo que el siguiente paso debería ser lanzar una sola copia "maestra". Después, que cada usuario lance un contenedor "scratch" (vacío) y monte todo el sistema de archivos del "maestro" excepto "home". ¿Esto es lo que hace cualquier linux "grosso modo"? En otras palabras ¿hay algún otro directorio en el sistema que dependa del usuario además de /home/user?
 

> Entiendo que el deb, además crea enlaces simbólicos para apio y copia
> los scripts de apio en sí. Pero tengo la sensación de que no utilizas
> los binarios en https://github.com/FPGAwars/toolchain-icestorm, ¿es así?

Exactamente, sería una locura hacerlo.

Lo es XD. Pero no queda más remedio en distribuciones y/o arquitecturas en las que no hay paquetes para cada herramienta. De ahí me sugerencia anterior a Jesús sobre explicitar en el README cuándo es preferible una opción y cuándo otra. Tal como yo lo veo, coincidiendo contigo, en sistemas Debian lo más sensato es utilizar los paquetes nativos cuando la arquitectura esté soportada. Si no existen los paquetes, por la arquitectura o el SO, la solución directa son los binarios estáticos de apio. Por último, para elecciones más precisas están las imágenes docker '*-dev'. Estas permiten, opcionalmente a través de QEMU, compilar para la architecura deseada, el SO preferido y la versión de cada librería que se prefiera, sea de forma dinámica o estática.

De hecho, actualmente, he creado dos imágenes para cada imagen base: una incluye todas las dependencias necesarias para compilar todas las herramientas desde las fuentes. A partir de la misma, se descarga a través de git/mercurial la versión deseada de cada herramienta, se compila, se ejecuta el test de yosys, y se extraen los binarios (dinámicos, por defecto). Por último, se crea la segunda imagen "limpia", sólo con las dependencias de ejecución, y se copian los binarios a /usr/local. Me falta incluir QEMU para la compilación cruzada (ARM es el principal objetivo).
 

No conozco Alpine, pero estas bibliotecas las usan los comandos más
básicos del OS. Salvo cosas hechas para embebidos lo normal es que estén.

De hecho, Alpine es una distribución para sistemas embedidos:

https://en.wikipedia.org/wiki/Alpine_Linux 

Originally, Alpine Linux began as a fork of the LEAF project.^[3] The members of LEAF wanted to continue making a Linux distribution that could fit on a single floppy disk, whereas the Alpine Linux wished to include some more heavyweight packages such as Squid and Samba, as well as additional security features and a newer kernel. One of the original goals was to create a framework for larger systems; although usable for this purpose, this is no longer a primary goal.

No obstante, aunque en sitios diferentes y con otro nombre, he comprobado que casi todos los comandos están (gracias a ldd que me enseñaste). Así he añadido los que faltaban, que son principalmente readline y xz. Puedes ver la lista concreta de dependencias aquí: https://github.com/1138-4EB/elide/blob/master/docker/Dockerfile-alpine-run Las dos últimas líneas, comentadas, son los que creía que podrían ser necesarios, pero por el momento no los he echado en falta.
 

Tendrías que investigar caso por caso. En lineas generales son bibliotecas muy básicas, el problema va a aparecer si querés poner algo gráfico. Ahí la cosa se complica.

Efectivamente, me dio un poco de dolor de cabeza que después de instalar gtk, al arrancar gtkwave, no había ni fuentes ni iconos. Instalé el navegador "midori" dentro del contenedor y podía arrancarlo pero cascaba en cuanto intentaba hacer click. Total, que todo se solucionó en cuanto instalé fuentes ttf completas y un pack de iconos. Todavia hay algún detalle que pulir, pero en general va como la seda.

Si has tenido alguna experiencia anterior poco satisfactoria al intentar ejecutar aplicaciones GUI en docker, te recomiendo echar un ojo a este artículo y su correspondiente repositorio en github: https://blog.jessfraz.com/post/docker-containers-on-the-desktop/

 

Si, uso WISHBONE, ¿versión? ni idea, lo uso desde hace más de 10 años ;-)

Hubo una "actualización" en 2010: https://opencores.org/cdn/downloads/wbspec_b4.pdf
No es que sea "muy nuevo" tampoco XD. Es una pena, porque parece que el proyecto está abandonado.

En cualquier caso, la diferencia principal es entre "Classic Bus Cycles" y "Registered Feedback Bus Cycles". Para escrituras/lecturas de un solo dato, la diferencia es irrelevante. Pero en transferencias de bloques de datos, especialmente en sistemas segmentados, el rendimiento mejora significativamente.

Me interesa especialmente porque yo utilizo la versión registered feedback para implementar buses internos a medida en mis diseños. No cumplo el estándar en cuanto a nomenclatura porque utilizo records en VHDL (que son como structs en C) para agrupar todas las señales de una interfaz. Además, los tamaños de palabra los defino en bits, y no en bytes. Observarás que ambas cuestiones pueden solventarse fácilmente con un wrapper que haga una simple conversión de tipos. También utilizo AXI-stream y AXI-lite, pero para proyectos libres prefiero Wishbone.

Si la versión del protocolo que utilizas es compatible, podría aportar algún periférico al sistema cuando esté más avanzado. Una tiny red neuronal compuesta por dos MACCs, por ejemplo.

Saludos, y muchas gracias a todos por vuestras aportaciones.