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

[nintiendo1]

Según comento Segata Sanshiro (el forero, no SEGA xD), lo suyo para empezar el diseño del PCB era hacer un diagrama de bloques.

No sé muy bien lo que es un diagrama de bloques, ya que no sé nada sobre PCB y diseños, pero bueno, he estado haciendo un diagrama de bloques básico a ver si sirve (ya me diréis los expertos), pero no sé si está muy básico o debería de incluir más datos (como ya he dicho, ni idea de esto).

Ya están todos los componentes (o por lo menos hasta el nivel de conocimientos que yo llego).

Mi idea, es que los que sabéis de esto, lo vayáis revisando, por si hay algo mal, hay que detallar más cosas o lo que sea. La idea es que gente que ha mostrado interés en el proyecto, como Drumpi o Segata Sanshiro lo vayan revisando, pero sé que en este foro hay más gente con conocimientos sobre estos temas, como ArChEr o Limonetti y seguro que más que no han dicho nada, pero que andan muy escasos de tiempo, por lo que si quieren pueden revisar en los ratos libres lo que puedan. Por cuanta más gente sea revisado, pues mejor, ya que si cada uno puede aportar su granito de arena, más lejos llegaremos y más posibilidades tendremos de que vea la luz.

A continuación os dejo lo que hay.



----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
Diagrama de Bloques ZEOMA v.1.0
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------


-----------------
Slot PCMCIA:
-----------------

Modelo: Amphenol G659EU1X2472X
Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/G659EU1X2472X.PDF
Desde aquí se sacan las conexiones del EOMA-68.
Lista de pines: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Table_of_EOMA-68_pinouts


------------
Pantalla:
------------

Modelo: BTL507212-W677L
Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/5.0''%20LCD%20HD%20-%20GL5005%20Spec_D.pdf
Conexiones:
- Las pines MIPI van conectados a los pines MIPI del MIPI-a-RGB IC.
- Los pines del PWM van conectados a los pines PWR de la EOMA-68.
- La pantalla va conectado al GPIO del STM32F para el power-up del LCD.


---------------
MIPI-a-RGB IC:
---------------

Modelo: SSD2828
Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/SSD2828QN4_1.0.pdf
Conexiones:
- Los pines MIPI van conectados a los pines MIPI de la pantalla.
- Los pines RGB van conectados a los pines RGB de la EOMA-68.
- Los pines SPI van conectados a los pines SPI de la EOMA-68.


----------------
Panel táctil:
----------------

Modelo: no hay modelo definitivo.
Datasheet: no hay modelo definitivo. Un datasheet de un modelo parecido: https://dl.dropboxusercontent.com/u/19251472/D50-L4030A-K0D.pdf
Conexiones:
- Los pines I2C van conectados a los pines I2C de la EOMA-68.


-----------
Batería:
-----------

Modelo: LP8067100-CI
Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/LP8067100-CI.pdf
Conexiones:
- Los pines de la batería van conectados al conectar de la batería.


------------------
Conector Batería:
------------------

Modelo: PH-LT-WT-NA
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/PH-LT-WT-NA%E6%89%BF%E8%AE%A4%E4%B9%A6.pdf
Conexiones:
- Los pines del conector de batería van conectados a los pines de batería del PMIC.


------------------
MicroUSB carga:
------------------

Este microUSB solo se encarga de cargar la batería (no es USB Host).
Modelo (provisional): 47590-0001
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/micro_usb_ab_475900001_sd.pdf
Conexiones:
- Los pines de energía del microUSB van conectados a los pines de carga del PMIC.


------------------
LED Carga:
------------------

Este LED se usará para iluminarse cuando esté cargándose la batería.
No hay modelo de LED seleccionado (uno genérico).
Conexiones:
- Los pines del LED de Carga van conectados a los pines del LED del PMIC.


--------------
PMIC:
--------------

Modelo: AXP209
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/AXP209-SpecSheet-Translated.pdf y http://hands.com/~lkcl/eoma/kde_tablet/AXP209%20Datasheet%20v1.0_cn.pdf
Conexiones:
- El PMIC va conectado a los pines PWR1, PWR2, PWR3 y PWR4
- El PMIC va conectado a los pines I2C_SCL y I2C_SDA del EOMA-68.
- El PMIC va conectado a un GPIO del Microcontrolador STM32F (IRQ-OUT del AXP209).
- Los pines del conector de batería van conectados a los pines de batería del PMIC.
- Los pines de energía del microUSB van conectados a los pines de carga del PMIC.
- Los pines del LED de Carga van conectados a los pines del LED del PMIC.


------------
EEPROM:
------------

Modelo: AT24C64
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/AT24C64.eeprom.pdf
Conexiones:
- Los pines del EEPROM van conectados a los pines I2C del EOMA-68.


------------------
Acelerómetro:
------------------

Modelo: MXC6225XU
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/MXC6225XU.pdf
Conexiones:
- Los pines del Acelerómetro van conectados a los pines I2C del EOMA-68.
- El acelerómetro va conectado a un GPIO del microcontrolador STM32F (IRQ del acelerómetro).


------------
MicroSD:
------------

Modelo: MM027S020R
Datasheet: http://hands.com/~lkcl/eoma/allwinner/litkconn_MICRO%20SD%20PUSH-PUSH%20A.pdf
Conexiones:
- Los pines de la MicroSD van conectados a los pines GPIO del EOMA-68.
- La MicroSD va conectada a un GPIO del microcontrolador STM32F (para detectar la microSD).


---------------
Botón Power:
---------------

El botón Power sería un botón normal de click.
Conexiones:
- El botón Power va conectado al pin 43 POWER# del EOMA-68.


-----------------
Jack de Audio:
-----------------

Modelo: PJ-3545-5L1G
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/PJ-3543-L6G%20Model%20(1).pdf
Conexiones:
- Los pines del Jack de Audio van conectados al Controlador de Audio USB.


----------------
Altavoz (x2):
----------------

Modelo: sin elegir (genérico).
Conexiones:
- Los pines del altavoz van conectados a las conexiones del Amplificador de Audio.


----------------------
Amplificador de Audio:
----------------------

Modelo: UTC2822D
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/YW-UTC2822D_C.pdf y http://pdf.datasheetcatalog.com/datasheets/90/492970_DS.pdf
Conexiones:
- Va conectado a la salida de audio que va desde el Controlador de Audio USB al Jack de Audio.
- Los pines del altavoz van conectados a las conexiones del Amplificador de Audio.


--------------
Micrófono:
--------------

Modelo: sin elegir (genérico).
Conexiones:
- Los pines del Micrófono van conectados al Controlador de Audio USB.


--------------------------
Controlador de Audio USB:
--------------------------

Modelo: CM108AH
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/CM108_DataSheet_v1.6.pdf
Conexiones:
- El Controlador de Audio USB va conectado a un HUB USB.
- El Controlador de Audio USB va conectado a un GPIO del microcontrolador STM32F (para detectar los auriculares y modificar el sonido).
- Los pines del Micrófono van conectados al Controlador de Audio USB.
- Los pines del Jack de Audio van conectados al Controlador de Audio USB.


-------------
WIFI USB:
-------------

Modelo: CCandC WM-294 1T1R
Datasheet: https://dl.dropboxusercontent.com/u/19251472/11/WM-294_module-V2.2%28PCB%20v%20C%29.pdf
Conexiones:
- Los pines del Wifi USB van conectados a los pines del HUB USB.


----------------
Bluetooth USB:
----------------

El modelo del Bluetooth USB todavía no ha sido elegido, aun así, es un BT USB genérico, por lo que la conexión/alimentación sería igual que en el WIFI USB.
Conexiones:
- Los pines del BT USB van conectados a los pines del HUB USB.


----------------
Host USB 2.0:
----------------

Modelo: sin elegir (genérico).
Conexiones:
- Los pines del Host USB 2.0 van conectados a los pines del HUB USB.


----------------
USB HUB:
----------------

Modelo: FE1.1s
Datasheet: http://hands.com/~lkcl/eoma/kde_tablet/FE1.1s%20Data%20Sheet%20(Rev.%201.0).pdf
Conexiones:
- El USB HUB va conectaado a los pines 1st USB del EOMA-68.
- Los pines del Host USB 2.0 van conectados a los pines del HUB USB.
- Los pines del BT USB van conectados a los pines del HUB USB.
- Los pines del Wifi USB van conectados a los pines del HUB USB.
- El Controlador de Audio USB va conectado a un HUB USB.


-----------------
Botones (x17):
-----------------

Son el resto de botones de la consola. 4 botones (los 2 gatillos digitales y el Vol+ y Vol-) irían con botones de click (aunque a lo mejor se le ponen membranas para no ser tan duro al pulsar, hay que valorarlo) y el resto de botones son los típicos botones de ABXY que van con membrana en el PCB.
Conexiones:
- El botón va conectado a un GPIO del microcontrolador STM32F (x17).


---------------------------
Gatillo Analógico (x2):
---------------------------

El gatillo analógico consiste en una pieza de plástico, conectado a un potenciómetro, que al pulsarlo desplaza al potenciómetro, y que para volver a su posición original al dejar de apretar tiene un muelle (ver gatillo analógico de GameCube o Mando Clásico Wii como ejemplo).
Modelo (potenciómetro): Panasonic EVA-W7NR04B34
Datasheet: http://www.digikey.com/product-detail/en/EVA-W7NR04B34/P13569-ND/1135944
Conexiones:
- Los pines del gatillo analógico va conectado a un ADC del microcontrolador STM32F (x2).


-----------------
Joystick (x2):
-----------------

Modelo: CTS 254TA103B50B-ND
Datasheet: http://www.digikey.com/product-detail/en/254TA103B50B/254TA103B50B-ND/1755918
Conexiones:
- Los pines analógicos del joystick va conectado a 2 ADCs del microcontrolador STM32F (x2).
- El pin digital del joystick va conectado a un GPIO del microcontrolador STM32F (x2).


--------------------
Microcontrolador:
--------------------

Modelo: STM32F072xx (todavía no se ha elegido modelo específico).
Datasheet: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/programming_manual/DM00051352.pdf http://www.st.com/web/en/resource/technical/document/datasheet/DM00090510.pdf y http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF259717
Conexiones:
- El STM32F va conectado a los pines del 2nd USB del EOMA-68.
- Los pines analógicos del joystick va conectado a 2 ADCs del microcontrolador STM32F (x2).
- El pin digital del joystick va conectado a un GPIO del microcontrolador STM32F (x2).
- Los pines del gatillo analógico va conectado a un ADC del microcontrolador STM32F (x2).
- El botón va conectado a un GPIO del microcontrolador STM32F (x17).
- El Controlador de Audio USB va conectado a un GPIO del microcontrolador STM32F (para detectar los auriculares y modificar el sonido).
- La MicroSD va conectada a un GPIO del microcontrolador STM32F (para detectar la microSD).
- El acelerómetro va conectado a un GPIO del microcontrolador STM32F (IRQ del acelerómetro).
- El PMIC va conectado a un GPIO del Microcontrolador STM32F (IRQ-OUT del AXP209).
- La pantalla va conectado al GPIO del STM32F para el power-up del LCD.




----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------


Algunos links de interés que a lo mejor os son útiles mirar:
- Esquemas de la tablet basada en EOMA-68: http://hands.com/~lkcl/eoma/kde_tablet/tablet2.pdf
- Datasheets de la tablet basada en EOMA-68: http://hands.com/~lkcl/eoma/kde_tablet/
- Esquemas de componentes de la tablet basada en EOMA-68: http://hands.com/~lkcl/eoma/kde_tablet/rev3_review/



----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------


40518


----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------


Saludos y gracias!

[nintiendo1]

Actualizado a la v.0.3, en la que he incluido el EEPROM, el acelerómetro, y el USB Host 3.0.

Saludos!

[nintiendo1]

Actualizado a la v.0.5, en la que he hecho un pequeño cambio del acelerómetro y he incluido el microUSB de carga, el LED de carga, la microSD, el WIFI USB y el BT USB.

Toda la info actualizada en el primer mensaje: http://www.gp32spain.com/foros/showthread.php?133592-ZEOMA-Diagrama-de-Bloques-de-ZEOMA-(PCB)-ZEOMA&p=1652963#post1652963

Saludos y gracias.

[Drumpi]

En principio, el diagrama de bloques muestra que es sencillo de montar... aunque me parece raro que el conector I2C se use para tantas cosas, más que nada porque el I2C que conozco sirve para interconectar CPUs, no periféricos ^^U Tengo tanto que aprender...
La cuestión es que, si el diagrama es correcto (que habrá qe mirarlo bien), luego habrá que precisar con más detalle la conexiones pin a pin, y después añadir el resto de componentes discretos, que es donde tengo los problemas: si afectan las pistas a los cálculos, añadir las impedancias y los filtros puede ser muy engorroso, y vamos a estar saltando del diseño del PCB al del circuito detallado varias veces.

Pero soy optimista :)

[nintiendo1]

En principio, el diagrama de bloques muestra que es sencillo de montar... aunque me parece raro que el conector I2C se use para tantas cosas, más que nada porque el I2C que conozco sirve para interconectar CPUs, no periféricos ^^U Tengo tanto que aprender...
La cuestión es que, si el diagrama es correcto (que habrá qe mirarlo bien), luego habrá que precisar con más detalle la conexiones pin a pin, y después añadir el resto de componentes discretos, que es donde tengo los problemas: si afectan las pistas a los cálculos, añadir las impedancias y los filtros puede ser muy engorroso, y vamos a estar saltando del diseño del PCB al del circuito detallado varias veces.

Pero soy optimista :)

A ver, lo tenéis que revisar, y bien revisado. Yo no tengo ni puñetera idea de circuitos (vamos, no se hacer ni un interruptor ni nada), y lo único que he hecho es hacer un diagrama muy básico mirando tanto los esquemas de la tablet como los datasheets. Esto es un diagrama muy básico ya que es a lo que yo soy capaz de hacer.

Lo he hecho porque la idea que propuso Segata Sanshiro me pareció bastante sensata sobre el orden que debíamos de llevar, y así creando yo este tema, a ver si le damos un empujoncito.

Yo también soy optimista, es complejo, pero no tan complejo como si tuviésemos que unir CPU, RAM y cosas así. Eso sí, necesita de unos conocimientos (que yo no tengo) y de mucho tiempo/trabajo.

Sobre todo no quiero que se queda en nada porque me daría mucha pena todo el trabajo que hizo PuNk_NoT_DeAd, que hizo muy buen trabajo y no me gustaría que se quedase en nada.

-----------------------------------------------

Actualizado a la v.0.7 añadiendo un Pendrive USB, Micrófono, Jack de Audio y Altavoces.

-----------------------------------------------

También hay avances respecto a los EOMA-68.

Pronto se van a producir nuevas unidades de prueba del Allwinner A20 con los nuevos cambios y 2 GB de RAM.

También se sigue con el desarrollo de la EOMA-68 basada en la ICubeCorp IC1T y en la Ingenic JZ4775.

Además, los de Allwinner le han pasado documentación sobre el nuevo Allwinner A33, el cual es quad-core y 2 GB de RAM (que tiene un diseño muy similar al Allwinner A20), por lo que van a desarrollar un nuevo EOMA-68 con este SoC.

Saludos y gracias!

[nintiendo1]

Actualizado a la v.0.8, en la que he añadido el botón Power, los 2 gatillos analógicos, los 2 joystick y los 17 botones restantes.

En principio, yo ya no tengo que añadir nada más, por lo que solo queda que lo repaséis y reviséis todo, por si hay errores (que los habrá), si hay que detallar algo más o si se puede hacer algo mejor.


si afectan las pistas a los cálculos, añadir las impedancias y los filtros puede ser muy engorroso, y vamos a estar saltando del diseño del PCB al del circuito detallado varias veces.

No tengo mucha idea, pero, creo que la longitud de las pistas no afectaría a los esquemas, ¿no? Por lo menos para el tipo de circuito que estamos haciendo (que no tiene CPU, ni RAM ni nada de eso).

Saludos y gracias!

[Drumpi]

Creo que podría afectar a las comunicaciones con la SD, la pantalla, o el wifi, ya que requieren una velocidad de transmisión rápida, no tanto como la RAM, pero sí que hablamos aun de altas frecuencias. Insisto, tengo que mirarlo con calma, no estoy seguro.

[nintiendo1]

Creo que podría afectar a las comunicaciones con la SD, la pantalla, o el wifi, ya que requieren una velocidad de transmisión rápida, no tanto como la RAM, pero sí que hablamos aun de altas frecuencias. Insisto, tengo que mirarlo con calma, no estoy seguro.

Ya de eso ni idea, creo recordar que las pistas de la pantalla debían ser todas iguales o algo así. De todas formas el WIFI es USB, por lo que sería el USB.

De todas formas, como dijo Segata, lo suyo es ir por pasos, para que nos vamos a ir complicando ahora.

Lo suyo sería:
-1º) Hacer el diagrama de bloques --> lo que yo he hecho más o menos --> Hecho!
-2º) Revisar el diagrama de bloques --> esto ya lo tiene que hacer Drumpi, Segata Sanshiro, o cualquiera que quiera --> En proceso.
-3º)
----A) Hacer/revisar los esquemas --> esto ya lo tiene que hacer Drumpi, Segata Sanshiro, o cualquiera que quiera --> Sin hacer.
----B) Terminar el diseño de la carcasa --> mientras se hacen los esquemas, PuNk_NoT_DeAd debe hacer los cambios de la pantalla y la batería y decidir exactamente el sitio de cada componente para cuando haya que hacer el PCB --> Sin hacer.
-4º)
----A) Hacer/revisar el PCB --> esto ya lo tiene que hacer Drumpi, Segata Sanshiro, o cualquiera que quiera --> Sin hacer.
----B) Hacer cambios en los esquemas (opcional) --> mientras se hace el PCB, por si hay que hacer algún cambio de los esquemas, esto ya lo tiene que hacer Drumpi, Segata Sanshiro, o cualquiera que quiera --> Sin hacer.
----C) Hacer cambios en los esquemas (opcional) --> mientras se hace el PCB, por si hay que hacer algún cambio de la carcasa porque algo no cuadre, esto ya lo tiene que hacer PuNk_NoT_DeAd --> Sin hacer.

Lo suyo sería ahora hacer: -2º) Revisar el diagrama de bloques.

Saludos y gracias.

[Segata Sanshiro]

Buf Drumpi, te estás volviendo a hacer la picha un lío de muy mala manera, hamijo xD El I2C es precisamente para conectar periféricos a un microcontrolador, osea que lo estamos usando para su cometido.

nintiendo, tiene mérito que sin tener ni idea hayas hecho el esquema tan detallado, es un buen punto de partida :brindis: Eso sí, veo un optimismo que no concuerda ni con los escasos conocimientos que tenemos los que estamos interesados en el proyecto ahora mismo, ni con las horas-hombre requeridas para un proyecto así.

Hay cosas que no entiendo por qué se hacen de ese modo, tengo que echarle un buen vistazo a cómo hicieron la tablet. Pero que pueda ir comentando de momento: para los controles necesitamos, por ejemplo, un microcontrolador con al menos 4 ADCs y unos cuantos pines libres para I/O para los botones digitales. En el esquema debería aparecer algo así



|
| I2C
_________|________
| |
| uC |
| |
|__________ |
| ADC (x4) | |
|__________|_______|
| | |______Botones (x17)
| |_____________Gatillos (x2)
|___________________Joysticks analógicos (x2)


Hacer este módulo ya es un proyecto en sí mismo que requiere su tiempo, y solo es una pequeña parte de la consola.

[nintiendo1]

Buf Drumpi, te estás volviendo a hacer la picha un lío de muy mala manera, hamijo xD El I2C es precisamente para conectar periféricos a un microcontrolador, osea que lo estamos usando para su cometido.

nintiendo, tiene mérito que sin tener ni idea hayas hecho el esquema tan detallado, es un buen punto de partida :brindis: Eso sí, veo un optimismo que no concuerda ni con los escasos conocimientos que tenemos los que estamos interesados en el proyecto ahora mismo, ni con las horas-hombre requeridas para un proyecto así.

Hay cosas que no entiendo por qué se hacen de ese modo, tengo que echarle un buen vistazo a cómo hicieron la tablet. Pero que pueda ir comentando de momento: para los controles necesitamos, por ejemplo, un microcontrolador con al menos 4 ADCs y unos cuantos pines libres para I/O para los botones digitales. En el esquema debería aparecer algo así



|
| I2C
_________|________
| |
| uC |
| |
|__________ |
| ADC (x4) | |
|__________|_______|
| | |______Botones (x17)
| |_____________Gatillos (x2)
|___________________Joysticks analógicos (x2)


Hacer este módulo ya es un proyecto en sí mismo que requiere su tiempo, y solo es una pequeña parte de la consola.

Está claro que va a ser difícil, pero no imposible, total, ahora no tenemos que gastar dinero, por lo que podemos arriesgarnos a hacer los esquemas/PCB sin palmar pasta. Por intentarlo no se pierde nada (bueno, se pierde dinero y se ganan conocimientos). De todas formas, quizás en algún momento se anima alguien más y nos ayuda. Además, ya lo dije antes, la gente del EOMA-68 nos puede ayudar si no sabemos hacer algo o a revisar cosas.

Voy a buscar un microcontrolador con esas características que me has dicho, cuando encuentre uno te aviso.

Saludos y gracias.

[Segata Sanshiro]

Perfect. En Digikey, si buscas en ICs > Microcontroladores, luego puedes buscar algo en plan "ADC 4x10b" o similar. Nos interesan todos los 4x??b. Los más baratos que veas tienen demasiados pocos pines de entrada/salida, así que hay que ajustar ese parámetro también en el buscador.

[nintiendo1]

Perfect. En Digikey, si buscas en ICs > Microcontroladores, luego puedes buscar algo en plan "ADC 4x10b" o similar. Nos interesan todos los 4x??b. Los más baratos que veas tienen demasiados pocos pines de entrada/salida, así que hay que ajustar ese parámetro también en el buscador.

Además de buscar por digikey y mouser, preguntaré a la gente del EOMA-68 a ver si conocen una buena alternativa.

Saludos.

[Limonetti]

Acordaos sobre todo de que si seleccionáis componentes que comuniquen por I2C, SPI, etc... ahorra un montón de trabajo el tener una driver ya hecho según el lenguaje de programación que se vaya a usar, e incluso ejemplos si es posible. Muchas veces sigues todo lo que pone el datasheet y aun así hay detalles que se te escapan que te pueden dar por el saquete cosa mala.

Por ejemplo, en el caso de buscar un adc, podeis cotillear primero en paginas como sparkfun, mikroelectronica y otras similares donde aficionados compran módulos para sus proyectos. Una vez que tengáis localizado un modulo que se pueda ajustar a lo que queréis veis que lleva, cuanto soporte hay por parte de los fabricantes o de la comunidad, y luego ya lo buscáis en paginas de venta tipo Farnell, RS, Digikey, etc... con el tipo de encapsulado que vaya mejor, o dentro de la propia familia con la variación de características / precio que mas se ajuste.


Pero vamos, que como dice Nintiendo y hemos hablado en otro hilo. Si dentro de otros proyectos de EOMA han usado cosas usad exactamente lo mismo y ya. al menos, no veo la parte de rutear una placa y programar el firmware para ella como cosas separadas. Son cosas que van de la mano y tienes que tener muy claro como funciona el periferico que vas a comunicar con tu sistema y como trabaja. No simplemente hacer las conexiones y ya.

De hecho lo primero muchas veces es siempre la placa blanca o de prototipos y tirar cables, y luego ya con todo funcionando bien realizar lo que seria el prototipo real.

Otra cosa en la que he caído que puede venir bien a la hora de trastear con estas cosas (para coger practica o bien para este proyecto) es hacer simulaciones en Proteus. Que si bien no suplen lo que es usar componentes físicos siempre es mejor que nada si no se dispone de ellos, o no se quiere gastar dinero. Tienes que tener los modelos hechos en Proteus, eso si, no tienen de todo obviamente.

Yo siento de veras no mojarme más. Aun con todo sigo todo esto con bastante interés.

[nintiendo1]

Acordaos sobre todo de que si seleccionáis componentes que comuniquen por I2C, SPI, etc... ahorra un montón de trabajo el tener una driver ya hecho según el lenguaje de programación que se vaya a usar, e incluso ejemplos si es posible. Muchas veces sigues todo lo que pone el datasheet y aun así hay detalles que se te escapan que te pueden dar por el saquete cosa mala.

Por ejemplo, en el caso de buscar un adc, podeis cotillear primero en paginas como sparkfun, mikroelectronica y otras similares donde aficionados compran módulos para sus proyectos. Una vez que tengáis localizado un modulo que se pueda ajustar a lo que queréis veis que lleva, cuanto soporte hay por parte de los fabricantes o de la comunidad, y luego ya lo buscáis en paginas de venta tipo Farnell, RS, Digikey, etc... con el tipo de encapsulado que vaya mejor, o dentro de la propia familia con la variación de características / precio que mas se ajuste.


Pero vamos, que como dice Nintiendo y hemos hablado en otro hilo. Si dentro de otros proyectos de EOMA han usado cosas usad exactamente lo mismo y ya. al menos, no veo la parte de rutear una placa y programar el firmware para ella como cosas separadas. Son cosas que van de la mano y tienes que tener muy claro como funciona el periferico que vas a comunicar con tu sistema y como trabaja. No simplemente hacer las conexiones y ya.

De hecho lo primero muchas veces es siempre la placa blanca o de prototipos y tirar cables, y luego ya con todo funcionando bien realizar lo que seria el prototipo real.

Otra cosa en la que he caído que puede venir bien a la hora de trastear con estas cosas (para coger practica o bien para este proyecto) es hacer simulaciones en Proteus. Que si bien no suplen lo que es usar componentes físicos siempre es mejor que nada si no se dispone de ellos, o no se quiere gastar dinero. Tienes que tener los modelos hechos en Proteus, eso si, no tienen de todo obviamente.

Yo siento de veras no mojarme más. Aun con todo sigo todo esto con bastante interés.

La verdad es que tienes razón.

De todas formas, la consola es casi una copia de la tablet excepto por la pantalla (que usamos MIPI) y los botones, por lo que en ese sentido no nos tenemos que calentar mucho la cabeza como si hiciésemos el diseño de cero.

Por otra parte, aunque no puedas ayudarnos más, aportes como este nos son útiles.

Saludos y gracias.

-----Actualizado-----

Por cierto Segata Sanshiro, parece que se necesitan 6 ADCs, o eso me pone uno del foro del EOMA-68:

I count 6 ADCs channels required.

¿Podrías confirmar/desmentir esto? Es que estas cosas no sé mirarlas.

Saludos y gracias!

[Segata Sanshiro]

Sí, tiene toda la razón! Solo había contado un potenciómetro por cada joystick y son dos.

[nintiendo1]

Sí, tiene toda la razón! Solo había contado un potenciómetro por cada joystick y son dos.

Ok, gracias.

Ya me han ofrecido varias alternativas, aunque no sé si son de 4 ADCs y entonces se nos quedan cortas.

Te digo todo lo que me han dicho para que lo analices tú y me respondas, que estos temas se me quedan muy grandes y no entiendo.

1º

but you should be able to do keyboard matrix scanning to cover 16 buttons, 4 input 4 output... unless you really really want all
possible button combinations, hmmm...

are there any keys which may not be pressed together, so you can do matrix-scanning on those, at least?

i will see if there is an I2C ADC/GPIO IC around... also now SPI is available so you could use that.


2º

ok so the MCP3004 is an SPI-based 10-bit ADC 4 channel, $1.50 in 5k volume, 200k-samples/sec, that's possibly waay more than you need? it's popular on adafruit and other places


3º

and if you use the next one up from the PCA9536 - the 16-bit one - i think you're covered?

http://uk.farnell.com/texas-instruments/ads7949srter/ic-adc-8bit-srl-2msps-16wqfn/dp/1863092

that one looks ok....


Con lo que me respondas tú a estas 3 preguntas-proposiciones, les respondo a ver que nos dicen. La verdad es que ellos saben bastante de esto, no han tardado mucho en ofrecer soluciones xD

Saludos y gracias.

-----Actualizado-----

Para Segata Sanshiro también. Si se nos queda corto el MCP3004 , mira a ver el MCP3008, que creo que tiene más ADCs (míralo a ver). Además me he dado cuenta que está muy usado en la Raspberry, por lo que hay muchos ejemplos:
http://ww1.microchip.com/downloads/en/DeviceDoc/21295C.pdf
https://learn.adafruit.com/reading-a-analog-in-and-controlling-audio-volume-with-the-raspberry-pi/overview
http://www.raspberrypi-spy.co.uk/2014/04/using-a-joystick-on-the-raspberry-pi-using-an-mcp3008/

Saludos y gracias!

[Segata Sanshiro]

Me parecen muy buenas ideas.

La posibilidad de usar un ADC por separado con interfaz serie (había pasado por alto que también tenemos SPI, no solo I2C) es interesante, aunque no sé qué haríamos con los controles digitales en ese caso. A bote pronto me parece mejor tener un microcontrolador con ADCs integrados que lo controle todo y salga con un interfaz serie, pero ni lo he pensado mucho ni he mirado proyectos caseros similares, que seguro que hay varios que ya han resuelto este problema.

El escaneo matricial que proponen creo que no sería recomendable en el caso concreto de un mando para videojuegos en el que queremos poder pulsar cualquier combinación de teclas sin problemas.

Otra cosa a considerar es la disponibilidad del ADC o micro que elijamos en un paquete que sea razonablemente fácil de soldar a mano.

¿Los mensajes que pones están sacados de correos o de un foro? Era para meterme directamente en el foro si fuera el caso.

[nintiendo1]

Me parecen muy buenas ideas.

La posibilidad de usar un ADC por separado con interfaz serie (había pasado por alto que también tenemos SPI, no solo I2C) es interesante, aunque no sé qué haríamos con los controles digitales en ese caso. A bote pronto me parece mejor tener un microcontrolador con ADCs integrados que lo controle todo y salga con un interfaz serie, pero ni lo he pensado mucho ni he mirado proyectos caseros similares, que seguro que hay varios que ya han resuelto este problema.

El escaneo matricial que proponen creo que no sería recomendable en el caso concreto de un mando para videojuegos en el que queremos poder pulsar cualquier combinación de teclas sin problemas.

Otra cosa a considerar es la disponibilidad del ADC o micro que elijamos en un paquete que sea razonablemente fácil de soldar a mano.

¿Los mensajes que pones están sacados de correos o de un foro? Era para meterme directamente en el foro si fuera el caso.

Es una especie de foro-email, te he enviado un MP explicándote como funciona y como puedes registrarte.

¿Al final entonces que nos recomiendas usar?

Saludos y gracias.

[Drumpi]

Bueno, el tema de los botones hay varias formas de enfocarlo.
Si usamos los analógicos mediante ADCs, los botones pueden ir directamente por otro lado. No sé si este I2C tiene suficientes puertos para ello, pero una solución que utilicé en una práctica con un 68000 era la multiplexación en el tiempo, o más bien una transmisión en serie:
Nos pasaba que teníamos que mostrar una matriz de 4x4 leds, lo cual nos consumía 16 terminales de salida. Se nos ocurrió que podíamos usar varios flip-flops en serie, y con dos líneas (una para el dato, y otra para provocar el flanco de subida) podíamos escribir los datos, e incluso nos volvimos locos e hicimos una matriz de 8x16 (y porque no nos cabían más en la placa).

Dado que la velocidad de reloj en el PCB es muy alta, quizás podamos usar multiplexación para leer los estados de cada botón, uno en cada ciclo. Una persona no va a pulsar más de 50 veces un botón por segundo, por lo que se necesita una velocidad mínima de 100Hz. Si son 16 botones, ya hablamos de 1'6KHz ¿A cuánto va la placa? Creo que a más de 100MHz seguro ¿no?. El problema es sincronizar los datos.

Una matriz de datos no me parece adecuado, y seguro que los mandos USB hacen algo parecido, con un conversor paralelo-serie o similar. Yo miraría por ahí... a menos que nos sobren puertos de entrada.
Y es por eso que pensaba que los controles iban a ir conectados por USB, porque nos ahorraba esto, pero cosa de mi ignorancia ^^U

PD: este mes voy a estar fuera, por si no respondo.

[nintiendo1]

Bueno, el tema de los botones hay varias formas de enfocarlo.
Si usamos los analógicos mediante ADCs, los botones pueden ir directamente por otro lado. No sé si este I2C tiene suficientes puertos para ello, pero una solución que utilicé en una práctica con un 68000 era la multiplexación en el tiempo, o más bien una transmisión en serie:
Nos pasaba que teníamos que mostrar una matriz de 4x4 leds, lo cual nos consumía 16 terminales de salida. Se nos ocurrió que podíamos usar varios flip-flops en serie, y con dos líneas (una para el dato, y otra para provocar el flanco de subida) podíamos escribir los datos, e incluso nos volvimos locos e hicimos una matriz de 8x16 (y porque no nos cabían más en la placa).

Dado que la velocidad de reloj en el PCB es muy alta, quizás podamos usar multiplexación para leer los estados de cada botón, uno en cada ciclo. Una persona no va a pulsar más de 50 veces un botón por segundo, por lo que se necesita una velocidad mínima de 100Hz. Si son 16 botones, ya hablamos de 1'6KHz ¿A cuánto va la placa? Creo que a más de 100MHz seguro ¿no?. El problema es sincronizar los datos.

Una matriz de datos no me parece adecuado, y seguro que los mandos USB hacen algo parecido, con un conversor paralelo-serie o similar. Yo miraría por ahí... a menos que nos sobren puertos de entrada.
Y es por eso que pensaba que los controles iban a ir conectados por USB, porque nos ahorraba esto, pero cosa de mi ignorancia ^^U

PD: este mes voy a estar fuera, por si no respondo.

En teoría tenemos puerto I2C y SPI, por lo que no tendríamos que recurrir a un USB, que supongo que encarecería (y dificultaría) el diseño.

Respecto a lo otro, ni idea, eso que ya lo valore alguien con idea sobre esto.

Saludos.

[Segata Sanshiro]

El I2C (y el SPI) usan un bus compartido por todos los periféricos, no hacen falta pines extra por cada uno que quieras añadir. El microcontrolador haría de serializador. Y en cuanto a la sincronización, ambos buses usan su propia señal de reloj. En nuestra placa de hecho habrá varias señales de reloj, no es raro en cualquier diseño mínimamente complejo.

Gracias por el mensaje nintiendo, ahora me apunto a la lista. De todos modos, ¿es privada o algo? Es por ponerlo por aquí para todo el que quiera acceder.

PD: Drumpi, aprovecha el mes de vacaciones para ir preparando el retorno de Echo, en este caso a Zeoma :D

[nintiendo1]

El I2C (y el SPI) usan un bus compartido por todos los periféricos, no hacen falta pines extra por cada uno que quieras añadir. El microcontrolador haría de serializador. Y en cuanto a la sincronización, ambos buses usan su propia señal de reloj. En nuestra placa de hecho habrá varias señales de reloj, no es raro en cualquier diseño mínimamente complejo.

Gracias por el mensaje nintiendo, ahora me apunto a la lista. De todos modos, ¿es privada o algo? Es por ponerlo por aquí para todo el que quiera acceder.

Es público, no lo he puesto porque es quizás demasiado complejo, no creo que interese mucho y no sé si se considera spam, pero bueno, lo pongo y si no que lo borren:


Es una especie de foro - email.

Te explico, es un servidor donde tú te registras con tu email. La gente envía un correo a ese servidor, y ese servidor lo reenvia a todos los que están registrados en ese servidor.

Para registrarte y que te llegen los mensajes a tu email como correos, entra en esta página: http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook y registrate poniendo los datos que te pide.

Una vez estas registrado, para crear un nuevo tema, crea un email arm-netbook@lists.phcomp.co.uk (el asunto del correo es el título del hilo y el mensaje es el mensaje).

Cuando te llegue un mensaje en forma de email, si quieres responder a ese hilo, responde al email como respondieses a un email cualquiera.

Para ver los mensajes antiguos, entra aquí: http://lists.phcomp.co.uk/pipermail/arm-netbook/

Los mensajes de este mes son: http://lists.phcomp.co.uk/pipermail/arm-netbook/2014-July/thread.html

Volviendo al tema de los controles, supongo que lo mejor es usar el MCP3004 (si soporta 6 ADCs) o el MCP3008 (si el anterior no soporta los 8 ADCs). Lo que no sé es si el MCP3004/8 soporta también los botones digitales, o deberíamos recurrir a otro IC.

De todas formas, si te vas a registrar allí, casi que mejor que pongas un mensaje y lo hables con ellos, que vamos a avanzar más que saben de esto (no como yo que estoy dando palos de ciego) xD

Saludos.

[Limonetti]

Ojo que por SPI normalmente aparte de datos y reloj se usa una linea para seleccionar el esclavo con el que quieres comunicarte. Ahí si que haría falta al menos una mas. Con I2C no hace falta porque mandas la dirección y ya el esclavo se da por enterado, quedándose los demás a su bola.

En cuanto a lo de las entradas y salidas que comentáis, veo que el port expander que hay en el diagrama solo tiene cuatro lineas (PCA9536). Si hacen falta para unicamente los botones, con uno de 16 por ejemplo creo que tenéis de sobra, y es lo más cómodo a la larga, creo. Hacerlo por multiplexación no es tan cómodo a la hora de programar el firmware ni a la hora de rutear la placa.

EDIT: acabo de darme cuenta de que son 17 botones. Pero vamos, imagino que habrá alguno que se ajuste.

[nintiendo1]

Ojo que por SPI normalmente aparte de datos y reloj se usa una linea para seleccionar el esclavo con el que quieres comunicarte. Ahí si que haría falta al menos una mas. Con I2C no hace falta porque mandas la dirección y ya el esclavo se da por enterado, quedándose los demás a su bola.

En cuanto a lo de las entradas y salidas que comentáis, veo que el port expander que hay en el diagrama solo tiene cuatro lineas (PCA9536). Si hacen falta para unicamente los botones, con uno de 16 por ejemplo creo que tenéis de sobra, y es lo más cómodo a la larga, creo. Hacerlo por multiplexación no es tan cómodo a la hora de programar el firmware ni a la hora de rutear la placa.

EDIT: acabo de darme cuenta de que son 17 botones. Pero vamos, imagino que habrá alguno que se ajuste.

Ahora tengo una duda. Los joystick son de esos que tienen un botón al pulsarlos, por lo que no sé si cada joystick son 2 ADCs solo (y en los ADCs se incluye el botón central), o si son 2 ADCs + botón digital, ¿alguien puede mirarlo? Es que no me aclaro. Estos son los joystick: http://www.digikey.com/product-detail/en/254TA103B50B/254TA103B50B-ND/1755918 y dentro de este enlace hay enlaces para los datasheets y drawings a ver si vosotros que entendéis me decís. Porque si el botón central es un botón aparte, en total serían 19 botones.

Por lo que veo de tu mensaje, nos recomiendas usar el PCA9536 para los botones y el MCP3004/8 para los ADCs, ¿no? ¿Eso sería lo más sencillo o no me he enterado bien?

Saludos y gracias.

[Limonetti]

El PCA9536 es muy pequeño, me refería a que haría falta algo más grande, como por ejemplo un par de 16 lineas como por ejemplo PCA9555.

Haciendo la busqueda en plan super rápida en farnell no he visto mucha cosa, y he puesto ese por ser del mismo fabricante. Ya más grandes hay de 40 alguno.

Los joystick por lo que veo también se pueden usar como botón. Llevan 8 pines (3 y 3 para los potenciomentros y dos para el interruptor imagino).

[nintiendo1]

El PCA9536 es muy pequeño, me refería a que haría falta algo más grande, como por ejemplo un par de 16 lineas como por ejemplo PCA9555.

Haciendo la busqueda en plan super rápida en farnell no he visto mucha cosa, y he puesto ese por ser del mismo fabricante. Ya más grandes hay de 40 alguno.

Los joystick por lo que veo también se pueden usar como botón. Llevan 8 pines (3 y 3 para los potenciomentros y dos para el interruptor imagino).

Supongo que aunque haya 2 pines para el interruptor, cuenta como un solo botón digital, ¿no? En ese caso, son un total de 19 botones digitales y 4 ADCs.

Según pone Mouser, el PCA9555 está en el final de su ciclo de vida, por lo que no recomiendan usarlo. ¿Alguna alternativa que nos sirva? Aquí está toda la línea del PCA95XX de TI por si queréis mirar cual nos sirve y no esté al final de vida: http://www.mouser.es/Semiconductors/Interface-ICs/Interface-I-O-Expanders/_/N-aq4ec?Keyword=pca95+texas&FS=True

Saludos y gracias.

[Limonetti]

Otra opción seria entonces el MCP23017 (http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP23017) que también va por I2C. Esta por ejemplo en Farnell (http://es.farnell.com/jsp/search/browse.jsp?N=2011+203654&Ntk=gensearch&Ntt=MCP23017&Ntx=mode+matchallpartial) en esas variantes. Tenéis también una libreria de ejemplo para arduino (https://github.com/adafruit/Adafruit-MCP23017-Arduino-Library). He visto que lo vendían en Adafruit y ahí suelen tener info de soporte. Pero habrá más cosas hechas por otros sitios seguro.

Esta también ha sido una busqueda rápida y en plan facil, no he entrado en el detalle de disponibilidades de cara a un futuro ni en otros factores. Si queréis afinar no creo que tengáis problemas en encontrar para un mismo fabricante.

[nintiendo1]

Otra opción seria entonces el MCP23017 (http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP23017) que también va por I2C. Esta por ejemplo en Farnell (http://es.farnell.com/jsp/search/browse.jsp?N=2011+203654&Ntk=gensearch&Ntt=MCP23017&Ntx=mode+matchallpartial) en esas variantes. Tenéis también una libreria de ejemplo para arduino (https://github.com/adafruit/Adafruit-MCP23017-Arduino-Library). He visto que lo vendían en Adafruit y ahí suelen tener info de soporte. Pero habrá más cosas hechas por otros sitios seguro.

Esta también ha sido una busqueda rápida y en plan facil, no he entrado en el detalle de disponibilidades de cara a un futuro ni en otros factores. Si queréis afinar no creo que tengáis problemas en encontrar para un mismo fabricante.

Supongo que el MCP23017 viene en sustitución del MCP3004/8 que ibamos a usar ¿no?

Mientras soporte 6 ADCs, nos sirve, y si además es más fácil usar I2C que SPI, pues mejor.

Por cierto, el creador del EOMA-68 se ha ofrecido a ayudarnos, aunque por ahora va a ser que no porque no tenemos nada (vamos mucho más atrasado de lo que piensa), pero en un futuro nos puede ayudar:

ok so you have an IC for the GPIO, and one for the ADC. i'm happy to help you with the PCB: would you like to try sending me a DXF file with the outline of the PCB edge, maybe also where the buttons are supposed to go? we can see if i can import it?

Saludos y gracias.

[Limonetti]

Supongo que el MCP23017 viene en sustitución del MCP3004/8 que ibamos a usar ¿no?

Mientras soporte 6 ADCs, nos sirve, y si además es más fácil usar I2C que SPI, pues mejor.

Por cierto, el creador del EOMA-68 se ha ofrecido a ayudarnos, aunque por ahora va a ser que no porque no tenemos nada (vamos mucho más atrasado de lo que piensa), pero en un futuro nos puede ayudar:


Saludos y gracias.

Nop, el MCP3004/8 es un ADC, el MCP23017 viene a sustituir al PCA9555 por lo que me has indicado antes de lo del ciclo de vida. Seria para las entradas digitales.

[Segata Sanshiro]

He enviado un correo a la lista sin suscribirme, a ver si aparece bien.

[nintiendo1]

Nop, el MCP3004/8 es un ADC, el MCP23017 viene a sustituir al PCA9555 por lo que me has indicado antes de lo del ciclo de vida. Seria para las entradas digitales.

Entonces sería el MCP23017 y el MCP3004/8. Queda por decidir si podemos usar el MCP3004 porque soporta los 6 ADCs, o hay que tirar a por el MCP3008.


He enviado un correo a la lista sin suscribirme, a ver si aparece bien.

No me ha llegado ningún correo, y eso es instantáneo, así que creo que vas a tener que registrarte xD

Saludos.

[nintiendo1]

Por cierto Segata, me ha enviado un mensaje el creador del EOMA-68 diciendo que si quieres que el mensaje le llegue a todo el mundo, tienes que suscribirte, así que ya sabes xD.

Saludos.

[Segata Sanshiro]

Qué pereza xD A ver si ahora llega.

[nintiendo1]

Qué pereza xD A ver si ahora llega.

Ya ha llegado perfectamente. Ahora cuando respondan o escriban algo te llegará al email xD

Saludos.

[nintiendo1]

Por lo que veo, tenemos 2 alternativas para los controles:
- Usar MCP23017 (para los 19 botones digitales) y el MCP3004/8 (para los 6 ADCs, hay que mirar si nos sirve el modelo terminado en 4 o hay que ir al terminado 8). Es más fácil de programar, pero supongo que más difícil de cara a hacer el PCB (porque son 2 IC).
- Usar un microcontrolador tipo ATtiny48, con el que podemos hacer tanto los 19 botones digitales como los 6 ADCs. Es más difícil de programar, pero más sencillo de cara a hacer el PCB (porque es 1 IC).

A ver si los expertos tipo Segata Sanshiro, Limonetti, Drumpi o cualquiera que tenga algo de idea nos dice cual sería la mejor elección en su opinión.

Por cierto Segata, ya te ha respondido a tu mensaje (supongo que te habrá llegado un email, pero por si acaso te lo dejo aquí):

> We could use two different IC's, but wouldn't using an appropriate microcontroller be a less complex solution?

software-wise, no. with a microcontroller you have to a) write the
firmware b) have two compilers c) upload the firmware d) design into
the hardware a means to upload the firmware.

> Some uc's in the ATtiny48 family have 6 ADCs and enough I/O pins.

ok yeah something like the arduino PICs would be extremely good, the
infrastructure is amazing and they have support in sdcc. i helped out
on the OSMC project a loong while ago so i know that you *do not* need
all the 168mbyte crud that comes with the arduino just to compile
sub-8k applications! :)

Si quieres responderle, tienes que hacerlo al email que te ha llegado con la respuesta.

Saludos y gracias.

[nintiendo1]

Bueno, como Segata Sanshiro me dijo que sería útil crear una wiki, pues me he puesto a ello.

Por ahora no he hecho mucho. Lo he alojado en un hosting gratuito, así que no sé como irá, pero es lo que hay. Si alguien conoce una alternativa mejor que me diga.

Por ahora hay poco hecho. Solo he hecho la página de inicio y la página de apóyanos. En los próximos días sigo con ello.

Lo pongo mientras por aquí para que le echéis un vistazo: http://zeoma.site40.net/

Podéis mirar a ver si hay algún error o algo. Se que es un poco denigrante, pero es que no tengo ni idea de programación web ni de diseño gráfico xD Si alguien quiere mejorarla, no tiene nada más que decírmelo. Si queréis añadir contenido, solo tenéis que registraros allí y ya podéis modificar.


Por lo que veo, tenemos 2 alternativas para los controles:
- Usar MCP23017 (para los 19 botones digitales) y el MCP3004/8 (para los 6 ADCs, hay que mirar si nos sirve el modelo terminado en 4 o hay que ir al terminado 8). Es más fácil de programar, pero supongo que más difícil de cara a hacer el PCB (porque son 2 IC).
- Usar un microcontrolador tipo ATtiny48, con el que podemos hacer tanto los 19 botones digitales como los 6 ADCs. Es más difícil de programar, pero más sencillo de cara a hacer el PCB (porque es 1 IC).

A ver si los expertos tipo Segata Sanshiro, Limonetti, Drumpi o cualquiera que tenga algo de idea nos dice cual sería la mejor elección en su opinión.

Por cierto Segata, ya te ha respondido a tu mensaje (supongo que te habrá llegado un email, pero por si acaso te lo dejo aquí):

Si quieres responderle, tienes que hacerlo al email que te ha llegado con la respuesta.

Saludos y gracias.

Le doy un UP! a ver si alguien dice algo. Por cierto, ¿alguien ha revisado el resto del diagrama de bloques?

Saludos y gracias.

[nintiendo1]

He estado hablando con el creador de la EOMA-68 y me ha dicho que aunque las 2 opciones son buenas, el optaría por la primera opción (Usar MCP23017 (para los 19 botones digitales) y el MCP3004/8 (para los 6 ADCs, hay que mirar si nos sirve el modelo terminado en 4 o hay que ir al terminado 8)), ya que es más fácil para programarlos y no vamos a ahorrar mucho dinero entre la 1ª y la 2ª opción

it'll be pretty straightforward. also you have the advantage that you can separate the analog ADC IC from the digital one, separate the ADC IC with some ground protection and you'll get less noise.

honestly i'd go for the less difficult to program option, straight away. you're not on a huge cost-saving exercise so it's fine.

Ya me diréis que pensáis vosotros.

Saludos.

[Segata Sanshiro]

No lo he comentado, estuve mirando de nuevo el tema del escaneo de una matriz de teclas y si se hace adecuadamente (apartado 8 de esta página http://www.dribin.org/dave/keyboard/one_html/) no hacen falta 19 entradas. Pero esto solo es aplicable si usáramos un microcontrolador. A mí me sigue gustando más esa idea, y se acerca más a como funcionan los mandos de verdad, pero es cierto que requeriría más trabajo.

Tengo alguna otra duda que preguntaré directamente en la lista de correo un día de éstos.

Por cierto, el integrado ése de los botones digitales solo tiene 16 entradas, ¿no nos quedamos cortos?

[nintiendo1]

No lo he comentado, estuve mirando de nuevo el tema del escaneo de una matriz de teclas y si se hace adecuadamente (apartado 8 de esta página) no hacen falta 19 entradas. Pero esto solo es aplicable si usáramos un microcontrolador. A mí me sigue gustando más esa idea, y se acerca más a como funcionan los mandos de verdad, pero es cierto que requeriría más trabajo.

Tengo alguna otra duda que preguntaré directamente en la lista de correo un día de éstos.

Por cierto, el integrado ése de los botones digitales solo tiene 16 entradas, ¿no nos quedamos cortos?

¿El apartado 8 de qué pagina? A mi la verdad me da igual usar una u otra opción, porque yo no soy capaz de de hacer una u otra.

Si alguno preferís una opción, podéis optar por ella, a mi me da igual que se haga de una forma u otra siempre que se pueda hacer. Si tú crees (u otro) que puedes intentar hacer lo del microcontrolador, adelante a por ello.

Respecto al integrado, ¿te refieres al MCP23017? A ver que dice Limonetti, que fue el que lo propuso. Yo ni idea xD

Saludos.

[Segata Sanshiro]

Perdón, se me olvidó el link, ya está :)

[Limonetti]

La propuse como opción sencilla y rápida, nada más.

Ir por el camino del micro es más peliagudo, aun no necesitando muchos casi componentes adicionales (se puede usar un oscilador interno en la mayoría, creo) ya tendrías que programarlo. Y no me refiero solo para hacer el bucle de refresco de las lineas/columnas de teclado, su lectura y demás. Sino en lo que es la forma de mandar los datos de entradas por el bus que vayas a usar. Aparte de que lo tendrías que programarlo también "físicamente" (bien antes de montarlo o bien habilitándole un puerto para ello).

Realmente un integrado como los que se van nombrado ya suplen lo que buscáis y seguramente por menos precio. Si ya es por aprender o experimentar es distinto, ya que no por lo que he dicho deja de poder hacerse así también, ojo.

Ah, casi se me olvida. Por lo de que no hay entradas suficientes con un integrado, es muy sencillo usar varios. Como normalmente los puertos se agrupan en 8 lineas es muy común que sean de multiplos de eso. Pero cuando hice la búsqueda ya me di cuenta que el siguiente salto de 16 era a bastantes más (creo que 40).

[nintiendo1]

Perdón, se me olvidó el link, ya está :)

Gracias, lo he estado mirando y he visto que han conseguido 3 botones (de 4) a la vez sin ghosting, pero mi duda es si se podría los 4 botones (de los 4).

De todas formas, no sé si habría alguien capaz de saber programar el microcontrolador para los controles y los ADCs. Ya está difícil encontrar suficientes para hacer los diagramas y el PCB xD

Saludos y gracias.

-----Actualizado-----


Ah, casi se me olvida. Por lo de que no hay entradas suficientes con un integrado, es muy sencillo usar varios. Como normalmente los puertos se agrupan en 8 lineas es muy común que sean de multiplos de eso. Pero cuando hice la búsqueda ya me di cuenta que el siguiente salto de 16 era a bastantes más (creo que 40).

Entonces sería usar 2 MCP23017, ¿no? Podemos dejar uno para los controles de la consola, y otros para los botones de Menu, vol y demás del sistema.

Saludos.

[nintiendo1]

Mirad lo que ha comentado uno en el foro del EOMA-68:

I suspect that we are not looking at the complete picture here. Don't you have some more sensors to add on the I2C? Like accelerometer, magnetometer, maybe light sensor (for auto brigthness) and so on? Maybe battery monitoring? I see that you are discussing about using I/O expanders and ADC chips. Not to say that IN YOUR CASE you have to use microcontroller - just to show some points that could help you to take the right decision. .
Using I/O expander means that you need several chips - at least two. This will take some board space and pin connections. Don't forget that beside I2C lines (SDA, SCL) you might need some (maybe one, maybe two) interrupt lines. Some clock lines in addition? Also, those simple chips will force you in scanning very often (1ms, 10ms?) about actual data.
Using microcontroller is not easy, that's right. But don't forget that it adds a lot of flexibility. Most modern microcontrollers now have built-in (ROM) bootloader with support for UART, SPI, I2C and so on. I would propose STM32 for example (it is quite well supported by open source tools and code base).
You get low power, low latency processing core - think of filtering, post processing, event detection. Yes, you need to manage firmware update - but this is just because IT IS POSSIBLE to do on the field update (vs fixed function I/O expanders). Some manufacturers (e.g. microchip), and distributors allow ordering chips with pre-programmed user firmware - so no need for programming equipment or JTAG port on the board.
I could imagine that in your case you might even use the microcontroller without precise crystal/ceramic resonator - just with built in RC oscillator (1-2% precision but this does not matter on I2C).
The code itself will not be much of an issue - I suspect that this will be open sourced too so you can get a lot of help on this. So called "sensor fusion" is quite close to your application.

I haven't used yet any of LPC line of Cortex-M microcontrollers from NXP, but I like one of the features - every signal from internal peripheral could be mapped to any microcontroller pin. This means several things:
- you can use all functionalities (internal blocks) without conflicts because of pre-defined "alternative function" mapping - usually this means that you get the smallest possible package to solve your task
- you get the flexibility to change pin mapping later - when the board is ready (but 2 pins were swapped ...)
- you can change pin mapping in runtime - think of using some pins as UART at power on, then switching to I2C

If you have a space USB port on the EOMA, you could put the STM/LPC on the USB. Than use the ready made USB HID examples and feed in your data. Than, use the whole input infrastructure of linux/android and get your events - without coding on the Linux side? (don't know if this is true, just speculating).

Yo no entiendo mucho si tiene razón o no. Os lo dejo aquí porque hay algunos como Segata Sanshiro y Limonetti sabéis más de esto. Si queréis, dejad aquí vuestra opinión y lo escribo allí (aunque Segata está registrado y si quiere puede escribirle directamente).

Saludos.

[nintiendo1]

Lo que ha respondido el creador del EOMA:

On Wed, Aug 6, 2014 at 9:57 AM, krasi gichev <krasimirr@gmail.com> wrote:
> I suspect that we are not looking at the complete picture here. Don't you
> have some more sensors to add on the I2C? Like accelerometer, magnetometer,
> maybe light sensor (for auto brigthness) and so on? Maybe battery
> monitoring?
> I see that you are discussing about using I/O expanders and ADC chips. Not
> to say that IN YOUR CASE you have to use microcontroller - just to show some
> points that could help you to take the right decision. .
> Using I/O expander means that you need several chips - at least two. This
> will take some board space and pin connections. Don't forget that beside I2C
> lines (SDA, SCL) you might need some (maybe one, maybe two) interrupt lines.

i've added 2 EINTs to the specification for exactly this purpose.

Saludos.

[nintiendo1]

Me ha pedido el diagrama de bloques el creador del EOMA-68, por lo que se lo he enviado (en inglés):

http://oi57.tinypic.com/16aeffb.jpg

Y me ha respondido lo siguiente:

ok great.

so, things that are missing from the diagram:

* digital GPIO IC connects its IRQ-OUT to EINT0-IN on EOMA68
* one GPIO IC IN pin is needed for MicroSD "detect"
* EOMA68 PWM out goes to LCD PWM
* digital GPIO IC OUT pin needed for power-up of LCD
* accelerometer IRQ goes to digital GPIO IC IN
* digital GPIO IC IN pin connects to IRQ-OUT of AXP209
* digital GPIO IC IN pin connects to Headphone-detect (in case you want to alter volume on headphone-out)

so you probably want at least 2 16-pin Digital GPIO ICs because that's quite a lot of GPIO. you have two EINTs so you can at least chain all the EINT IRQs together.

if you start using USB (with an STM32F) then you will need 2 USB hubs (or drop the USB Flash Drive idea)

if you use UART (with an STM32F) i would be concerned about the speed / latency of the control protocol communicating data.

honestly i think you are better off with discrete GPIO and ADC ICs (SPI for preference, I2C otherwise).

Pero me pierdo con lo que me dice, ya que no sé lo que es e IRQ-OUT ni el EINT0-IN ni cosas de esas. Por lo que si alguno de los que sepáis, arregláis el diagrama de bloques con lo que dice (aunque sea en sucio con el paint) ya lo pongo yo más bonito y se lo mando para que lo compruebe de nuevo y nos diga si está bien.

La lista de pinout del EOMA-68 por si la necesitáis para los arreglos: http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Table_of_EOMA-68_pinouts

Saludos y gracias.

[lelillo]

Hola. le he dado un vistazo por encima al proyecto y sin tener conocimientos del EOMA68 y muy pocos del proyecto, te comento:
*Te dice de conectar una interrupción de salida del microcontrolador a la interrupción externa 0 del EOMA68 (pin32)
*Una entrada del microcontrolador para detectar uSD
*En este punto no se como funciona la LCD
*Mas del lcd
*La interrupción del acelerómetro va al micro
*la interrupción de salida del PMU la conectas al micro
* Y otra entrada del micro para detectar el headphone
luego comenta que probablemente necesites 2 integrados de 16 entradas
lo siguiente no se para que es el stm32f
finalmente os recomienda no usar microcontroladores y preferentemente comunicación spi

Si meto la pata, disculparme, pues ni soy muy bueno en ingles ni tengo mucha info del proyecto.

[nintiendo1]

Hola. le he dado un vistazo por encima al proyecto y sin tener conocimientos del EOMA68 y muy pocos del proyecto, te comento:
*Te dice de conectar una interrupción de salida del microcontrolador a la interrupción externa 0 del EOMA68 (pin32)
*Una entrada del microcontrolador para detectar uSD
*En este punto no se como funciona la LCD
*Mas del lcd
*La interrupción del acelerómetro va al micro
*la interrupción de salida del PMU la conectas al micro
* Y otra entrada del micro para detectar el headphone
luego comenta que probablemente necesites 2 integrados de 16 entradas
lo siguiente no se para que es el stm32f
finalmente os recomienda no usar microcontroladores y preferentemente comunicación spi

Si meto la pata, disculparme, pues ni soy muy bueno en ingles ni tengo mucha info del proyecto.

Gracias por el comentario y bienvenido al foro.

Por lo que entiendo de lo que he leído y tú pones, sería poner un IC de I2C/SPI-a-GPIO, y en este conectar microSD, pantalla, acelerómetro, el PMIC y los auriculares.

Lo que no entiendo es lo del EINT. No sé si es para I2C o para SPI (o para ambos), y que I2C va conectado a los EINT y cuales no. Es algo que a mis nulos conocimientos se me escapa.

Por otro lado, Limonetti recomendaba I2C sobre SPI, mientras que el creador del EOMA-68 recomienda SPI sobre I2C; ¿que diferencias hay de uno a otro?

De todas formas, para los botones digitales, si usamos un IC exclusivo para botones digitales, como el MCP23017, hay una alternativa para SPI que es el MCP23S17. Aquí el datasheet de ambos: http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf

Saludos y gracias.

[Limonetti]

No he recomendado I2C sobre SPI. Hice alguna búsqueda rápida de un port expander para I2C porque es lo que teníais. Cada uno tiene sus cosas.

A grandes rasgos, SPI es más rápido que I2C. SPI necesita de más hilos que I2C (tres + chip select por componente frente a 2). Y luego ya cada uno con sus peculiaridades y diferencias.

[nintiendo1]

No he recomendado I2C sobre SPI. Hice alguna búsqueda rápida de un port expander para I2C porque es lo que teníais. Cada uno tiene sus cosas.

A grandes rasgos, SPI es más rápido que I2C. SPI necesita de más hilos que I2C (tres + chip select por componente frente a 2). Y luego ya cada uno con sus peculiaridades y diferencias.

Entonces si SPI es más rápido, quizás nos sale más rentable usar SPI para los controles, ¿no? El MCP23S17 es igual que el MCP23017 que nos recomendaste pero por SPI, por lo que usamos uno u otro.

El EOMA-68 tiene tanto SPI como I2C, por lo que nos debería dar igual. Lo que no entiendo es lo del EINT.

Bueno, de todas formas queda decidir si usar el microcontrolador o los 3 componentes para los botones xD

Saludos y gracias.

[Limonetti]

Lo que ha respondido el creador del EOMA:


Using I/O expander means that you need several chips - at least two. This
> will take some board space and pin connections. Don't forget that beside I2C
> lines (SDA, SCL) you might need some (maybe one, maybe two) interrupt lines.

i've added 2 EINTs to the specification for exactly this purpose.

Saludos.

Dice que ha añadido 2 interrupciones para los ports expanders para ese proposito. A eso se refiere con las EINT.

Normalmente puedes configurar un port expander para que te avise de que se ha cambiado el estado de una entrada en un puerto con una de esas lineas. Luego esa linea la conectas a una entrada especifica de interrupción externa del micro y así solo tienes que leer el port expander cuando haga falta (en el handler de la interrupción), en vez de tener que leer todo el rato.

[nintiendo1]

Dice que ha añadido 2 interrupciones para los ports expanders para ese proposito. A eso se refiere con las EINT.

Normalmente puedes configurar un port expander para que te avise de que se ha cambiado el estado de una entrada en un puerto con una de esas lineas. Luego esa linea la conectas a una entrada especifica de interrupción externa del micro y así solo tienes que leer el port expander cuando haga falta (en el handler de la interrupción), en vez de tener que leer todo el rato.

¿Y eso que beneficios da? Me explico, realmente me da igual o no que lea todo el rato, ¿no? Mientras detecte los cambios, me da igual que esté todo el rato leyendo.

Por otro lado, he visto que el EOMA-68 tiene EINT0 y EINT1, ¿se puede conectar los 2 MCP23S17 y el MCP3008 a los 2 EINT que hay o solo puedo conectar 1 IC por cada EINT o como va eso?

Saludos y gracias.

[Limonetti]

Leer todo el rato te ocupa tiempo de proceso y también el bus por el que estas leyendo los datos. Puede importar o no depende de lo que estés haciendo y la cantidad de cosas que quieras atender en un momento dado.

Lo de conectar o no salidas de periféricos de ese tipo a las lineas de interrupción externa ya depende de como se lo plantee el que haga el firmware por lo comentado arriba. En este caso vuestro con la Zeoma ni idea.

[nintiendo1]

Leer todo el rato te ocupa tiempo de proceso y también el bus por el que estas leyendo los datos. Puede importar o no depende de lo que estés haciendo y la cantidad de cosas que quieras atender en un momento dado.

Lo de conectar o no salidas de periféricos de ese tipo a las lineas de interrupción externa ya depende de como se lo plantee el que haga el firmware por lo comentado arriba. En este caso vuestro con la Zeoma ni idea.

Ok, muchas gracias por la explicación.

--------

Al final parece que el creador del EOMA-68 nos recomienda un microcontrolador como decía Segata Sanshiro. El nos recomienda la familia STM32F. Iría por USB, por lo que quitaríamos el PenDrive del USB HUB y pondríamos en su lugar el STM32F:

the nice thing about using the USB interface is that a it's pretty quick (ok 11mbits/sec) but also IRQs etc. are all handled over USB.

the down-side is you'll need to write both the firmware on the STM32F as well as a matching library, but hey that should be fine: i'd suggest doing something like a USB-HID device and a USB-Mouse device, there is plenty of example code for both. anything else you can do as say a USB-ACM (modem) to read unusual stuff.

En concreto, el modelo recomendado sería el STM32F072VBH6 que tiene medidas de 7x7mm y que en teoría tiene pines para todo.

Páginas con datasheets y datos de interés:
- http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259604
- http://www.st.com/st-web-ui/static/active/en/resource/technical/document/programming_manual/DM00051352.pdf
- http://www.st.com/web/en/resource/technical/document/datasheet/DM00090510.pdf
- http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF259717

Más info que me han dado:

Check this link for reference - you can use design files of this eval board for quick start: http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF259717

There is a claim in the datasheet: "Internal 48 MHz oscillator with automatic trimming based on ext. synchronization" - not sure but I suspect that this would be a good option if used on USB - no need for clock crystal for the STM32.


Update - it is written at line 1 at page 1 of the datasheet "ARM-based 32-bit MCU, up to 128 KB Flash, crystal-less USB
FS 2.0, CAN, 12 timers, ADC, DAC & comm. interfaces, 2.0 - 3.6 V" - so it should do clock recovery from USB data stream.

Another note (if you go this way) - this chip has two I2C controllers - so you could "spread" the sensors on both of them to get better throughput. Just take care to estimate the data rate of each one of them so make a good balance.

Ya me diréis que pensáis vosotros. Segata, supongo que si tienes alguna duda o comentario, la harás allí también.

Saludos y gracias!

[nintiendo1]

Bueno, finalmente parece una posibilidad el STM32F072 para los controles, por lo menos por lo que dicen el creador del EOMA-68.

Creo que Segata Sanshiro le estaba echando un vistazo, por lo que ya nos dirá él si es una opción correcta. También habría que ver cuantos pines necesitamos para todo (controles y GPIO de acelerómetro y demás), para escoger un modelo u otro.

Ah, al final pondremos un USB Host 2.0 en vez de uno 3.0, ya que si no hay que cambiar el PMIC y quizás coger otro USB HUB, y además hoy día no existe ningún EOMA-68 con 3.0 que lo aprovechase. Quedaría así (si usamos el STM32F):

1st USB ---> FE 1.1 --> USB Host 2.0
--> USB WIFI
--> USB BT
--> USB Audio

2nd USB ---> STM32F072

Tras esto, creo que ya el diagrama estaría más o menos terminado.

Saludos.

[Segata Sanshiro]

Parece que han secuestrado la discusión de la consola con cuestiones filosóficas sobre el proyecto EOMA xD Los controles en caso de emergencia se pueden volver a meter por I2C en vez de USB.

Efectivamente tengo que mirar qué variante del microcontrolador tiene suficientes GPIO (si la pequeña o la mediana), aunque no sé si tengo los conocimientos suficientes para ello. En cualquier caso hasta mediados de octubre no podré contribuir mucho, pero seguiré escribiendo por aquí o por la lista de correo de vez en cuando.

[nintiendo1]

Parece que han secuestrado la discusión de la consola con cuestiones filosóficas sobre el proyecto EOMA xD Los controles en caso de emergencia se pueden volver a meter por I2C en vez de USB.

Efectivamente tengo que mirar qué variante del microcontrolador tiene suficientes GPIO (si la pequeña o la mediana), aunque no sé si tengo los conocimientos suficientes para ello. En cualquier caso hasta mediados de octubre no podré contribuir mucho, pero seguiré escribiendo por aquí o por la lista de correo de vez en cuando.

Eso parece GP32Spain, que al final te llenan los hilos de offtopic xD

Por ahora eres el único que se ofrece a hacer lo del STM32F, por lo que eres nuestra única esperanza xD. Siempre podemos intentar lo del STM32F, y si no como dices volver al I2C. Piensa que supongo que también nos ayudaría el creador del EOMA-68 (a fin de cuentas, si quiere vender su EOMA-68 necesita nuestra consola, y el hombre siempre se ha mostrado receptivo a ayudarnos).

No te preocupes, a ver si a mediados de octubre ya avanzamos más rápido.

De todas formas, a ver si en Agosto ya se queda terminado el diagrama de bloques (lo pondré allí para que le echen un vistazo también), y ya en Septiembre, cuando vuelva Drumpi (si no hay ningún problemas), empezamos con los esquemas, que si no va a salir la EOMA v2 antes de que terminemos la consola con la EOMA v1 xD

Saludos y gracias.

[Segata Sanshiro]

Lo que me preocupa es si algo tan sensible como el audio tendrá problemas al ir en el mismo USB que algo que consume tanto ancho de banda como el wifi. Creo que dijo el Luke que no habría problema pero no me quedó muy claro.

[nintiendo1]

Lo que me preocupa es si algo tan sensible como el audio tendrá problemas al ir en el mismo USB que algo que consume tanto ancho de banda como el wifi. Creo que dijo el Luke que no habría problema pero no me quedó muy claro.

Según la discusión que tuvimos, el USB debe ser al menos 2.0 para tirar de Audio, WIFI y todo eso.

Por eso pasamos todo lo "gordo" al 1º USB, que según Luke siempre será 2.0, y en el 2º USB, que puede ser 1.1, ponemos solo el STM32F.

De esta forma, quedaría así:

1st USB ---> FE 1.1 --> USB Host 2.0
--> USB WIFI
--> USB BT
--> USB Audio

2nd USB ---> STM32F072

Saludos.

[nintiendo1]

Bueno, ya estamos en Septiembre:
- He actualizado la primera página de este hilo: http://www.gp32spain.com/foros/showthread.php?133592-ZEOMA-Diagrama-de-Bloques-de-ZEOMA-(PCB)-ZEOMA&p=1652963#post1652963
En él ya he subido la v.1.0 donde ya están todas las conexiones (incluidas las del STM32F) y además he cambiado el texto para que se vea más ordenado.
- Agradecería que alguien le echara un vistazo a ver si está bien o hay que cambiar algo.
- Para Drumpi, ¿has vuelto ya de vacaciones? ¿Alguna novedad?
- Para Segata Sanshiro, ¿has podido mirar algo nuevo del STM32F?

Saludos y gracias.

[Segata Sanshiro]

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

[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_ideas/kde_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 :lol:

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 :lol:

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 :(

[nintiendo1]

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 :(

Ok, le he enviado lo que me has dicho. Según lo que me responda ya te digo

Saludos y gracias.

[nintiendo1]

Para Segata Sanshiro

Me ha respondido lo siguiente:

ok, so would you like to ask him, would it help to have some schematics and PCB files that may be directly imported into KiCAD, with the majority of components that you will need already done, parts already done, connections already done, layout already done?

Supongo que la respuesta es sí, pero te lo dejo aquí por si quieres que le dé una respuesta más compleja. Me quedo a la espera de lo que me digas para contestarle.

Saludos y gracias.

[Segata Sanshiro]

Hombre, ciertamente ayudaría, pero me sabe mal decirle que haga todo ese trabajo cuando yo de momento no me puedo comprometer a nada. Si no le cuesta mucho trabajo hacerlo, sería útil tener en formato KiCad los esquemas de cosas comunes con la tableta: alimentación y carga de batería, microSD, ¿audio?...

Lo que no quiero es que haya un malentendido si él invierte tiempo en ZEOMA y luego nosotros por lo que sea no podemos hacerlo, que el hombre ya tuvo algún problema en el pasado con alguien que iba a hacer una tableta basada en EOMA.

[nintiendo1]

Hombre, ciertamente ayudaría, pero me sabe mal decirle que haga todo ese trabajo cuando yo de momento no me puedo comprometer a nada. Si no le cuesta mucho trabajo hacerlo, sería útil tener en formato KiCad los esquemas de cosas comunes con la tableta: alimentación y carga de batería, microSD, ¿audio?...

Lo que no quiero es que haya un malentendido si él invierte tiempo en ZEOMA y luego nosotros por lo que sea no podemos hacerlo, que el hombre ya tuvo algún problema en el pasado con alguien que iba a hacer una tableta basada en EOMA.

Ya le he dicho varias veces que no sé si podríamos hacerlo, le he dicho que tú estabas muy ocupado en tu trabajo y que no ibas a poder avanzar apenas.

Con respecto a que sí nos sería útil, me ha dicho:

i'll check that conversion and import works. give me a couple of days.

Supuestamente nos ayudar por esto que me ha dicho:

the idea's awesome, i'd really like you guys to succeed :)

En realidad supongo que porque necesita dispositivos para sus EOMA-68, y además la idea de una consola así es muy buena, ya que ofrece algo diferente a lo que hay en el mercado como puede ser una tablet, y por tanto le ayudaría a introducir el concepto de EOMA-68 en el mercado.

Lo de la tablet fue otro problema, en realidad encargaron a una empresa china hacer no se cuantas tabletas, y después querían hacer menos o algo así cuando las iban a hacer, y se enfadaron con los chinos.

Saludos.