[Butia-devel-list] Futuro y alternativas de motores CC

[Alan Jhonn Aguiar Schwyn]

Yo todavía creo en los hackpines! No será exactamente la filosofía.. pero es una corrientecercana..
Para mi, hay que darle compatibilidad a los hackpines con un display:

http://d24w6bsrhbeh9d.cloudfront.net/photo/6923471_700b.jpg

> Date: Mon, 1 Apr 2013 00:02:08 -0300
> From: xxopxe en gmail.com
> To: aaguirre en fing.edu.uy
> CC: butia-devel-l en fing.edu.uy; barbierimartinezlucio en gmail.com; dearmas en fing.edu.uy; edgardovaz en gmail.com; jpereira en fing.edu.uy; fandrade en fing.edu.uy
> Subject: Re: [Butia-devel-list] Futuro y alternativas de motores CC
> 
> Comento entre lineas.
> 
> On 31/03/13 22:14, Andres Aguirre wrote:
> > Como dije antes, no es agregar nada, es una forma de ver las cosas a 
> > futuro.
> Según entendí hay que volver a cambiar el enrutamiento. Otra vez. En 
> cuanto a la visión de futuro, comento más adelante.
> 
> > Hay dos opciones, mantener hackpoint o no.
> Por mi, no si complican lo mas mínimo al Butia 2. O sea, no. Hackpines 
> no es Butia 2.0, y nunca lo fue. En un momento se agregaron para hacer 
> cosas que no eran Butia, porque no jodían. Ahora resulta que joden.
> 
> > Programar la detección del shield es trivial, eso no nos va a mover de 
> > nuestro camino crítico.
> Lo que está en el camino es toda la idea de hackpines. Este tiempo 
> debería usarse en hacer sensores y actuadores. Todo el tiempo que 
> estamos gastando en esto es tiempo perdido. La usb4all ya existe y es 
> compatible, ahí estan todos los hackpines que puedan hacer falta.
> 
> > Yo lo plantie el serial como algo a futuro, para sensores complejos 
> > que necesiten de un micro o simplemente como una forma de extensión. 
> >  No esta conteplado para la entrega de ANTel.
> Butia 2.0 se acaba en Butia 2.0. Por algunos de los argumentos que 
> mencionas, al diseño actual no le queda mucho futuro, porque dentro de 
> dos años la tecnología va a ser otra. Deberíamos estar aprovechando el 
> presente, y eso es sacando lo antes posible Butia 2.0, y que sea lo más 
> accesible posible (minimizar costo, producción viable) y usable posible 
> (software testeado, documentación, sensores suficientes). Y proyectos de 
> ejemplo que muestren todo, y la lista sigue.
> 
> > En lo que no estoy de acuerdo es en el doble capa, para mi es 
> > prioritario que la tecnología no sea un impedimento para trabajar con 
> > robótica pedagógica y por eso considero importante usar shields, es 
> > una forma fácil de implementar dos capas. Hasta que no exista una 
> > forma accesible para cualquier profesor de liceo de imprimir algo en 
> > dos capas, tiene que seguir existiendo este diseño.
> Esto es independiente de la discusión actual de los hackpines, por eso 
> no voy a argumentar demasiado. Solo diré: deberíamos regalar las placas.
> 
> > Si vamos a pensar un diseño de multicapa ni siquiera pensaría en un 
> > microcontrolador, con los costos de los SOC de hoy día directamente me 
> > inventaría una SBC o usaría el diseño de una ya existente como la 
> > beagle y la modificaría.
> Yo estoy a favor :)
> 
> Jorge
> 
> PS: estoy con fiebre, por las dudas.
> 
> PS2: Probando la herramienta splint la apunté a los .c del firmware... y 
> detonó. Encontró una torta de asignaciones de int a byte, shifts con 
> números negativos, y cosas por el estilo. Alguien que sepa podría pegar 
> una revisada...
> 
> _______________________________________________
> Butia-devel-l site list
> Butia-devel-l en fing.edu.uy
> https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
 		 	   		  
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: https://www.fing.edu.uy/pipermail/butia-devel-l/attachments/20130401/57535e40/attachment.html