sábado, 11 de enero de 2014

Instalación MPLAB


Instalación MPLAB
MPLAB es un IDE gratuito de Microship, el cual nos permite crear proyectos para diferentes microcontroladores, la versión que vamos a utilizar en las prácticas será la 8.33.
Lo primero que debemos hacer es descargar e instalar el programa. http://www.microchip.com
Luego de esto se procede a instalarlo como cualquier programa recuerden que se esta desarrollando bajo el SO Windows, al acabar la instalación ejecutamos el MPLAB que nos muestra una pantalla así:

 
Luego debemos verificar que el compilador este configurado.
Para esto vamos a Project -> Set Lenguage Tools Locations buscamos Microchip C18 toolsuite entramos en Executables, aparecen 4 nombre, estos son MPASM, MPLAB C18 C Compiler, MPLIB Librarian y MPLINK Object Linker; hay que localizar en una parte del disco duro donde se instalaron estos recursos, en mi caso:
C:\MCC18\mpasm\MPASMWIN.exe
C:\MCC18\bin\mcc18.exe
C:\MCC18\bin\mplib.exe
C:\MCC18\bin\mplink.exe
Luego OK y listo tenemos nuestro compilador configurado.



 
Una vez instalado podremos comenzar a trabajar, para eso crearemos un nuevo proyecto utilizando el Wizard de MPLAB que se encuentra en el menú Project -> Project Wizard, al hacerlo aparecerá la siguiente pantalla.




Hacemos click en Siguiente, luego se mostrará una ventana donde debemos escoger el PIC que se vaya a usar, en la lista que aparece seleccionamos PIC16F628A y damos click en Siguiente.



El siguiente paso es definir el programa de lenguaje que será usado. En nuestro caso el lenguaje es Ensamblador así que seleccionamos la opción mostrada en la siguiente imágen y de nuevo hacemos click en Siguiente.


En la siguiente ventana tenemos que darle un nombre al proyecto y escoger el directorio en el que se guardará. Es recomendable que la ruta de la carpeta donde se guarda el proyecto no sea muy larga ya que al compilarlo MPLAB marca un error, es por eso que en el ejemplo la ruta escogida se encuentra cerca de la raiz del disco duro, así que recomiendo crear una carpeta directamente en el disco "C:\" o en cualquiera que se use, pero que sea en la raiz del disco. Para este caso la ruta escogida fue C:\micropic\Proyecto1\ pero sientan la libertad de escoger cualquier otro nombre para la carpeta.
 
Una vez dado el nombre al proyecto al hacer click en Siguiente se abrirá una nueva ventana que nos pedirá agregar archivos existentes al proyecto, como aún no hemos escrito ningún archivo simplemente damos click en Siguiente y para terminar en la última ventana hacemos click en Finalizar.

Ya que creamos el proyecto y habiendo dado click a Finalizar en la ventana anterior debemos ver la ventana del MPLAB más o menos con este aspecto.

Y ahora si empieza lo bueno, una vez creado el proyecto es hora de crear un archivo y empezar a escribir el código. Lo que hacemos es crear un nuevo archivo y guardarlo con extensión .asm en la carpeta donde tenemos nuestro proyecto, para crear un archivo damos click en File -> New, después y antes de escribir en el archivo hacemos click en File -> Save As. En la ventana que se abra le damos un nombre a nuestro archivo y nos aseguramos de que el tipo de archivo seleccionado sea ensamblador.

Ahora el archivo creado tiene extensión .asm, pero para el proyecto eso no nos sirve, tenemos que agregar el archivo al proyecto y después comenzar a trabajar en el así que en la ventana del proyecto hacemos click derecho en Source Files y después seleccionamos Add File.
Posteriormente se abrirá una ventana donde debemos seleccionar el archivo que queremos agregar al proyecto. Por defecto se abrirá la carpeta del proyecto que acabamos de crear así que seleccionamos el archivo (en este caso led.asm) y hacemos click en Abrir. Hecho eso la ventana del proyecto debe verse asi:
Ahora si podemos escribir nuestro código en el archivo led.asm y todos los cambios que hagamos en este se verán reflejados en nuestro proyecto. Escribamos un código sencillo. Un programa que solamente encienda un led conectado al pin 17 del microcontrolador, lo que sería el bit 0 del puerto A. El código sería el siguiente:


Al final incluiré un enlace para descargar el código en formato PDF que fácilmente se puede copiar y pegar en MPLAB.
Una vez escrito el código podemos compilar el programa, con esto se genera el archivo.hex con el que podremos grabar el PIC. Para compilar el programa podemos usar el menú Project - Build All o usar la combinación Ctrl + F10. El archivo HEX generado se encuentra en el mismo directorio que el proyecto y lleva el mismo nombre que el archivo con el código, en este caso sería led.hex.
Con esto cubrimos la parte de crear un proyecto y realizar un programa en MPLAB, más adelante veremos cómo simular los proyectos utilizando el simulador MPLAB SIM y también como grabar el programa en el PIC utilizando programas como IC-PROG y WinPIC800.

miércoles, 16 de octubre de 2013

II CONGRESO INTERNACIONAL DE INGENIERÍA MECATRÓNICA Y AUTOMATIZACIÓN - II CIIMA

II CONGRESO INTERNACIONAL DE INGENIERÍA MECATRÓNICA Y AUTOMATIZACIÓN - II CIIMA

Las Universidades de la Red Colombiana de Ingeniería Mecatrónica y Automatización de Colombia, invitan a participar en el II CIIMA, evento a desarrollarse en la ciudad de Bogotá, del 23 al 25 de Octubre de 2013.
Las temáticas centrales del congreso son:

 - Control y Aplicaciones Industriales,
 - Automatización e Instrumentación Industrial,
 - Inteligencia Artificial y Procesamiento de Señales,
 - Diseño Mecatrónico
 - Robótica

 El evento incluye: 7 conferencias magistrales con expertos internacionales, 42 ponencias simultáneas, muestra de posters, workshops,muestra académica, empresarial y cultural.
Todos los futuros profesionales de la Automatización, Control y  Mecatrónica, reunidos en un solo evento!

Descuento del 15% para miembros IEEE (para aplicar el descuento, el asistente debe enviar solicitud aiautomatizacion@lasalle.edu.co indicando nombre completo, número de identificación y número de membresía).

Visita la página web: www.ciima.net/CIIMA2013
Organiza: Red de Ingeniería Mecatrónica y Automatización de Colombia

martes, 15 de octubre de 2013

Festival de Robótica: Robotic People Fest 2013

La comunidad Robotic People tiene el gusto de invitarlos al gran Festival de Robótica: Robotic People Fest 2013, que se llevará a cabo en Corferias en el marco de SOFA (Salón de Ocio y la Fantasía) del 14 al 17 de noviembre.
¡Anímate a participar en alguna de nuestras categorías!
Sumo 1Kg
Sumo 3Kg
Seguidor de línea
Laberinto- seguidor de línea
Recolector- seguidor de línea
Recolector Lunar- teleoperado
Penales robots Humanoides
Penales robots con ruedas
Expo robot: Animatrónicos
Expo robot: Industrial
Expo robot: Libre
Simulación
Para mas información:
http://roboticpeople.com/roboticpeoplefest2013/
Búscanos en SOFA, Agenda de Contenidos:
http://enelsofa.com/sofa2013/
La primera versión del festival estará constituida por talleres para niños y adultos y tutoriales para principiantes y conocedores en el tema, exhibiciones de las empresas más representativas del país, muestras de grupos de trabajo que participan en las competencias mundiales más importantes y una gran variedad de concursos.
Síguenos en:
https://www.facebook.com/roboticpeoplefest2013
https://twitter.com/RoboticPplFest
Mira el video promocional Aqui
http://vimeo.com/70855756
Asi mismo los invitamos a registrarse en nuestra comunidad en linea en www.roboticpeople.com , con el fin de mantenerse actualizado con todas las noticias de nuestra área de interés.

martes, 1 de octubre de 2013

LLAMADO A PRESENTACIÓN DE RESÚMENES EXTENDIDOS - SEMINARIO INTERNACIONAL EN FUENTES ALTERNATIVAS DE ENERGÍA Y EFICIENCIA ENERGÉTICA

CALL FOR ABSTRACTS – LLAMADO A PRESENTACIÓN DE RESÚMENES EXTENDIDOS 

IEEE SIFAE 2013
SEMINARIO INTERNACIONAL EN FUENTES ALTERNATIVAS DE ENERGÍA Y EFICIENCIA ENERGÉTICA
Noviembre 14, 2013
Compensar Calle 94, Bogotá, Colombia

El cuarto Seminario Internacional en Fuentes Alternativas de Energía y Eficiencia Energética (SIFAE 2013) se llevará a cabo en Compensar de la calle 94 (Calle 94 No. 23-43) en la ciudad de Bogotá, Colombia. SIFAE 2013, es un seminario que busca promover el desarrollo y la difusión de  las fuentes alternas de energía, la eficiencia energética, así como promover la estandarización y regulación del mercado energético. Abrirá además un espacio para discutir acerca del impacto de la gestión energética a través de casos de estudio que serán presentados.
El comité organizador invita a enviar sus resúmenes extendidos de trabajos inéditos para consideración. Los resúmenes de los trabajos que sean aceptados serán presentados en la sesión de posters.

AREAS TEMÁTICAS

La siguiente es una lista no exhaustiva de las áreas temáticas de  la
conferencia:

Energía solar
Energía eólica
Energía del océano
Energía del Hidrógeno
Energía geotérmica
Energía hidroeléctrica (MCH, PCH, uCH, pCh)
Bioenergía (biocombustibles)
Generación distribuida
Uso racional y eficiente de la energía
Redes Inteligentes
Eficiencia térmica y/o eficiencia eléctrica
Gestión energética - ISO 50001
Micro-redes
Vehículos eléctricos


FECHAS IMPORTANTES
Fecha límite para recepción de resúmenes extendidos: octubre 18, 2013
Notificación de aceptación: octubre 25, 2013
Recepción de resúmenes corregidos y fecha límite para registro de
autores: noviembre 01, 2013

ENVÍO DE TRABAJOS

Los autores deberán enviar un resumen extendido de máximo dos páginas de tamaño A4, incluyendo figuras, tablas y referencias hasta el 18 de octubre de 2013. El resumen extendido deberá presentarse en formato PDF y deberá tener el formato IEEE http://www.ieee.org/conferences_events/conferences/publishing/templates.html . Este  debe ser enviado al correo electrónico del evento sifae@ieee.org.co . Los resúmenes extendidos serán evaluados y el autor o los autores recibirán notificación de los resultados por correo electrónico el día 25 de octubre de 2013. Los resúmenes aceptados recibirán instrucciones para la preparación y presentación de sus posters

Sponsors:

IEEE Colombia Section
IEEE Colombia Power & Energy Society Chapter

Technical Sponsors:
IEEE Industry Applications Society Colombia Chapter

lunes, 23 de septiembre de 2013

Experiencias usando SCRUM para el desarrollo de software: 1

Luego de pasar mucho tiempo desarrollando software de la llamada "manera tradicional", me doy cuenta que muchas cosas se pudieron hacer mejor si se hubiera utilizado metodologías ágiles como scrum.

En ocasiones recuerdo cuando teníamos reuniones con algún cliente, nos solicitaba un software que hiciera aquella función u otra , pero no daba mas detalle, no acompañaba el desarrollo, solo esperaba que para el tiempo que el tenia estipulado, se concretara un proyecto y que funcionara a las mil maravillas.

Con que ilusión asentábamos con la cabeza sin reprochar, sin confrontar, sin siquiera recabar por mas información. Pero bueno, como dicen por ahí siempre hay una luz al final del camino y esta me parece hasta hora es SCRUM.

No quiero entrar en definiciones exhaustivas  pero les daré la definición que le doy a la gente cuando me pregunta que es scrum: "SCRUM es un marco de trabajo flexible en el que las personas, las interacciones, la confianza, el software funcionando y respuesta ante el cambio son los principios que rigen el desarrollo de un proyecto".

Luego resulta la pregunta de que ventajas tiene esto respecto a los otros métodos de trabajo, y por donde empezar: 
Bueno pues el equipo de desarrollo se pone las metas para el sprint
Hay re-alimentación  temprana de parte del cliente
El equipo se siente valorado
El cliente se integra al desarrollo del proyecto
Si hay algún problema se busca una solución , se prueba , si funciona esta bien, sino, se busca otra y listo.
No hay sobreesfuerso.

y muchas otras más.

Bueno pero como esto se trata de contar la experiencia con scrum, puedo decir que me gusta, facilita la realización de los proyectos, no se carga una persona con el conocimiento de un negocio, sino que un equipo esta en capacidad de hacerlo por si solos. 

Para poder ser conscientes del cambio que hay que dar, se debe empezar por dejar "el ego atrás"  pues siempre es el primer impedimento silencioso que nos hace reacios al cambio.

Y este punto es muy importante pues si veníamos trabajando de otra forma, algunas veces somos héroes que conocen código que nadie mas a tocado o quiere tocar, algunas veces conocemos negocios que son complejos, y explicarlos son una tarea difícil , otras veces  dejar a cargo a alguien cuando uno se va de vacaciones es una pesadilla, siempre lo van a llamar a uno.

Estas y muchas más situaciones me habrán pasado con los años y que probablemente se me olvido mencionar. Debo aclarar que esta es mi muy humilde y sincera manera de contarles mis experiencias usando SCRUM para el desarrollo de software.

domingo, 22 de septiembre de 2013

sábado, 7 de septiembre de 2013

Extractos 3 - del libro SCRUM Y XP DESDE LAS TRINCHERAS de Henrik Kniberg

Por qué insistimos en que todos los equipos hagan retrospectivas 

Lo más importante de las retrospectivas es asegurarse de que tienen lugar. Aun así, todo el mundo coincide en que las retrospectivas son extremadamente  útiles. De hecho, yo diría que la retrospectiva es el segundo evento más importante de Scrum (siendo el primero la reunión de planificación de Sprint) ya que ¡es tu mejor oportunidad para mejorar! 

Difundiendo las lecciones entre los equipos
Reglas importantes para la persona que actúa como “puente de conocimiento”:

• Debería ser bueno escuchando. 
• Si la retrospectiva es poco activa, debería estar listo para realizar preguntas simples pero bien apuntadas para estimular la discusión dentro del grupo. Por ejemplo, “si pudierais rebobinar y hacer este Sprint otra vez desde el día 1, ¿qué haríais de forma diferente?” 
• Debe estar dispuesto a pasar tiempo visitando todas las retrospectivas de todos los equipos. 
• Debería tener algún tipo de autoridad, de forma que pueda actuar sobre las sugerencias que estén fuera del control del propio equipo.

Descansos entre Sprints 
Como mínimo, intentamos que la retrospectiva y la subsiguiente reunión de planificación de Sprint no ocurran el mismo día. Todo el mundo debería tener al menos una buena noche de sueño sin Sprint antes de comenzar el siguiente Sprint.

Scrum se enfoca en las prácticas de organización y gestión, mientras que XP se centra más en las prácticas de programación. Esa es la razón de que funcionen tan bien juntas: tratan de áreas diferentes y se complementan entre ellas. 

Ritmo sostenible / trabajo enérgico
Hace cosa de un año uno de nuestros equipos (el más grande) estaba trabajando un número insalubre de horas extra. La calidad de la base de código era pésima y habían pasado la mayor parte del tiempo apagando fuegos. El equipo de pruebas (que también estaba haciendo horas extra) no tenía ninguna 
posibilidad de hacer aseguramiento de la calidad en condiciones. Nuestros usuarios estaban enfadados y la prensa nos estaba devorando vivos. Después de unos meses conseguimos disminuir las horas de trabajo a un nivel decente. La gente comenzó a trabajar en horarios normales (excepto durante 
algunas crisis de proyecto, a veces). Y, oh sorpresa, la productividad y la calidad mejoraron notablemente. Por supuesto, reducir las horas de trabajo no fue en absoluto el único aspecto que condujo a la mejora, pero todos estamos convencidos de que tuvo mucho que ver.

Cómo hacemos pruebas 
Nuestra experiencia nos dice que eso rara vez funciona. Habrán errores graves. Si la calidad tiene algún valor para ti, es necesario algún tipo de fase de pruebas de aceptación manuales. Se trata de que encargados de pruebas dedicados que no son parte del equipo machaquen el sistema con ese tipo de pruebas que el equipo de Scrum no pudo imaginar, o no tuvo tiempo de hacer o no contaban con el hardware necesario para implementar. Los encargados de pruebas acceden al sistema en la forma exacta en la que los usuarios finales lo harán, lo que significa que debe hacerse manualmente (asumiendo que tu sistema sea para usuarios humanos).

Así que ¿cómo maximizamos la calidad del código desarrollado por el equipo Scrum? Bueno, hay muchas maneras. He aquí dos que nos funcionan muy bien: 
• Incluir encargados de pruebas en el equipo Scrum - Me parece una buena práctica aunque las empresas consideren que no es necesario.
• Hacer menos cosas en cada Sprint.

El encargado de pruebas es quien da el visto bueno.

Un bonito efecto secundario de esta práctica es que el equipo tiene ahora una persona que está perfectamente preparada para organizar la Demo del Sprint.

JS -2: Tricks and tips

El objecto global de JS es el window. una varaible vive dependiendo de su scope.