[ZEOMA] ¡Imágenes (casi) finales del prototipo de carcasa/controles! [ZEOMA]

[nintiendo1]

Esto va tomando forma y ayudará a la realización del proyecto, sin duda. Siento no estar muy activo, mucho curro

Bueno, por ahora lo más importante es el diseño del PCB, que se está encargando Archer (cuando vuelva a principios de Octubre de su viaje se pondrá de nuevo con el diseño), así que mientras tanto no podemos avanzar mucho (por ejemplo, yo he pedido que le manden la pantalla para ir avanzando).

Saludos.

[nintiendo1]

Bueno, aquí os dejo un mensaje con los avances que hay con la tablet, sobre todo porque nos servirá para aprender en el diseño de la ZEOMA:

2nd revision, more hardware confirmed working

(Status update at the PCB page). The 3-axis sensor has been confirmed as being a 2-axis MXC6225 sensor, and, through a small python program that opens the /dev/mxc622x entry and carries out a couple of ioctls, confirmed as working. Also the address of the I2C EEPROM has been confirmed (and the elinux.org EOMA68 specification updated accordingly). The reason for updating the specification is because the mistake was made in reading the AT24C64 datasheet: there is no point having a specification where the EEPROM's I2C address is impossible to match, with an address where there are simply no EEPROMs available on the market.

For USB, a mistake has been discovered in the schematics: there is a 1.5k pull-up resistor missing from the USBDP line. Currently there is a resistor precariously perched on top of the STM32F, wired between a USB cable that's soldered directly to the STM32F pins. The libopencm3 usbhid example was then uploaded, and the STM32F responded by turning into a mouse.

Next up was apalmer's audio patches to libopencm3, along with some gratefully-received demo code. libopencm3 as it stands does not have ISOCHRONOUS usb, nor proper support for USB attributes and descriptors: apalmer's patch adds this capability (USB IN only). The code was compiled and demonstrated as successfully working, by being able to record an (accidentally) reversed sine-wave which was generated by DMA reads off of the STM32F.

All in all this is extremely good progress. The challenging parts are going to be the speakers, microphone and the camera. The microphone should be reasonably straightforward: read the ADC and output it as data. Speakers: last time they were tried, the amplifier IC was overloaded - some care has to be taken here. The camera is quite involved: it needs to be powered up carefully (by programming the AXP209 to output 2.8V), then the Camera can be programmed over I2C. After that the Master Clock can be enabled at around 15mhz, and then data read back in a very fast interrupt handler and stored for transfer over USB. This is where it will get... interesting...

Ya han conseguido más avances en la tablet + EOMA. En concreto son con el STM32F:

Status:
- CPU Card: all interfaces confirmed working (as of mid-september)
- STM32F: working (and programmable). UART communication established
- LCD Power-Enable: working (GPIO pull-up on STM32F)
- LCD Backlight: working (GPIO pull-up 100% on STM32F instead of PWM)
- IPS 1024x600 LCD (LVDS): working fully (power-up, display, backlight)
- I2C Bus and devices: working (see i2cdetect below)
- USB 4-port hub: working (see lsusb below)
- WIFI: working with rtlwifi driver (scan at least)
- I2C MXC6225 2-axis sensor: working (sort-of. one axis confirmed operational)
- STM32F accessible on USB bus: confirmed (1.5K pull-up resistor needed)

TODO:
- Confirm access to I2C EEPROM operational
- forward-port touchpanel I2C experiments from 3.3-dev to sunxi-3.4 kernel
- Confirm (again) FT5306 touchpanel working
- experiment (cautiously) with speaker PWM output
- experiment (cautiously) with microphone ADC input
- experiment (cautiously) with AXP209 for Camera voltages
- experiment (cautiously) Camera
- compile up stm32f tools on CPU Card and add them to startup

Saludos.

[Endor]

Gracias por el currazo de buscar todo y mantener vivo el proyecto

[nintiendo1]

Os dejo los nuevos avances que hay en la tablet y un vídeo que ha hecho su autor para mostar los avances:

2nd revision, ADC (for Microphone) confirmed operational

(Status update at the PCB page). The firmware for the Flying Squirrel is making good experimental progress. An interesting learning curve with the ADC has shown that it's necessary to carry out a hard reset of the STM32F ADC subsystem: it's insufficient to just power it off and on again, it's necessary to power off, reset, then configure and finally switch on. Once this was discovered (through random internet searches) reading the ADC was very straightforward, and also successful.

The next part was making it easy to read the ADC values, for debugging purposes. This was achieved by turning the STM32F USB gadget into a CDC ACM (USB Serial) interface. Copying one of the libopencm3 examples turned out to be very straightforward. Next up will be adding a Timer around the ADC as well as using DMA. Enough code exists: it just needs to be successfully plugged together.

The actual circuit around the LM13700 however is a different matter. The layout from March bears absolutely no relation to the example schematics in the datasheet! Fortunately, there are three LM13700 ICs now available to experiment with, as a means to create a working amplifier circuit.

Software-wise the microphone is turning out to be straightforward as expected, and the progress being made will help accelerate the development of the tougher task - the camera. The camera will require not just DMA but possibly some very tight post-processing and more. The fact that it's now possible to interact with the STM32F as a USB-Serial device will make debugging that much easier.

A video showing the progress made:

Saludos.

[nintiendo1]

Ya han conseguido aceleración 3D con Ubuntu 13.04 para el EOMA-68 con Allwinner A20:

Ubuntu 13.04 Desktop Linux With 3D Acceleration Working on EOMA68-A20:

Functions more and more like a real PC now.

Kicad also got installed and it is reasonably usable. So use that to design your next EOMA application PCBs

Also installed were xfce4, lxde and openbox window managers. Gambas installed from sources.

The sound works through jack socket (hdmi sound - nothing as yet although it is known to work through booting up Android), and espeak works. So you could send it commands through serial port for example software, let gambas serial port program read the text and then the machine can be made talk back by gambas calling espeak.



The image is available on this link http://www.gplsquared.com/eoma_boot/...3_04_3d.bin.xz
(Further operations require use of dd command which can seriously damage your disk data if you are not sure how to use it properly.)
Unzip the image file, and the use the dd command to write the image to an ext4 partition such as /dev/sda1 on a fresh new hard disk. Then run gparted, right click and select check to repair partition problems.

The uSD boot cards set to boot from SDA1 are available for EOMA68-A20 http://www.gplsquard.com/eoma_boot/u...a1_eoma.bin.xz and Cubieboard2 http://www.gplsquard.com/eoma_boot/u..._cubie2.bin.xz .
Unzip the image file and use the dd command to write the image to the uSD card directly to the device e.g. /dev/sdc

The 3 image files were made by extending the work earlier (2013-09-29) using instructions at http://linux-sunxi.org/Binary_drivers
A big thanks to popolon of freenode #cubieboard, rz2k and ssvb from #linux-sunxi.
popolon first made it work on the image file after hunting down all the details. This is a duplicate of those attempts.
:
When installing 3D acceleration against this version of Ubuntu, came across a number of problems.
1. Create /dev/ump and /dev/mali manually and set permissions to 777. The advise to set up 50-mali.rules doesn't work.
2. The command mv /usr/lib/arm-linux-gnueabihf/mesa-egl/ /usr/lib/arm-linux-gnueabihf/.mesa-egl/ needed to be run earlier otherwise later compiling may not work.
3. Install mesa-utils, mesa-utils-extra, and glmark2-es2. The mesa utils has a package glxgears, mesa-utils-extra has the es2gears program and the program glmark2-es2 are all test
programs to check 2D/3D accleration. The blue cat in above picture is from glmark2-es2.

The linux checked out was stage/sunxi-3.4 and compiled in 8 minutes on a 2.4GHz quad core. The versions and their details can be found in this file git_show_2013_10_07.txt
The instructions for obtaining and compiling the Linux is same as before.
The exact .config file used is automatically placed in the /proc/config.gz file which can be found by booting the Linux and checking in /proc directory.
A copy of it is at http://www.gplsquared.com/eoma_boot/...2013_10_06.txt

Terminology
Opengl is a graphics lib, but a lot of it is proprietary despite wanting to calling itself open, opengl ES is a cut down version for embedded CPUs, and mesa is the 'real' gpl'd version of opengl.
What is working is the cut down opengl ES. So if the software requires opengl or mesa then it may not work. If it can use opengl ES then it can work fairly well.
If software can use emulation of opengl, then that too will work, though it will be slow. Software rendering has advantage that it works over X/ssh tunnel.

Additional software
Also installed from the repositories were gparted, kicad, gimp. xmaxima (symbolic maths solver), libreoffice, htop, xfce4, lxde, openbox, rasmol, wicd, inkscape and kdiff3.
The kicad is reasonably usable to design new PCBs.

Everything is from sources. The links should and version number information should get you exact information. If anything is missing, let me know.

[BonesCollector]

Que tan opensource es el Allwinner A20 ?? tiene soporte open del fabricante o han sacado drivers por ingeniería inversa ??

[nintiendo1]

Que tan opensource es el Allwinner A20 ?? tiene soporte open del fabricante o han sacado drivers por ingeniería inversa ??

Pues sí, parece que Allwinner Tech da soporte a sus SoC. De hecho, el creador del EOMA-68 siempre ha intentado buscar un SoC que fuese lo más abierto posible, por eso escogió el Allwinner A20.

Respecto a los driver 3D, el Allwinner tiene Mali, así que tiene los mismos drivers "open" que todos los Mali (es decir, ninguno xD). Con respecto a los demás drivers, sí, creo que todo (o casi todo) está liberado por ellos.

Por último, para aclarar el apoyo de Allwinner, uno de los ingenieros de Allwinner, es el creador de la CubieBoard. De hecho, este mismo ingeniero es el que nos ha ayudado a conseguir la pantalla TFT (¡gracias!) para la ZEOMA.

Ahora estoy con el tema de la pantalla táctil. Esto es importante para @PuNk_NoT_DeAd. Me haría falta que me dijeses una cosa sobre ella, ¿cuales son las dimensiones recomendadas que tú le quieres poner al marco negro? ¿Y las dimensiones máximas que podría tener ese marco negro?

Saludos.

[PuNk_NoT_DeAd]

Pues sí, parece que Allwinner Tech da soporte a sus SoC. De hecho, el creador del EOMA-68 siempre ha intentado buscar un SoC que fuese lo más abierto posible, por eso escogió el Allwinner A20.

Respecto a los driver 3D, el Allwinner tiene Mali, así que tiene los mismos drivers "open" que todos los Mali (es decir, ninguno xD). Con respecto a los demás drivers, sí, creo que todo (o casi todo) está liberado por ellos.

Por último, para aclarar el apoyo de Allwinner, uno de los ingenieros de Allwinner, es el creador de la CubieBoard. De hecho, este mismo ingeniero es el que nos ha ayudado a conseguir la pantalla TFT (¡gracias!) para la ZEOMA.

Ahora estoy con el tema de la pantalla táctil. Esto es importante para @PuNk_NoT_DeAd. Me haría falta que me dijeses una cosa sobre ella, ¿cuales son las dimensiones recomendadas que tú le quieres poner al marco negro? ¿Y las dimensiones máximas que podría tener ese marco negro?

Saludos.

No se si te refieres a lo que te voy a decir pero bueno ,hay va, el marco mide 115mm de largo por 75mm de alto y podría medir sin que choque con los botones o sin llegar a la parte curva de carcasa por arriba,hasta unos 120mm de largo y 92mm de alto, no se si es esto lo que querías saber.

Salud.