[ZEOMA] Diagrama de Bloques de ZEOMA (PCB) [ZEOMA]

[nintiendo1]

Nop, hasta octubre no podré mirar gran cosa, pero si averiguo algo lo pondré por aquí.

Ok, no te preocupes. Cuando vuelva Drumpi (que supongo que será dentro de poco) a ver si empezamos con los esquemas, y ya cuando en octubre tengas más tiempo libre, si puedes nos ayudas y vamos más rápido.

Por cierto, he puesto el diagrama de bloques en el foro-email de la EOMA-68 y me han dicho lo siguiente:

there are two EINT lines on EOMA68. i suggest that one of them be connected to the AXP209, and the other to the STM32F072, although because there are only 2 this leaves some slight issue with the touchpanel to resolve (in linux kernel source, which will need modification).

the problem is this: things like the touchpanel it is fairly essential (because you want to wake up the entire device based on an EINT) to have external interrupt.

one alternative to modifying the linux kernel source is to have a NAND (NOR?) IC multiplexing multiple IRQ lines from various peripheral ICs onto the one EINT line.

another alternative is to wire the AXP209 to the STM32F (on one of its GPIOs, then put that into EINT mode), then have the STM32F software generate a simple GPIO pull-up out to one of the EOMA68 EINTs.

so instead of doing the multiplexing using a NAND (NOR) gate IC, you do it in software (firmware) instead.

then you can do whatever you want, without modifying any linux kernel source.

so, you need to identify which devices have IRQ outputs. i count these:

* Accelerometer
* Touch panel
* AXP209
* STM32F072xx
* MicroSD
* Headphone detect

all of these _should_ be connected to (generate) EINTs... but there are only 2 EINTs available...

* analog joysticks are exactly that, they always generate data so there is no concept of "IRQ"
* power button is connected to the AXP209 so the AXP209 does the "IRQ"
* Buttons are converted to USB HID (keyboard) events via the STM32F072 in software...

anything else?

¿Como lo veis vosotros? ¿Cual sería la mejor opción?

Saludos.

[Drumpi]

Hola, chicos, he vuelto (no, por favor, no me pongais la voz del Chuache ).
Llevo unos días que no paro, entre vuelta de vacaciones, limpieza, llamadas de entrevistas de trabajo (a ver si cae alguna), etc y por eso no he entrado.

Vengo a decir que, por desgracia, no he podido mirar nada de nada este verano, lo siento mucho: la conexión a internet estaba muy restringida, y el ordenador apenas lo he sacado de la funda. Empiezo a pensar que no puedo estar a la altura de el proyecto. Voy a seguir intentándolo pero a este ritmo casi mejor que venga otro a sustituirme.
Voy a intentar ponerme al día con el foro y con el proyecto. De momento, de los mensajes que he leido de la página 3, hay dudas en si usar dos chips para el input (uno digital y otro analógico) o un microcontrolador para todo. Bueno, no puedo dar una opinión concreta, pero la opción del microcontrolador parece la más viable, porque es la que (quizás) menos sitio ocupe en la placa, requiera menos líneas y es más flexible, no sólo porque podemos añadir más o menos elementos, es que podemos incluir la lectura de cosas como acelerómetros, sensores de luz o temperatura... La contrapartida es que es posible que sea más lento, al necesitar de un pequeño código para leer, interpretar, codificar y comunicarse con la CPU (suelen ser rápidos, pero ¿más rápidos que dos chips dedicados o que la CPU?), o que consuma bastante. También está el tema de programarlo... pero bueno, si la documentación es buena, codificar la funcionalidad no debería llevar más de un mes, ya sea en ASM o pseudo-C (con el 68000 he programado filtros de audio en un par de días).

Si queremos ir a lo simple, lo de los chips dedicados por separado es la solución fácil. Si queremos algo más flexible, pese a que vamos a necesitar algo más de trabajo para sincronizarlo, el microcontrolador es lo mejor. Pero ya digo, esto sabiendo del tema un 10%. [/divagando mode]

[nintiendo1]

Hola, chicos, he vuelto (no, por favor, no me pongais la voz del Chuache ).
Llevo unos días que no paro, entre vuelta de vacaciones, limpieza, llamadas de entrevistas de trabajo (a ver si cae alguna), etc y por eso no he entrado.

Vengo a decir que, por desgracia, no he podido mirar nada de nada este verano, lo siento mucho: la conexión a internet estaba muy restringida, y el ordenador apenas lo he sacado de la funda. Empiezo a pensar que no puedo estar a la altura de el proyecto. Voy a seguir intentándolo pero a este ritmo casi mejor que venga otro a sustituirme.
Voy a intentar ponerme al día con el foro y con el proyecto. De momento, de los mensajes que he leido de la página 3, hay dudas en si usar dos chips para el input (uno digital y otro analógico) o un microcontrolador para todo. Bueno, no puedo dar una opinión concreta, pero la opción del microcontrolador parece la más viable, porque es la que (quizás) menos sitio ocupe en la placa, requiera menos líneas y es más flexible, no sólo porque podemos añadir más o menos elementos, es que podemos incluir la lectura de cosas como acelerómetros, sensores de luz o temperatura... La contrapartida es que es posible que sea más lento, al necesitar de un pequeño código para leer, interpretar, codificar y comunicarse con la CPU (suelen ser rápidos, pero ¿más rápidos que dos chips dedicados o que la CPU?), o que consuma bastante. También está el tema de programarlo... pero bueno, si la documentación es buena, codificar la funcionalidad no debería llevar más de un mes, ya sea en ASM o pseudo-C (con el 68000 he programado filtros de audio en un par de días).

Si queremos ir a lo simple, lo de los chips dedicados por separado es la solución fácil. Si queremos algo más flexible, pese a que vamos a necesitar algo más de trabajo para sincronizarlo, el microcontrolador es lo mejor. Pero ya digo, esto sabiendo del tema un 10%. [/divagando mode]

En teoría, y según estuve hablando con Segata Sanshiro, vamos a optar por el microcontrolador, y en caso de que no podamos, ya optamos por los chips dedicados.

Cuando ya saques tiempo, ya puedes empezar a mirarlo y empezar los esquemas. Una buena base es el 1º post, en el que hay un diagrama básico con las conexiones.

Saludos y gracias.

[nintiendo1]

Invoco a @Drumpi para saber si ha habido a algún avance.

Por otro lado, también a @Segata Sanshiro para saber si ha mirado algo del microcontrolador.

Respecto al EOMA-68, ya tiene terminado los EOMA-68 con Allwinner A20, así como la placa para usarlo como un miniPC y ahora están terminando la tablet.

En poco tiempo lanzarán la campaña de crowfunding: https://www.crowdsupply.com/eoma68/micro-desktop

Saludos.

[Segata Sanshiro]

Buenas! No he mirado nada, pero no me he olvidado. Te dije que miraría en octubre, que es cuando iba a volver a tener tiempo libre pero se me ha alargado la cosa, espero poder ponerme con ello en enero.

[Drumpi]

Yo tampoco he mirado nada, con el tema del máster y un par de entrevistas de trabajo (y terminar el segundo video ^^U) se me ha ido el santo al cielo.

[nintiendo1]

Buenas! No he mirado nada, pero no me he olvidado. Te dije que miraría en octubre, que es cuando iba a volver a tener tiempo libre pero se me ha alargado la cosa, espero poder ponerme con ello en enero.

Ok, sin problemas, ya en Enero cuando te pongas nos avisas.

Yo tampoco he mirado nada, con el tema del máster y un par de entrevistas de trabajo (y terminar el segundo video ^^U) se me ha ido el santo al cielo.

Ok, cuando vayas mirando ya nos cuentas. Por otro lado, cualquier duda ponla aquí y se lo pregunto al del EOMA-68, o puedes registrarse en su especie de foro-email y preguntárselo a él, seguro que está dispuesto a ayudarte.

Saludos.

[nintiendo1]

Os pongo el siguiente mensaje del creador de la tablet:

http://rhombus-tech.net/community_id...e_tablet/news/
the mendel90 printer is working really well, and was absolutely worth
it to use for prototyping of casework. the 7in tablet project is now
being done as an open hardware project, under the GPLv3+. files are
available at http://hands.com/~lkcl/eoma/kde_tablet
with a preliminary casework finished that has been prepared in
conjunction with the pcb layout, work can proceed to finalise the pcb
and then send it off for assembly. there are a couple of risky areas
on the tablet pcb, due to datasheets and app notes simply not being
available: the usb audio and the usb camera IC. these are a CM108AH
and a Vi Micro VC0345 respectively. perhaps prior to sending off this
PCB it may be worthwhile tracking down small USB devices with those
chipsets in, in order to inspect them and check their PCB layout.

Yo lo considero bastante bueno, ya que la tableta pasa a ser completamente abierta y la licencian con GPLv3.

Esto significa que si hacemos nuestro PCB basado en GPLv3 podemos reutilizar todas las partes de la tablet (que son bastantes), y además al ser GPLv3, seguro que el creador de la tablet/EOMA-68 nos podría ayudar si tenemos dudas.

En teoría aquí deben estar todos los archivos de la tablet: http://hands.com/~lkcl/eoma/kde_tablet Yo le he echado un vistazo y hay bastantes cosas de diciembre, que será los archivos de la tablet del PCB, pero vamos, yo no entiendo de eso, así que os lo dejo por si queréis echarle un vistazo.

Saludos.

[nintiendo1]

Me han mandado el siguiente email el creador del EOMA-68:

hi, just checking in to see how things are going, we are likely
to launch in a couple of weeks with the desktop unit. the offer to
help with the pcb for the console is still open: i worked out how to
convert to kicad if you absolutely absolutely must do so, you can go
via PADS to Altium and from there export to ASCII PCAD which kicad can
import from.

relatively speaking it will not take me very long as PADS has proper
design rules, an auto-router, push-and-shove, is not a total pain to
work with. it would take me a few weeks, especially just converting
what i already have, but if you use KiCAD it will take absolutely
months.

i have released the tablet PCB files as GPLv3+ Open Hardware btw.

Invoco a @Drumpi y @Segata Sanshiro ya que son los que han mostrado interés en el PCB, para que me digáis que le respondo, ya que yo no tengo ni idea de PCB y no puedo ayudar en ese aspecto.

Saludos y gracias!

[Drumpi]

Por mi parte, estoy absorto a tope con el Máster, y me temo que me es imposible mirar nada del Zeoma, especialmente en, si he entendido bien, el poco tiempo que nos queda hasta que deje de ser un proyecto abierto (aunque parece que parte del HW será abierto, de todas formas).
Ya digo que me gustaría dedicarle tiempo al proyecto, pero me parece que no tengo horas ni motivación suficiente para ello. Lo siento.
No digo que sea un "no" definitivo, en serio, me encantaría desarrollar HW para una consola abierta, y que volviera el espíritu de GP32 y GP2X, pero cada vez que digo de abrir los PDF tengo que hacer otra cosa (incluso el último video que he editado se ha alargado seis meses de producción). Sigo diciendo lo mismo, si hay alguien que se pueda hacer cargo, por mi bien, si no, pues a medida que vaya leyendo cosas, iré montando lo que pueda, porque lo que veo y lo que estudié tienen como unos 20 años de diferencia tecnológica

Espero que esto no suponga un problema para la gente que está ilusionada con el proyecto.

[nintiendo1]

Por mi parte, estoy absorto a tope con el Máster, y me temo que me es imposible mirar nada del Zeoma, especialmente en, si he entendido bien, el poco tiempo que nos queda hasta que deje de ser un proyecto abierto (aunque parece que parte del HW será abierto, de todas formas).
Ya digo que me gustaría dedicarle tiempo al proyecto, pero me parece que no tengo horas ni motivación suficiente para ello. Lo siento.
No digo que sea un "no" definitivo, en serio, me encantaría desarrollar HW para una consola abierta, y que volviera el espíritu de GP32 y GP2X, pero cada vez que digo de abrir los PDF tengo que hacer otra cosa (incluso el último video que he editado se ha alargado seis meses de producción). Sigo diciendo lo mismo, si hay alguien que se pueda hacer cargo, por mi bien, si no, pues a medida que vaya leyendo cosas, iré montando lo que pueda, porque lo que veo y lo que estudié tienen como unos 20 años de diferencia tecnológica

Espero que esto no suponga un problema para la gente que está ilusionada con el proyecto.

No entiendo bien eso de "el poco tiempo que nos queda hasta que deje de ser un proyecto abierto". Todo el PCB sería abierto y para siempre.

De todas formas, no te preocupes.

Bueno, ya solo me queda la opinión de @Segata Sanshiro (no sé si habrá alguien más en el foro interesado), a ver que dice.

Saludos.

[Segata Sanshiro]

Yo sigo igual, liado con el trabajo y el PFC, y aprovecho mal el poco tiempo libre que tengo. Mis sugerencias para contestarle serían las siguientes:

- Agradecerle su interés continuado por el proyecto
- Comentarle que apenas tenemos gente que se esté dedicando a ello
- Todavía quedan cosas por decidir del diseño, como la elección definitiva del SoC para los controles, aunque si no recuerdo mal solo quedaba eso y poco más, ya que muchas otras decisiones ya se han tomado para la tablet y el portátil (circuito de carga de batería, etc.)
- Nosotros no podemos usar software CAD de pago para el diseño, pero si él quiere trabajar en el proyecto de la consola con el software de su elección será por supuesto bienvenido

[nintiendo1]

Yo sigo igual, liado con el trabajo y el PFC, y aprovecho mal el poco tiempo libre que tengo. Mis sugerencias para contestarle serían las siguientes:

- Agradecerle su interés continuado por el proyecto
- Comentarle que apenas tenemos gente que se esté dedicando a ello
- Todavía quedan cosas por decidir del diseño, como la elección definitiva del SoC para los controles, aunque si no recuerdo mal solo quedaba eso y poco más, ya que muchas otras decisiones ya se han tomado para la tablet y el portátil (circuito de carga de batería, etc.)
- Nosotros no podemos usar software CAD de pago para el diseño, pero si él quiere trabajar en el proyecto de la consola con el software de su elección será por supuesto bienvenido

Ok, ya se lo he enviado, cuando me responda ya lo pongo por aquí.

Gracias.

[nintiendo1]

Para @Segata Sanshiro

En relación a esta frase:

- Todavía quedan cosas por decidir del diseño, como la elección definitiva del SoC para los controles,

Él me ha respondido:

ok - at least though if he has some schematics it would be a much faster start

Y en relación a esta frase:

- Nosotros no podemos usar software CAD de pago para el diseño, pero si él quiere trabajar en el proyecto de la consola con el software de su elección será por supuesto bienvenido

Él me ha respondido:

what software has he got? i can do some conversions, now - i have
(sort-of) access to PADS 9.3, Altium 14 (i think) and ORCAD/Allegro
16.3 . not a big fan of orcad/allegro i can tell you

through all of those i _can_ convert to PCAD ASCII, which KiCAD can
import (yay)

Ya me dirás que le contesto.

Saludos y gracias!

[Segata Sanshiro]

En el trabajo uso software antiguo de Mentor Graphics (me es difícil tener acceso a él) y en casa solo puedo usar software gratuito (Eagle free o KiCad).

Sobre lo del esquema, de momento no tenemos nada. Yo no sé si sería capaz de hacerlo, ni cuándo