SIEBOT 2.0 Propuesta arquitectura

[Juan José Díaz Vecchio]

Buenas noches!!!

El principio del nuevo diseño es similar al de la SIE, solo que con un nuevo procesador conectado mediante I2C a un microcontrolador AVR de 8 bits (en reemplazo de la FPGA), existe una conexión SPI para reprogramar el AVR cuando sea necesario, y el I2C es para comunicación en tiempo real.

EL MICRO: En diálogo con el profe Carlos acerca de la comparación entre el actual MIPS de la SIE y el ARM iMX233 de Freescale, surgieron las siguientes conclusiones:

* "El imx permite el uso de DDR, lo que nos permite poner hasta 64MBytes a menores costos que la de 32Mbytes SDRAM de SIE."

* "... el jz exige el uso de NAND, las q tambien son costosas, el iMX permite hacer boot por la SD"

* "El iMx tiene USB host, eso es muy bueno para poner todo tipo de periféricos."

Adicionalmente existe la posibilidad de experimentar con la tecnología Jazelle del iMX, aunque parece ser una tecnología con poco uso.

* Tendremos velocidad de reloj a 454MHz... :D:D:D

* Este micro sale por US$8.59 comprando 25 (y a 5.37 si se compran 100 :P:P:P), en comparación con los 3.70 del JZ4725

EL AVR: Por el lado del AVR a utilizar, hay varias opciones que pongo en cuadro comparativo a continuación:

item                  ATmega8A           ATmega328             ATmega2560

                                                                                 JTAG interface

Clock                16MHz                 20MHz                   16MHz    

Flash                8K                       32K                         256K

SRAM              1K                        2K                          8K

EEPROM          512B                    1k                          4K

PWM(HW)*       2 (8bits)                5 (8bits)                  15 (algunos de hasta 16 bits)

ADC**               6 (10bits)              6 (10bits)                16 (10bits)

                                                   Temp sensor

SPI                   sí                         sí                            sí

GPIO***            10                        7                              51

$$$ ****            US$2.01               US$3.05                   US$8.50                   

                   comprando 25        comprando 25            comprando 50

* PWM que quedan libres después de conectar interfaz SPI

** ADC que quedan libres después de conectar interfaz I2C

*** GPIO que quedan libres después de conectar ambas interfaces, usando los puertos seriales y RESET pin's como GPIO's.

**** no incluye impuestos ni shipping :(:(:( Téngase en cuenta que la FPGA más baratica que usó la SIE costó 10 dólares; Que si se compra en mayor cantidad el precio baja otro tanto; y que hice presupuesto para una primera tanta de aproximadamente 50 tarjetas, tal como sucedió con la SIE (65 de prueba).

Es decir, la cantidad de periféricos disponibles efectivos, asumiendo que tenemos conectada una plataforma robótica que use todos los sensores disponibles, todos los servos posibles, tanto la interfaz SPI como I2C, y los gpio que queden libres después de eso para controlar actuadores sencillos mediante puente(s) H. 

CONCLUSIÓN de JJ: Someto a votación en la sociedad de linux en caja, esta nueva plataforma llamada SIEBOT 2.0, en mi opinión con el iMX233 y el ATmega2560 para lograr una combinación realmente útil en cuanto a robótica se refiere.

Quedo a espera de sus opiniones, quejas, dudas, comentarios, .....

JJ

--
Juan José Díaz Vecchio
Estudiante Ing. Mecatrónica
Grupo Ceimtun
Departamento Ing. Mecánica y Mecatrónica
Universidad Nacional de Colombia

[Carlos Camargo]

Hola JJ

El principio del nuevo diseño es similar al de la SIE, solo que con un nuevo procesador conectado mediante I2C a un microcontrolador AVR de 8 bits (en reemplazo de la FPGA), existe una conexión SPI para reprogramar el AVR cuando sea necesario, y el I2C es para comunicación en tiempo real.

Vale la pena aclarar que el cambio obedece a consideraciones económicas, ya que la FPGA que utiliza SIE cuesta 30 USD, en cantidades de 100, lo que nos parece muy elevado, adicionalmente, el conversor serial utilizado de texas instruments cuesta casi 6 USD de a 100 unidades, lo que resulta más costoso que el procesador, por estos motivos pensamos en cambiar la FPGA a un AVR.

El ATmega2560 me gusta contaríamos con una buena cantidad de PWMs y de ADCs que podrían utilizarse para plataformas robóticas. Nosotros en anteriores diseños ya hemos trabajado con la combinación SoC + Microcontrolador, utilizamos el programa UISP para que el SoC programe el uC utilizando la interfaz ISP, con esto no es necesario cables adicionales,


Carlos


 

--
Usted recibió este mensaje porque está suscrito al grupo "Linux en-Caja".
 
http://wiki.linuxencaja.net
 
Paa enviar un email al grupo, escriba a linux...@googlegroups.com
Para desuscribirse, escriba a linuxencaja...@googlegroups.com
Para más opciones, visite http://groups.google.com/group/linuxencaja

--
Carlos Iván Camargo Bareño
Profesor Asistente
Departamento de Ingeniería Eléctrica y Electrónica
Universidad Nacional de Colombia
cicam...@unal.edu.co

[Andrés Calderón]

2011/2/22 Juan José Díaz Vecchio <jjd...@gmail.com>:

Proponen un proyecto interesante y creo que el AVR es muy útil

Interesante comparación, aunque no me gusta que el ATmega2560 resulte
más caro el AVR que el ARM.

Monté la tabla comparativa que iniciaron en la wiki y agregué 2 AVR nuevos:
http://linuxencaja.net/wiki/SIEBOT2/AVR

ciao

Andrés Calderón
Cel: +57 (300) 275 3666
Email: andres....@emqbit.com
Gtalk: andresf...@gmail.com
Web: www.emqbit.com

> --
> Juan José Díaz Vecchio
> Estudiante Ing. Mecatrónica
> Grupo Ceimtun
> Departamento Ing. Mecánica y Mecatrónica
> Universidad Nacional de Colombia
>
>

[Carlos Camargo]

Pues parece ser que los Xmega no son tan fáciles de programar, según he leido se necesita un programador especial de Atmel para utilizar el puerto PDI que utiliza un protocolo propietario de Atmel, por lo que no sería bueno utilizarlo.


Carlos

2011/2/22 Andrés Calderón <andres....@emqbit.com>

[Andrés Calderón]

2011/2/22 Carlos Camargo <cicam...@gmail.com>:

> Pues parece ser que los Xmega no son tan fáciles de programar, según he
> leido se necesita un programador especial de Atmel para utilizar el puerto
> PDI que utiliza un protocolo propietario de Atmel, por lo que no sería bueno
> utilizarlo.
>
>
> Carlos

Este chip parece interesante aunque se salga un poco de la idea
original: STM32F100C6T6B
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-10500-ND

Además del ADC de 12 bits (10 canales), tiene 2 DACs de 12 bits y
sólo tiene 6 PWM por HW (Implementar PWM eficientes en SW es trivial).

Hay herramientas de programación para Linux:
http://code.google.com/p/stm32flash/

[Carlos Camargo]

Pues es una muy buena opción el STM32, por lo que veo se puede programar por JTAG, utilizando openocd, y por puerto serie, tendríamos que ver cual es más fácil y práctico de implementar,

JJ, podría mirar en esta famila cual es el más adecuado en su relación periféricos/precio?


Carlos

[Juan José Díaz Vecchio]

Hi!,

Contestando rápidamente la pregunta: La versión V8 (eso sonó a alto octanaje y llantas quemadas jajaja), es decir, el STM32F100V8T6B, es comparable con el atmega2560, son 80 gpios por us$4.17. Casi las mismas cosas por la mitad del precio, más abajo menciono otra ventaja del STM.

En seguida me empiezo a preguntar cosas que debí preguntarme antes:

* Cuantos PWM queremos/necesitamos

* Lo de hacer PWM por software no es tan trivial PARA MANEJO DE MÚLTIPLES SERVOS, pero el STM aparentemente le da palo a ese tema con sus 1.25 DMIPS / MHz (Eso se lee 12.5 MIPS por MHz???? confírmenme porque sí es así este micro tiene mucha capacidad de procesamiento para el precio que tiene!!!! y por otro lado es muchísima más de la que necesitamos... O puedo estar leyendo mal esa cosa) .

* Yo soy usuario de linux, programador del mismo, y no puedo evitar recordar que dividir un problema grande en muchos pequeños hace más fácil resolver todo.... realmente vale la pena hacerlo toodo por software para ahorrar más dólares??? ya bajamos de 36 a 8.5 usando el atmega2560.

Planteo esas preguntas, y lo que es más importante: por qué entonces no nos tomamos el tiempo para hacer la misma comparación con productos de motorola/freescale, o texas instruments (que solo tiene uC de 16bits pero pues manda en lo que a instrumentación respecta)?.

Qué opinan? Yo estoy abierto a todas las posibilidades, pero considerando que uno prefiere utilizar lo que ya sabe utilizar. EL tiempo de trabajo es un factor importante para definir costos. Todos lo sabemos, pero a veces lo olvidamos.

JJ

[digitalfredy]

Hola todos, no soy un experto en el tema (apenas tengo idea e interes)
pero no quiero deja pasar esta nota:

> todo.... realmente vale la pena hacerlo toodo por software para ahorrar más
> dólares??? ya bajamos de 36 a 8.5 usando el atmega2560.
> Planteo esas preguntas, y lo que es más importante: por qué entonces no nos
> tomamos el tiempo para hacer la misma comparación con productos de
> motorola/freescale, o texas instruments (que solo tiene uC de 16bits pero
> pues manda en lo que a instrumentación respecta)?.
> Qué opinan?

Creo que es clave que el micro se pueda programa desde linux (el linux
en caja), por ejemplo si hay una red de robots conectados
inalámbricamente y tienen un programa determinado en el micro,
derrepente te das cuenta que hay un error, lo corriges rápidamente y
puedes reprogramar los robots inalámbricamente "sin sacarlos de la
arena" :)

--
ATT: Fredy Pulido López, +1 procurando un mejor mundo para todos.

[Andrés Calderón]

2011/2/22 digitalfredy <digita...@gmail.com>:

> Hola todos, no soy un experto en el tema (apenas tengo idea e interes)
> pero no quiero deja pasar esta nota:
>
>> todo.... realmente vale la pena hacerlo toodo por software para ahorrar más
>> dólares??? ya bajamos de 36 a 8.5 usando el atmega2560.
>> Planteo esas preguntas, y lo que es más importante: por qué entonces no nos
>> tomamos el tiempo para hacer la misma comparación con productos de
>> motorola/freescale, o texas instruments (que solo tiene uC de 16bits pero
>> pues manda en lo que a instrumentación respecta)?.
>> Qué opinan?
>
> Creo que es clave que el micro se pueda programa desde linux (el linux
> en caja), por ejemplo si hay una red de robots conectados
> inalámbricamente y tienen un programa determinado en el micro,
> derrepente te das cuenta que hay un error, lo corriges rápidamente y
> puedes reprogramar los robots inalámbricamente "sin sacarlos de la
> arena"  :)
>

Sí, de eso se trata. Todas las boards que hemos desarrollado tienen
esa capacidad, en la ECB_AT91 el ARM9 programa un AVR a través de un
UISP que modificamos. Y en SIE modificamos xc3sprog para desde el MIPS
programe la FPGA.

[1] http://www.nongnu.org/uisp/
[2] http://projects.qi-hardware.com/index.php/p/nn-usb-fpga/source/tree/master/Software/xc3sprog

ciao,

[digitalfredy]

Hola, contesto abajo

>> Creo que es clave que el micro se pueda programa desde linux (el linux
>> en caja), por ejemplo si hay una red de robots conectados
>> inalámbricamente y tienen un programa determinado en el micro,
>> derrepente te das cuenta que hay un error, lo corriges rápidamente y
>> puedes reprogramar los robots inalámbricamente "sin sacarlos de la
>> arena"  :)
>>
>
> Sí, de eso se trata. Todas las boards que hemos desarrollado tienen
> esa capacidad, en la ECB_AT91 el ARM9  programa un AVR  a través de un
> UISP que modificamos. Y en SIE modificamos xc3sprog para desde el MIPS
> programe la FPGA.
>
> [1] http://www.nongnu.org/uisp/
> [2] http://projects.qi-hardware.com/index.php/p/nn-usb-fpga/source/tree/master/Software/xc3sprog

Gracias por la aclaración y justamente con eso en mente es que hago mi
intervención cuando leo:

"por qué entonces no nos tomamos el tiempo para hacer la misma
comparación con productos de motorola/freescale, o texas instruments"

Teniendo como propósito que si hacen la compraración tengan en cuenta
este asunto que considero destacable.

[Juan José Díaz Vecchio]

Hola Profe!

El 22 de febrero de 2011 18:19, Carlos Camargo <cicam...@gmail.com> escribió:

Hola JJ

En seguida me empiezo a preguntar cosas que debí preguntarme antes:

* Cuantos PWM queremos/necesitamos

Pues eso lo debemos definir, yo pienso que entre más servos tengamos disponibles mucho mejor, los puente-H, servos, y señales análogas de salida se controlan con ellos, la pregunta es que piensa incluir en esta plataforma? con que equipo básico vendría equipada? y que se le deja al usuario para que la expanda.

Bueno yo pienso que lo básico es un puente H para cuando el usuario quiera una plataforma móvil, según el datasheet del STM ...V8, hay 6 PWM por hardware, a primera instancia me parece que ese número está apenas, quiero decir: por ejemplo un manipulador (bracito con pinzas o u otro elemento en la punta) de 5 o 6 grados de libertad está bastante bien. De ahí a que el usuario quiera hacer una aplicación mucho más interesante... pues podemos dejar unos poquitos PWM por software (más adelante toco este tema de nuevo). Dejar los 16 ADC disponibles para sensores me parece perfecto para la plataforma. Dejar el puerto serial del micro para comunicarse con algún sensor digital, de tal forma que el serial del iMX quede disponible para comunicación inalámbrica/alámbrica.

 

 

* Lo de hacer PWM por software no es tan trivial PARA MANEJO DE MÚLTIPLES SERVOS, pero el STM aparentemente le da palo a ese tema con sus 1.25 DMIPS / MHz (Eso se lee 12.5 MIPS por MHz???? confírmenme porque sí es así este micro tiene mucha capacidad de procesamiento para el precio que tiene!!!! y por otro lado es muchísima más de la que necesitamos... O puedo estar leyendo mal esa cosa) .

La D es de Dhrystone, un benchmark que se usa paradeterminar la velocidad, por lo que sería "solo" de 1.25 MIPS

Osea que sí estaba leyendo mal, pero bueno 30MIPS  (1.25 * 24 MHz)en total sigue siendo una buena capacidad de procesamiento :P:P:P

 

* Yo soy usuario de linux, programador del mismo, y no puedo evitar recordar que dividir un problema grande en muchos pequeños hace más fácil resolver todo.... realmente vale la pena hacerlo toodo por software para ahorrar más dólares??? ya bajamos de 36 a 8.5 usando el atmega2560.

A mi no me gusta la idea de hacer todo por SW, en algunos casos no es tan fácil, sobretodo con tareas que son HW netas como los PWMs, yo creo que los STM 32 tienen PWMs disponibles y ADCs.

Exactamente!!!, por eso me pareció buena idea utilizar el atmega2560, tiene PWM por hardware de sobra, amí sinceramente no me gusta mucho la idea de controlar varios servos simultáneamente con PWM por software, eso es tragar mucha capacidad de procesamiento, pero pues 6 PWM HW en el STM alcanzan para hacer cosas chéveres, y si se necesitan adicionales ... ni modo, toca por software pero que no sean tantos.

 

 

Planteo esas preguntas, y lo que es más importante: por qué entonces no nos tomamos el tiempo para hacer la misma comparación con productos de motorola/freescale, o texas instruments (que solo tiene uC de 16bits pero pues manda en lo que a instrumentación respecta)?.

Nosotros ya hemos mirado varios procesadores, lo más importante aca es poder utilizar las mismas herramientas GCC, y poder realizar el proceso completo de programación con herramientas abiertas, la verdad no sé si eso sea posible con los micros de 16 bits de freescale.

Ciertamente, creo que estamos llegando a un punto en que el STM puede resultar bien, sin necesidad de buscar otras marcas.

 

 

Qué opinan? Yo estoy abierto a todas las posibilidades, pero considerando que uno prefiere utilizar lo que ya sabe utilizar. EL tiempo de trabajo es un factor importante para definir costos. Todos lo sabemos, pero a veces lo olvidamos.

Completamente de acuerdo, debemos buscar documentación sobre los procesadores STM32, pero según parece son muy populares, así que no creo que sea dificiles de usar.

He googleado un poco, y he encotnrado bastante información de los STM32, estoy de acuerdo.

 

Otra ventaja de usar los STM32 es que es posible utilizar el sistema operativo de tiempo real eCos:

http://ecos.sourceware.org/about.html
http://ecos.sourceware.org/hardware.html

eCos fué mi primer sistema operativo y es muy amigable, la parte del RT es muy importante en este tipod e aplicaciones, y sería bueno evaluarlo.

Eso sería genial también!!, poder manejar hilos sería una ventaja si duda alguna, y mejoraría mucho en cuanto los posibles inconvenientes debidos al PWM por software.

 

Igual lo más importante para mi es bajar costos, nunca esta de más rebajar 4 USD, cuando fabriquemos 4 millones de placas me lo agradeceran :) Igual debemos ver cuantos PWM tienen en esta familia

Ahí sí me gana una vez más profe, 4 dólares a gran escala hacen la diferencia. En conclusión:

* Puente H

* 6 pwm por hw

* 16 ADC de 12 bits

* Comunicación serial para sensores

* Comunicación serial global con otros dispositivos Xbee u otra interfáz inalámbrica (o cableada)... Bueno no sé qué tan lejos esté el USB inalámbrico teniendo en cuenta que el iMX tiene usb host también. No descarto esa posibilidad :P, aunque Xbee parece más apropiado para robótica cooperativa.

* La escalabilidad que le dejamos al usuario, por lo pronto la veo entérminos de los GPIO restantes con los que puede manejar más actuadores, más puente H, (más pwm por software ¬¬), más sensores de menor complejidad, manejo de pantallas simples etc... Con casi 30 gpio's que quedan libres después de todo lo anterior, un usuario no se puede quejar en cuanto a escalabilidad si usamos el V8 (son 100 pines y cuesta us$4.17 pidiendo tan solo 10 unidades :D:D:D).

* Utilizar eCos en el STM me parece fabuloso, les sigo la corriente en ese sentido.

No sé qué más se me queda en el tintero profe.

JJ

 

Carlos


 

[Juan José Díaz Vecchio]

Hi!

Obtuve estos precios para los micros propuestos por Andrés:

STM32F100V8T6B  us$3.00

STM32F100C6T6B  us$2.20

Tienen en mente alguna buena referencia para la ram ddr que pudiéramos utilizar con iMX?

JJ

[Carlos Camargo]

Hola JJ

De cuantos pines son esos chips?
Numero de PWMs, ADC, ?

La DDR ya la seleccionamos, ouede mirarla en los esquematicos del
repositorio stamp, ya en estos dias mandamos a fabricar el PCB

Carlos

[Andrés Calderón]

2011/2/23 Carlos Camargo <cicam...@gmail.com>:

> Hola JJ
>
> De cuantos pines son esos chips?
> Numero de PWMs, ADC, ?

http://linuxencaja.net/wiki/SIEBOT2/AVR

[Andrés Calderón]

2011/2/23 Carlos Camargo <cicam...@gmail.com>:

> Hola JJ
>
> De cuantos pines son esos chips?

Hay 12 opciones disponibles que salen de la combinación de diferentes
número de pines y de flash de programa:
pines: 48, 64 y 100 TQFP,
flash: 16,32,64 y 128KB

[Juan José Díaz Vecchio]

Hola !

Actualicé la información de ambos micros, http://linuxencaja.net/wiki/SIEBOT2/AVR.

JJ

[Carlos Camargo]

---------- Forwarded message ----------
From: Carlos Camargo <cicam...@gmail.com>
Date: 2011/2/24
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura
To: Juan José Díaz Vecchio <jjd...@gmail.com>


Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en algunas ocasiones se pueden usar los timers para generar más de un PWM


Carlos

2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Juan José Díaz Vecchio <jjd...@gmail.com>
Date: 2011/2/24
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Carlos Camargo <cicam...@gmail.com>


Hi!,

Lo que dice el datasheet es lo siguiente:

* Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de pulsos.

* Hay un timer de control avanzado de 6 canales, de los cuales todos pueden ser salidas de PWM.

* Hay otro timer de 16 bit con un canal para PWM.

* Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.

Osea que por hardware tenemos más pwm de lo que interpreté incialmente... mi error :( .

JJ

El 24 de febrero de 2011 05:28, Carlos Camargo <cicam...@gmail.com> escribió:

Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en algunas ocasiones se pueden usar los timers para generar más de un PWM


Carlos

2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Juan José Díaz Vecchio <jjd...@gmail.com>
Date: 2011/2/24
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura
To: Carlos Camargo <cicam...@gmail.com>

Hola!

Me agrada mucho saber que tienen gente trabajando en este rediseño. Los componentes que finalmente harán parte de la nueva tarjeta no están dentro de mis dominios, así que no soy útil en este momento.

Por lo pronto le dedicaré más tiempo a lo que tiene que ver con el actual SIEBOT, cuya documentación está muy muy pobre, y me mantendré atento a las novedades con respecto al 2.0.

SI en algún momento puedo ser de ayuda, con mucho gusto.

JJ

El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio <jjd...@gmail.com> escribió:

Hi!,

Lo que dice el datasheet es lo siguiente:

* Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de pulsos.

* Hay un timer de control avanzado de 6 canales, de los cuales todos pueden ser salidas de PWM.

* Hay otro timer de 16 bit con un canal para PWM.

* Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.

Osea que por hardware tenemos más pwm de lo que interpreté incialmente... mi error :( .

JJ

El 24 de febrero de 2011 05:28, Carlos Camargo <cicam...@gmail.com> escribió:

Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en algunas ocasiones se pueden usar los timers para generar más de un PWM


Carlos

2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Carlos Camargo <cicam...@gmail.com>
Date: 2011/2/25
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Juan José Díaz Vecchio <jjd...@gmail.com>



Hola JJ

>

Hola!

Me agrada mucho saber que tienen gente trabajando en este rediseño. Los componentes que finalmente harán parte de la nueva tarjeta no están dentro de mis dominios, así que no soy útil en este momento.

Pues solo se está diseñando la placa base, sin los accesarios para robótica, yo creo que debemos ir pensando en que actuadores y que sensores vamos a colocar y crear un proyecto nuevo para hacer la plataforma robótica, claro, tomando como punto de partida la plataforma base que ya esta diseñada. Debemos conectar el STM32, pensar en q canales de comunicación dejamos, así que solo tenemos el punto de partida falta adaptarlo a SIEBOT V2.0, usted es el indicado para hacer esa "personalización"

Y claro la documentación también puede hacerla :)


Carlos


 

SI en algún momento puedo ser de ayuda, con mucho gusto.

JJ

El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio <jjd...@gmail.com> escribió:

Hi!,

Lo que dice el datasheet es lo siguiente:

* Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de pulsos.

* Hay un timer de control avanzado de 6 canales, de los cuales todos pueden ser salidas de PWM.

* Hay otro timer de 16 bit con un canal para PWM.

* Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.

Osea que por hardware tenemos más pwm de lo que interpreté incialmente... mi error :( .

JJ

El 24 de febrero de 2011 05:28, Carlos Camargo <cicam...@gmail.com> escribió:

Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en algunas ocasiones se pueden usar los timers para generar más de un PWM


Carlos

2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Juan José Díaz Vecchio <jjd...@gmail.com>
Date: 2011/2/25
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Carlos Camargo <cicam...@gmail.com>


Hi profe!,

El 25 de febrero de 2011 08:34, Carlos Camargo <cicam...@gmail.com> escribió:

Hola JJ

>

Hola!

Me agrada mucho saber que tienen gente trabajando en este rediseño. Los componentes que finalmente harán parte de la nueva tarjeta no están dentro de mis dominios, así que no soy útil en este momento.

Pues solo se está diseñando la placa base, sin los accesarios para robótica, yo creo que debemos ir pensando en que actuadores y que sensores vamos a colocar y crear un proyecto nuevo para hacer la plataforma robótica, claro, tomando como punto de partida la plataforma base que ya esta diseñada. Debemos conectar el STM32, pensar en q canales de comunicación dejamos, así que solo tenemos el punto de partida falta adaptarlo a SIEBOT V2.0, usted es el indicado para hacer esa "personalización"

Ah entiendo entiendo. En ese caso yo ya le he estado echando ojito al "reference". Profe y alguno de ustedes ha usado los STM32 antes?

JJ

 

Y claro la documentación también puede hacerla :)


Carlos


 

SI en algún momento puedo ser de ayuda, con mucho gusto.

JJ

El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio <jjd...@gmail.com> escribió:

Hi!,

Lo que dice el datasheet es lo siguiente:

* Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de pulsos.

* Hay un timer de control avanzado de 6 canales, de los cuales todos pueden ser salidas de PWM.

* Hay otro timer de 16 bit con un canal para PWM.

* Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.

Osea que por hardware tenemos más pwm de lo que interpreté incialmente... mi error :( .

JJ

El 24 de febrero de 2011 05:28, Carlos Camargo <cicam...@gmail.com> escribió:

Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en algunas ocasiones se pueden usar los timers para generar más de un PWM


Carlos

2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Carlos Camargo <cicam...@gmail.com>
Date: 2011/2/25
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Juan José Díaz Vecchio <jjd...@gmail.com>


Hola

Yo he usado los de Atmel, son muy parecidos todos, lo que debemos
hacer es estudiar el disenyo de referencia de ST y usarlo como punto
de partida.


Corrdial saludo


Carlos

On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
> Hi profe!,
>

> El 25 de febrero de 2011 08:34, Carlos Camargo
> <cicam...@gmail.com>escribió:
>
>>
>> Hola JJ
>>
>>
>> >
>>

>>> Hola!
>>>
>>> Me agrada mucho saber que tienen gente trabajando en este rediseño. Los
>>> componentes que finalmente harán parte de la nueva tarjeta no están
>>> dentro
>>> de mis dominios, así que no soy útil en este momento.
>>>
>>
>> Pues solo se está diseñando la placa base, sin los accesarios para
>> robótica, yo creo que debemos ir pensando en que actuadores y que sensores
>> vamos a colocar y crear un proyecto nuevo para hacer la plataforma
>> robótica,
>> claro, tomando como punto de partida la plataforma base que ya esta
>> diseñada. Debemos conectar el STM32, pensar en q canales de comunicación
>> dejamos, así que solo tenemos el punto de partida falta adaptarlo a SIEBOT
>> V2.0, usted es el indicado para hacer esa "personalización"
>>
>>
> Ah entiendo entiendo. En ese caso yo ya le he estado echando ojito al
> "reference". Profe y alguno de ustedes ha usado los STM32 antes?
>
> JJ
>
>
>> Y claro la documentación también puede hacerla :)
>>
>>
>> Carlos
>>
>>
>>
>>
>>> SI en algún momento puedo ser de ayuda, con mucho gusto.
>>>
>>> JJ
>>>

>>> El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio
>>> <jjd...@gmail.com>escribió:
>>>

>>> Hi!,
>>>>
>>>> Lo que dice el datasheet es lo siguiente:
>>>>
>>>> * Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de pulsos.
>>>> * Hay un timer de control avanzado de 6 canales, de los cuales todos
>>>> pueden ser salidas de PWM.
>>>> * Hay otro timer de 16 bit con un canal para PWM.
>>>> * Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.
>>>>
>>>> Osea que por hardware tenemos más pwm de lo que interpreté
>>>> incialmente...
>>>> mi error :( .
>>>>
>>>> JJ
>>>>
>>>> El 24 de febrero de 2011 05:28, Carlos Camargo
>>>> <cicam...@gmail.com>escribió:
>>>>
>>>> Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en
>>>> algunas
>>>>> ocasiones se pueden usar los timers para generar más de un PWM
>>>>>
>>>>>
>>>>> Carlos
>>>>>
>>>>>

>>>>> 2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Juan José Díaz Vecchio <jjd...@gmail.com>
Date: 2011/2/25
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Carlos Camargo <cicam...@gmail.com>


Hi !

Listo profe, precisamente estoy buscando algunas "application notes" para partir de ahí. Ya he estado revisando algunas librerías de ST, y es puro C bien chévere :D:D:D. Entonces todas mis preocupaciones quedan anuladas. Según he leído hasta ahora, como esos micros traen un bootloader de fábrica, se programan por puerto serial, seleccionado ese modo de boot con unos pines, muy similar a como se hace con el JZ.

JJ

El 25 de febrero de 2011 14:45, Carlos Camargo <cicam...@gmail.com> escribió:

Hola

Yo he usado los de Atmel, son muy parecidos todos, lo que debemos
hacer es estudiar el disenyo de referencia de ST y usarlo como punto
de partida.


Corrdial saludo


Carlos

On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
> Hi profe!,
>

> El 25 de febrero de 2011 08:34, Carlos Camargo
> <cicam...@gmail.com>escribió:
>
>>
>> Hola JJ
>>
>>
>> >
>>

>>> Hola!
>>>
>>> Me agrada mucho saber que tienen gente trabajando en este rediseño. Los
>>> componentes que finalmente harán parte de la nueva tarjeta no están
>>> dentro
>>> de mis dominios, así que no soy útil en este momento.
>>>
>>
>> Pues solo se está diseñando la placa base, sin los accesarios para
>> robótica, yo creo que debemos ir pensando en que actuadores y que sensores
>> vamos a colocar y crear un proyecto nuevo para hacer la plataforma
>> robótica,
>> claro, tomando como punto de partida la plataforma base que ya esta
>> diseñada. Debemos conectar el STM32, pensar en q canales de comunicación
>> dejamos, así que solo tenemos el punto de partida falta adaptarlo a SIEBOT
>> V2.0, usted es el indicado para hacer esa "personalización"
>>
>>
> Ah entiendo entiendo. En ese caso yo ya le he estado echando ojito al
> "reference". Profe y alguno de ustedes ha usado los STM32 antes?
>
> JJ
>
>
>> Y claro la documentación también puede hacerla :)
>>
>>
>> Carlos
>>
>>
>>
>>
>>> SI en algún momento puedo ser de ayuda, con mucho gusto.
>>>
>>> JJ
>>>

>>> El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio
>>> <jjd...@gmail.com>escribió:
>>>

>>> Hi!,
>>>>
>>>> Lo que dice el datasheet es lo siguiente:
>>>>
>>>> * Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de pulsos.
>>>> * Hay un timer de control avanzado de 6 canales, de los cuales todos
>>>> pueden ser salidas de PWM.
>>>> * Hay otro timer de 16 bit con un canal para PWM.
>>>> * Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.
>>>>
>>>> Osea que por hardware tenemos más pwm de lo que interpreté
>>>> incialmente...
>>>> mi error :( .
>>>>
>>>> JJ
>>>>
>>>> El 24 de febrero de 2011 05:28, Carlos Camargo
>>>> <cicam...@gmail.com>escribió:
>>>>
>>>> Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en
>>>> algunas
>>>>> ocasiones se pueden usar los timers para generar más de un PWM
>>>>>
>>>>>
>>>>> Carlos
>>>>>
>>>>>

>>>>> 2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Juan José Díaz Vecchio <jjd...@gmail.com>
Date: 2011/2/25
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura
To: Carlos Camargo <cicam...@gmail.com>


Hi !

Profe, cuando decía que iniciar un nuevo proyecto se refería a uno en git?, es decir, ¿¿¿la idea es tomar como punto de partida el proyecto llamado "stamps" que está en el git de linux en caja, para agregarle el STM32 y los demás componentes que finalmente formen la plataforma SIEBOT2.0 ??? 

Pregunto porque me gustaría mucho (en ese caso) ir agregando el STM32, haciendo las conexiones básicas, e ir revisando entre todos.

Ya estoy leyendo el application note de hardware. Está bien explicadito el asunto :D.

JJ

El 25 de febrero de 2011 15:51, Juan José Díaz Vecchio <jjd...@gmail.com> escribió:

Hi !

Listo profe, precisamente estoy buscando algunas "application notes" para partir de ahí. Ya he estado revisando algunas librerías de ST, y es puro C bien chévere :D:D:D. Entonces todas mis preocupaciones quedan anuladas. Según he leído hasta ahora, como esos micros traen un bootloader de fábrica, se programan por puerto serial, seleccionado ese modo de boot con unos pines, muy similar a como se hace con el JZ.

JJ

El 25 de febrero de 2011 14:45, Carlos Camargo <cicam...@gmail.com> escribió:

Hola

Yo he usado los de Atmel, son muy parecidos todos, lo que debemos
hacer es estudiar el disenyo de referencia de ST y usarlo como punto
de partida.


Corrdial saludo


Carlos

On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
> Hi profe!,
>

> El 25 de febrero de 2011 08:34, Carlos Camargo
> <cicam...@gmail.com>escribió:
>
>>
>> Hola JJ
>>
>>
>> >
>>

>>> Hola!
>>>
>>> Me agrada mucho saber que tienen gente trabajando en este rediseño. Los
>>> componentes que finalmente harán parte de la nueva tarjeta no están
>>> dentro
>>> de mis dominios, así que no soy útil en este momento.
>>>
>>
>> Pues solo se está diseñando la placa base, sin los accesarios para
>> robótica, yo creo que debemos ir pensando en que actuadores y que sensores
>> vamos a colocar y crear un proyecto nuevo para hacer la plataforma
>> robótica,
>> claro, tomando como punto de partida la plataforma base que ya esta
>> diseñada. Debemos conectar el STM32, pensar en q canales de comunicación
>> dejamos, así que solo tenemos el punto de partida falta adaptarlo a SIEBOT
>> V2.0, usted es el indicado para hacer esa "personalización"
>>
>>
> Ah entiendo entiendo. En ese caso yo ya le he estado echando ojito al
> "reference". Profe y alguno de ustedes ha usado los STM32 antes?
>
> JJ
>
>
>> Y claro la documentación también puede hacerla :)
>>
>>
>> Carlos
>>
>>
>>
>>
>>> SI en algún momento puedo ser de ayuda, con mucho gusto.
>>>
>>> JJ
>>>

>>> El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio
>>> <jjd...@gmail.com>escribió:
>>>

>>> Hi!,
>>>>
>>>> Lo que dice el datasheet es lo siguiente:
>>>>
>>>> * Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de pulsos.
>>>> * Hay un timer de control avanzado de 6 canales, de los cuales todos
>>>> pueden ser salidas de PWM.
>>>> * Hay otro timer de 16 bit con un canal para PWM.
>>>> * Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.
>>>>
>>>> Osea que por hardware tenemos más pwm de lo que interpreté
>>>> incialmente...
>>>> mi error :( .
>>>>
>>>> JJ
>>>>
>>>> El 24 de febrero de 2011 05:28, Carlos Camargo
>>>> <cicam...@gmail.com>escribió:
>>>>
>>>> Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en
>>>> algunas
>>>>> ocasiones se pueden usar los timers para generar más de un PWM
>>>>>
>>>>>
>>>>> Carlos
>>>>>
>>>>>

>>>>> 2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Carlos Camargo <cicam...@gmail.com>
Date: 2011/2/26
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Juan José Díaz Vecchio <jjd...@gmail.com>


Hola JJ
Si la idea es comenzar un proyecto nuevo, Andres nos ayudara a eso

Carlos

On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
> Hi !
>
> Profe, cuando decía que iniciar un nuevo proyecto se refería a uno en git?,
> es decir, ¿¿¿la idea es tomar como punto de partida el proyecto llamado
> "stamps" que está en el git de linux en caja, para agregarle el STM32 y los
> demás componentes que finalmente formen la plataforma SIEBOT2.0 ???
>
> Pregunto porque me gustaría mucho (en ese caso) ir agregando el STM32,
> haciendo las conexiones básicas, e ir revisando entre todos.
> Ya estoy leyendo el application note de hardware. Está bien explicadito el
> asunto :D.
>
> JJ
>

> El 25 de febrero de 2011 15:51, Juan José Díaz Vecchio
> <jjd...@gmail.com>escribió:
>

>> Hi !
>>
>> Listo profe, precisamente estoy buscando algunas "application notes" para
>> partir de ahí. Ya he estado revisando algunas librerías de ST, y es puro C
>> bien chévere :D:D:D. Entonces todas mis preocupaciones quedan anuladas.
>> Según he leído hasta ahora, como esos micros traen un bootloader de
>> fábrica,
>> se programan por puerto serial, seleccionado ese modo de boot con unos
>> pines, muy similar a como se hace con el JZ.
>>
>> JJ
>>

>> El 25 de febrero de 2011 14:45, Carlos Camargo
>> <cicam...@gmail.com>escribió:
>>
>> Hola
>>>

>>> Yo he usado los de Atmel, son muy parecidos todos, lo que debemos
>>> hacer es estudiar el disenyo de referencia de ST y usarlo como punto
>>> de partida.
>>>
>>>
>>> Corrdial saludo
>>>
>>>
>>> Carlos
>>>
>>>
>>> On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
>>> > Hi profe!,
>>> >

>>> > El 25 de febrero de 2011 08:34, Carlos Camargo
>>> > <cicam...@gmail.com>escribió:
>>> >
>>> >>
>>> >> Hola JJ
>>> >>
>>> >>
>>> >> >
>>> >>

>>> >>> Hola!
>>> >>>
>>> >>> Me agrada mucho saber que tienen gente trabajando en este rediseño.
>>> Los
>>> >>> componentes que finalmente harán parte de la nueva tarjeta no están
>>> >>> dentro
>>> >>> de mis dominios, así que no soy útil en este momento.
>>> >>>
>>> >>
>>> >> Pues solo se está diseñando la placa base, sin los accesarios para
>>> >> robótica, yo creo que debemos ir pensando en que actuadores y que
>>> sensores
>>> >> vamos a colocar y crear un proyecto nuevo para hacer la plataforma
>>> >> robótica,
>>> >> claro, tomando como punto de partida la plataforma base que ya esta
>>> >> diseñada. Debemos conectar el STM32, pensar en q canales de
>>> comunicación
>>> >> dejamos, así que solo tenemos el punto de partida falta adaptarlo a
>>> SIEBOT
>>> >> V2.0, usted es el indicado para hacer esa "personalización"
>>> >>
>>> >>
>>> > Ah entiendo entiendo. En ese caso yo ya le he estado echando ojito al
>>> > "reference". Profe y alguno de ustedes ha usado los STM32 antes?
>>> >
>>> > JJ
>>> >
>>> >
>>> >> Y claro la documentación también puede hacerla :)
>>> >>
>>> >>
>>> >> Carlos
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> SI en algún momento puedo ser de ayuda, con mucho gusto.
>>> >>>
>>> >>> JJ
>>> >>>

>>> >>> El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio
>>> >>> <jjd...@gmail.com>escribió:
>>> >>>

>>> >>> Hi!,
>>> >>>>
>>> >>>> Lo que dice el datasheet es lo siguiente:
>>> >>>>
>>> >>>> * Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de
>>> pulsos.
>>> >>>> * Hay un timer de control avanzado de 6 canales, de los cuales todos
>>> >>>> pueden ser salidas de PWM.
>>> >>>> * Hay otro timer de 16 bit con un canal para PWM.
>>> >>>> * Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.
>>> >>>>
>>> >>>> Osea que por hardware tenemos más pwm de lo que interpreté
>>> >>>> incialmente...
>>> >>>> mi error :( .
>>> >>>>
>>> >>>> JJ
>>> >>>>
>>> >>>> El 24 de febrero de 2011 05:28, Carlos Camargo
>>> >>>> <cicam...@gmail.com>escribió:
>>> >>>>
>>> >>>> Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en
>>> >>>> algunas
>>> >>>>> ocasiones se pueden usar los timers para generar más de un PWM
>>> >>>>>
>>> >>>>>
>>> >>>>> Carlos
>>> >>>>>
>>> >>>>>

>>> >>>>> 2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Juan José Díaz Vecchio <jjd...@gmail.com>
Date: 2011/2/26
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Carlos Camargo <cicam...@gmail.com>


Listo profe, me avisan entonces, mientras hiré trabajando localmente.

JJ

El 26 de febrero de 2011 08:52, Carlos Camargo <cicam...@gmail.com> escribió:

Hola JJ

Si la idea es comenzar un proyecto nuevo, Andres nos ayudara a eso

Carlos

On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
> Hi !
>
> Profe, cuando decía que iniciar un nuevo proyecto se refería a uno en git?,
> es decir, ¿¿¿la idea es tomar como punto de partida el proyecto llamado
> "stamps" que está en el git de linux en caja, para agregarle el STM32 y los
> demás componentes que finalmente formen la plataforma SIEBOT2.0 ???
>
> Pregunto porque me gustaría mucho (en ese caso) ir agregando el STM32,
> haciendo las conexiones básicas, e ir revisando entre todos.
> Ya estoy leyendo el application note de hardware. Está bien explicadito el
> asunto :D.
>
> JJ
>

> El 25 de febrero de 2011 15:51, Juan José Díaz Vecchio
> <jjd...@gmail.com>escribió:
>

>> Hi !
>>
>> Listo profe, precisamente estoy buscando algunas "application notes" para
>> partir de ahí. Ya he estado revisando algunas librerías de ST, y es puro C
>> bien chévere :D:D:D. Entonces todas mis preocupaciones quedan anuladas.
>> Según he leído hasta ahora, como esos micros traen un bootloader de
>> fábrica,
>> se programan por puerto serial, seleccionado ese modo de boot con unos
>> pines, muy similar a como se hace con el JZ.
>>
>> JJ
>>

>> El 25 de febrero de 2011 14:45, Carlos Camargo
>> <cicam...@gmail.com>escribió:
>>
>> Hola
>>>

>>> Yo he usado los de Atmel, son muy parecidos todos, lo que debemos
>>> hacer es estudiar el disenyo de referencia de ST y usarlo como punto
>>> de partida.
>>>
>>>
>>> Corrdial saludo
>>>
>>>
>>> Carlos
>>>
>>>
>>> On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
>>> > Hi profe!,
>>> >

>>> > El 25 de febrero de 2011 08:34, Carlos Camargo
>>> > <cicam...@gmail.com>escribió:
>>> >
>>> >>
>>> >> Hola JJ
>>> >>
>>> >>
>>> >> >
>>> >>

>>> >>> Hola!
>>> >>>
>>> >>> Me agrada mucho saber que tienen gente trabajando en este rediseño.
>>> Los
>>> >>> componentes que finalmente harán parte de la nueva tarjeta no están
>>> >>> dentro
>>> >>> de mis dominios, así que no soy útil en este momento.
>>> >>>
>>> >>
>>> >> Pues solo se está diseñando la placa base, sin los accesarios para
>>> >> robótica, yo creo que debemos ir pensando en que actuadores y que
>>> sensores
>>> >> vamos a colocar y crear un proyecto nuevo para hacer la plataforma
>>> >> robótica,
>>> >> claro, tomando como punto de partida la plataforma base que ya esta
>>> >> diseñada. Debemos conectar el STM32, pensar en q canales de
>>> comunicación
>>> >> dejamos, así que solo tenemos el punto de partida falta adaptarlo a
>>> SIEBOT
>>> >> V2.0, usted es el indicado para hacer esa "personalización"
>>> >>
>>> >>
>>> > Ah entiendo entiendo. En ese caso yo ya le he estado echando ojito al
>>> > "reference". Profe y alguno de ustedes ha usado los STM32 antes?
>>> >
>>> > JJ
>>> >
>>> >
>>> >> Y claro la documentación también puede hacerla :)
>>> >>
>>> >>
>>> >> Carlos
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> SI en algún momento puedo ser de ayuda, con mucho gusto.
>>> >>>
>>> >>> JJ
>>> >>>

>>> >>> El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio
>>> >>> <jjd...@gmail.com>escribió:
>>> >>>

>>> >>> Hi!,
>>> >>>>
>>> >>>> Lo que dice el datasheet es lo siguiente:
>>> >>>>
>>> >>>> * Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de
>>> pulsos.
>>> >>>> * Hay un timer de control avanzado de 6 canales, de los cuales todos
>>> >>>> pueden ser salidas de PWM.
>>> >>>> * Hay otro timer de 16 bit con un canal para PWM.
>>> >>>> * Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.
>>> >>>>
>>> >>>> Osea que por hardware tenemos más pwm de lo que interpreté
>>> >>>> incialmente...
>>> >>>> mi error :( .
>>> >>>>
>>> >>>> JJ
>>> >>>>
>>> >>>> El 24 de febrero de 2011 05:28, Carlos Camargo
>>> >>>> <cicam...@gmail.com>escribió:
>>> >>>>
>>> >>>> Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en
>>> >>>> algunas
>>> >>>>> ocasiones se pueden usar los timers para generar más de un PWM
>>> >>>>>
>>> >>>>>
>>> >>>>> Carlos
>>> >>>>>
>>> >>>>>

>>> >>>>> 2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Carlos Camargo]

---------- Forwarded message ----------
From: Carlos Camargo <cicam...@gmail.com>
Date: 2011/2/26
Subject: Re: [Linux en-caja] Re: SIEBOT 2.0 Propuesta arquitectura

To: Juan José Díaz Vecchio <jjd...@gmail.com>


listo, Andres no se demora en crear el proyecto, mientras vaya creando
2 nuevas hojas, una para el STM y otra para los sensores y actuadores,
y unalas en el esquema de mas alta jerarquia como estan las del ARM y
de las memorias


Carlos

On 2/26/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
> Listo profe, me avisan entonces, mientras hiré trabajando localmente.
>
> JJ
>

> El 26 de febrero de 2011 08:52, Carlos Camargo
> <cicam...@gmail.com>escribió:
>
>> Hola JJ

>> Si la idea es comenzar un proyecto nuevo, Andres nos ayudara a eso
>>
>> Carlos
>>
>> On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
>> > Hi !
>> >
>> > Profe, cuando decía que iniciar un nuevo proyecto se refería a uno en
>> git?,
>> > es decir, ¿¿¿la idea es tomar como punto de partida el proyecto llamado
>> > "stamps" que está en el git de linux en caja, para agregarle el STM32 y
>> los
>> > demás componentes que finalmente formen la plataforma SIEBOT2.0 ???
>> >
>> > Pregunto porque me gustaría mucho (en ese caso) ir agregando el STM32,
>> > haciendo las conexiones básicas, e ir revisando entre todos.
>> > Ya estoy leyendo el application note de hardware. Está bien explicadito
>> el
>> > asunto :D.
>> >
>> > JJ
>> >

>> > El 25 de febrero de 2011 15:51, Juan José Díaz Vecchio
>> > <jjd...@gmail.com>escribió:
>> >

>> >> Hi !
>> >>
>> >> Listo profe, precisamente estoy buscando algunas "application notes"
>> para
>> >> partir de ahí. Ya he estado revisando algunas librerías de ST, y es
>> >> puro
>> C
>> >> bien chévere :D:D:D. Entonces todas mis preocupaciones quedan anuladas.
>> >> Según he leído hasta ahora, como esos micros traen un bootloader de
>> >> fábrica,
>> >> se programan por puerto serial, seleccionado ese modo de boot con unos
>> >> pines, muy similar a como se hace con el JZ.
>> >>
>> >> JJ
>> >>

>> >> El 25 de febrero de 2011 14:45, Carlos Camargo
>> >> <cicam...@gmail.com>escribió:
>> >>
>> >> Hola
>> >>>

>> >>> Yo he usado los de Atmel, son muy parecidos todos, lo que debemos
>> >>> hacer es estudiar el disenyo de referencia de ST y usarlo como punto
>> >>> de partida.
>> >>>
>> >>>
>> >>> Corrdial saludo
>> >>>
>> >>>
>> >>> Carlos
>> >>>
>> >>>
>> >>> On 2/25/11, Juan José Díaz Vecchio <jjd...@gmail.com> wrote:
>> >>> > Hi profe!,
>> >>> >

>> >>> > El 25 de febrero de 2011 08:34, Carlos Camargo
>> >>> > <cicam...@gmail.com>escribió:
>> >>> >
>> >>> >>
>> >>> >> Hola JJ
>> >>> >>
>> >>> >>
>> >>> >> >
>> >>> >>

>> >>> >>> El 24 de febrero de 2011 07:37, Juan José Díaz Vecchio
>> >>> >>> <jjd...@gmail.com>escribió:
>> >>> >>>

>> >>> >>> Hi!,
>> >>> >>>>
>> >>> >>>> Lo que dice el datasheet es lo siguiente:
>> >>> >>>>
>> >>> >>>> * Hay 3 timers de 16 bits cada uno con 4 IC/OC/PWM o contador de
>> >>> pulsos.
>> >>> >>>> * Hay un timer de control avanzado de 6 canales, de los cuales
>> todos
>> >>> >>>> pueden ser salidas de PWM.
>> >>> >>>> * Hay otro timer de 16 bit con un canal para PWM.
>> >>> >>>> * Hay otros 2 timers de 16 bits cada uno con IC/OC/OCN/PWM.
>> >>> >>>>
>> >>> >>>> Osea que por hardware tenemos más pwm de lo que interpreté
>> >>> >>>> incialmente...
>> >>> >>>> mi error :( .
>> >>> >>>>
>> >>> >>>> JJ
>> >>> >>>>
>> >>> >>>> El 24 de febrero de 2011 05:28, Carlos Camargo
>> >>> >>>> <cicam...@gmail.com>escribió:
>> >>> >>>>
>> >>> >>>> Cuando colocan que tiene 4 PWMs de 16 bits, son PWMs o timers? en
>> >>> >>>> algunas
>> >>> >>>>> ocasiones se pueden usar los timers para generar más de un PWM
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> Carlos
>> >>> >>>>>
>> >>> >>>>>

>> >>> >>>>> 2011/2/23 Juan José Díaz Vecchio <jjd...@gmail.com>

[Juan José Díaz Vecchio]

Hola a todos!!

Aún sigo trabajando en los esquemáticos basado en el stamp del iMX233, me surgen algunas dudas y quisiera compartirlas:

* Tanto el iMX como el STM32 tienen RTC:

          alimentar ambos con una pila "onboard" ?

          alimentar solo el iMX con la pila y mantener el stm32 con VDD?

* Sería prudente para la plataforma (teniendo en cuenta que será especial para robótica) agregar un pequeño circuito para la recarga de Lipo/LiIon?

* Qué combinación resultaría mejor para la alimentación?:

         BAtería de 3V6 + conversor DC-DC para obtener 5V, es adecuado o contraproducente conectar directamente la salida del DC-DC con estos 5V a la alimentación de la tarjeta?

         Batería de más de 5V + regulador de voltaje?

Si me equivoco, corrijan mi ignorancia porfa :D:D:D.

En el caso de la última pregunta, ya tengo la experiencia con el SIEBOT: liIon de 3V6 (4V2 cargada) y un DC-DC hasta 7V para luego mendante regulador de 5V alimentar la SIE. Esa combinación está funcionando muy bien y el consumo en corriente es de alrededor de los 550mA cuando están funcionando encoders, GPS .... y de alrededor de 700mA cuando funcionan los motores (por lo menos con el multímetro, no sé los picos de cuánto serían :( ); en últimas eso da como resultado que el SIEBOT pueda funcionar entre 30 y 50 minutos antes de que la SIE empiece a reiniciarse sola, con una pila de 3V6 a 900mAh. Me parece algo razonable, pero no tengo mucho contra qué comparar, quizá ustedes tengan datos que soporten este caso o que revelen que el SIEBOT es un tragón de energía jajaja.

JJ

[Andrés Calderón]

2011/3/10 Juan José Díaz Vecchio <jjd...@gmail.com>

Hola a todos!!

Aún sigo trabajando en los esquemáticos basado en el stamp del iMX233, me surgen algunas dudas y quisiera compartirlas:

* Tanto el iMX como el STM32 tienen RTC:

          alimentar ambos con una pila "onboard" ?

          alimentar solo el iMX con la pila y mantener el stm32 con VDD?

En general, es innecesario un segundo RTC, el del SMT32 sobraría.
 

* Sería prudente para la plataforma (teniendo en cuenta que será especial para robótica) agregar un pequeño circuito para la recarga de Lipo/LiIon?

De cuantos As la batería? el MX233 incluye cargador lineal para batería de LiPo de una sola celda. Tiene una restricción fuerte, carga máximo a 0.5A/h

 

* Qué combinación resultaría mejor para la alimentación?:

         BAtería de 3V6 + conversor DC-DC para obtener 5V, es adecuado o contraproducente conectar directamente la salida del DC-DC con estos 5V a la alimentación de la tarjeta?

         Batería de más de 5V + regulador de voltaje?

Como siempre.... depende :)   Me gusta la idea de usar baterías de LiPo, que tensiones necesitan? cuantos Amperios? que quieren hacer? En el mercado de hobby[1] hay disponible un montón de baterías de 2,3,4 celdas (3.7V por celda). Pero en el caso de usar más de una celda, es necesario  un circuito de carga adecuado para múltiples celdas (y así evitar incomodas explosiones), otra opción es dejar el problema del cargador a otro, o usar un cargador externo [2]. Posiblemente la tarjeta que están haciendo hace parte de algo que consume mucho, y para los que ya hay un manejo de las baterias, en donde el consumo del mx233 es muy poco comparado al de los motores...

[1] http://www.hobbyking.com/hobbyking/store/uh_listCategoriesAndProducts.asp?catname=Li-Poly+%28All+brands%29&idCategory=86&ParentCat=85

[2] http://www.hobbyking.com/hobbyking/store/uh_listCategoriesAndProducts.asp?catname=Battery+Chargers&idCategory=216&ParentCat=408

Si me equivoco, corrijan mi ignorancia porfa :D:D:D.

En el caso de la última pregunta, ya tengo la experiencia con el SIEBOT: liIon de 3V6 (4V2 cargada) y un DC-DC hasta 7V para luego mendante regulador de 5V alimentar la SIE. Esa combinación está funcionando muy bien y el consumo en corriente es de alrededor de los 550mA cuando están funcionando encoders, GPS .... y de alrededor de 700mA cuando funcionan los motores (por lo menos con el multímetro, no sé los picos de cuánto serían :( ); en últimas eso da como resultado que el SIEBOT pueda funcionar entre 30 y 50 minutos antes de que la SIE empiece a reiniciarse sola, con una pila de 3V6 a 900mAh. Me parece algo razonable, pero no tengo mucho contra qué comparar, quizá ustedes tengan datos que soporten este caso o que revelen que el SIEBOT es un tragón de energía jajaja.

Datos interesantes.

-- Andrés
 

[Carlos Camargo]

Hola 

* Tanto el iMX como el STM32 tienen RTC:

          alimentar ambos con una pila "onboard" ?

          alimentar solo el iMX con la pila y mantener el stm32 con VDD?

Estoy de acuerdo con andrés, podemos utilizar solo uno alimentado con batería para el iMX, igual debemos tener la posibilidad de obtener el tiempo del GPS que ustedes están usando.

En el caso de la última pregunta, ya tengo la experiencia con el SIEBOT: liIon de 3V6 (4V2 cargada) y un DC-DC hasta 7V para luego mendante regulador de 5V alimentar la SIE. Esa combinación está funcionando muy bien y el consumo en corriente es de alrededor de los 550mA cuando están funcionando encoders, GPS .... y de alrededor de 700mA cuando funcionan los motores (por lo menos con el multímetro, no sé los picos de cuánto serían :( ); en últimas eso da como resultado que el SIEBOT pueda funcionar entre 30 y 50 minutos antes de que la SIE empiece a reiniciarse sola, con una pila de 3V6 a 900mAh. Me parece algo razonable, pero no tengo mucho contra qué comparar, quizá ustedes tengan datos que soporten este caso o que revelen que el SIEBOT es un tragón de energía jajaja.

Pues no me parece tan bueno usar un regulador lineal de 5V después de un conversor DC/DC, ya que la caida de voltaje en él hace que se disipe mucha potencia, a mi megustaría más poder generar los 5V a partir de un DC/DC para optimizar más. 

Carlos

[Juan José Díaz Vecchio]

El 12 de marzo de 2011 09:41, Carlos Camargo <cicam...@gmail.com> escribió:

Hola 

* Tanto el iMX como el STM32 tienen RTC:

          alimentar ambos con una pila "onboard" ?

          alimentar solo el iMX con la pila y mantener el stm32 con VDD?

Estoy de acuerdo con andrés, podemos utilizar solo uno alimentado con batería para el iMX, igual debemos tener la posibilidad de obtener el tiempo del GPS que ustedes están usando.

Totalmente de acuerdo con Carlos, me hizo reflexionar y realmente no hay necesidad de almacenar la hora en la plataforma robótica, y si en determinado momento se necesita, ahí está el GPS.

En el caso de la última pregunta, ya tengo la experiencia con el SIEBOT: liIon de 3V6 (4V2 cargada) y un DC-DC hasta 7V para luego mendante regulador de 5V alimentar la SIE. Esa combinación está funcionando muy bien y el consumo en corriente es de alrededor de los 550mA cuando están funcionando encoders, GPS .... y de alrededor de 700mA cuando funcionan los motores (por lo menos con el multímetro, no sé los picos de cuánto serían :( ); en últimas eso da como resultado que el SIEBOT pueda funcionar entre 30 y 50 minutos antes de que la SIE empiece a reiniciarse sola, con una pila de 3V6 a 900mAh. Me parece algo razonable, pero no tengo mucho contra qué comparar, quizá ustedes tengan datos que soporten este caso o que revelen que el SIEBOT es un tragón de energía jajaja.

Pues no me parece tan bueno usar un regulador lineal de 5V después de un conversor DC/DC, ya que la caida de voltaje en él hace que se disipe mucha potencia, a mi megustaría más poder generar los 5V a partir de un DC/DC para optimizar más. 

Ah perfecto!!!, mi duda era esa, pero si no hay problema en poner la salida del DC-DC directo al iMX entonces voy a ajustarlo para generar de una los 5V, conectarlo al iMX y también regular los 3V3 para el STM32 y los 2V5 para la DDR.

Por otro lado:

* Voy a conectar dos puertos U[S]ART entre el stm32 y el iMX

* Voy a conectar los pines JTAG del STM32 a los correspondientes del iMX (para esto me falta documentarme un poco más)

* Conectaré los pines para "boot select" y  "reset" del STM32 a algunos gpios del iMX. Con respecto a eso adelante un detalle de interés:

Hay 3 modos de boot del stm32: - boot por la SRAM. - boot por la memoria de sistema (bootloader) y - boot por la memoria de programa. El bootloader (que por fortuna viene de fabrica) ocupa aproximadamente 2KB de espacio en la flash del micro, y lo demás es para programa, así que en principio con un puerto serial, y los pines del boot y del reset conectados al iMX tendremos control completo sobre el STM32.

* De manera adicional, el STM32 tiene capacidad para ser programado mediante IAP (In Application Programming), por cualquiera de los pines del mismo (cualquiera de los UART, cualquiera de los I2C, por SPI e incluso los GPIO... por donde sea) si la aplicación de usuario incluye las rutinas necesarias (el protocolo de comunicación y de lectura/escritura de la flash es abierto :D:D:D). Por lo anterior tengo ganas de conectar también uno de los puertos I2C del STM32 al iMX, leo opiniones.... :D:D:D.

JJ

Carlos

--

Carlos Iván Camargo Bareño
Profesor Asistente
Departamento de Ingeniería Eléctrica y Electrónica
Universidad Nacional de Colombia
cicam...@unal.edu.co

--

Usted recibió este mensaje porque está suscrito al grupo "Linux en-Caja".
 
http://wiki.linuxencaja.net
 
Paa enviar un email al grupo, escriba a linux...@googlegroups.com
Para desuscribirse, escriba a linuxencaja...@googlegroups.com
Para más opciones, visite http://groups.google.com/group/linuxencaja

[Carlos Camargo]

El puerto JTAG del STM32 debe conectarse a GPIOs del imx,
antes de conectar los puertos i2c debe mirar si el STM32 se puede
conectar como esclavo.
Tambien debe pensar que mjuchos sensores interesantes para robotica
son i2c o spi, por lo que es bueno dejarlos disponibles. El imx
sopporta DMA con el puerto SPI por lo q seria un buen candidato pazra
realizar la comunicacion entre los procesadores,

Cuantos puertos I2c tiene el stm32?

Carlos

[Carlos Camargo]

El puerto JTAG del STM32 debe conectarse a GPIOs del imx,
antes de conectar los puertos i2c debe mirar si el STM32 se puede
conectar como esclavo.
Tambien debe pensar que mjuchos sensores interesantes para robotica
son i2c o spi, por lo que es bueno dejarlos disponibles. El imx
sopporta DMA con el puerto SPI por lo q seria un buen candidato pazra
realizar la comunicacion entre los procesadores,

Cuantos puertos I2c tiene el stm32?

Carlos

[Andrés Calderón]

2011/3/12 Juan José Díaz Vecchio <jjd...@gmail.com>:

Hola JJ,

Los seriales son un recurso escaso y valioso. Le recomiendo que sólo
use uno entre ARM7 y ARM9. El IMX233 tiene 3 seriales y en una
aplicación típica Ud. tendría un serial para el GPS la consola de
depuración y la programación de SMT32...

-- andrés

[Juan José Díaz Vecchio]

El 12 de marzo de 2011 19:50, Carlos Camargo <cicam...@gmail.com> escribió:

El puerto JTAG del STM32 debe conectarse a GPIOs del imx,

Oki Doki! 

antes de conectar los puertos i2c debe mirar si el STM32 se puede
conectar como esclavo.  

Sí puede :D, tiene capacidad multimaster 

Tambien debe pensar que mjuchos sensores interesantes para robotica
son i2c  o spi, por lo que es bueno dejarlos disponibles.

Ciertamente, solo quería dejar uno de los dos, para probar eficiencia y tenerlo como alternativa en caso de falla, tal como los comentamos, según las conclusiones que resultaran del prototipo, pues lo puedo quitar o dejar para el RC.

 

El imx
sopporta DMA con el puerto SPI por lo q seria un buen candidato pazra
realizar la comunicacion entre los procesadores,

Ok, voy a ver si con el remapeo preliminar de pines que hice para el STM32 quedaron bien los pines del SPI o si me toca reintegrar algunos. 

Cuantos puertos I2c tiene el stm32?

2 puertos, ambos con multimaster. 

JJ

[Juan José Díaz Vecchio]

Totalmente de acuerdo, son recursos valiosos, por eso es que quiero probarlos todos en el prototipo, fue un punto que me expuso Carlos y que me gustó mucho. De manera adicional, no todos los días se tiene a la mano un dispositivo con el que se pueda documentar claramente una comparación directa entre todos estos métodos de comunicación, me parece que ese prototipo podría arrojar datos muy valiosos para futuros diseños de todos nosotros. Como dije antes, luego de ver esos resultados, podremos escoger cuál de todos usar como puente entre el STM y el iMX para dejar los demás disponibles.

Están de acuerdo?

JJ