Concepto
El chip Propeller está diseñado para proporcionar procesamiento de alta velocidad para diferentes sistemas y al mismo tiempo mantener bajo consumo de corriente y circuitos impresos pequeños. Además de ser rápido el Propeller proporciona flexibilidad y potencia a través de sus ocho procesadores, llamados cogs, que pueden desarrollar independientemente tareas cooperativas o simultaneas, todo mientras se mantiene una arquitectura relativamente simple la cual es fácil de entender y utilizar.
El resultado del diseño del Propeller libera aplicaciones a los desarrolladores de sistemas. Por ejemplo:
El mapa de memoria es plano. No hay necesidad de esquemas de páginas con bloques de código, datos o variables. Esto es un ahorrador de tiempo durante el desarrollo de la aplicación.
Eventos asíncronos son más sencillos de manejar que aquellos que usan interrupciones. El Propeller no tiene necesidad de interrupciones, solo asigne algunos cogs a tareas individuales, alto ancho de banda, y mantenga los otros cogs libres y sin compromiso. EL resultado es una aplicación de mayor respuesta y fácil de mantener.
El lenguaje Ensamblador Propeller tiene características de ejecución condicional y escritura opcional de los resultados para cada instrucción individual. Esto lo hace crítico, bloques de código mejor temporizados, manejadores de eventos son menos propensos a fluctuaciones y los desarrolladores generan menos tiempo de relleno y dejan de apretar ciclos aquí y allá.
Tipos de Encapsulados
El chip Propeller está disponible en los tipos de paquetes mostrados aquí:
Figura 1. Tipos de Encapsulados
Tabla 1. Descripción de Pins
El Propeller (P8X32A) tiene 32 pins de E/S (Puerto A, pins P0 a P31). Cuatro de estos pins de E/S, P28-P31 tienen un propósito especial durante el inicio o reinicio. Al iniciar-reiniciar los pins P30 y P31 se comunican con un host para programación y P28 y P29 interactúan con una EEPROM externa de 32KB (24LC256).
Especificaciones
Tabla 2. Especificaciones
Conexiones de Hardware
En la siguiente figura se muestra un ejemplo del cableado que proporciona acceso a la memoria EEPROM desde el chip Propeller. En la parte para la grabación del chip se logra a través del Propeller Plug (un convertidor serial USB a TTL).
Figura 2. Ejemplo del diagrama de conexiones que permite programar el Propeller y una EEPROM externa de 32 Kbyte así como el Propeller usando un cristal externo.
Procedimiento de Inicio
Una vez que se enciende (+100 ms), RESn va de bajo-alto o se reinicia el software:
1. El chip Propeller inicia su reloj interno en modo lento (≈ 20 kHz), se retrasa por 50ms (retraso de reinicio), cambia el reloj a modo rápido (≈ 12 MHz) y luego carga y corre el programa de inicio que está cargado en el primer procesador (Cog 0).
2. El cargador de inicio desarrolla una o más de las siguientes tareas en orden:
a. Detecta comunicación de un host, tal como una PC o pins P31 y P31. Si se detecta comunicación de un host el programa se comunica con él para identificar el chip Propeller y la posiblemente descargar un programa en la RAM principal y opcionalmente en la EEPROM externa de 32 KB.
b. Si no hay comunicación con un host el cargador busca la memoria externa EEPROM de 32 KB (24LC256) en los pins P28 y P29. Si se detecta la EEPROM la imagen completa de los 32 KB se carga en la memoria RAM principal del chip Propeller.
c. Si no se detecta la EEPROM, el cargador se detiene, el Cog 0 finaliza, el chip Propeller se va a modo de apagado y todos los pins E/S quedan como entradas.
3. Si cualquiera de los pasos 2a o 2b cargaron un programa en la memoria RAM y no se dio una instrucción de suspender el comando por el host entonces el Cog 0 se recarga con el interprete spin y el código de usuario se corre desde la RAM principal.
Una aplicación Propeller es un programa de usuario compilado en su forma binaria y descargada a la RAM del chip Propeller y posiblemente a la EEPROM externa. La aplicación consiste de código escrito en lenguaje spin del chip Propeller (código de alto nivel) con componentes de Ensamblador Propeller opcionalmente (código de bajo nivel). El código escrito en lenguaje spin se interpreta por un Cog al momento que corre el intérprete mientras que el código escrito en Ensamblador Propeller corre en su forma pura directamente por el Cog. Cada aplicación Propeller consiste de al menos un pequeño código spin y quizá puede estar escrito completamente en spin o con varias partes de spin y ensamblador. El interprete spin del chip Propeller inicia en el paso 3 del procedimiento de arranque para poder correr la aplicación.
Una vez que el procedimiento de arranque se complete y una aplicación está corriendo en el Cog 0 la demás actividad se define por la aplicación misma. La aplicación tiene control completo sobre cosas como velocidad del reloj interno, uso de E/S, configuración de registros y cuando y cuantos cogs corren en determinado tiempo. Todo esto mientras corre ya que es controlado por la aplicación, incluyendo la velocidad del reloj interno.
Procedimiento de apagado
Cuando el Propeller queda en modo de apagado el reloj interno se detiene y al mismo tiempo detiene los Cogs, así mismo todos los pins de E/S quedan activados como entradas (alta impedancia). El modo de apagado puede ser ocasionado por tres de los siguientes eventos:
- VDD queda por debajo del límite brown-out (≈2.7 VDC), cuando el circuito brownout está habilitado.
- El pin RESn está en modo bajo, o
- La aplicación solicita un reinicio (REBOOT).
El modo de apagado termina cuando el nivel del voltaje queda por arriba del disparo brownout y el pin RESn queda en alto.
Diagrama de Bloques
Figura 3. Diagrama de Bloques del Chip Propeller
La relación Cog y Hub es crítica para el chip Propeller. El Hub controla al Cog que tiene acceso a los recursos mutuamente exclusivos, tales como RAM/ROM principal, configuración de registros, etc. El Hub le da acceso exclusivo a cada cog en determinado momento de forma “round robin” sin importar cuantos cogs están corriendo.
Figura 4. Continuación Diagrama de Bloques del Chip Propeller
Recursos Compartidos
Hay dos tipos de recursos compartidos en el Propeller: 1) Común y 2) Mutuamente exclusivos. Los recursos comunes pueden accederse en cualquier momento por cualquier número de cogs. Los recursos mutuamente exclusivos pueden accederse por todos los cogs pero solo por un Cog a la vez. Los recursos comunes son los pins E/S y el contador del sistema. Todos los demás recursos son mutuamente exclusivos por naturaleza y su acceso es controlado por el hub.
Reloj del Sistema
El reloj del sistema (mostrado como CLOCK en la Figura) es la fuente del reloj central para casi cada componente del chip Propeller. La señal del reloj del sistema viene de una de tres posibles Fuentes:
- El oscilador interno RC
- El reloj de Fase de Ciclo Cerrado (PLL),
- El cristal oscilador (un circuito interno que se alimenta de un cristal externo o un paquete cristal/oscilador).
La fuente se determina por la programación del registro CLK, el cual se puede seleccionar al compilar o mientras está corriendo. Los únicos componentes que no usan el reloj del sistema directamente son el Hub y el Bus; estos dividen el reloj del sistema por dos.
Cogs (Procesadores)
El Propeller contiene ocho (8) procesadores, llamados Cogs, numerados del 0 al 7. Cada Cog contiene los mismos componentes: un bloque procesador, 2KB de RAM local configurada como 512 longs (512 x 32 bits), dos módulos contadores con PLL, un generador de video, registro de E/S y otros registros que no se muestran en el diagrama (Tabla 3). Cada cog se diseña exactamente igual y puede correr tareas independientemente de los otros.
Los ocho cogs son manejados por la misma fuente de tiempo, el reloj de sistema, así que todos mantienen la misma referencia y todos los cogs activos ejecutan instrucciones simultáneamente. También tienen acceso a los mismos recursos compartidos como pins E/S, RAM principal y el contador del sistema.
Los Cogs pueden iniciar o detenerse en tiempo real y pueden programarse para desarrollar tareas simultáneas, ya sea independientemente o en coordinación con otros cogs a través de la RAM principal. Sin importar la naturaleza de su uso el diseñador de la aplicación Propeller tiene control total sobre cómo y cuando se usa un cog; no hay control de compilador o control de sistemas operativos dividiendo tareas entre los múltiples cogs. Esto permite al desarrollador a entregar tiempos determinados, consumos de potencia y respuesta a la aplicación desarrollada.
Cada cog tiene su propia RAM, llamada RAM cog, a cual contiene 512 registros de 32 bits cada uno. La RAM cog es de propósito general excepto los últimos 16 registros, los cuales son de propósito especial como se describe en la Tabla 3. La RAM cog se usa para código ejecutable, datos, variables y las ultimas 16 localidades sirven como interface al contador del sistema, Pins E/S y periféricos locales del cog.
Cuando se inicia un cog, las direcciones ($000) a 495 ($1EF) se cargan secuencialmente de la
RAM / ROM principal y sus localidades de propósito especial 496 ($1F0) a 511 ($1FF) se limpian a cero. Después de cargarlas, el cog comienza a ejecutar instrucciones, empezando con la localidad 0 de la RAM del cog. Continuara ejecutando código hasta que se detiene o reinicia ya sea por el mismo o por otro cog o cuando una interrupción de corriente ocurre.
Tabla 3. Ram del Cog. Registros de propósito especial
Hub
Para mantener la integridad del sistema, los recursos mutuamente exclusivos no pueden accesarse por más de un cog al mimo tiempo. El Hub mantiene esta integridad controlando el acceso a los recursos mutuamente exclusivos dando a cada cog su turno para accederlos de manera “round robin” desde el Cog 0 hasta el Cog 7 y de regreso al Cog 0 nuevamente. El Hub y el Bus que controla corren a la mitad del ritmo del reloj del sistema. Esto significa que el Hub le da al cog acceso a los recursos mutuamente exclusivos cada 16 ciclos de reloj del sistema. Las instrucciones del Hub y las instrucciones del ensamblador Propeller que acceden los recursos mutuamente exclusivos requieren 7 ciclos para ejecutarse, pero primero necesitan sincronizarse al inicio de la ventana de acceso del Hub. Toma hasta 15 ciclos (16 menos 1, si lo perdió) para sincronizar la ventana de acceso al Hub mas 7 ciclos para ejecutar la instrucción del Hub, por lo tanto las instrucciones del hub toman de 7 a 22 ciclos para completarse.
La Figura 5 y Figura 6 muestran ejemplos donde el Cog 0 tiene una instrucción para ejecutar. La Figura 5 muestra el mejor caso; la instrucción estaba lista al empezar el acceso al cog. La instrucción se ejecuta inmediatamente (7 ciclos) dejando 9 ciclos adicionales para otras instrucciones antes de que la ventana de acceso al siguiente Hub llegue.
Figura 5. Interacción Cog-Hub – Mejor escenario
La Figura 6 muestra el peor escenario; la instrucción del hub estaba lista en el ciclo inmediato posterior después de iniciar la ventana de acceso al Cog 0; perdió el acceso. El Cog espera a la siguiente ventana de acceso al Hub (15 ciclos después) y entonces ejecuta la instrucción (7 ciclos) para un total de 22 ciclos para esa instrucción. Nuevamente hay 9 ciclos adicionales después de la instrucción del hub para ejecutar otras instrucciones antes de que llegue la nueva ventana de acceso.
Para obtener la mayor eficiencia de las rutinas de Ensamblador Propeller que tienen que acceder a recursos mutuamente exclusivos puede ser de beneficio intercambiar instrucciones de hub con instrucciones de no-hub para reducir el número de ciclos en espera para el siguiente acceso. Debido a que la mayoría de las instrucciones propeller toman 4 ciclos de reloj pueden ejecutarse dos de estas instrucciones entre instrucciones contiguas de Hub.
Figura 6. Interacción Cog-Hub – Peor escenario
Tenga en cuenta que una instrucción particular de un Cog no interfiere de ninguna manera con otras instrucciones de Cogs debido al mecanismo. El Cog 1 por ejemplo puede iniciar una instrucción durante el ciclo 2 del reloj del sistema, en estos ejemplos quizá se encimen las instrucciones con la del Cog 0 sin tener efectos. Mientras tanto los demás cogs continúan ejecutando instrucciones no-hub o esperando su ventana individual de acceso sin importar lo que otros están haciendo.
Pins E/S
El Propeller tiene 32 pins de E/S, 28 de los cuales son enteramente de propósito general. Cuatro pins E/S (28-31) tienen un propósito especial al inicio y después están disponibles para propósito general. Después de iniciar cualquier pin E/S puede usarlo cualquier cog en cualquier momento ya que los pins de E/S son recursos comunes. Depende de la aplicación del desarrollador asegurar que dos cogs no traten de usar el mismo pin E/S para evitar conflictos durante la ejecución del programa.
Cada cog tiene sus propios Registros de Dirección 32-bit E/S y Registros de salida 32-bit E/S para influir en las direcciones y estados de salida del chip Propeller y corresponde a los 32 pins E/S. Las direcciones deseadas del cog y estados de salida se comunica a través del cog colectivamente para finalmente convertirse en lo que se llama “Dirección de Pin” y “Pin de Salida”. El cog colectivamente determina la Dirección de Pin y Salida de Pins como sigue:
1. La dirección del pin es el resultado de la OR de los estados de salida de los cogs.
2. Las salidas son el resultado de la OR de los estados de salida de todos los cogs. Un estado de salida del Cog consiste en los bits de sus módulos I/O (los contadores, el generador de video y el registro de salidas E/S) OR juntas y luego AND con los bits de dirección del registro. En esencia cada dirección de pin E/S y estado de salida es el “OR” del cog entero. Esto permite a los cogs acceder e influir sobre los pins E/S simultáneamente sin la necesidad de cualquier recurso negociador y sin cualquier posibilidad de contención eléctrica entre los cogs.
El resultado de la configuración de este cableado de pins E/S puede describirse fácilmente con las siguientes reglas:
a. Un pin es una Entrada SOLO si un cog no lo activa como Salida.
b. Un pin es Salida Bajo SOLO si todos los cogs lo activan como Salida Baja
c. Un pin es Salida Alta si CUALQUIERA de los cogs lo activa como Salida Alta
El contador del sistema es global, de solo lectura y 32-bit que se incrementa con cada ciclo del reloj. Los cogs pueden leer el contador del sistema para desarrollar cálculos de tiempo usando el comando WAITCNT, para crear retrasos efectivos en el proceso. El contador del sistema es un recurso común. Cada cog puede leerlo simultáneamente. El contador del sistema no se limpia una vez iniciado el sistema ya que tiene uso práctico para diferenciales de tiempo. Si un cog necesita mantener un tiempo específico solo necesita leer y guardar el valor del contador inicial en ese momento para luego compararlo con otros valores respecto a ese valor inicial.
Registro CLK
El registro CLK es el control de la configuración del reloj del sistema; determina la fuente y las características del reloj del sistema. El Registro CLK configura el oscilador RC, el Reloj PLL, el cristal oscilador y los circuitos selectores de reloj. Se configura en la compilación por la constante _CLKMODE y puede escribirse en tiempo real a través del comando Spin CLKSET o con la instrucciones Ensamblador CLKSET. Cada que el registro CLK se escribe, un retraso global de ≈75μs ocurre como transición de fuentes de reloj.
Cada vez que se cambia el registro una copia del valor escrito deberá permanecer en el valor de la localidad Modo de Reloj (el cual es BYTE[4] en RAM principal) y el resultado de la frecuencia del reloj maestro deberá escribirse en el valor de la localidad Frecuencia del Reloj (el cual es LONG[0] en RAM principal) así los objetos a los cuales hace referencia tendrán disponible esta información para sus cálculos de tiempo. Cuando sea posible se recomienda usar el comando Spin CLKSET, ya que automáticamente actualice todas las localidades mencionadas.
Solo cierto patrón de bits en el registro CLK es válido en modos de reloj. Ver constante _CLKMODE. El objeto Clock en la librería Propeller puede ser útil ya que proporciona información de modificaciones de reloj y métodos de tiempo.
Seguros
Hay ocho bits “seguros” (conocidos como semáforos) disponibles para facilitar el acceso exclusivo de recursos entre múltiples cogs. Si un bloque de memoria se usa por dos o más cogs a la vez y ese bloque consiste en más de un long (4 bytes), los cogs tendrán que leer y escribir varias veces para obtener o actualizar el bloque de memoria. Esto lleva a la posibilidad de contenciones de lectura/escritura en ese bloque donde un cog podrá estar escribiendo mientras otro está leyendo, resultando en lecturas o escrituras incorrectas.
Los seguros son bits globales que acceden a través del hub vía instrucciones de hub: LOCKNEW,
LOCKRET, LOCKSET, y LOCKCLR. Debido a que los seguros se acceden solo a través del hub solo un cog a la vez puede afectarlos haciendo esto un mecanismo efectivo de control. El Hub mantiene un inventario de cuales seguros se usan así como sus estados actuales y los cogs pueden verificarlos, regresar, activar y limpiar según lo necesite en su tiempo.
La memoria principal es un bloque de 64 KBytes (16 K largos) que acceden los cogs como recurso mutuamente exclusivo a través del hub. Son 32 KB de RAM y 32 KB de ROM. Los 32 KB de RAM principal es de propósito general y es el destino de la aplicación Propeller ya sea descargándolo de un host o subiéndolo de una memoria externa EEPROM de 32 KB. Los 32 KB de ROM principal incluye el código y datos de recursos vitales para las funciones del Propeller.
RAM Principal
La primera mitad de la memoria principal es RAM. Este espacio se usa para el programa, datos, variables y pilas, también conocida como la aplicación Propeller.
Cuando un programa se carga en el chip ya sea de un host o de EEPROM externa este espacio se escribe completamente. Las primeras 16 localidades, $0000 – $000F, tienen la inicialización de datos usados por el cargador de inicio e intérprete. El código de programa ejecutable y los datos comenzaran en $0010 y se extenderá por algunos largos. El área posterior al código ejecutable se extiende hasta $7FFF, se usa como variable y pila.
Hay dos valores almacenados en el área de inicialización que pueden ser de interés al programa: un largo en $0000 contiene la frecuencia del reloj maestro inicial en Hertz y un byte siguiéndolo en $0004 contiene el valor inicial escrito en el registro CLK. Estos dos valores pueden ser leídos/escritos usando su dirección física (LONG[$0] y BYTE[$4]) y pueden leerse usando sus nombres predefinidos (CLKFREQ y CLKMODE). Si cambias el registro CLK sin usar el comando CLOCKSET, tendrás que actualizar estas dos localidades para que los objetos a los cuales hace referencia tengan la información actual.
ROM Principal
La segunda mitad de la memoria principal es ROM. Este espacio se usa para definición de caracteres, funciones matemáticas, el cargador de inicio y el interprete Spin.
ENTORNO DE DESARROLLO SPIN
Los ingenieros de Parallax han utilizado muchos entornos de desarrollo durante más de 20 años. Esta experiencia ha permitido diseñar, en esta ocasión, un software de desarrollo para programar al Propeller™ basado en herramientas simples y prácticas, que proporciona muchas funciones útiles, al mismo tiempo que rapidez en el trabajo de desarrollo.
Así pues, encontramos que este software se compone de un único y pequeño archivo ejecutable, con ayuda en línea y biblioteca de ejemplos; todo disponible en la misma carpeta de instalación. Ni siquiera usa archivos especiales de sistema.
Cada archivo de la biblioteca (archivos con extensión ".spin") es un objeto autónomo, disponible para su uso en nuestros proyectos para el Propeller™, con el código fuente y documentación incluido en el mismo archivo. En realidad, estos son archivos de texto que pueden ser editados con cualquier editor de textos, incluso el Bloc de notas del Windows. El objeto en que estemos trabajando, en cualquiera de los 3 modos de edición, también será almacenado con el mismo formato pero en el directorio de trabajo de nuestra elección.
La herramienta incluye muchas facilidades para añadir al código comentarios, "bookmarks" y números de líneas, así como una fuente de caracteres especiales para toda clase de diagramas. Sobre esto último cabe destacar que, una vez que hemos utilizado por primera vez el software del Propeller™, esta fuente está disponible para otros programas instalados en el ordenador, de manera que desde un Word hasta el mismo Bloc de notas se pueden utilizar dichos caracteres para realizar esquemas de circuitos electrónicos, muestras de ondas de señales, tablas, etc.; incluso desde un programa de correo (siempre que soporte texto Unicode).
Figura 7. Entorno SPIN
La organización de la pantalla del software del Propeller™ está partida en cuatro secciones o paneles, cada uno con funciones específicas, que ofrecen en definitiva facilidades para el trabajo actual, para continuar con el último trabajo, para trabajar con varios proyectos a la vez, para localizar archivos fácilmente, ... Incluso permite mover bloques de código y sacar fuera de la herramienta de edición ventanas con proyectos (mediante "arrastrar y soltar"), con el fin de organizar mejor nuestra área de trabajo.
Además, una barra de estado al pie nos ofrece información útil sobre las varias etapas del proceso de desarrollo.
Se ha desarrollado un pequeño programa en la herramienta Spin y simulado en Proteus, para la visualización de un mensaje en una pantalla LCD, en si la programación no es difícil ya que maneja un compilador Basic, fácilmente podemos realizar el control de la mano con esta nueva herramienta teniendo los beneficios del chip Propeller que hemos mencionado en este documento.
Figura 8. Simulación de Propeller en Proteus
Este comentario ha sido eliminado por el autor.
ResponderEliminarHola que tal , veo que dices que simulaste el maneo del LCD con el propeller en proteus , podrias orientarme , como le hiciste para simular el chip propeller en proteus , te dejo mi correo nian_ceralu@hotmail.com ojala puedas ayudarme ya que me gustaria simular mis aplicaciones en proteus con el chip propeller.
ResponderEliminartengo la misma inquietud. si lo solucionaste, te agradecería mucho que me pudieses orientar.
Eliminarmi correo es 1sebastianaraya@gmail.com.
Gracias