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