Autor Tema: Sistemas operativos en PIC  (Leído 102891 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado Darukur

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 464
    • Informacion, recursos y ejemplos para desarrollos con microcontroladores
Re: Sistemas operativos en PIC
« Respuesta #75 en: 10 de Marzo de 2007, 10:51:45 »
Evidentemente reiniertl tienes capacidades de orador / profesor, los tienes todos bien atentos a tus enseñanzas :P :P :P
Te felicito por tu trabajo!

Saludos
El que no sabe lo que busca no entiende lo que encuentra.
Mi Pagina Web:  http://www.sistemasembebidos.com.ar
Mi foro:             http://www.sistemasembebidos.com.ar/foro/

Desconectado Zaphyrus

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 323
    • Mi blog: Es cuestión de actitud
Re: Sistemas operativos en PIC
« Respuesta #76 en: 10 de Marzo de 2007, 15:17:52 »
Gracias por el esfuerzo y las horas que has dedicado en compartir tus conocimientos.

Este es el espíritu que hay en las personas que gustan compartir, similar a lo que es el software libre (Open Source), Free Software Fundation y GNU.

El foro de TodoPic está creciendo en cantidad y calidad, esto me pone contento.

Saludos
"¿Lo quiere rápido, barato, o bien hecho? Puede elegir dos de las tres cosas." Arthur C. Clarke.
Mi Proyecto Final de Carrera-Microprocesador RISC de 16 bits en HDL: http://martin.calveira.googlepages.com/home
Mi página web o blog: http://es-cuestion-de-actitud.blogspot.com/
Martín Calveira - Zárate - Argentina

Desconectado kamehouse

  • PIC12
  • **
  • Mensajes: 55
Re: Sistemas operativos en PIC
« Respuesta #77 en: 13 de Marzo de 2007, 03:43:17 »
 :-/Felicidades reiniertl por esta gran enseñanza y por compartirlo tan desinteresadamente.Gracias. :-)

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #78 en: 16 de Marzo de 2007, 12:12:32 »
Se terminaron mis vacaciones.

Muchas gracias por los agradecimientos, espero que para la semana próxima pueda ponerles nuevos posts sobre este maravilloso mundo de los RTOS.

Así que amigos a prepararnos, (porque yo también tengo mucho que estudiar para escibierles estos posts) para sacarle el jugo a los RTOS.


Un saludo Reinier

Desconectado aitopes

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5102
    • uControl
Re: Sistemas operativos en PIC
« Respuesta #79 en: 16 de Marzo de 2007, 12:42:23 »
Bienvenido! Espero la hayas pasado bien.

Y esperamos esos posts! :)
Si cualquier habilidad que aprende un niño será obsoleta antes de que la use, entonces, ¿qué es lo que tiene que aprender? La respuesta es obvia:
La única habilidad competitiva a largo plazo es la habilidad para aprender
“. Seymour Papert

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #80 en: 21 de Marzo de 2007, 10:04:43 »
Estoy un poco ocupado con un trabajo y no he podido tirarle ni un chícharo a esto de los RTOS, pero para el viernes seguro tengo algo listo. Ya lo he estado pensando y recreando en mi procesador central, así que en cuanto tenga un time, lo escribo y lo posteo.

Sinceramente disculpen mis atrasos, se que muchos esperan estos mensajes y a mi mismo me gusta mucho trabajar en ellos porque aprendo un montón de cosas cada vez que les escribo.

Un saludo Reinier

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Sistemas operativos en PIC
« Respuesta #81 en: 21 de Marzo de 2007, 16:53:18 »
Sin embargo quisiera que alguien me dijera donde consigo una versión del compilador GCC para PIC's, si es que existe.

Hasta donde los conocimientos de este mortal llegan, no hay tal cosa y según los que saben es muy difícil que exista un puerto del GCC para los pics. 

Esto lo he visto en piclist, en gnupic y en el foro de Microchip.

Lo más parecido es el puerto para pics del SDCC , codificado por Scott Dattalo.

Saludos
- La soberbia de un Einstein es entendible.. la de un salame es intolerable (A.Dolina)
- En teoría no hay diferencia entre la teoría y la práctica. En la práctica... si la hay.
- Lee, Lee, Lee y luego pregunta.(maunix)
- Las que conducen y arrastran al mundo no son las máquinas, sino las ideas (V. Hugo)
- Todos los hombres se parecen por sus palabras; solamente las obras evidencian que no son iguales.(Moliere)
- Todo debería ser hecho tan simple como sea posible pero no mas simple que eso.(A.Einstein)

Desconectado microman

  • PIC10
  • *
  • Mensajes: 17
Re: Sistemas operativos en PIC
« Respuesta #82 en: 23 de Marzo de 2007, 15:46:00 »
Saludos Reinertl,
Te felicito una vez mas por la exelente introducción que estas brindando a cerca de los RTOS.
Quiesiera que me aclares una duda referente al ejemplo q has mostrado en la sección de Insertar Cita
¡Interrupciones! ¡A MÍ!
Tengo entendido q utilizas 2 Pic 16F877 los cuales estan interconectados a traves de su respectiva interfaz serial (USART). Hasta ahi me queda todo claro...lo q no logro entender es si el 2do. Pic q hace de receptor de la cadena del otro y luego lo retransmite...hacia donde...? Es hacia el primero...? Puesto q el Pic solo posee una interfaz fisica ( el primer pic no posee una rutina para la recepcion, aunque entiendo q no habra colision simplemente la cadena retransmitida no tendrá un receptor.. )....la cual esta configuarada al principio....(directiva #use rs232(...)). Si quisieramos debugear en Hardware seria mas interesante retransmitirlo hacia la PC...obviamente a traves de otro puerto USART simulado por soft.

Desde ya gracias..y que siogas adelante, ya que el curso se esta volviendo cada vez mas interesante


Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #83 en: 23 de Marzo de 2007, 17:22:57 »
La respuesta está en este link: Discusión sobre RTOS por motivos que ya he explicado anteriomente.

Un saludo Reinier

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Volviendo sobre nuestros pasos
« Respuesta #84 en: 30 de Marzo de 2007, 19:32:31 »
Volviendo sobre nuestros pasos


Hasta el momento hemos visto que los RTOS pueden ser muy útiles al enfrentar la implementación de aplicaciones complejas, ellos nos ofrecen herramientas poderosas y simples que facilitan el desarrollo rápido de aplicaciones, las desventajas fundamentales que hemos estado viendo son aceptables cuando las comparamos con los beneficios que obtenemos por utilizar un RTOS.

Hasta hace algún tiempo, el diseño de sistemas con microcontroladores se enfrentaba con horas y horas delante de una PC o con una hoja de papel, escribiendo código en ensamblador y pasando mucho trabajo para que cualquier cosa que diseñásemos funcionara, eso solamente en teoría, ni que decir de llevar esos diseños a la práctica, y tener que lidiar entonces con las PCB, circuitos haciendo cosas “extrañas” y demás.

Con la llegada de los compiladores para lenguajes como C, PASCAL, BASIC y simuladores avanzados como el PROTEUS, los desarrolladores de aplicaciones han tenido un importante respiro para llevar adelante sus diseños. Pero el mercado, y los consumidores se han vuelto más exigentes y la parada ha tenido que subir un poco, la solución: utilizar sistemas operativos en los dispositivos embebidos.

Como toda maravilla tecnológica, el uso de un SO requiere muchas veces perder ciertas ventajas respecto a los métodos anteriores. Cuando programábamos en ensamblador obteníamos el máximo en desempeño y aprovechamiento del microcontrolador pero el desarrollo y puesta a punto era muy lento y las aplicaciones podían tener errores muy difíciles de detectar.

Los compiladores mejoraron el problema de los errores y redujeron considerablemente el tiempo de desarrollo, pero los programas gastan más memoria de programa, memoria de datos y son más lentos en ejecución.

Los SO aumentan las desventajas de los compiladores pero mejoran el desarrollo de aplicaciones en muchos otros aspectos.

La solución al dilema de eficiencia vs eficacia nos la ofrecen los mismos fabricantes de microcontroladores, al diseñar dispositivos cada vez más rápidos y con más memoria. Ahora podemos simplemente movernos entre las diferentes gamas y familias de dispositivos buscando el que se adapta mejor a nuestras necesidades y utilizar métodos de diseño tan avanzados como los RTOS. Los precios no son el mayor problema como antaño, incluso algunos uC ya obsoletos salen más caros que sus sustitutos.

Toda la explicación anterior está destinada a refrescar el por qué utilizar un RTOS respecto de utilizar los medios que hemos venido utilizando hasta el momento y porque a partir de ahora comenzaremos a ver los peligros de implementar aplicaciones con el uso de este tipo de herramientas.

La mayor pesadilla para cualquier programador es que su aplicación se bloquee o “cuelgue” y el sistema deje de trabajar como debe, este tipo de problemas es muy frecuente en sistemas operativos orientados a usuarios como Windows y en menor medida GNU/LINUX, la razón para ello está en la diversidad de aplicaciones que puede utilizar un usuario, los errores de estos programas, los propios del SO, la capacidad del usuario para hacer que el SO colapse (conozco varios usuarios expertos en esta materia), etc.

Al utilizar un RTOS para programar aplicaciones nos estamos enfrentando al problema de crear aplicaciones que tienen alta probabilidad de bloquear al sistema, ello está dado porque las cosas que debe hacer el sistema están divididas en procesos o tareas que se ejecutan de forma más o menos independiente del resto, compartiendo recursos del sistema y compitiendo por ellos. A todo lo anterior hay que sumarle que en el momento de la ejecución, el SO no tiene idea de que orden lleva la ejecución de los procesos o cuanto tiempo le tomará a un proceso terminar su ejecución, es por eso que no se pueden programar aplicaciones para SO en base a suposiciones en el orden de ejecución de las tareas o los tiempos requeridos para su completamiento.

Todo lo anterior puede asustarnos mucho porque implica que programar utilizando RTOS es potencialmente peligroso, y sí, ¡ES PELIGROSO! Pero más que peligroso es complicado y puede ser muy tedioso, ya que se complica la semántica y la depuración de las aplicaciones, pero eso no debe ser motivo de desaliento, ya que existen técnicas para reducir esas complicaciones y los problemas están debidamente identificados. Y eso es lo que vamos a comenzar a tratar en las próximas entregas.

Existen muchos problemas con los que los diseñadores deben lidiar al programar utilizando un SO, pero en nuestro caso, por las características de nuestros dispositivos, estamos salvados de un buen número de ellas. Sin embargo Némesis ha querido de todas formas poner un límite a nuestra dicha, y nos ha obsequiado dos clases de problemas que pueden hacernos perder la razón si decidimos utilizar un RTOS:

  • Condiciones de competencia
  • Bloqueo mutuo

En las próximas entregas iremos viendo poco a poco cada una de estas clases de problemas, como detectar los problemas, ejemplos tipos de aplicaciones en que se presentan y como enfrentar estas dificultades.

El arma fundamental con que contamos está en utilizar correctamente los mecanismos de coordinación y sincronización, ya que el mal uso de ellos es una da las causas que pueden provocar una condición de competencia o un bloque mutuo, otras veces el hecho está en un diseño chapucero, mal pensado, errores semánticos en el código o simplemente que no haya solución al problema (aunque esto último es muy poco frecuente o muy difícil de detectar).

Ahora, como veremos próximamente, aprender a programar con un RTOS es mucho más complicado de lo que hemos visto hasta el momento, pero yo no quise meterles miedo y poner los problemas por delante de las ventajas de los RTOS, sino mostrarles un poco de lo mucho que se puede hacer para luego meternos con los problemas a los que debemos enfrentarnos.

Como han podido apreciar, hoy no tengo ninguna aplicación que mostrarles, pero no se desalienten porque próximamente vamos a toparnos con cada programita que ya ustedes tendrán de sobra para dolores de cabeza, pero al final cada uno de ustedes estará en condiciones de enfrentarse a la solución de aplicaciones difíciles de implementar en muy poco tiempo, podrán también estudiar y profundizar en la teoría de los Sistemas Operativos sin muchas dificultades y si explotan bien lo aprendido podrán llegar a ser profesionales muy competitivos y capaces.

Un saludo Reinier

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17671
    • MicroPIC
Re: Sistemas operativos en PIC
« Respuesta #85 en: 31 de Marzo de 2007, 01:23:11 »
No acabo de entender cuál es el problema. Si el RTOS pone una bandera cuando utiliza un recurso del micro y antes de utilizarlo mira si la bandera la ha puesto otro proceso no debería haber problemas.
Supongo que cuando la cosa se va complicando el problema también lo hace, pero esperaré a que nos ilustres en el próximo capítulo para quedarme con "la copla".
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado reiniertl

  • Moderador Local
  • PIC24H
  • *****
  • Mensajes: 1187
Re: Sistemas operativos en PIC
« Respuesta #86 en: 31 de Marzo de 2007, 23:14:31 »
Ya que el amigo Nocturno lo pide, voya a darles un adelanto:

Los SO cooperativo tienen la ventaja de mejorar un poco los problemas de los que les he estado hablando, pero aún así estos se pueden presentar.

Imaginen que tenemos dos tareas, A y B, que deben esperar por dos semáforos pra poder hacer su trabajo, es decir, por alguna razón estas tareas necesitan acceder a recursos compartidos a las que tienen derecho otras tareas, digamos que C tiene acceso al semáforo 1 y D al semáforo 2. Por razones de diseño, estos recursos compartidos no pueden accederse con un solo semáforo pero A y B necesitan acceso exclusivo a los dos recursos para poder trabajar. mientras que C y D solamente necesitan de uno de los recursos.

Ahora A toma el control del semáforo 1 y como el otro está siendo utilizado por D, se queda a esperar pacientemente entregando el procesador. Luego D termina de ejecutarse y libera el semáforo pero en ese momento B comienza a ejecutarse y toma el control del semáforo 2 por lo que debe quedarse a esperar por el semáforo 1, que está en poder de la tarea A y como este espera por el semáforo 2, no podrá continuar ejecutándose, pero tampoco B que espera por el semáforo 1. Ahora C y D tampoco pueden ejecutarse porque sus semáforos están en poder de otras tareas (A y B que están en una espera circular que nunca termina), así que se ha producido una condición de competencia y el sistema se ha colgado.

Como pueden ver es bastante enredado explicar una situación de condición de competencia y es por eso que es difícil darse cuenta cuando existe una de ellas. En el ejemplo anterior tenemos un caso de un diseño con una semántica mal diseñada, que se puede resolver fácilmente como veremos, pero si el SO fuese de tiempo compartido los problemas serían más difíciles de evitar.

Más adelante iremos viendo estos problemas con más detalle.

Un saludo Reinier

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17671
    • MicroPIC
Re: Sistemas operativos en PIC
« Respuesta #87 en: 01 de Abril de 2007, 02:11:14 »
Pues ya me ha quedado claro. Ciertamente no se me había ocurrido que las cosas se podrían complicar tanto, pero me alegro que sea un problema detectado y analizado. Ahora nos queda esperar que nos expliques cómo se arreglan esas competencias  :D

Gracias Reinier
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado Darukur

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 464
    • Informacion, recursos y ejemplos para desarrollos con microcontroladores
Re: Sistemas operativos en PIC
« Respuesta #88 en: 03 de Abril de 2007, 16:29:48 »
Sip, para que no aparezcan deadlocks es conveniente manejar un orden estricto de captura de los recursos compartidos.
Se puede elegir tratar de capturar todo al comienzo o ir capturando y liberando en el mismo orden en las diferentes tareas que solicitan dichos recursos.
Lo que me gusta de los sistemas operativos cooperativos es que nos libera de problemas "no pensados en el momento" acerca de recursos que compartimos y no pueden ser compartidos en cioertos casos.
Por EJ: Usamos una funcion que no es reentrante y que utiliza para sus tareas una unica memoria, en un RTOS cooperativo no existe problema ya que no es interrumpida hasta que la tarea que la solicito no relegue el micro (con lo que se le da la oportunidad de ejecutarse hasta su conclusion).
En un RTOS preemptivo depende del "quantum" de tiempo predeterminado, con lo que es posible que se pause la ejecucion de dicha tarea y que en otra tarea que gane el micro se la vuelva a ejecutar.
En un RTOS cooperativo es posible evitar la "reentrancia" de una funcion.

Saludos
El que no sabe lo que busca no entiende lo que encuentra.
Mi Pagina Web:  http://www.sistemasembebidos.com.ar
Mi foro:             http://www.sistemasembebidos.com.ar/foro/

Desconectado gauchosuizo

  • Colaborador
  • PIC18
  • *****
  • Mensajes: 457
Re: Sistemas operativos en PIC
« Respuesta #89 en: 10 de Abril de 2007, 10:13:19 »
hola amigos

muy interesante el tema, sigan asi que yo estoy prendido como garrapata al perro :).
Saludos desde Suiza, Pablo.