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

[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):

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_Modu...OMA-68_pinouts

Saludos y gracias.