Captulo 1 Introduccin Arduino 1 es un cdigo abierto y hardware abierto

plataforma de micro controlador para diversos fines, ubicados principalmente

en proyectos de tiempo libre. Arduino viene junto con un simple utilizar el
desarrollo integrado medio ambiente, que contiene la cadena completa
herramienta para escribir cdigo fuente, a navegar a travs de las muestras y
bibliotecas, para compilar y enlazar el software y para subirlo a la pizarra y
parpadean ella. Los RTuinOS proyecto aade el paradigma de la programacin
de un sistema operativo en tiempo real al mundo Arduino. En tiempo real los
sistemas operativos, o RTOS, simplificar fuertemente la implementacin de
aplicaciones tcnicas que suelen hacer las cosas de una manera bastante
regular, como el control entradas y salidas de ajuste en consecuencia cada
(fijo) fraccin de un segundo. Por ejemplo, el controlador de temperatura para
una instalacin de calefaccin podra ser diseado de esta manera. Los
sensores de temperatura, que informan las temperaturas ambientales son
evaluados y la quemador y tal vez algunas vlvulas se controlan para producir
la temperatura objetivo deseada. Adems, el uso un sistema en tiempo real el
programa podra actualizar casualmente y regularmente una pantalla para
proporcionar informacin - Al mismo o cualquier otro tipo de cambio. , La
programacin basada en el tiempo regular puede hacerse sin la necesidad de
CPU consume bucles de espera tal como se utiliza en la realizacin de
funciones de biblioteca retraso de Arduino y delayMicroseconds. Los sistemas
operativos en tiempo real caracterizan el uso profesional de micro
controladores. RTuinOS es un pequeo sistema operativo en tiempo real (RTOS)
para el entorno Arduino. Es sencillo de usar y encaja muy bien en el entorno
Arduino cdigo existente. Aade el concepto de pseudo-paralelo hilos de
ejecucin a los bocetos. El dibujo tradicional Arduino tiene dos puntos de
entrada; la configuracin de la funcin, que es el lugar para poner el cdigo de
inicializacin necesaria para ejecutar el dibujo y la funcin de bucle, que se
llama peridicamente. La frecuencia de bucle no es determinista sino que
depende del tiempo de ejecucin del cdigo dentro del bucle. Utilizando
RTuinOS, las dos mencionadas funciones siguen existiendo y siguen teniendo el
mismo significado. Sin embargo, como parte de la inicializacin de cdigo en la
configuracin se puede definir una serie de tareas que tienen individuo
propiedades. La propiedad ms relevante de una tarea es una funcin de
cdigo C 2 , Que se convierte en la tarea llamada funcin. Una vez que entra
en el bucle tradicional Arduino, todas estas funciones de tareas se ejecutan en
paralelo entre s y a la ejecucin repetida de bucle de funcin. Decimos, bucle
se convierte en la tarea ociosa de la RTOS. Una caracterstica de RTuinOS es
que el comportamiento de una tarea no est completamente predeterminado
en tiempo de compilacin. RTuinOS apoya tareas regulares, control de tiempo,
as como un evento puramente controlados queridos, donde los eventos puede
ser transmitido o comportarse como mutex o un semforo. Las tareas pueden
ser preventivo o interactuar cooperativamente. Programacin de tareas se
puede hacer utilizando segmentos de tiempo y un patrn de round robin.

Adems, muchos de estos modos puede ser mixto. Una tarea no es per se
regular, su cdigo implementar decide lo que pasa y esto puede ser decidido
contexto o dependiente situacin. Esta flexibilidad se consigue por la idea
bsica de que tiene una planificador controlado evento, donde los casos de uso
tpico RTOS son apoyados por proporcionar eventos de acuerdo, 1 Ver
www.arduino.cc 2 El compilador de C de GNU es bastante complicada en
mezclar archivos de C y C ++. Aunque RTuinOS est escrito en C que no es
materia implementan funciones de trabajo en C ++ si slo las reglas generales
de la combinacin de C y C ++ y las consideraciones acerca de utilizando las
funciones de biblioteca (sobre todo nuevos) en un entorno multi-tarea se
obedeci. Funciones miembro de clase no estticos Obviamente, no hay
candidatos para una funcin de tarea.

por ejemplo, lleg a-absoluta-point-in-time. Si el cdigo de la tarea decide

siempre esperar a que el mismo absoluto- punto en el tiempo alcanzado
evento, entonces se convierte en una tarea regular. Sin embargo, depende de
la situacin de la misma tarea podra decidir esperar para un evento de
aplicacin enviado - y renunciar a su comportamiento normal. En muchos RTOS
implementaciones de la caracterstica bsica de una tarea se determina en
tiempo de compilacin, en RTuinOS Esto se hace en parte, en tiempo de
compilacin y en parte en tiempo de ejecucin. RTuinOS se proporciona como
un archivo de cdigo fuente nica que se compila junto con su otro cdigo, que
ahora se convierte en una aplicacin RTuinOS. En el caso ms sencillo, si no se
define ninguna tarea, su aplicacin se parecen mucho a un dibujo tradicional:
Usted implementar su configuracin y su bucle funcin; la antigua se ejecutar
una vez al comienzo y el segundo repetidamente. RTuinOS por s sola no puede
ser compilado, es necesario que haya una aplicacin. RTuinOS se organiza
como un paquete que combina el archivo de origen RTuinOS con algunas
aplicaciones de ejemplo que son la prueba casos al mismo tiempo. El cdigo
fuente de cada aplicacin de la muestra se llev a cabo en una carpeta
independiente, nombrado tc <nn>. Cualquiera de ellos puede ser seleccionado
para la compilacin. Puede agregar ms carpetas, la celebracin de la fuente
cdigo de sus aplicaciones RTuinOS. Un punto de partida de la carpeta de la
aplicacin puede ser una copia de cualquiera de las carpetas tc <nn>. La
compilacin siempre es el mismo. Ejecute el archivo MAKE, donde el nombre de
la carpeta (Que no tiene por qu ser tc <nn>) es una opcin en la lnea de
comandos. Vea la seccin 4.2 para ms. Este documento introduce el concepto
bsico de RTuinOS y da una visin general de sus caractersticas y limitaciones:
Captulo 2 explica los principios bsicos de funcionamiento. Algunas
consideraciones bsicas de la aplicacin se destacan, pero la documentacin
pertinente de la aplicacin es el propio cdigo. Se comenta utilizando doxygen
3 etiquetas; la documentacin doxygen compilado es parte de este proyecto.
Contiene slo el documentacin de los objetos globales de RTuinOS;

comprender plenamente la aplicacin tendr para inspeccionar el cdigo

fuente en s, por favor consulte [1], [2], [3]. Captulo 3 listas y documentos
todos los elementos de la API RTuinOS '. Captulo 4 se explica cmo escribir
RTuinOS-aplicacin que funcione bien. El captulo comienza con una breve
receta, lo que garantiza el xito pronto. Aqu es donde usted puede comenzar a
leer si usted ya est familiarizado con el concepto de un RTOS. El manual
concluye con el captulo 5 , que da una visin general de las posibles mejoras y
desaparecidos y tal vez ms tarde liberado caractersticas

Captulo 2 Cmo funciona RTuinOS? En un esquema tradicional, el bucle de

funcin define todas las acciones que tienen que ser ejecutados. La ejecucin
del cdigo es estrictamente secuencial. bucle puede, por supuesto, llamar a
cualquier sub-rutinas que pueden aconsejar a otros, pero esto no cambia el
carcter estrictamente secuencial de la ejecucin de las sentencias. Por lo
tanto es difcil de ejecutar acciones especficas en los puntos especficos en el
tiempo. Por ejemplo cambiar el estado de un LED cada segundo. Esto todava
podra ser fcil de hacer si su dibujo no hace nada ms - vase la norma de
Arduino ejemplo parpadeo -, pero si ests en medio de un boceto, que por
ejemplo, transfiere algunos datos a travs de USB puerto, se vuelve feo: Usted
tendr que fusionar algunos, las declaraciones especficas que sirven de LED,
en su USB cdigo de manejo. Y la exactitud del tiempo cedido no ser perfecto.
Imagnese, usted puede simplemente escribir dos bocetos. La comunicacin
USB queda como est, pero un segundo bosquejo, por ejemplo, la muestra
boceto abrir y cerrar, se define al mismo tiempo y se ejecutar, tambin. Ahora
el USB cdigo ya no se echa a perder con un doble control del estado de los
LED, pero sin embargo el LED parpadear segn se desee. En realidad, esto es
lo que ofrece RTuinOS. Sin embargo, no es un boceto completo, sino slo una
funcin - que por supuesto puede ser almacenada en un archivo separado
fuente C -, que se ejecuta en paralelo. Escribe dos tales funciones, hacen
llamados tareas y se obtiene lo que quiere. Cmo funcionara? La placa
Arduino sigue teniendo una nica CPU, que est disponible para el cdigo la
ejecucin. El truco es utilizar alternativamente para proceder con la tarea uno y
luego con la otra. Si este cambio entre las tareas que sucede con la suficiente
rapidez, lo que es lo mismo, como si ambos se ejecute a al mismo tiempo - slo
con la velocidad de ejecucin limitado. El alternando entre las tareas suceden
con regularidad? Eso depende. Diferentes patrones de alternancia entre las
tareas son posibles. El patrn ms simple es compartir la CPU en porciones fijas
entre las tareas. La relacin puede ser elegido. Si asumimos en nuestro
ejemplo que sirve el puerto USB es ms desafiante que parpadear un LED,
sera razonable para compartir la CPU por 95: 5 ms que por 50:50. Este patrn
se llama round robin y encaja muy bien si las tareas son completamente
independientes entre s (como en nuestro ejemplo) y si todos ellos requieren
continuamente la CPU - que no es el caso en nuestro ejemplo! Alternar el

estado de los LED se puede hacer mediante la observacin permanente y un

reloj de conmutacin de la salida del LED cuando llega a la siguiente marca.
Una aplicacin tradicional Arduino de esta estrategia requiere la CPU de hecho
permanente y esto es exactamente cmo se implementa un abrir y cerrar
boceto muestra. En un RTOS puedas hacerlo mejor. Dgale al sistema cuando
desee cambiar el estado del LED la prxima vez y no hace nada hasta que. Su
tarea es inactivo, no requiere de la CPU ms y no obstante se ejecuta de nuevo
exactamente en el punto deseado en el tiempo. Surgen dos ventajas. Su tarea
no apenas consumen energa de la CPU y la regularidad de la ejecucin es muy
buena. Este patrn es la solucin adecuada para nuestro ejemplo. La LED
parpadea de forma regular, y casi todo el rendimiento de la CPU todava puede
ser gastar en la USB tarea, que por lo tanto se comporta de la misma manera
que si no haba LED parpadeante en absoluto. El siguiente patrn de compartir
la CPU entre las diferentes tareas es el acoplamiento directo de las tareas. Por
medio de los llamados eventos una tarea pueden indicar una situacin
especfica a ninguna otra tarea, que luego reaccionar ante esto situacin. Por
ejemplo, el LED no debe constantemente parpadear. Ahora se utiliza para
indicar el estado de la 9
Pgina 10
10 CAPTULO 2. CMO FUNCIONA RTUINOS? Comunicacin USB mediante el
parpadeo varias veces si se produce un cambio de estado significativo. El
nmero de parpadea notificarn lo que pas. La tarea del LED ahora usar un
evento que se active y, posteriormente, que va a utilizar el patrn ejecutar-entiempo varias veces para darse cuenta de la secuencia de destellos. El LED
permanece oscuro, siempre y cuando el evento no se contabiliza en la tarea.
Despus de la secuencia de abrir y cerrar la tarea volver a empezar a esperar
a la prxima ocurrencia del evento. 1 . El tiempo activo de esta tarea es an
cerca de cero: cada vez que se ejecuta slo va a utilizar algunas declaraciones
para cambiar el estado de LED y de informar a la RTOS sobre el prximo
condiciones en las que se active nuevamente. La tarea principal, que
implementa la lata comunicacin proceder casi como si no hubiera ninguna
tarea LED. Hay sin embargo una extensin de su aplicacin. En caso de un
cambio de estado significativo tiene que indicar el nmero de flashes de
acuerdo y enviar el evento. El primero puede ser realizado por una escritura en
una variable global y la segunda es una simple llamada de una API RTuinOS
funcin. La variable global es compartida por ambas tareas, la tarea LED leer
al ser activado por el evento. Si hay ms tareas que el escenario se vuelve ms
complicado y necesitamos un nuevo trmino. Si dos tareas decirle al RTOS el
momento en que desea que se active de nuevo, hay una cierta posibilidad, que
es la misma tiempo. En esta situacin, si se alcanza este punto en el tiempo,
RTuinOS decide que ambas tareas son debidos - pero slo uno de ellos puede
obtener la CPU, es decir, se puede activar. Cul es decidido por prioridad. La
prioridad de una tarea es una propiedad esttica, predeterminada de una

tarea. En tiempo de compilacin, usted decidir cul de los tareas tiene la

mayor prioridad y que es el de conseguir la CPU en la situacin mencionada.
Similares: Las tareas no especifican el mismo punto en el tiempo, pero casi lo
mismo. Obviamente, la tarea con vencimiento anterior tendr la CPU. Y cuando
el otro se vence un poco ms tarde, todava podra el deseo de tener la CPU.
Continuar tenerlo? Depende de nuevo en la prioridad de las tareas. Si el ms
tarde debido tarea tiene la mayor prioridad, que va a hacerse cargo de la CPU
de la tarea anterior. La tarea anterior es todava debido (ya que no volvi la
CPU voluntariamente hasta ahora), pero ya no est activa. La tarea es tanto
ms tarde, debido (Que de momento ha llegado) y activa (que tiene la CPU).
Cuando la tarea ms tarde activa dice RTuinOS para ya no necesitan el CPU, el
todava debido tarea anterior har de nuevo obtener la CPU y continuar
ejecutando. Si una tarea indica al sistema a un momento ya no requieren la
CPU (mediante notificacin: "Continuar mi ejecucin en / cuando ") nos dicen
que est suspendido. Si se vence de nuevo, decimos que se reanuda. Si se
ejecuta de nuevo, decimos que se active. Siempre hay una y slo una tarea
activa. Qu pasara si todas las tareas en el sistema suspendieron s mismos
ya que estn a la espera de un punto en el tiempo o un evento? Ahora, hay una
sola tarea que nunca debe suspender s mismo. Esta tarea se llama la tarea
inactivo y RTuinOS no se puede compilar sin ser una tarea tan presente. 2 No
tiene que ser definido en el cdigo de la tarea ociosa. RTuinOS utiliza el bucle
de la funcin como inactivo tarea. Todo el cdigo en el bucle de la funcin
compensa ociosa tarea. Si usted no necesita una tarea inactiva (como todo el
cdigo es tiempo o evento controlado) slo implementan bucle como un cuerpo
de la funcin vaca. Sin embargo no implementar la tarea ociosa es una prdida
de tiempo de CPU. RTuinOS pasa todo el tiempo en el bucle cuando ninguna de
las otras tareas es debido. As que si hay algunas operaciones en su aplicacin
que puede o se debe hacer de vez en cuando es una buena prctica para
ponerlas en la tarea ociosa. No hay inconveniente, si cualquier tarea necesita
la CPU, inactivo slo est esperando hasta que la tarea ha terminado. La
velocidad de ejecucin de la tarea ociosa est determinado directamente por el
consumo de CPU de las otras tareas. Idle nunca se ralentizar las tareas, pero
las tareas se ralentizar inactivo. Idle es una tarea de menor prioridad que
todas las otras prioridades en el sistema. Idle es una tarea que nunca se
suspendi, pero siempre se debe ya veces activa. 2.1 Aplicacin del
Programador RTuinOS ' El conjunto de reglas de cmo compartir la CPU entre
las diferentes tareas que se llama el planificador. En realidad, RT- uinOS es otra
cosa que la aplicacin de un planificador. 3 La comprensin de los detalles de
la decisin 1 Una implementacin de este patrn se puede encontrar en la
prueba de aplicacin TC08 2 Atencin, si la tarea ociosa alguna vez tratar de
suspender s mismo, tendra como resultado una cada del sistema. 3 Desde el
mundo de los ordenadores personales se le asocie ms con el sistema
operativo plazo que una tarea planificador. De hecho, en este entorno, el
programador es slo la parte ms importante del sistema operativo, por lo

tanto denominado ncleo, pero rodeado de un montn de empresas de

servicios pblicos, sobre todo para apoyar a diversas operaciones de E / S. En
el mundo incrustado
Pgina 11
2.2. Tiempo basado EVENTOS 11 reglas implementadas en RTuinOS es esencial
para escribir aplicaciones que se comportan como se desee. (Un RTOS puede
mostrar fcilmente efectos que no se esperan ni desean.) Las reglas del
planificador RTuinOS "voluntad pondr de manifiesto en la siguiente
documentacin de su aplicacin. En RTuinOS, una tarea est representada por
un objeto de tarea. Todos los objetos de la tarea se asignan estticamente, all
no es creacin o supresin dinmica. 4 Los objetos se configuran en funcin de
la configuracin de Arduino y permanecen sin cambios a partir de ahora
(adems de la actualizacin continua de la informacin de tiempo de ejecucin
por el planificador, ver ms abajo). RTuinOS gestiona todas las tareas en las
listas. Por favor refirase a la figura 2 0.1 en la pgina 15. Hay una lista por
prioridad. Todas las tareas que tiene formar una prioridad especfica de una
clase de prioridad y esta clase se gestiona con la lista de asociados. El nmero
de diferentes prioridades se determina en tiempo de compilacin por la
aplicacin. Una lista adicional posee todas las tareas (de cualquier prioridad)
que estn suspendidas actualmente. Dentro de un objeto de tarea hay algunos
miembros que expresan una condicin bajo la cual un suspendidos tarea se
reanuda. (Estos miembros estn vacas o en un estado no les importa cuando
una tarea se debe o activa.) Ms hormign, RTuinOS sabe acerca de un nmero
limitado de eventos distintos 5 y la condicin mencionada es una subconjunto
de stos ms lo siguiente eleccin booleana: tendrn la tarea se reanudar tan
pronto como cualquier evento de la sub-conjunto es visto o no la estancia tarea
suspendida hasta que todos los eventos se han visto? Adems, tres de los
eventos conocidos tienen un significado especfico; todos ellos estn
relacionados con el tiempo y tener un parmetro de tipo cuando. En el
momento de inicializacin todas las tareas se ponen en estado de suspensin.
En consecuencia, la hoja de vida inicial condicin es parte de la inicializacin
tarea. Por lo general, esta condicin es dbil, como "reanudar
inmediatamente". Sin embargo, un curriculum vitae retardada es posible. A
partir de algunas de las tareas regulares con diferentes retrasos puede ser taja
tajosa con el fin de evitar tener demasiadas tareas con vencimiento, todo al
mismo tiempo. Adems, una tarea puede especificar la hoja de vida inicial de
un evento de aplicacin transmitido. Y si una tarea implementa el controlador
de una solicitud de interrupcin es probable que se reanudar inicialmente por
esta interrupcin. Tenga en cuenta, que los eventos de tipo mutex o un
semforo no deben ser utilizados como parte de la formacin inicial de una
tarea reanudar la condicin. En muchos casos esta condicin simplemente no
define un estado de suspensin; si el mutex o un semforo (o mejor decir un
valor de contador de la misma) est disponible actualmente la tarea requirente

no lo hara ser suspendida - que es una necesidad en el momento de la

inicializacin de los objetos de la tarea que el ncleo no es RTuinOS sin
embargo, se ejecuta en este punto en el tiempo. 2.2 Eventos basados Tiempo
Los acontecimientos ms relevantes de RTuinOS son eventos de tiempo
absolutos y relativos. Un evento de tiempo absoluto significa "tarea hoja de
vida en un momento dado". Un evento de tiempo relativo significa "reanudar la
tarea despus de un perodo de tiempo determinado contados a partir de ahora
". Usted ve, este ltimo - probablemente con lapso de tiempo cero - es la hoja
de vida inicial ms tpico condicin para una tarea. Se empezar
inmediatamente. En la implementacin de un tiempo los resultados de eventos
de un tic temporizador del sistema. El ncleo del planificador es un reloj
interrupcin basado. En RTuinOS Este reloj tiene una frecuencia de reloj
predeterminada de alrededor de 2 ms, pero esto puede ser alterado por el
cdigo de la aplicacin. 6 En la rutina de servicio de interrupcin (ISR), una
variable que contiene la absoluta, la corriente hora del sistema se incrementa.
(La tasa de la interrupcin es la unidad de todas las operaciones de
sincronizacin independientemente de el valor fsico real.) El nuevo valor de la
hora del sistema se compara con el parmetro cuando de todas las tareas
suspendidas que suspenden con una hoja de vida-en la condicin. Si hay
igualdad, el tiempo absoluto evento se notifica a esta tarea. Para todas las
tareas que se haba suspendido a s mismos con una condicin de reanudacin
despus, el cuando el parmetro de esta condicin se reduce. Si llega a nulo, el
deseado suspender el tiempo tiene transcurrido y el evento de tiempo relativo
se notifica a la tarea. El evento basado tercera vez slo est disponible si el
sistema se compila con la caracterstica de round robin. Ahora una tarea puede
tener un intervalo de tiempo definido. El segmento de tiempo es el tiempo
mximo que la tarea puede ser continuamente un sistema operativo de tiempo
real normalmente no ofrece mucho ms que un planificador y lo mismo ocurre
con RTuinOS. 4 Por favor, consulte la seccin 5 de las consideraciones ms
detalladas sobre este. 5 Por buenas razones los eventos son implementadas
por los bits en una palabra entero sin signo. Actualmente, el tipo uint16 t se
utiliza como es un buen compromiso entre el nmero de eventos y
rendimiento. Un cambio a la uint8 t o Uint32 t es posible pero no trivial cuando
se vea afectada cdigo ensamblador. As pues, tenemos 16 este tipo de
eventos. 6 RTuinOS utiliza temporizador 2 como fuente para fichar su hora del
sistema. En Arduino este temporizador - destinados a la salida PWM - ciclos con
cerca de 2 ms. RTuinOSdoesn't cambiar la configuracin del temporizador de
Arduino en su configuracin estndar.
Pgina 12
12 CAPTULO 2. CMO FUNCIONA RTUINOS? activo. Este evento se lleva a cabo
directamente, no como un poco, no como la notificacin a la tarea. Un round
robin tarea tiene un contador que se carga con la duracin de segmento de
tiempo en el momento de la activacin. En cada temporizador del sistema tic

que se disminuye por primera y nica tarea activa (si slo es una tarea round
robin). Cuando el contador alcanza nula que se vuelve a cargar y la tarea se
toma inmediatamente de la cabeza de su lista de vencimientos y puso en el
final de esta lista. Esto significa que la tarea se mantiene debido pero quedar
inactiva. Otra de las tareas, el nuevo jefe de la lista, es un candidato ms
prometedor para el nuevo, tarea activa. El siguiente paso es comprobar las
condiciones de todas las tareas suspendidas. Para cada uno de tales tarea se
comprueba si su condiciones de reanudacin se ha cumplido, es decir, si todos
los eventos que est esperando han sido escritos a ella por su parte. Si es as,
se saca de la lista de tareas suspendidas y se coloca al final de la lista debido a
la clase de prioridad de la tarea pertenece. Ahora, despus de la reordenacin
de las tareas en las varias listas, el ISR termina con la bsqueda de lo nuevo,
activo tarea. La decisin es fcil. Se realiza un bucle sobre todas las listas de
vencimiento, a partir de la ms alta prioridad. El jefe de la lista no vaca
primero encontrado es el nuevo, tarea activa. Si todas las listas de vencimiento
estn vacos, se elige la tarea vaca. La tarea seleccionada se activa y termina
el ISR. 2.3 Eventos Explcitamente anunciados Adems de la tic temporizador
del sistema, el programador se vuelve activo en otras dos situaciones. El
primero es el evento publicado explcitamente por una tarea de aplicacin.
RTuinOS conoce un nmero predefinido de propsito general eventos, que
pueden ser enviados por una tarea y que otra tarea puede esperar. Esta ltima
tarea suspende s y especifica el evento como condicin currculum. Bajo las
condiciones de aplicacin definido, el ex tarea llama a la funcin API RTuinOS
rtos sendEvent y esta ltima tarea se reanudar. En esta situacin depende de
las prioridades de las dos tareas cmo rtos SendEvent devoluciones. Si el
evento- tarea ajuste tiene el mismo o superior rtos prioritarios sendEvent
devolver inmediatamente como un ordinario sub-rutina. La otra tarea vence
pero no activo. Si la tarea de evento de recepcin tiene la mayor prioridad,
RTOS sendEvent conduce a la inactivacin temporal de la tarea de llamada y
slo volver cuando se activa de nuevo. Ms en general, RTOS sendEvent se
implementa como una interrupcin de software (SWI) y se comporta similar a el
ISR temporizador del sistema. Notifica un evento transmitido ordinaria a todas
las tareas actualmente suspendidas, que se espera de l y pasa a eventos de
tipo mutex o un semforo a la propia tarea de alta prioridad, que exigido para
adquirirla. El resto se hace exactamente como el temporizador del sistema ISR
hace. cheques rtos SendEvent la condicin hoja de vida de todas las tareas
suspendidas. Esas tareas la condicin de que se cumple se mueven a al final
de su debido lista. Entonces se selecciona la nueva tarea activa. Este podra
ser el mismo o en otro tarea. El SWI termina con la continuacin de la nueva
tarea activa. Como cuestin de hecho, una llamada de RTOS sendEvent nunca
har que la indebida tarea llamada (es decir, en suspensin); ms externa
inactiva. Esta es la razn, por qu rtos sendEvent incluso puede ser llamado
por la tarea ociosa. Nota al pie: Existe una relacin transversal entre rtos
sendEvent y los comandos de suspensin. A vista de pjaro sobre el cambio de

cdigo de tareas del sistema aparece de la siguiente manera: La funcin de

suspender es invocado pero devuelve de una llamada de RTOS sendEvent de
otra tarea o de la orden de suspender una tarea que se convirti por su parte.
Si una tarea requiere rtos sendEvent que no tenga que volver pero pudo por
ejemplo, volvern de comando mencionado inicialmente suspendido. 2.3.1
Eventos de Kind objeto mutex Un evento puede ser un mutex, un objeto de
sincronizacin para la exclusin mutua de las tareas de un recurso. La tipo de
evento se especifica en tiempo de compilacin, es parte de la configuracin de
RTuinOS. Si un evento de mutex est en el conjunto de los acontecimientos
anunciados explcitamente su manejo difiere de los acontecimientos ordinarios.
Si bien estos son notificados a todas las tareas suspendidas actualmente un
mutex se notifica a ms externa una tarea. Si uno o ms tareas suspendidas
estn actualmente a la espera de la exclusin mutua del uno perteneciente a la
ms alta prioridad clase lo obtendr. Si hay varias tareas en suspensin de esta
clase la que lo conseguir, que espera a que el ms largo. Si no hay ninguna
tarea suspendida a la espera de la exclusin mutua se almacena dentro
RTuinOS y puede ser
Pgina 13
2.4. ALARMAS DE APLICACIN 13 adquirida ms tarde por cualquier tarea.
Guardar un evento publicado para uso futuro es diferente a los
acontecimientos ordinarios: Ellos no tendr ningn efecto si nadie est
esperando. Bajo todas las condiciones de un evento mutex publicado se
registra en algn lugar y la tarea de llamar pierde el propiedad del mutex. La
titularidad es inmediatamente pasa a una tarea de espera o el mutex es
almacenado en el ncleo para la adquisicin ms tarde. La aplicacin necesita
un seguimiento de esto. Normalmente, la posesin de un mutex medios para
una tarea de tener acceso a un recurso gestionado relacionada. En RTuinOS
que no se puede consultar por una llamada a la API que actualmente es el
dueo de un mutex; en realidad RTuinOS ni siquiera es consciente de ello. La
tarea cdigo necesita para realizar un seguimiento sobre, por ejemplo,
mediante la implementacin de una variable booleana relacionada. 7 2.3.2
Eventos de tipo semforo Un evento puede ser tambin un semforo, un objeto
de sincronizacin para gestionar el acceso a un conjunto de recursos
compartida entre diferentes tareas. El tipo de un evento se especifica en
tiempo de compilacin, es parte de la figuracin uracin de RTuinOS. Si un
evento de semforo est en el conjunto de los acontecimientos anunciados
explcitamente su manejo difiere de los acontecimientos ordinarios. Si bien
estos son notificados a todas las tareas suspendidas actualmente un semforo
se notifica a ms externa una tarea. Si uno o ms tareas suspendidas estn
actualmente a la espera para el semforo el que pertenece al ms alto clase de
prioridad lo obtendr. Si hay varias tareas en suspensin de esta clase la que lo
conseguir, que espera por ello el ms largo. Si no hay ninguna tarea
suspendida esperando el semforo el contador del semforo se incrementa (el

contador se implementa dentro de RTuinOS), lo que indica una instancia que no

es liberado requerido por cualquier tarea en el momento, pero que puede ser
adquirido en el futuro. Guardar un evento publicado para uso futuro es
diferente a los acontecimientos ordinarios: No tienen ningn efecto si nadie
est esperando. Bajo todas las condiciones de un evento de semforo
publicado est grabado en algn lugar, est bien comunicada a una espera
tarea o Es contados en el ncleo, y la aplicacin necesita para realizar un
seguimiento de este. Normalmente, la adquirida nmero de instancias de un
semforo (o sus valores de contador, respectivamente) se corresponde con el
nmero de instancias de una piscina ordenada de los recursos de la tarea se
concedi acceso. El nmero de instancias de una tarea ha acumulado a travs
de una serie de llamadas de RTOS waitForEvent y RTOS sendEvent no se puede
consultar por una llamada a la API; en realidad RTuinOS ni siquiera es
consciente de ello. El cdigo de la aplicacin tiene que perder de vista, por
ejemplo, mediante la aplicacin de una variable de contador correspondiente. 8
2.4 Aplicacin Interrupciones La ltima situacin en la que el planificador se
pone activo es una interrupcin de la aplicacin. Por interruptor de
compilacin, puede unir cualquier AVR de interrupcin a la funcin sendEvent
RTOS. El ISR de la fuente de interrupcin llamar rtos sendEvent. El evento que
se publica ya no es un evento de propsito general, pero dedicado a esta
interrumpir. Las acciones son exactamente el mismo que el descrito para RTOS
sendEvent en la seccin 2.3 . Obviamente, el ISR es asncrona a la ejecucin de
la tarea. Si el evento publicado hace una tarea por la que tiene mayor prioridad
que la tarea interrumpida, la tarea interrumpida se hace inactiva (pero an
sigue siendo debido) y el otro tarea se activar. Slo hay un caso de uso de
este tipo de invocacin planificador. Normalmente, una aplicacin definir una
tarea de alta prioridad a la espera para el evento. La interrupcin desencadena
esta tarea dedicado - indirectamente a travs de la llamada oculta de RTOS
sendEvent -, que en realidad sirve como controlador de interrupciones,
haciendo todo tipo de cosas que son necesarios por la interrupcin. Esta tarea
se llevar a cabo como un bucle while infinito, donde el 7 Esta variable
booleana podra estar oculto en una clase de C ++ incrustar todas las llamadas
de RTOS waitForEvent y RTOS sendEvent en funciones miembro como
acquireMutex y ReleaseMutex. Cada tarea tendra su propio objeto, local de
esta clase. Sin embargo, este concepto es simple slo si la espera de
combinaciones de eventos se excluye - que no ser una restriccin dolorosa
para la mayora de aplicaciones. 8 Una forma adecuada de hacerlo podra ser
una clase de C ++ incorporacin de todas las llamadas de RTOS waitForEvent y
RTOS sendEvent en funciones miembro como acquireSemaphore y
ReleaseSemaphore. Sin embargo, este concepto es simple slo si la espera de
combinaciones de eventos se excluye - que hay restriccin dolorosa para la
mayora de aplicaciones.
Pgina 14

14 CAPTULO 2. CMO FUNCIONA RTUINOS? mientras que la condicin es el

comando que espera a que el evento de interrupcin y donde suspender el
cuerpo de la bucle es el controlador real de la interrupcin. 2.5 Regreso de un
comando Suspender Un detalle importante de la aplicacin de RTuinOS es la
forma de informacin se pasa de nuevo a partir de la planificador para el
cdigo de aplicacin. La interaccin directa del cdigo de la aplicacin con el
programador es hecho con los comandos suspender y RTOS funcin SendEvent
en la API RTuinOS. rtos sendEvent toma un parmetro - el conjunto de eventos
que se publicarn a las tareas suspendidas - pero no lo hace devolver nada.
Aqu, la nica complejidad a entender es, que no volver inmediatamente.
Desencadena un acto planificador y no regresan hasta que la tarea de llamada
es el vencimiento de la tarea con mayor prioridad. Qu se puede ser el caso
entre inmediatamente y nunca en caso de inanicin. Los comandos suspender
toman algunos parmetros que especifican las condiciones en que la tarea se
vencer de nuevo, por ejemplo, una vez al evento absoluta. Mientras que se
suspende la tarea, el diferente planificador acta repetidamente doble
verificacin si un conjunto suficiente de eventos se ha publicado en la tarea
(ver arriba). Cada publicado evento se almacena en el objeto de tarea. Tan
pronto como las basta conjunto publicado, la tarea se mueve de la lista
suspendida hasta el final de la lista de vencimiento de clase de prioridad dada.
A partir de ahora, ya que la tarea no es suspendido por ms tiempo, hay ms
eventos sern publicados en esta tarea y ni van a ser almacenados en la tarea
objeto. De este modo, el conjunto de eventos, lo que hizo la tarea debido ahora
est congelado en el objeto de tarea. Cuando el tarea, que se debe ahora, se
convierte en el flujo de cdigo de los rendimientos de trabajo a partir de la
suspensin de la tarea activa de nuevo comando que haba invocado
inicialmente. En esta ocasin, el almacenado, conjunto esttico de los
acontecimientos, que haba hecho la tarea debido se devuelve como valor de
retorno del comando de suspensin. Simplemente evaluando el cdigo de
retorno de una tarea puede reaccionar depende de los eventos que se haba
hecho debido. Esto es de particular inters si una tarea suspende la espera de
una combinacin de eventos. En la prctica esta voluntad ser lo ms a menudo
la combinacin de un evento de aplicacin y un evento de tiempo relativo, que
de esta manera obtiene el es decir de un tiempo de espera. Obviamente, la
tarea tiene que comportarse de manera diferente si se recibi la espera evento
o si se ha producido un tiempo de espera. Por cierto, lo que se ha dicho de la
devolucin de un comando de suspender tambin es vlido para la inicial
entrada en funcin de tareas. Cualquier tarea es inicializada en estado
suspendido. La primera vez que se libera el cdigo flujo entra en la funcin de
tarea. Qu hay de lo contrario el cdigo de retorno de un comando suspender
ahora pasa a la funcin de tarea como parmetro de la funcin. De esta
manera la tarea sabe por qu condicin ha sido inicialmente activado. 2.6
Resumiendo las acciones del Programador Las diferentes acciones del
planificador se representan en la figura 2.1 . Las flechas continuas indican

cmo objetos tarease mueven dentro y fuera de las listas en diferentes

situaciones. Las flechas discontinuas representan punteros a objetos tarea en
particular. En todas las circunstancias, la tarea activa - resaltada en verde - es
la cabeza de la parte superior ms no vaco lista, es decir, la primera
vencimiento de la tarea en el orden de la cada de prioridad. Debido a la
importancia particular de esta tarea del planificador mantiene
permanentemente un puntero a este objeto de tarea. Se podra decir, que el
mantenimiento de este puntero en realidad es todo lo que el programador
tiene que hacer. El objeto de tarea ociosa puede ser considerado como el nico
miembro de la lista debido de prioridad ms baja posible. Se necesita esta
tarea como caer de nuevo si no es tarea de vencimiento se encuentra en
ninguna de las clases de prioridad y el planificador tiene un puntero constante
a este objeto tarea especfica. Si RTuinOS est inactivo ambos punteros tienen
el mismo valor; sealan el objeto de tarea ociosa. Flecha 1 representa la accin
del round robin. Actividades round robin slo se pueden aplicar a la activa
actualmente tarea. Si transcurrido el intervalo de tiempo, que se toma de la
cabeza de la lista debido y se coloca al final de este lista. Naturalmente - e
indicada por la flecha 2 - el siguiente objeto de la lista se convierte en el nuevo
jefe de la lista
Pgina 15
2.6. RESUMEN DE LAS ACCIONES SCHEDULER 15 Figura 2.1: Programador de
RTuinOS y por lo tanto ser la nueva tarea activa. 9 Si todas las tareas en esta
lista estn configurados para tener intervalos de tiempo (y si no haba otras
condiciones de reanudacin), la lista se completa un ciclo y todas las tareas de
la CPU para obtener un predefinido cantidad de tiempo. Flecha 3 muestra el
efecto de un comando de suspensin. Si la tarea activa emite un comando tal,
se mueve de la cabeza de su lista debido a la final de la lista de tareas
suspendidas. Una vez ms, flecha 2 se muestra cmo el siguiente tarea en la
lista debido se convertir en el nuevo jefe y la tarea activa. Sin embargo, si no
hay segunda tarea en esta lista, la cabeza de un pool de menor prioridad se
convertira en la nueva tarea activa. En nuestra figura, esta entonces podra
ser el cabeza de lista de prioridad 1. La explicacin de la flecha 3 necesita un
poco de refinamiento. Si RTuinOS est compilado sin soporte para eventos de
tipo mutex y semforo que de hecho ponen la tarea suspendida al final de la
lista - pero slo En aras de la simplicidad de la aplicacin. La lista de tareas
suspendidas no se ordena; en realidad no lo es una lista, sino un conjunto de
objetos de la tarea. La situacin es diferente si tenemos bien mutex o eventos
semforo. Ahora Realmente tenemos una lista ordenada de tareas
suspendidas. La lista se ordena por prioridad de la tarea y de la suspendida
tarea no se pone al final, pero detrs de la ltima tarea de igual o mayor
prioridad. Esta orden de la lista ser fuertemente facilitar la distribucin de los
eventos anunciados de mutex tipo o semforo para el receptor justo en una
llamada ms tarde de RTOS sendEvent. Flechas 4 y 5 muestran cmo una tarea

suspendida se vence de nuevo. En cualquier llamada ya sea del temporizador

del sistema ISR o RTOS sendEvent todas las tareas suspendidas se comprueban
si su condicin hoja de vida se hizo realidad. Si es as, la objeto de tarea se
mueve de la lista de tareas pendientes hasta el final de su lista de
vencimientos. La lista por una tarea pertenece a est predeterminado en
tiempo de compilacin, cuando se elige la prioridad de la tarea. Acciones 4 y 5
fuerzas aparecer en el mismo tic temporizador o llamada de RTOS sendEvent o
en otros diferentes. Arrow 5 muestra la hoja de vida de una tarea de prioridad
ms alto conocido: Aqu tenemos un ejemplo en el un evento causa la
interrupcin de una tarea en ejecucin. El pool de la tarea reanudado estaba
vaco antes esta accin. As, la hoja de vida crea un objeto de tarea debido
nueva prioridad mxima - mayor que la de la tarea que estaba activa hasta el
momento. Esta tarea menos antes es inactivada. Desde la perspectiva de la
tarea se interrumpe la ejecucin de su flujo de cdigo. Tenga en cuenta, que el
objeto de tarea inactivada no se mueve! Sigue siendo la cabeza de su lista de
vencimientos. La tarea est inactiva, pero an vencido y sigue siendo el primer
candidato para la reactivacin dentro de su clase de prioridad. 9 Esto no es
totalmente correcta: Si la accin del round robin tiene lugar en la lista debido
que no tiene la ms alta prioridad, lo que puede de vez en cuando sucede que
una tarea de mayor prioridad sea exigible - y activo - en el mismo tic
temporizador.
Pgina 16
16 CAPTULO 2. CMO FUNCIONA RTUINOS? 2.7 Interruptores de tareas El
principio bsico del planificador es para cambiar entre las diferentes tareas. Los
captulos antes explicados las reglas del planificador se aplica para decidir
cundo y por qu cambiar a qu tarea. En esta seccin se explica cmo se
realiza un cambio de tarea. La CPU no sabe acerca de las tareas. Se trata de
una mquina de estado, que tiene un conjunto de registros, que determinan la
siguiente accin en la siguiente tic del reloj de la CPU. El registro ms relevante
en este contexto es el programa contador (PC). Es un puntero a una palabra
especfica en la memoria de programa (ROM flash). La palabra que apunte a es
el siguiente comando CPU, que ser ejecutado. Este comando siguiente
probablemente tendr un efecto en uno o ms de los registros de la CPU;
podra, por ejemplo, ordenar a la CPU para agregar dos registros de datos,
aadir una constante a uno de los registros de datos, para leer una celda de
memoria en un registro o escribir un registro en una celda de memoria.
Mientras que el comando se ejecuta el PC se incrementa de manera que
apunte a la siguiente palabra en el flash de programa. Se selecciona el
siguiente comando. Etctera. Un programa es construir desde cientos y miles
de estos comandos elementales. La secuencia de comandos forman el
programa. Puesto que no son sin fin es posible tener varios de tales secuencias
de comandos uno tras otro en la memoria de programa. Estas diferentes
secuencias forman ahora el cdigo de programa de las diferentes tareas. La Lo

principal que hacer cuando el cambio entre tareas es alterar el valor del
contador de programa de la que se secuencia a uno de los otros. Hay comando
CPU dedicada para hacerlo, como salto, que directamente carga el PC con la
direccin deseada objetivo o estrategia en tiempo real y reti, que cargar el PC
de la pila. Obviamente, un programador tiene que ser capaz de continuar
despus la secuencia de comandos izquierda, o tarea respectiva tivamente. La
continuacin tiene que ser transparente, hacer como si no hubiera habido un
cambio a otro secuencia en absoluto. Esto significa, en primer lugar, que
nosotros recordamos el valor del PC tena antes de que nos forzamos para que
apunte a la otra secuencia del programa. Pero tambin significa que los
registros de datos de todas las CPU tienen exactamente el mismo valor que
solan tener antes del cambio. Esta condicin slo puede cumplirse si salvamos
el contenido de todos los registros antes de cambiar a otra secuencia de
comandos. El AVR CPU tiene 32 registros de datos de uso general adems de
un registro de estado. El planificador tiene una objeto de tarea para cada tarea.
Sera sencillo tener una uint8 ordenacin t saveReg [32 + 1] como miembro del
objeto de trabajo y colocar el contenido del registro aqu. S, esto bsicamente
trabajar bien pero hay es una manera mucho ms simple y ms barato que
hacer: Todos los registros se insertan en la pila. La facilidad de hacer comienza
con el ahorro de la PC: Como hemos visto, un cambio de tarea se inicia siempre
por cualquiera de una interrupcin o la llamada de una funcin API (una funcin
o RTOS SendEvent suspender). Ambas operaciones de las mquinas comienzan
ejecucin con empujar la PC actual en la pila. Como tenemos la intencin de
utilizar la pila como lugar de almacenamiento de todo nuestro registra que est
bien tener ya la PC aqu, donde desea que tenga. Almacenamiento de los otros
registros en la pila es tan fcil: El conjunto de comandos de cualquier CPU
contiene un comando de empuje que almacena directamente la contenido de
un registro de datos en la pila. Para una CPU AVR este comando se llama
empuje. En consecuencia, todas las rutinas de interrupcin de servicio y todas
las funciones de la API, lo que podra iniciar un cambio de tarea, empezar con
32 empuje operaciones para guardar los registros de datos de propsito
general. (Una excepcin importante se menciona en la seccin 2.7.1 .) Esta
secuencia de cdigo se completa con dos comandos CPU simples que tambin
empujan el estado de la CPUregistrarse en la pila. El registro de entrada
empujando los comandos de un ISR o una funcin API cambio de tarea
causando bsicamente permiten esta funcin para cambiar el PC para que
apunte al cdigo de otra tarea (y as continuar con esa tarea). Averiguar si esto
es necesario, ser el siguiente paso de estas funciones. Muy a menudo esto no
lo har ser el caso. En cuyo caso, la funcin termina haciendo todo en orden
inverso. Todos los registros se leen y tomada de la pila de nuevo. (Ellos se
"saltaron" de la pila). Esto incluye el PC como ltimo registro - y la ejecucin de
cdigo contina donde la interrupcin haba interrumpido el cdigo de tarea, o
detrs la funcin de la API, respectivamente. Esto es como cualquier rutina de
servicio de interrupcin ordinaria. Cmo guardar los registros en la pila es fcil,

pero slo la mitad de la batalla. Diferentes tareas no pueden operar en la

misma pila. Una pila es la aplicacin del paradigma de llamadas a funciones
estrictamente jerrquicas y llamadas sub-funcin anidada y todos los datos
locales de estas invocaciones de funciones anidadas. El paradigma de este
modo de muchos lenguajes de alto nivel, entre los que C / C ++. Este
paradigma no es aplicable a la multitarea. Las tareas pueden ser cambiados sin
tener en cuenta los puntos de entrada y salida de la funcin; la tarea activa no
es una sub-funcin
Pgina 17
2.7. TAREA INTERRUPTORES 17 de la otra tarea izquierda. 10 Por lo tanto, cada
tarea tiene su propia pila dedicado. Antes de cambiar de una tarea a otro que
necesitamos para salvar la pila de la tarea izquierda. En tiempo de ejecucin,
es decir, fuera del alcance de la asignacin de memoria y la pila de
consideraciones de inicializacin, la pila actualmente est completamente
representada por el puntero a su superior actual - y este "puntero de pila" (el
ltimo registro de la CPU mencionar) es lo que necesitamos para salvar
tambin. Aqu, nosotros usamos una ubicacin de almacenamiento absoluta. El
objeto de tarea tiene un elemento para mantener el puntero de pila de esta
tarea. El valor de este miembro objeto es significativa siempre y slo mientras
la tarea est inactiva. Antes de proceder a la tal vez ms difcil de entender los
detalles, vamos a resumir lo que en breve vimos hasta el momento: Todo el
cdigo, que puede iniciar un cambio de tarea es una funcin. Cualquiera de un
ISR o una funcin API dedicado. Todas estas funciones estn bien preparados
para hacer un cambio de tarea a medida que impulsan el PC, todos los
registros de datos y el registro de estado en la pila de la tarea activa. Decimos,
ahorran el "contexto de la CPU" en la tarea de apilar. Y en caso de un cambio
de tarea, deber tener lugar estas funciones conocen bien definido un posicin
de memoria en que tambin guardar el puntero de pila de la tarea activa.
Ahora llegamos al detalle tal vez lo ms difcil, fcil, por un lado, pero sin
embargo un poco difcil ver en la otra mano. Vamos a ponerlo en una pregunta:
Cmo podramos llegar al punto en el que estn a punto de dejar la tarea
activa en ese momento? La respuesta: Por el mismo tipo de cambio de tarea de
otro tarea en esta tarea! En consecuencia, la otra tarea habr hecho lo mismo.
En este caso, habr su pila dedicado y esta pila tendrn todos los registros
guardados de esa tarea en su parte superior (incluyendo el PC). As que, si
cargamos el puntero de pila de esa tarea, slo tenemos que hacer lo mismo
que si nos gustara volver de la cambio de tarea que causa la funcin de nuevo
a la misma tarea (vase ms arriba): pop todos los registros y seguir adelante
con eso tarea. 11 Importante para ver: Todas las tareas que no estn
actualmente activos se han desactivado la misma manera; todos han dejado
una pila con todos los registros, incluyendo el PC en su parte superior y todos
sus punteros de pila se han guardado en el, ubicacin conocida bien definido.
Un cuadro de un cambio de tarea podra ser la siguiente: Empujar los registros

en la pila es como subir una colina, desde su cima de saltar a la parte superior
de cualquiera de las otras colinas alrededor y luego nos deslizamos hacia abajo
(es decir, restaurar los registros con el contenido de esta otra colina). Hacer la
buena preparacin de almacenar el contexto de la CPU en la pila el cambio de
tarea completa se reduce a nada ms que intercambiar el valor de puntero de
pila de la CPU. El valor de la todava tarea activa se guarda y se carga el valor
de la tarea recin activado - eso es todo. A continuacin os dejamos el cambio
de tarea causando funcin y su registro sencillo apareciendo cdigo de salida
carga el contexto anterior guardada de la nueva tarea al igual que en la CPU.
La historia general es completa si mencionamos la inicializacin. Antes de la
primera tarea se vuelve activo el cdigo de inicializacin todava un-roscados
de RTuinOS prepara las reas de pila de todas las tareas como si estas tareas
haba estado activo antes y como si hubieran sido suspendidos luego. Esto se
hace por la simple, ensamblador cdigo libre C funcin prepareTaskStack. Se
coloca 33 bytes al comienzo de esta zona de memoria 12 - Y estos bytes se
convertirn en los valores iniciales de los registros de datos de la CPU cuando
se activa la tarea que el primera vez muy (registros de propsito general y
estado). Y frente a estos 33 bytes se coloca el dos o tres bytes de la PC
deseada (dependiendo del tipo de microcontrolador AVR). En tiempo de
ejecucin es la ubicacin de memoria de programa dnde continuar una tarea;
ahora en tiempo de inicializacin es obviamente el inicio direccin de la tarea o
- en C - el puntero a la funcin de la tarea. La direccin donde el ltimo byte ha
sido coloc es el valor del puntero de pila que tiene que ser almacenado en el
objekt tarea. Cuando se preparan todas las reas de la pila de la interrupcin
del reloj del sistema est activado y la primera tarea de activacin un poco
ms tarde de ninguna manera puede ser distinguida de cualquier cambio de
tarea ms tarde. 10 Demostrar: Para continuar la tarea izquierda no es un
requisito previo que la tarea activado termina - con el fin de "retorno" a la tarea
a la izquierda. 11 El contador de programa se extrae como el ltimo registro
con un reti comando "regreso de interrupcin". 12 El principio lgico se refera.
Esta es la ltima direccin de la memoria en el rea de pila. La arquitectura
AVR permite la pila crecer de mayor a menor direcciones de memoria.
Pgina 18
18 CAPTULO 2. CMO FUNCIONA RTUINOS? 2.7.1 Interrupcin frente Funcin
API Bsicamente todo cambio de tarea causando funciones se comportan como
se describe en la seccin anterior. Conmutador de tareas causando funciones
son o rutinas de interrupcin de servicio o funciones de la API. Las
interrupciones pueden ser el tic temporizador del sistema o una solicitud de
interrupcin. Las funciones de la API son o bien la suspensin rtos comando
waitForEvent 13 o funcin RTOS sendEvent para publicar un evento. Hay una
diferencia significativa entre las rutinas de servicio de interrupcin y funciones
de la API. La funcin API ciones pueden devolver un resultado al cdigo de
llamada pero un ISR no. Cuando la ISR devuelve a una tarea (la haba

interrumpido o otro en caso de un cambio de tarea) todos los datos de los

registros necesitan estar en el exactamente mismo estado en el punto de
inactivacin de esta tarea. Cuando las funciones de la API regresan, algunos
registros pueden ser alterados y algunos otros necesitan ser alterados. Los
registros de datos que pasan informacin de parmetros para el funcin podra
ser cambiado en la funcin sin confundir el cdigo de llamada despus del
regreso. Estos "podrn ser cambiado "las condiciones son ignorados por
RTuinOS; los registros sern restaurados incluso si esto no es necesario.
Algunos otros registros de datos, que son seleccionados por el compilador para
pasar el resultado de la funcin de vuelta al cdigo de llamada sin embargo
necesitar ser alterado; slo restaurarlos como los otros registros significara no
devolver un resultado de la funcin significativa. Slo tenemos el caso de la
orden de suspender uint16 t rtos waitForEvent; el compilador GNU permite tal
funcin volver su resultado entero de 16 bits en par de registro r24 / r25. En
consecuencia, si un cambio de tarea activa una tarea, que haba sido
desactivado por una orden de suspender, el contexto operacin de
restauracin diferente. Todos los registros, pero el par de registro r24 / r25 se
restauran y r24 / r25 se carga con el resultado de la funcin. La reti comando
final luego aparece la PC de la pila y la tarea se contina (y probablemente
evaluar el resultado de la funcin en r24 / r25 como una de sus primeras
operaciones). Algunos detalles todava necesitan explicacin. En primer lugar
el equilibrio pila; por favor refirase a la figura 2.2 . Como nos ahorramosel
contexto de la CPU en la pila tarea que siempre debe empujar y hacer estallar
el mismo nmero de bytes en cada tarea interruptor. Al restaurar el contexto
en el retorno a una tarea suspendida originalmente no vamos a restaurar r24 /
r25 de la pila (pero cargar con el resultado de la funcin) y por lo tanto no hay
que empujar estos registros cuando guardar el contexto. El contexto operacin
de salvar a la entrada en un comando suspender salvar todos los registros
pero R24 / R25 - previendo que estos registros no se restaurarn despus. La
funcin de la API cambio de tarea causando rtos sendEvent es una funcin
void. No devuelve un resultado y todos los registros se guardan en tanto, la
entrada en rtos sendEvent y restauraron a su regreso a la tarea de llamada.
(Que podra ser inmediatamente o ms tarde a causa de la liberacin de otro,
ejecutado de forma intermedia tarea de mayor prioridad.) Un segundo detalle,
menos importante es acerca de cmo el par de registro r24 / r25 se carga con
la funcin resultado. Si el cdigo de conmutacin de tareas reconoce que la
tarea que se active haba sido suspendido antes de que empuja el resultado de
la funcin en la pila como una ltima accin antes de salir de la funcin. La
secuencia de cdigo para dejar el cambio de tarea funcin que ha causado (ya
sea un ISR o una funcin API) ahora pueden ser idnticos bajo todo
condiciones: que salte todos los registros de datos, que aparece el registro de
estado, que finalmente aparece el PC y que va a continuar con la nueva tarea
activa. Esta idea sencilla aplicacin requiere que el cdigo de salvar al contexto
empuja no los registros en su orden natural, r0. . . r31, pero los registros r24 /

r25 necesita ser empujado en ltimo registros. El ltimo e importante detalle es

acerca de cmo saber si haba sido originalmente una tarea activado
suspendida o no. La consideracin de este detalle tambin responde a la
pregunta que el resultado de la funcin de el suspender comandos viene. Las
respuestas se muestran en la figura 2.3. Un objeto de tarea es propietaria de
un miembro de postedEventVec, que es nula inicialmente y cuando la tarea
est activa. Ella sigue siendo nula la entrada en estado suspendido. Mientras
que una tarea est en estado suspendido escucha a todos transmitido eventos
y que podra esperar a exclusiones mutuas o semforos especficos. Siempre
que otros puestos de trabajo de un evento es doble facturado si este evento es
relevante para la tarea suspendida. Si es as, se aade al miembro de
postedEventVec de la tarea suspendida. Esta variable contiene el conjunto de
eventos, que han sido recibidos por la tarea desde se hizo suspendido. Tan
pronto como el conjunto de eventos recibidos suficiente para hacer la tarea
suspendido debido de nuevo ya no se cambia esta variable. Una tarea puede
llegar a ser debido tambin en otro camino a travs de la tabla de estado. En
cualquier momento la tarea activa puede 13 Esto incluye la deriva suspender
comandos retraso rtos y RTOS suspendTaskTillTime.
Pgina 19
2.7. TAREA INTERRUPTORES 19 Figura 2.2: Implementacin de conmutadores
de tareas. En el lado izquierdo de rutinas de servicio de interrupcin. En el lado
derecho de suspender los comandos: La nica diferencia es empujar o no
empujar el registro par r25 / r25 de entrada de la funcin. La funcin de la API
RTOS sendEvent no se muestra; se implementa como un ISR, empuja el par de
registros
Pgina 20
20 CAPTULO 2. CMO FUNCIONA RTUINOS? Figura 2.3: Modelo de Estado de
una sola tarea. Las condiciones de transicin se muestran en la fuente por
defecto, mientras que el acciones de transicin se muestran en cursiva. La
variable tarea postedEventVec se utiliza como bandera que indica si la tarea va
a regresar de una orden de suspender o no. ser inactivados por cualquier otra
tarea de mayor prioridad con vencimiento (y activos al mismo tiempo). Si se
trata de una tarea round robin una tarea puede ser inactivado cuando ha
transcurrido su porcin de tiempo. La inactivacin significa el trnsito de un
estado activo a estado debido. La variable postedEventVec es siempre nulo en
estado activo. Si los trnsitos de tareas de activo debido al variable es todava
nula en el estado debido y no puede cambiar aqu. Si y slo si a los trnsitos de
tareas de suspensin Debido a la variable no es nulo. De esta manera, la
variable tiene un doble significado una vez que alcanzamos el estado debido:
En primer lugar se lleva a cabo el conjunto de eventos recibidos que hicieron la
tarea debido. Este es el valor de retorno de el comando que originalmente hizo

la tarea inactiva suspender. En segundo lugar, la variable contiene la

informacin de Boole si la tarea de volver de alguno de los comandos de
suspender (que espera el resultado en r24 / r25) o de un ISR o RTOS sendEvent
(que debe regresar con contenidos restauradas de r24 / r25). Esta informacin
es explotada por el cdigo de cambiar de tarea. La variable postedEventVec se
pone a nulo al activar la tarea, es decir, cuando se hace la tarea cambiar a esta
tarea. Ahora se prepara para el siguiente ciclo activo debido activo o
activo suspendida debido activa respectivamente.
Pgina 21
Captulo 3 La API de RTuinOS Este captulo presenta las diferentes funciones de
la interfaz de programacin de aplicaciones RTuinOS '(API). La intencin es
explicar el significado y uso de los casos de las diferentes funciones de la API,
no todos los detalles de las firmas de funcin. Por favor, consulte la
documentacin doxygen que se basa directamente en la fuente de C cdigo
para obtener detalles sobre los parmetros de funcin, valores de retorno,
efectos secundarios, etc. 3.1 Configuracin de RTuinOS: rtos.config.template.h
Creacin de una aplicacin RTuinOS comienza con la configuracin del sistema.
Todos los elementos de RTuinOS, que requieren configuracin depende de la
aplicacin se han colocado en el rtos.config.template.h archivo. Este archivo no
es parte de la construccin, que es slo una plantilla para el archivo que en
realidad por lo utilice. Copie la plantilla a su cdigo fuente de la aplicacin y
cambiarle el nombre a rtos.config.h. Este es el nombre que tiene que tener, ya
que es el nombre utilizado en las instrucciones #include en el cdigo. Abra el
archivo renombrado en un editor de texto y leer los comentarios. Usted
encontrar una serie de # de definir qu es necesario ajustar de acuerdo a las
demandas de su aplicacin. El nmero de tareas (adems de la tarea inactiva)
que va a utilizar, el nmero de prioridad clases a las que pertenecen y el
tamao de estas clases son los ajustes ms evidentes. Usted puede permitir
que el estrategia de round robin (por defecto est desactivada), puede
configurar sus interrupciones de aplicacin y que podrn elegir la resolucin
del temporizador del sistema. Por favor, encontrar una ms en detalle la
discusin de algunos de ellos temas a continuacin y en los comentarios en el
cdigo fuente. 3.2 Inicializacin de RTuinOS: configuracin La aplicacin
RTuinOS comienza con una llamada de configuracin. Esta funcin es una
devolucin de llamada desde la puesta en marcha de Arduino cdigo (y el
cdigo de inicializacin RTuinOS al mismo tiempo) en su aplicacin. Si usted no
proporciona esta funcin el vinculador reportar un problema y se niegan a
construir el ejecutable. Usted puede poner toda la cdigo de inicializacin de la
aplicacin aqu. Y es necesario colocar la especificacin de las tareas de su
aplicacin aqu. Ninguna otra ubicacin de cdigo es posible hacer esto. 3.3
Especificacin de tareas: rtos initializeTask Desde dentro de la configuracin
que tienes que llamar rtos initializeTask vez por tarea. Esta funcin especifica
las propiedades de una tarea. Es importante saber, que las interrupciones

especficas RTuinOS no se han iniciado, mientras que la configuracin se

ejecuta. De este modo se puede interferir con ningn objeto de datos
propiedad de sus tareas sin tener en cuenta condiciones de carrera y la
sincronizacin de acceso. La cosa ms importante a especificar es el cdigo
ejecutable de la tarea, es decir, la funcin de la tarea. La Tipo de puntero de
funcin especfica, taskFunction rtos t, se ha definido para este propsito. Una
funcin de tarea es una 21
Pgina 22
22 CAPTULO 3. LA API DE RTUINOS void funcin con un solo parmetro. Este
parmetro pasar el conjunto de eventos para el cdigo de trabajo, que hecho
que la tarea debe la primera vez despus de iniciar el sistema; en los casos de
uso ms tpicos esto ser slo uno de los dos eventos del temporizador del
sistema y pueden ser ignorados por el cdigo de tarea. Tpicamente, las
funciones de trabajo del ciclo de alrededor de (similar al bucle de la funcin en
un croquis tradicional Arduino). Algunos otros RTOS ofrecen una terminacin
tarea pero RTuinOS no. En RTuinOS una tarea nunca debe terminar. Si alguna
vez lo que sera "volver" al vector de reset de la placa Arduino y su aplicacin
comenzara de nuevo - y probablemente en un bucle de hacerlo varias veces
para que. El rea de pila de la tarea se especifica mediante un puntero a un
espacio de direcciones reservado en la memoria RAM y por el longitud de esta
rea reservada. Reservados significa que su aplicacin tiene que asignar la
memoria necesaria. Desde el rea de pila nunca se puede cambiar en tiempo
de ejecucin que no tiene sentido considerar alguna dinmica operaciones de
asignacin. Basta con definir una serie de uint8 t y pasar su direccin y
tamao. Precaucin: Reservado tambin significa que el rea de pila
especificado no debe ser tocado por su aplicacin cdigo. Si ha configurado
RTuinOS para apoyar la estrategia de round robin especificar la duracin de la
tiempo rebana la tarea se hace. No todas las tareas deben estar sujetos a la
programacin de todos contra todos. Si el duracin del intervalo de tiempo se
ajusta a 0 no existe tal comportamiento para esta tarea; con otras palabras, su
tiempo rebanada tiene una duracin ilimitada. Otra parte importante de la
especificacin de tareas es la condicin inicial currculum. Se especifica como
en tiempo de ejecucin cuando se utiliza el comando suspender rtos
waitForEvent; por favor refirase a la seccin 3. 6 f o detalles.Su tarea slo se
pondr en marcha si la condicin especificada ahora se convierte en realidad.
rtos initializeTask utiliza un ndice para identificar qu tarea objeto que se
entiende por la llamada a la funcin. La ndice tiene ningn significado
particular, adems de ser una especie de mango al mismo objeto tarea cuando
ms tarde utilizando las funciones de diagnstico RTOS getTaskOverrunCounter
y RTOS getStackReserve. El ndice tiene que ser menor que el nmero de
tareas, pero no tendr un impacto en la prioridad u orden de ejecucin de la
tareas. 3.4 Inicializacin de aplicacin interrumpe: rtos enableIRQ- Usuario
<nn> Su aplicacin puede configurar RTuinOS utilizar sus propias

interrupciones que desencadenan tareas dedicadas. Si configurar una

interrupcin una devolucin de llamada en el cdigo de aplicacin se realiza
como parte de la puesta en marcha del sistema. La rtos funcin enableIRQUser
<nn> el objetivo de liberar su interrupcin <nn>. Esto significa tpicamente
para configurar algunos registros de hardware de un dispositivo perifrico y
para establecer finalmente la llamada mscara de interrupcin bit. Usted
nunca debe tratar de hacer esto como parte del cdigo de inicializacin general
de configuracin: En este punto en el tiempo la tarea, que est acoplado a la
interrupcin no est listo para funcionar y la liberacin de la interrupcin ahora
podra causar comportamiento impredecible de la rutina de servicio de su
interrupcin. Por otro lado, cuando rtos enableIRQUser <nn> se invoca, el
sistema RTuinOS est en marcha (Adems de su interrupcin) y todas las
implicaciones con respecto a condiciones de carrera y acceso a datos
sincronizacin cin deben tenerse en cuenta. Su aplicacin debe permitir a la
fuente de interrupcin, pero no tiene que implementar un servicio rutina. Esta
rutina es parte de la implementacin RTuinOS. Su accin estndar - que no
puede ser cambiado - es para publicar un evento dedicado. Su solicitud
seguramente especificar una tarea de alta prioridad que cclicamente espera
para este evento y ejecuta el cdigo real de servicio de interrupcin. La
especificacin de la fuente de interrupcin es un detalle de la configuracin
RTuinOS hecho en rtos.con- fig.h. Actualmente, RTuinOS implementa hasta dos
interrupciones de la aplicacin (es decir, <nn> es 00 o 01), pero es simple y
directo para extender la aplicacin a ms interrupciones en caso necesario.
Tras el regreso de la ltima llamada de retorno rtos enableIRQUser <nn> su
aplicacin es totalmente suya y correr.
Pgina 23
3.5. LA TAREA DE REPOSO: LAZO 23 3.5 El Grupo de reposo: bucle Una vez que
se inicia el sistema que llama cclicamente el bucle funcin void que tiene que
ser ejecutado por su aplicacin. Si usted no proporciona esta funcin el
vinculador reportar un problema y se niegan a construir el ejecutable. La
llamada repetida de bucle es la tarea ociosa de RTuinOS. Esto significa que la
ejecucin de este cdigo se hace slo si no hay otra tarea pide al CPU. La
velocidad de ejecucin del bucle es directamente dependiente de las
actividades de sus tareas. Por lo tanto, normalmente contiene cdigo que no
tiene limitaciones de tiempo real. Un caso de uso tpico de la tarea ociosa es
poner un poco de cdigo de diagnstico aqu. Por ejemplo, RTuinOS permite
volver a verificar el uso de las reas de pila. (Si una tarea jams exceder su
rea de pila reservado un accidente de inmediato es probable; que es una
difcil de encontrar error en el cdigo.) Este cdigo es bastante caro pero
cuando se encuentra en la tarea ociosa que no importa en absoluto. El nico
impacto de cdigo caro del ralent tarea es que los resultados estarn
disponibles un poco ms tarde o con menos frecuencia. Para una funcin de
diagnstico de esta es tpicamente acrtica. RTuinOS soporta casos de uso

tpicos donde siempre al menos una tarea se debe. Un ejemplo es un par de

tareas, todo funcionando continuamente, y programado por la estrategia de
round robin. Se activan cclicamente pero nunca suspendido. En este bucle
situacin nunca ser llamado. Sin embargo, como requisito previo del xito
cdigo de vinculacin est, no obstante, es necesario tenerlo. Si no se requiere
ninguna tarea vaca o si no hay tiempo de inactividad izquierda simplemente
aplicar bucle como una funcin vaca. 3.6 Suspender una tarea: rtos
waitForEvent Una tarea en RTuinOS permanece por el tiempo que desee. Si se
ha terminado o si se vuelve dependiente de la resultado de trabajo de alguna
otra tarea o en un evento externo (reportado por una interrupcin de la
aplicacin) lo har suspender voluntariamente. En un sistema tcnico, se aplica
a menudo una tarea que hacer una operacin regular, por ejemplo, leer y
procesar la valor de entrada de un convertidor analgico-digital cada segundo
Milli. 1 Aqu, "termin" significara tener efectuado la grabacin. Cuando el
valor de esta segunda Milli ha sido procesado, la tarea suspendera hasta que
comience el prximo segundo intervalo de Milli. Suspender siempre incluye una
condicin en la que el extremos estado suspendido - en nuestro ejemplo sera
el evento de temporizador absoluta y su parmetro cuando se establece en el
segundo siguiente Milli. Desde la perspectiva del flujo de cdigo de tarea,
suspendiendo voluntariamente siempre significa que espera por algo y no
hacer nada hasta que. Esto explica el nombre de la suspensin de funcin. Con
la vista en el sistema completo, medios de suspensin para devolver la CPU y
pasarla a otras tareas, que actualmente no tienen que esperar a que sean
cuales sean los acontecimientos. En RTuinOS una tarea puede suspender y
esperar hasta un punto en el tiempo, por un tiempo, hasta un conjunto de
eventos ha sido publicado por otras tareas (o un tiempo de espera ha
transcurrido mientras tanto), hasta por lo menos un evento de un conjunto ha
sido publicado por otras tareas (o ha transcurrido un tiempo de espera
mientras tanto). 2 La firma de la orden de suspender tiene un conjunto de
eventos como poco vector (con un mximo de 16 bits o eventos
respectivamente), un operador booleano (todos los eventos requiere o
cualquier evento libera la tarea) y un parmetro de tiempo. Los eventos
pueden ser de cualquier tipo, ordinaria emitida, mutex o un semforo. Con
xito a la espera de un evento de tipo mutex o un semforo significa adquirir el
objeto de sincronizacin, o conseguir la propiedad de la asociada, gestionado
recursos respectivamente. 1 En la configuracin predeterminada RTuinOS el tic
temporizador del sistema es de 2 ms; una segunda tarea Milli no puede
implementarse sin un cambio de configuracin. 2 En realidad, las dos primeras
condiciones son casos especiales de los dos ltimos: El conjunto de eventos
que esperar a que slo contiene un temporizador evento, pero nada ms.
Pgina 24
24 CAPTULO 3. LA API DE RTUINOS static void regularTask (uint16 t
initialResumeCondition) { #define MI TAREA TIEMPO DE CICLO 1 / * Unidad es

tic temporizador del sistema, e. g. 1 ms * / hacer { / * Aplicacin tarea real: leer

ADC, valor del proceso. . . * / readADCAndProcess1ms (); } while (RTOS
waitForEvent (RTOS EVT ABSOLUTA TIMER , / * WaitForAllEvents * / falsas , / *
Cuando * / MI TIEMPO DE CICLO DE TAREAS ) ); } / * Fin de regularTask * / Ficha
3.1: caso de uso tpico: tarea peridica El parmetro de tiempo no le importa si
hay evento de temporizador es parte del conjunto de eventos. Si el
temporizador absoluta evento est en el conjunto del parmetro de tiempo
tiene el sentido cuando. Si el evento de temporizador familiar o demora es en
el establecer el parmetro de tiempo tiene el significado despus. En
consecuencia, no se le permite tener ambos eventos de temporizador en el
conjunto. Un bit especfico es el parmetro cuando el temporizador de
absoluta. El caso de uso ms tpico de lo absoluto evento de temporizador es la
realizacin de una misin regular; en nuestro ejemplo anterior de una tarea,
que se activa cada Segundo Milli. Ver lista 3. 1: La implementacin situar la
accin en un bucle infinito. El tiempocondicin al final del bucle ser una
llamada de RTOS waitForEvent, dirigindose a la evento de temporizador
absoluta. En cada bucle al segundo siguiente Milli se pasa como parmetro
cuando. Esto requerira una acumulacin variable en la aplicacin, que se
actualiza en cada bucle. Para evitar esto, el parmetro cuando es definida
como una diferencia, la diferencia a la ltima referencia reciente al
temporizador absoluta. Esto hara significa en nuestro caso de uso tpico, ese
parmetro cuando se convierte en una constante. En cada bucle, el parmetro
simplemente es 1 [ms] en la convocatoria de RTOS waitForEvent. Atencin, si
una tarea espera a un conjunto de eventos y que quiere ser liberada cuando
todos los eventos se publican en la tarea, entonces la condicin de todo no se
refiere slo a los sucesos de la aplicacin (ordinaria, de exclusin mutua o
semforos) pero no a un evento de temporizador. Los eventos de temporizador
seguirn liberar la tarea tan pronto como se produzcan. El significado de
eventos de temporizador siendo los tiempos de espera no se ve afectada por la
eleccin de espera para todos o para cualquier evento. 3.6.1 Eventos de Kind
objeto mutex Un evento que esperar a que puede ser un mutex, un objeto de
sincronizacin para la exclusin mutua de las tareas de un de recursos. El tipo
de un evento se especifica en tiempo de compilacin, es parte de la
configuracin de RTuinOS, ver [4]. Desde la perspectiva de una tarea en espera
de un mutex es como la espera de eventos transmitidos ordinarios. La tarea se
suspende hasta que el mutex est disponible. Este ser el caso cuando la otra
tarea, que Actualmente posee el mutex lanzar usando rtos sendEvent. O
inmediatamente, si no hay otra tarea en la actualidad posee el mutex. Si una
tarea suspende a la espera de un mutex puede suceder que rtos waitForEvent
no suspende la tarea pero inmediatamente vuelve. Por favor, consulte la
seccin 3.6.3 para ms.3.6.2 Eventos de tipo semforo Un evento que esperar
a que puede ser un semforo, un objeto de sincronizacin para gestionar el
acceso a una piscina de recursos compartidos entre diferentes tareas. El tipo
de un evento se especifica en tiempo de compilacin, es parte de

Pgina 25
3.6. SUSPENDER UNA TAREA: RTOS WAITFOREVENT 25 la configuracin de
RTuinOS, ver [4]. A la espera de un semforo y conseguir que significa
disminuir los semforos cuenta interna. La tarea se concede el acceso a una
instancia de los recursos que son administrados por el semforo. Tenga en
cuenta, que los semforos de manejo como Boolean eventos (estar all o no
estar all) valorado impide proporcionar una API ms generalizado a los
semforos. En RTuinOS es por principio imposible adquirir varios casos desde el
fondo de recursos a la vez. Una aplicacin que tiene que tener varios casos
est obligado a repetir la invocacin de RTOS waitForEvent ese nmero de
veces. Aunque este finalmente lleva a la cantidad necesaria de instancias no es
equivalente con respecto a la distribucin patrn de los recursos compartidos.
La misma consideracin se aplica a la devolucin / liberacin de un semforo
utilizando rtos sendEvent. Desde la perspectiva de una tarea a la espera de un
semforo es como la espera de los acontecimientos ordinarios. La tarea se
suspende hasta que una instancia (o valor del contador respectivamente) del
semforo est disponible. Este ser el caso cuando una instancia cualesquiera
otros lanzamientos de tareas tales usando rtos sendEvent. O inmediatamente,
si Actualmente hay al menos un caso que queda en el semforo. Si una tarea
suspende a la espera de un semforo puede suceder que rtos waitForEvent no
suspende la llamando tarea pero vuelve inmediatamente. Por favor, consulte la
seccin 3.6.3 para ms.3.6.3 Notas sobre la espera de eventos de tipo objeto
mutex o un semforo Puede suceder que los disponibles inmediatamente
exclusiones mutuas o semforos satisface la condicin de espera de la
llamando tarea: Espera para cualquier evento entre los que un mutex
disponible inmediatamente o semforos. O espera a que todos los eventos
fuera de un conjunto, pero todos ellos estn disponibles de inmediato. Si es as,
la llamada de la funcin rtos waitForEvent no suspender la tarea. En lugar rtos
waitForEvent simplemente devuelve como un ordinario sub-rutina y el valor de
retorno indica las exclusiones mutuas y semforos adquiridos. Si una tarea
espera a que uno o ms mutexes o semforos que necesita para evaluar el
cdigo de retorno de la funcin. Si un poco ajustado corresponde a un evento
mutex la tarea es el nuevo dueo de este mutex. Si un bit activado
corresponde a un evento de semforo la tarea tuvo acceso a una instancia del
fondo de recursos administrados por este semforo. Se va a poseer el mutex o
tener acceso al recurso hasta que se libere voluntariamente el mutex o un
semforo utilizando rtos sendEvent. Dado que las condiciones de espera
pueden ser complejas, el retorno de la funcin como tal hay ninguna indicacin
segura de que un mutex o un semforo ha sido adquirido por la tarea. El ms
simple ejemplo de ello es una espera para un evento mutex con tiempo de
espera y el tiempo de espera que transcurre antes de liberar el mutex por la
tarea que propietaria. Precaucin, manteniendo correctamente un registro de la
propiedad de las exclusiones mutuas e instancias de semforos est

totalmente en la responsabilidad de la aplicacin. RTuinOS no se molestar con

quin tiene que mutexes o semforos. Se aceptar un comando de liberacin
mutex / semforo por cualquier tarea sin importar si esta tarea realmente
posee o no. Mediante el valor de retorno de RTOS waitForEvent RTuinOS slo
proporciona la informacin para la aplicacin para que pueda implementar el
control de la propiedad adecuada. 3.6.4 rtos suspendTaskTillTime Para apoyar
an ms el caso de uso tpico de las tareas regulares, hay una abreviatura de
la convocatoria de RTOS espera- ForEvent como esbozado en el listado 3.1 . En
lugar de llamar rtos waitForEvent uno puede llamar rtos suspendTask-TillTime.
El nico parmetro de la funcin es el parmetro cuando. rtos
suspendTaskTillTime se implementa como preprocesador macro, as que no hay
diferencia en la comparacin hijo a usar directamente rtos waitForEvent
excepcin de la legibilidad del cdigo. Retraso 3.6.5 rtos Otra llamada
abreviada de RTOS waitForEvent apoya la condicin de "esperar por un tiempo"
(pero no para cualquier evento especfico). Usted puede utilizar el
preprocesador rtos macro retrasan para esto. El nico parmetro de macro es
el parmetro de temporizador, que especifica el tiempo de retardo (o el tiempo
que permanecen suspendidas, respectivamente).
Pgina 26
26 CAPTULO 3. LA API DE RTUINOS No hay ninguna diferencia en comparacin
con el uso directamente rtos waitForEvent excepcin de la legibilidad de el
cdigo. 3.7 Awake suspendido Tareas: rtos sendEvent Los eventos de
temporizador son gestionados en su totalidad por el sistema, todos los dems
eventos se realizarn slo si son enviados por el cdigo de aplicacin. Esto se
puede hacer ya sea por interrupciones de aplicacin o mediante la invocacin
de la funcin API rtos sendEvent. El nico parmetro de la funcin es el
conjunto de actos que se publicado, implementado como un vector de bits de
16 Bits. Ni los eventos del temporizador ni los eventos de interrupcin de
aplicaciones deben ser publicados; siguen existiendo (dependiente de la
configuracin de RTuinOS) de doce a catorce eventos, que se manejan
directamente por la aplicacin cdigo de tarea. Hay tres tipos de eventos:
eventos ordinarios, eventos mutex y eventos de semforos. El tipo de cada uno
de los eventos disponibles se define en tiempo de compilacin como parte de
la configuracin de RTuinOS hecho en [4]. Hay nombres predefinidos para los
eventos disponibles, vase [2]. En cualquier caso, es posible que tambin
definir sus propios, nombres adecuados. Cada nombre se define como el valor
del bit de evento; en consecuencia, conjuntos de eventos se pueden expresar
por sumas o O binarias (|) trminos de estos nombres. Un caso de uso tpico de
eventos manejados de aplicacin son los modelos de productores y
consumidores. Una tarea prepara algunas seales de datos y la disponibilidad
de los datos de consumo tarea mediante el establecimiento de un evento.
Obviamente, la consumidor comienza con la espera de este evento. Un evento
ordinario se amplia fundido slo a las tareas suspendidas actualmente y no se

almacena aparte eso. Si una tarea suspende poco despus de otra ha

publicado tal caso, la tarea nunca se suspendi recibir este evento y puede
permanecer suspendido para siempre. Eventos mutex y semforos difieren y
son la mejor opcin para manejar la comunicacin inter-tarea en muchos casos
de uso. Por favor, consulte las secciones 2.3. 1 y 2.3.2 para obtener detalles
sobre el significado y la manipulacin deeste tipo de eventos. Acceso 3.8
Datos: rtos entran / LeaveCriticalSection En todos los casos de uso pertinentes,
tareas compartirn algunos datos. Algunas tareas producirn datos, otros lo
leern. Si su aplicacin tiene tareas de diferente prioridad, esto se convierte en
un asunto. A excepcin de algunos ejemplos triviales como leer o escribir una
palabra un byte, todo acceso a los datos no es atmico, es decir, puede ser
interrumpido por cualquier interrupcin del sistema. El software tiene que
anticipar que este es un sistema de interrupcin de temporizador o un RTuinOS
interrupcin aplicacin que puede causar fcilmente un cambio de tarea. Una
tarea puede ser activada en-si bien es ocupado la actualizacin de los datos y
otra tarea puede continuar operando en los mismos datos de la mitad del
camino, completados. La resultados son impredecibles y seguramente mal.
Tenga en cuenta, incluso una operacin en busca atmica como ++ u, donde u
es una de tipo uint8 t, es peligroso y requiere proteccin. El par de funciones
de la API RTOS EnterCriticalSection y RTOS LeaveCriticalSection hace cualquier
parte de cdigo que encierran atmica - y por lo tanto seguro con respecto al
acceso compartido a partir de las diferentes tareas. RTOS EnterCriticalSection
simplemente inhibe todas esas interrupciones, que pueden causar un cambio
de tarea y rtos LeaveCriticalSection vuelve a habilitar todas esas
interrupciones. Una aplicacin puede implementar las interrupciones, que
pueden establecer un evento RTuinOS y causar un cambio de tarea. Estas
interrupciones son obviamente relevantes para RTOS entra /
LeaveCriticalSection, tienen que ser inhibido tambin. En consecuencia, si sus
implementos aplicacin interrumpe tendr que extender la aplicacin por
defecto cin del par de funciones. Las funciones se implementan como macros
de preprocesador en la aplicacin fichero titularidad RTuinOS configuracin [4]
y su modificacin debe ser sencillo. Las dos funciones no guardar y restaurar el
estado de interrupcin de inhibicin. Despus de cualquier RTOS leaveCriticalSeccin, todas las interrupciones estn seguramente habilitado. Por lo tanto,
las llamadas parejas de las funciones no se pueden anidar. El cdigo de los
pares exteriores no estara protegida. El par de funciones de CLI y sei de la
biblioteca AVR casi tiene el mismo significado y puede tambin ser utilizado
para hacer las operaciones de acceso a datos atmica. La diferencia es que
inhiben todas las interrupciones. La
Pgina 27
3.8. DATOS DE ACCESO: RTOS ENTER / LeaveCriticalSection 27 capacidad de
respuesta del sistema podra ser algo degradada y sin necesidad, por ejemplo,
las funciones de tiempo de Arduino como el retraso o millis podran sufrir. Por

otra parte, estas dos funciones son un poco ms barato en trminos de Carga
de la CPU. Le sugerimos que lo use cuando la secuencia de cdigo protegido es
bastante corto, por ejemplo, slo uno o unos pocos tareas sencillas y utilizar
rtos entran / LeaveCriticalSection lo contrario. En RTuinOS una tarea de mayor
prioridad nunca llegar a ser inactivo en favor de una tarea de baja prioridad
con tal de que no suspende voluntariamente. Y si la tarea no es una tarea
round robin que va incluso nunca convertido en inactivo en favor de una tarea
igualmente prioridad (con tal de que no suspende en s). Por lo tanto, una
tarea normal de la misma o mayor prioridad no necesita operaciones atmicas
acceder comparte datos con otras tareas de igual o menor prioridad, una
tarea round robin de mayor prioridad no necesitan operaciones atmicas para
acceder a los datos que comparte con otras tareas de menor prioridad. Pero a
la inversa, sus homlogos de igual o menor prioridad, por supuesto, necesitan
proteger su cdigo de acceso para los mismos, datos compartidos. En las
tareas de sistemas cooperativos generalmente no necesitan para proteger su
acceso a los datos compartidos como tareas nunca ser interrumpido en
puntos imprevisibles (e indeseables) en el tiempo. En RTuinOS cooperativa
aplicaciones multitarea son implementados por las tareas de todos los que
pertenecen a la misma clase de prioridad. En resumen, Siempre ponga su
cdigo de acceso a datos en un par de funciones de proteccin si las acciones
de tarea esta de datos o partes del mismo con al menos otra tarea de mayor
prioridad, Siempre ponga su cdigo de acceso a datos en un par de funciones
de proteccin si la tarea tiene round robin caractersticas y si comparte estos
datos o partes de ella con al menos otra tarea de igual o mayor prioridad,
rtos uso entran / LeaveCriticalSection como par de funciones de proteccin si el
cdigo de acceso es complejo, Uso cli / sei como par de funciones de
proteccin si el cdigo de acceso es trivial. 3.8.1 Objeto mutex frente seccin
crtica Acceso a los datos compartidos de diferentes tareas de forma segura se
puede hacer con diferentes patrones de cdigo. El crtico seccin se puede
utilizar o un mutex se puede aplicar. Hay diferencias e implicaciones
significativas. El uso de un mutex es un tipo de contrato entre diferentes
tareas. Estn de acuerdo en acceder a los datos compartidos slo cuando
poseen el mutex y que prometen ser la duea ya no lo absolutamente
necesario. Hay sin embargo no hay medios tcnicos que garanticen este;
cualquier tarea realmente puede acceder a los datos compartidos en cualquier
momento y corromperlo. Por otra parte, no hay ninguna relacin directa, visible
en el cdigo fuente entre el mutex y los datos compartidos. Los ejemplos de
cdigo que vienen junto con RTuinOS demuestran dos tcnicas a superar esta:
o re-definir el nombre genrico de la exclusin mutua para que la relacin con
el compartido objetos se hacen evidentes o se esconden las operaciones para
adquirir y liberar el mutex de la misma clase que implementa el objeto
compartido. Una seccin crtica es un mecanismo tcnico, lo que dificulta el
planificador para cambiar a cualquier otra tarea (Incluyendo las interrupciones
y sus tareas de controlador) mientras se ejecuta el cdigo cerrado. Manejo de

una interrupcin o activar otra tarea se mueve en el tiempo hasta el momento

inmediatamente despus de la ejecucin del cdigo dentro de la seccin
crtica. Bloqueando el planificador es la razn, por qu secciones crticas se
pueden usar slo para secuencias de cdigos cortos, tpicamente algunas
operaciones de actualizacin de una estructura de datos. Un ejemplo sera la
cola, que es un elemento AP pendidos o hecho estallar apagado. El cdigo para
agregar y hacer estallar (unas pocas lneas cada uno) se colocara en una
crtica seccin. Ya estara mal estilo para poner algunos de depuracin o
retroalimentacin cdigo como Serial.println ("Elemento anexa ") en la seccin
crtica. La ejecucin de esta operacin tarda demasiado tiempo. Un patrn de
cdigo muy comn al usar secciones crticas es tener una copia local de los
datos compartidos en la tarea. La seccin crtica slo se utiliza para copiar los
datos compartidos en la copia local; Los siguientes,
Pgina 28
28 CAPTULO 3. LA API DE RTUINOS procesamiento lento y comentarios de los
usuarios opera slo en la copia y es, por supuesto efectuadas fuera de la
seccin crtica. Y lo mismo a la inversa para la actualizacin de los datos
compartidos. Un n veces de consumo de datos es la consecuencia, como cada
tarea necesita tener acceso a su copia local. Una propiedad subvenciones
mutex a los datos compartidos a travs de cualquier nmero de interruptores
de tareas. El planificador se queda en pleno funcionamiento. Slo esas tareas,
que tambin quieren tener el mutex (pero pronunci su demanda un poco a
ms tardar el afortunado) se encuentra temporalmente fuera de onda. Ellos se
suspenden. Tenga en cuenta, el bloqueo mutuo de las tareas que toda la
demanda del mismo recurso compartido ser probablemente en conflicto con
la requisito de tener tareas estrictamente regulares. Si tiene tareas regulares,
usted tendr que tener cuidado al aplicar exclusiones mutuas organizarlos.
Especificacin de un tiempo de espera al esperar un mutex puede ser una
salida. Bsicamente, un mutex podra ser adquirida mediante rtos waitForEvent
y puesto en libertad utilizando rtos sendEvent para un corto, operacin rpida;
el par de funciones podra ser utilizado como los otros RTOS par entran /
LeaveCriticalSection. Sin embargo, esto es mucho, mucho ms costoso en
trminos de carga de la CPU y no se debe hacer si un crtico seccin es
aplicable. Ejemplos, donde un mutex reemplaza razonablemente una seccin
crtica es cuando se hace la consola salida con serie o cuando se accede a la
pantalla LCD utilizando la biblioteca LiquidCrystal. 3.9 Diagnstico: rtos
getTaskOverrunCounter Cada tarea tiene un contador de desbordamiento
incorporado. El significado de este contador est bien definida slo para regular
de tareas. Estas tareas quieren ser debido en puntos fijos en el tiempo. Si
demasiadas tareas tienen demasiado que hacer Puede suceder que no es
posible realizar una tarea debido en el punto deseado en el tiempo. Esto es
entonces una tarea evento rebasamiento. Se cuenta internamente. Esta
funcin lee el valor actual del contador para una determinada tarea. Con esta

funcin, la aplicacin puede escribir cdigo de autodiagnstico. Sin embargo, si

este tipo de eventos son visto, no hay apenas nada que hacer en tiempo de
ejecucin. La evaluacin de los contadores se debe considerar una especie de
informacin de depuracin, una pista de desarrollo y prueba de tiempo que la
aplicacin sigue siendo insuficiente y necesita cambios. Hay dos escollos. Los
controles de funcionamiento de una tarea invadidos como parte de un
comando de suspender presentado por una tarea. Reconoce una tarea invadido
si se encuentra que el tiempo exigido de hoja de vida para estar ya terminado.
La hora del sistema actual se compara con el tiempo exigido de curriculum
vitae. La comparacin puede causar una desbordamiento aritmtico debido a
la duracin limitada de la hora del sistema utilizado internamente. En
particular, si una aplicacin utiliza la hora del sistema de 8 bits hay una
probabilidad significativa de tomar la decisin falsa: Si una tarea peridica
elige un tiempo demasiado largo perodo de una sobrecarga de tareas podra
ser reconocido en realidad hay tal rebasamiento se produce. Esto no slo dar
lugar a un valor de contador incorrecto, sino tambin a la sincronizacin de
tareas mal. La tarea result ser vencida se hace debe de inmediato, que es la
decisin equivocada en este caso. Si una tarea excesivamente superior a su
nominal tiempo de ejecucin regular no se reconocer la sobrecarga de tareas.
Llamadas de tareas son silenciosamente omite. Por favor, consulte la Secci n
4. 3. Aqu usted encuentra una discusin de cmo elegir la hora del sistema
apropiado para su aplicacin. Los rtos funcin getTaskOverrunCounter pueden
ser llamados por cualquier tarea. Tenga en cuenta que la funcin no est
definido para la tarea ociosa, sino que puede ser llamado por la tarea vaca
para consultar alguna de las otras tareas. 3.10 Diagnstico: rtos
getStackReserve Un simple algoritmo determina el uso de las pilas de tareas.
(En cualquier RTOS, cada tarea tiene su propio, dedicada pila.) El tamao
mximo de las pilas est predeterminado en tiempo de compilacin y
determinar el uso de pila real en tiempo de ejecucin es slo una herramienta
de desarrollo. Si el tamao mximo de la pila de cualquier tarea es superado el
sistema de seguridad se bloquear y la causa del accidente va a ser difcil de
encontrar. La asignacin de la pila tamaos demasiado grandes es demasiado
caro con respecto a RAM de uso. Por lo tanto, mediante la aplicacin de esta
funcin, usted puede mantener un ojo en el uso real de pila durante el
desarrollo y las pruebas de la fase y reducir el asignacin a un valor razonable.
Pgina 29
3.11. DIAGNSTICO: GSL GETSYSTEMLOAD 29 Hay dos escollos. El algoritmo
busca en el rea de la pila para obtener un patrn especfico byte la completa
rea se ha inicializado con, y que por lo general no est escrito en la pila en
tiempo de ejecucin. Sin embargo, podra escribirse en tiempo de ejecucin
mnima pero significativa probabilidad. Como resultado, el uso real pila puede
ser un byte ms que calculado con una probabilidad de que no se debe
descuidar. Es por mucho menos probable que dos de estos bytes se escribirn

consecutivamente en la pila en tiempo de ejecucin - la probabilidad que el

nmero calculado de bytes es demasiado poco a dos es mucho menos. Y as
sucesivamente. Si se agrega un nmero de cinco Byte a la utilizacin pila
calculado la probabilidad restante que esto es menos de la pila real uso es
insignificante. Los actuales aumenta el uso de pila de repente por 36 bytes en
el caso de una interrupcin del sistema (la CPU contexto de la tarea
interrumpida se guarda en la pila de esta tarea). rtos getStackReserve
devuelve el el uso mximo de la pila hasta el momento (en realidad devuelve
el valor inverso, la reserva, pero esto es equivalente). Este es un valor til una
vez que su cdigo de prueba se extiende a travs de todas las rutas de cdigo,
particularmente a travs de la ms profunda anidados subfunciones. Puede
asegurarse de esto mediante rutinas de prueba reservados. Pero puede
tambin estar seguro de que un interrupcin del sistema se produjo en el caso
de estar dentro de la ms profunda sub-rutina anidada? Si no, va a
seguramente ocurra tarde o temprano y se consumir otros 36 bytes de la pila.
Es una buena prctica aadir otro 36 Byte para el uso de pila computarizada.
Resumiendo, se debe aadir 41 Byte para el uso de pila calculado antes de la
reduccin del tamao de la pila de el valor realmente necesario. El RTOS
getStackReserve funcin podra ser llamada por cualquier tarea. Tenga en
cuenta que la funcin no est definido para la tarea de reposo, pero puede ser
llamado por la tarea de inactividad para la consulta de cualquiera de las otras
tareas. 3.11 Diagnstico: gsl getSystemLoad La medicin de la carga del
sistema es una herramienta de desarrollo importante para las aplicaciones
RTOS. La carga del sistema da una indicacin de un uso medio de la CPU, es
decir, el tiempo de la CPU pasa en la tarea ejecucin en comparacin con el
tiempo que queda, su tiempo de inactividad. Este valor se completa la
informacin proporcionada por la funcin API RTOS getTaskOverrunCounter.
Una medicin exacta de esta cantidad es difcil y RTuinOS realidad no ofrecen
la misma. Sin embargo, un simple algoritmo ha sido implementado, que calcula
una estimacin bastante buena y til de la carga de la CPU. El algoritmo est
disponible como un archivo fuente C independiente. Ya se haba publicado en
un anterior liberacin de RTuinOS como parte de uno de los ejemplos de
cdigo. Ahora, los archivos necesarios, [7] y [8], han sido integrado en la
instalacin RTuinOS y puede ser utilizado por cualquier aplicacin as como as.
Tenga en cuenta, que debe an no se puede considerar como una verdadera
parte de RTuinOS. Hay apenas requisito previo para aplicar la carga de la
estimacin de la CPU en su aplicacin RTuinOS. Incluir el archivo de cabecera
gsl systemLoad.h y funcin llamada gsl getSystemLoad de la tarea ociosa.
Devuelve el estimado de carga media de la CPU despus de alrededor de un
segundo del tiempo de observacin del sistema. Por favor, consulte [8] y [7]
para ms detalles. La idea de la estimacin de la carga es comparar el tiempo
del mundo dedicado a una secuencia conocida de la mquina cdigos a la
suma de tics de reloj de CPU requeridos por la secuencia. La ejecucin de la
secuencia de prueba se hace en una tarea que tiene una prioridad siendo

menor que cualquier tarea de la aplicacin correspondiente, por lo general la

tarea ociosa. Debido a su baja prioridad, esta tarea tendr un impacto en el
esquema de planificacin de la otra aplicacin, observado tareas pertinentes.
La relacin de las dos denominaciones de tiempo indica el porcentaje del
tiempo del mundo de la CPU gasta en la aplicacin tareas pertinentes, pero no
la tarea de ejecutar la prueba. El valor es una directa medir para la carga
media de la CPU, si la duracin de la ejecucin de la secuencia de prueba es
largo en comparacin a los conmutadores de tareas de la aplicacin. Por
principio, la aplicacin de la estimacin de carga tiene la desventaja de
cualquiera de consumir toda el sistema de tiempo de inactividad o - si
intercaladas con otras operaciones de la tarea ociosa - slo volver muestras
estimadas de la carga del sistema. Depende del diseo de la aplicacin y de la
configuracin de la funcin de qu tan bien las muestras se ajustan a la
realidad.
Pgina 30
Captulo 4 Escribiendo una Solicitud RTuinOS 4.1 Receta Corto Crear una
carpeta vaca en la carpeta de cdigo / aplicaciones. El nombre de la carpeta
es el nombre de la aplicacin. Copie el archivo de plantilla de configuracin [3]
en esta carpeta y cambiarle el nombre a rtos.config.h. Abrir rtos.config.h y
configurar el nmero de tareas, el nmero de diferentes clases de prioridad y la
tamao de estos. No utilice las clases de prioridad vacas, esto desperdicia
memoria costosa. Las prioridades deben siempre ser contados 0, 1,. . . , Max.
Configure el nmero de exclusiones mutuas y semforos en uso. Seleccione la
palabra anchura de la hora del sistema. A menudo un valor de ocho bits ser
suficiente. Por favor, consulte 4.3. En general,usted encontrar un montn de
consejos y comentarios en el archivo de configuracin que le dice lo que debe
hacer en detalle. Abra un nuevo archivo fuente C en la misma carpeta. Este
archivo implementa el ncleo de su aplicacin. Usted necesitar dos funciones
estndar, la configuracin y el lazo, las funciones de su trabajo y algunos datos
estticos. Crear una matriz esttica para cada tarea. El tipo es uint8 t. Esta
matriz se convertir en la pila de la tarea rea. Como regla general un tamao
de 100. . . 200 Byte es un punto de partida adecuado. Ms tarde, usted puede
solicitar rtos getStackReserve para tener una mejor idea. Crear funciones de
tareas vacas: static void taskFct (uint16_t). En configuracin, deber llamar
rtos initializeTask vez por tarea. Pase el puntero a la funcin de la tarea, la pila
rea y especificar la prioridad y la condicin en la que la tarea se convierte en
un principio debido (probablemente: inmediatamente). Crear el lazo funcin
vaco: void loop (void). Ahora llenar las funciones de trabajo con cdigo
funcional til. Tenga en cuenta, que una funcin de tarea no debe ser nunca a
la izquierda, un restablecimiento del sistema sera la consecuencia. Por lo
tanto, siempre se implementar un bucle infinito, por ejemplo, utilizando rtos
suspendTaskTillTime. Encuentra un ejemplo en el listado 4. 1. bucle puede
permanecer vaco si no lo hacenecesitar operaciones de inactividad.

task10ms void estticos (uint16 t initialResumeCondition) { hacer { / * Lugar

cdigo tarea real aqu, e. g. la llamada de un externo funcin. * /
myActual10MsTask (); } while (suspendTaskTillTime RTOS (5 / * unidad: 2ms
* /); } Ficha 4.1: habitual de tareas, activa regularmente 30
Pgina 31
4.2. El Makefile 31 Al aplicar el cdigo funcional siempre estar al tanto de la
discusin de proteger el acceso a datos compartidos entre las tareas; consulte
la seccin 3.8. Compilar la aplicacin utilizando el makefile genrico.
Compruebe su entorno: La herramienta de maquillaje necesita estar en la ruta
de bsqueda de Windows / Linux y la casa necesita entorno ARDUINO variables
para apuntar a su instalacin Arduino (ver seccin 4.2.1) . Si ha colocado todo
el cdigo en la carpeta nicacreada al principio, todo lo que tienes que hacer
ahora es ejecutar hacer -s APP = myFolderName construccin Iniciar la
aplicacin utilizando el makefile. Su placa Arduino se conecta a travs del cable
USB. Ser este COM6. 1 Ahora ejecute hacer -s APP = myFolderName COM_PORT
= COM6 carga El archivo de origen RTuinOS [1] no debe ser tocado en absoluto.
Slo tiene que abrir para leer si lo que entender cmo funciona RTuinOS. 4.2 El
Makefile RTuinOS como tal, no puede ser compilado, es slo un archivo fuente C
que tiene que ser compilado con su aplicacin cin. (Sin cdigo de la aplicacin
que terminaras con externos sin resolver al vincular el cdigo.) Sin embargo,
RTuinOS se distribuye con algunos casos de prueba autnomos que son
verdaderas aplicaciones RTuinOS. Todo estos pueden ser construidos y subido
usando la herramienta make, que es parte de la instalacin Arduino y el que
makefile es parte de la distribucin RTuinOS. Puedes organizar tus aplicaciones
similares a los casos de prueba. Entonces usted ser capaz de utilizar el
makefile sin cambios para su aplicacin, tambin. Incluso si su aplicacin crece
y necesita una ms compleja estructura de carpetas de los casos de prueba
para organizar el cdigo fuente usted todava ser capaz de utilizar el makefile,
sin embargo, con algunos cambios simples. Muy a menudo, usted har de la
siguiente manera: Abra una ventana Shell (es decir, un smbolo del sistema o
Powershell ventana en Windows o en Linux Bash) y cd al directorio raz de la
carpeta RTuinOS. Este es donde se encuentra la GNUmakefile archivo. Conecte
su tablero MEGA Arduino 2 al puerto USB, por ejemplo, nmero de puerto 6.
Ahora escriba hacer -s APP = TC05 COM_PORT = COM6 carga y caso de prueba
(o aplicacin) TC05 se compila y se cargan en el tablero. La placa Arduino es
restablece y se inicia la aplicacin RTuinOS. Ahora usted puede ser que
considere para abrir el Arduino IDE y abrir el monitor de serie (es decir, la
ventana de la consola) para ver lo que est pasando. Ms tarde, es posible
reemplazar la por defecto el puerto COM en el makefile con su nmero de
puerto especfico y la lnea de comandos se vuelve an ms corto. El makefile
explica a s misma llamando a hacer de la siguiente manera. El comando
requiere que la corriente de directorio de trabajo es el directorio raz de
RTuinOS. Llamar a hacer con la ayuda de destino, se imprimir una lista de

todos destinos disponibles en la consola con una breve explicacin: hacer

ayuda -s Una aplicacin RTuinOS no puede desarrollarse como un boceto en el
IDE de Arduino. Hicimos algunas pequeas cambios del archivo main.c Arduino,
que se perderan al utilizar el IDE. Sin embargo, puede continuar utilizar el IDE
para la consola de E / S si utiliza la serie de objetos para la comunicacin - que
es particularmente tiles durante el desarrollo de aplicaciones y que es
apoyado por el proceso makefile incluso mejor que por el IDE como el makefile
le permite tener la E / S de comandos slo condicionalmente en el cdigo. Su
presencia puede ser restringido a una configuracin de compilacin desarrollo
por medio de un #ifdef DEBUG. 1 Utilice el Arduino IDE para averiguar qu
puerto su tablero est conectado. Normalmente, despus de conectar la placa
que va a ser el ltimo puerto se muestra en el men Herramientas / puerto
serie. O bien, abra el Administrador de dispositivos de Windows y buscar en
"Puertos (COM & LPT)". Aqu encontrars tu placa conectada con el nombre y el
puerto COM asignado. 2 Otras tarjetas deben primero algn tipo de
personalizacin cdigo. Por favor, consulte la seccin 4.7.
Pgina 32
32 CAPTULO 4. ESCRIBIR UN RTUINOS APLICACIN 4.2.1 Requisitos previos El
nombre del archivo MAKE es GNUmakefile. Se encuentra ubicado en el
directorio raz de la instalacin RTuinOS. El makefile es compatible con el make
GNU de Arduino 1.0.5, que es "GNU Make 3.81". Precaucin: Hay docenas de
derivados de la herramienta de maquillaje alrededor y la mayora de stos son
incompatibles con respecto a la sintaxis del archivo MAKE. Incluso GNU make
3.80 no funcionar con makefile RTuinOS 'como que no conoca a los $ macro
(informacin) todava. Adems, hay puertos incompatibles Windows del GNU
hacer de la herramienta, por ejemplo, por MinGW y Cygwin. Para ejecutar la
herramienta de maquillaje que podra ser necesario aadir la ruta al binario al
frente de - para evitar sombreado por un derivado incompatible de maquillaje la ruta de bsqueda de Windows. 3 Dentro de su 1.0.5 Arduino instalacin,
encontrar la herramienta de maquillaje como arduino-1.0.5 / hardware /
herramientas / avr / utils / bin / make.exe. El makefile compila los archivos de
origen estndar de Arduino al core.a. biblioteca estndar Para ello, lo que
necesita saber, donde las fuentes de Arduino - se encuentran - que no forman
parte de este proyecto. Ella espera una variable ARDUINO entorno HOME para
que apunte al directorio de instalacin de Arduino, por ejemplo, c:
/ProgramFiles/arduino-1.0.5 en un sistema Windows. Usted probablemente
tendr que aadir una variable como a sus variables del sistema, ya que no se
define por el proceso de instalacin estndar de Arduino. Otro requisito de
ejecutar con xito el makefile es que su aplicacin no tiene ninguna dos
archivos de origen del mismo nombre - aunque esto sera bsicamente posible
con respecto al compilador y enlazador si estuvieran ubicados en diferentes
carpetas. Por ltimo, todas las rutas pertinentes a los ejecutables y archivos de
origen y de los propios nombres de los archivos no deben contener espacios en

blanco. Esto incluye la ruta de acceso a la instalacin de Arduino. Si usted es

un usuario de Windows, en particular significa que usted tendr que volver a
instalar Arduino si debe haber colocado en la norma ruta de instalacin c: /
Archivos de programa / arduino-1.0.5. 4.2.2 Concepto de Makefile El makefile
tiene un concepto muy simple. Una lista de directorios de cdigo fuente es el
punto de partida de todos. Todos de estos directorios se buscan archivos de C y
C ++. Los archivos encontrados se compilan y vinculados con el Core.a.
biblioteca Arduino Pasos de procesamiento de correos crean los ficheros
binarios como se requiere para la carga a la placa Arduino. An, permisos regla
final opcional para cargar el cdigo binario para la placa Arduino. Si su
aplicacin hace uso de la comunicacin USB con Serial todo lo que todava
tiene que hacer en un sistema Windows para hacer su aplicacin visiblemente
correr es un ALT-TAB para cambiar a la (abierta) Arduino IDE y un Ctrl-Shift-ma
abrir la ventana de la consola. Por el lado de salida de la compilacin, por el
bien de la simplicidad del makefile, la estructura de carpetas de la cdigo
fuente no se conserva. Todos los productos de compilacin (* .o, entre ms) de
una aplicacin RTuinOS son recogido en una carpeta de salida nica dedicada a
esta aplicacin. Esta es la razn, por qu nunca debe haber dos archivos de
origen de mismo nombre. Incluso myModule.c y myModule.cpp llevara a un
enfrentamiento. En el IDE de Arduino el core.a biblioteca es parte del cdigo
fuente del boceto. Se reconstruy a partir de cdigo fuente despus de un
limpio. El makefile RTuinOS tambin contiene las reglas para construir core.a
pero lo considera una esttica parte del software, que es de ninguna manera
en desarrollo. Va a ser construido si no es hasta al fecha, pero que va a ni se
elimina y reconstruida en caso de una reconstruccin (es decir, blanco limpio) y
ni su acumulacin depende de la configuracin de compilacin. Como se ha
dicho, la compilacin es controlada principalmente por una lista de directorios
de cdigo fuente. Esta lista es cacin mentado como valor de macro srcDirList.
El valor por defecto es tener dos directorios: El cdigo fuente RTuinOS cdigo
del directorio / RTOS y un segundo directorio, variable. Este directorio se
encuentra en el cdigo / aplicaciones, pero su nombre es proporcionado por
macro APP. Esto le permite seleccionar una aplicacin para la compilacin
simplemente indicando APP = myRTuinOSApplication en la lnea de comandos
de make. Si su aplicacin requiere algo ms que un simple directorio, plana
para administrar todos sus archivos de cdigo fuente, puede seguir utilizando
el makefile. El makefile conoce una especie de "devolucin de llamada". Si est
presente, posea una aplicacin fragmento makefile se lee antes de hacer la
compilacin y vinculacin. Este fragmento makefile puede anular o 3 Despus
de la instalacin, tipo hacen -version para averiguarlo.
Pgina 33
4.2. El Makefile 33 DEBUG #ifdef / * Algunos auto cdigo -Diagnstico * / S
erial. print ("reserva de pila actual:"); S erial. println (RTOS getStackReserve
(IDX MI TAREA)); si (RTOS getTaskOverrunCounter (IDX MI TAREA, / * DoReset

* / true)! = 0) doBlinkLED (3 veces / * * /); #endif Listing 4.2: Uso del

preprocesador cambia apoyar diferentes configuraciones de compilacin
ampliar el valor por defecto del archivo MAKE srcDirList variable. Especifique
diferentes carpetas o simplemente aadir un poco. El fragmento se busca por
nombre: Tiene que ser llamado <appName> .mk, donde <appName> es el
valor del makefile APP variable. Estructura de carpetas El makefile est
organizado en diferentes archivos. El punto de entrada es la GNUmakefile
archivo. Este nombre de archivo evita la necesidad de utilizar el interruptor de
lnea de comandos -f de la herramienta make <makefileName> y evita
conflictos mimbres otros derivados, incompatibles de maquillaje. Archivo
GNUmakefile slo contiene algunos ajustes comunes a todas las aplicaciones
RTuinOS. Aqu, lo hara por ejemplo, encontrar la configuracin correcta para el
puerto COM por defecto que se utilizar para la carga del software compilado
(consulte 4.2.5 tambin).Despus de leer estos ajustes, el
compileLinkAndUpload.mk makefile "ejecutable" se lee. Se encuentra en el
makefile subcarpeta. Es a su vez se basa en algunos sub-rutinas, que se
implementan en ms incluido fragmentos makefile. Todos ellos se encuentran
en la misma sub-carpeta makefile. 4.2.3 Configuraciones de compilacin El
makefile compatible con diferentes configuraciones de compilacin. En el nivel
makefile, una configuracin no es nada otra cosa que un conjunto de macros
del preprocesador de C., que se transmite al compilador. El significado de la
configuraciones es completamente transparente para el makefile y slo
depende del uso del preprocesador macros en el cdigo fuente C. Dos
configuraciones estn predefinidas (y utilizados por el cdigo fuente RTuinOS) y
cualquier nmero adicional de configuraciones pueden ser creados por una
simple extensin del archivo MAKE. Las configuraciones estndar se llaman
DEBUG y produccin. DEBUG define el prepro- C procesador DEBUG macro y
PRODUCCIN configuracin define las macros de preprocesador C
PRODUCCIN CIN y NDEBUG. Nuestra recomendacin es colocar un cdigo de
auto-diagnstico adecuado en la C / C ++ cdigo fuente, que est rodeado de
interruptores preprocesador. Esto incluye salida de diagnstico utilizando el
Serial.println, la comunicacin USB con la mquina de Windows, que es
particularmente til durante el desarrollo y fase de prueba, pero por lo general
no se requiere de una verdadera aplicacin de la placa Arduino. Un ejemplo
puede ser encontrado en el listado de 4,2. Un ejemplo especfico de dicho
cdigo es la macro ASSERT, que se expande a nada si no es DEBUG definida
(como en la produccin de configuracin), pero que los dobles controles
algunas condiciones de cdigos invariables durante el desarrollo, cuando se
utiliza DEBUG configuracin. Por favor, ver [5]. El cdigo RTuinOS s hacen uso
intensivo de ASSERT con el fin de informar de los errores ms probables en la
configuracin de depuracin. La configuracin es elegido por el valor de la
makefile CONFIG variable. El valor por defecto es DEBUG pero esto puede
alterarse en la lnea de comandos del archivo MAKE; por favor, encontrar un

ejemplo: hacer -s APP = myFolderName CONFIG = PRODUCCIN COM_PORT =

COM6 carga
Pgina 34
34 CAPTULO 4. ESCRIBIR UN RTUINOS APLICACIN 4.2.4 Seleccin de la placa
Arduino La plataforma de destino se selecciona como valor de
targetMicroController macro en el makefile. Sin embargo, no todas las placas
Arduino estn soportados por la implementacin de RTuinOS. Si selecciona un
micro controlador, que todava no es posible, que se ejecutar en las directivas
de error en el cdigo fuente. Por favor, consulte a la seccin 4.7 para ms.El
makefile no ha sido probado con cualquier placa Arduino distintas de la Mega
Arduino 2560. Por favor, tenga en cuenta que los cambios adicionales en el
archivo MAKE podran ser necesarias: Diferentes controladores pueden requerir
diferentes opciones de lnea de comandos del compilador, enlazador y
herramienta flash. Estas diferencias an no se prevn por el makefile. Es
necesario volver a revisar todas las lneas de la receta, que normalmente se
componen usando macros como targetMicroController, CFLAGS y LFLAGS.
Puede utilizar el Arduino IDE para averiguar, que las lneas de comandos son
apropiados en su especfica medio ambiente. En el men de archivo del IDE se
puede navegar al dilogo de propiedades. Aqu, usted debe comprobar la salida
detallada tanto, la compilacin y carga. Ahora seleccionar, construir y enviar
uno de los bocetos de muestra en el IDE. Copie el contenido de la ventana de
salida de la IDE y pegarlos en un texto editor. Usted encontrar las lneas de
comandos apropiados para todas las herramientas. Hay un pit-cada: Al
ejecutar la herramienta Flash avrdude el Arduino IDE utiliza un protocolo que
desafortunadamente requiere un comando de restablecimiento adicional,
preparatorio. Este protocolo trabaja con el makefile slo si se pulsa el botn de
reinicio en breve antes de ejecutar avrdude, que es al menos un inconveniente
si no inaceptable. El makefile utiliza un protocolo muy similar, que funciona
bien y no requiere el restablecimiento. Coloque -cWiring en la lnea de
comandos de avrdude lugar de -cstk500v2. 4.2.5 Seleccin del puerto USB El
puerto USB (o COM) que se utiliza para la conexin entre el PC y la placa
Arduino tiene que ser conocido por la regla, que carga (y los flashes) la
aplicacin compilado y vinculado. Se puede especificar el puerto como parte de
la lnea de comandos del archivo MAKE (tipo por ejemplo COM_PORT = COM6).
Sin embargo, en su entorno especfico que probablemente va a terminar con la
siempre misma designacin del puerto, por lo que podra ser til para elegir
esta designacin de puerto por defecto del makefile. Busque la inicial
asignacin de PUERTO COM macro en el makefile. 4.2.6 Deficiencias del
Makefile Inseguro Reconocimiento de Dependencias El makefile incluye el
compilador genera archivos * .d. Los archivos * .d contienen normas makefile,
que describen las dependencias de archivos de objetos en archivos de origen.
Se crean como "efecto secundario" de la compilacin de un archivo de origen.
Esto significa, que no estn presentes en el comienzo y despus de un limpio y

no son vlidos despus de cdigo o configuracin de la fuente cambia que

tienen un impacto en el rbol real de anidado incluyen declaraciones.
Particularmente en este ltimo caso el reconocimiento de dependencias no es
fiable y la resultado de la compilacin podra ser malo. Por otra parte, si un
archivo de cabecera se cambia el nombre o elimina entonces es problemtico,
que an se hace referencia a las reglas de los archivos * .d. Haga aborta con un
mensaje como: "No sabes cmo para hacer. . . .h " En consecuencia, en todos
los casos de cambios no triviales de macros del preprocesador e incluir
declaraciones o al cambiar el nombre o eliminar encabezado archivador debe
llamar siempre las reglas para reconstruir la aplicacin. g ++ frente gcc El
makefile compila todos los archivos de origen, independientemente de su
extensin de nombre de archivo con g ++, es decir, la fuente cdigo siempre
es tratado como un archivo de C ++. Esta es una decisin extraa un poco,
que ha sido adoptado por la Arduino original IDE, que se comporta de la
misma. No hay inconveniente tcnico de hacerlo, el generado cdigo de
mquina es la misma. El problema ms bien es que uno escribe con facilidad y
sin pretenderlo C ++ declaraciones en un archivo que cree que es un archivos
de origen C. El compilador no se quejar. RTuinOS
Pgina 35
4.3. CONFIGURACIN DE LA HORA DEL SISTEMA 35 s debe ser el cdigo fuente
en C limpio y puede ser compilado con gcc tambin. (Es trivial para cambiar el
makefile para hacerlo; hay reglas de todos modos separados para archivos *
.c .cpp y *). Sin embargo, cuando se compila * .c como C y * .cpp Como C ++
hay que utilizar correctamente la declaracin "C" extern, al acceder a las
cabeceras C de C ++ archivos. Esto no se ha hecho en las muestras RTuinOS
mientras seguamos el estilo Arduino. 4 4.3 Configuracin de la hora del
sistema Un elemento central de RTuinOS es su hora del sistema. Este tiempo es
por ejemplo, el parmetro de una orden de suspender si una tarea quiere
esperar hasta un punto especfico en el tiempo o por un tiempo especfico.
Muchas de las operaciones en RTuinOS y su acuerdo de cdigo de la aplicacin
con la hora del sistema. Por lo tanto, hemos decidido hacer la tipo de
implementacin de la hora del sistema sujeto a la configuracin de la
aplicacin; tienes que personalizar el tipo de copia de su solicitud de
rtos.config.h. En muchas situaciones un corto un byte nmero entero ser
suficiente, pero no en general. La intencin de esta seccin es explicar todas
las implicaciones de la eleccin de tipo para permitirle elegir el tipo ptimo,
ms corto posible para su aplicacin. 4.3.1 La Unidad de la hora del sistema La
hora del sistema es un valor entero cclico. La unidad es el perodo de tiempo
de la interrupcin principal, la cual est asociada con la hora del sistema. Cada
interrupcin de reloj voluntad el tiempo en una unidad. Si el caso de uso de
RTuinOS es una programacin tradicional de las tareas regulares de diferentes
prioridades es una buena prctica para elegir el perodo de tiempo de la tarea
peridica ms rpido como unidad de la hora del sistema. Esto produce el

mejor rendimiento, o la sobrecarga del sistema menos respectivamente. Pero,

en general la unidad de la hora del sistema no importa con respecto a la
funcin de RTuinOS y el tiempo incluso no necesita ser regular. Todas las
operaciones relacionadas con el tiempo utilizan el tic de la hora del sistema
como unidad. El tiempo de retardo de RTOS retraso puede para especificarse
ejemplo slo en mltiplos de esta unidad. La aplicacin requiere la resolucin
de estos tiempo condiciones determinarn la duracin tic de la hora del
sistema. (Y su aplicacin configurar el conducir fuente de interrupcin en
consecuencia.) Con respecto a la sobrecarga del sistema esta resolucin debe
ser elegido tan bajo como aceptable. Cada interrupcin del reloj provoca al
menos una parada de operacin de restauracin de la completa Contexto de la
CPU y esto se convierte en una carga de la CPU significativa si la duracin tic
est relacionado o incluso por debajo de 1 ms. 4.3.2 Recomendado Timer Tic
para tareas regulares Si procede y si la aplicacin utiliza tareas regulares le
recomendamos para elegir el tic de temporizador idntica duracin con el
tiempo de perodo de la tarea de ayuno. Ahora cada interrupcin realmente
causar una tarea cambiar y no hay (intil) los gastos generales slo para el
reloj del tiempo. La resolucin de tiempo es idntica a la perodo de la tarea.
Esto significa que la tarea ms rpido apenas puede operar con tiempos de
espera de, por ejemplo si necesita esperar a que los acontecimientos escritos
por otras tareas. La nica condicin de tiempo de espera se puede utilizar es
declarar la prxima regulares a su debido tiempo. No obstante, razonable
cdigo de manejo de errores sigue siendo posible que el cdigo de tarea puede
distinguir entre convertirse en activo debido al evento recibido, el tiempo de
espera o porque es su debido tiempo normal. 4.3.3 Lmite superior del perodo
de la tarea Hora El tiempo de perodo de la tarea de una tarea regular no debe
ser mayor que la mitad del mximo del sistema tiempo. En la prctica, esto es
una limitacin slo si el uso del tiempo de 8 bits. Ahora, el parmetro de una
llamada a rtos suspendTaskTillTime no debe superar los 127. La tarea de
reconocimiento invadido puede fallar si esta regla es hecho caso omiso. Un
reconocimiento tarea invadido se implementa en RTuinOS para apoyar el caso
de uso de las tareas regulares. La sistema decide en una tarea invadido si una
tarea se refiere a las exigencias del temporizador absolutos que se reanud en
la pasado. La implementacin utiliza operaciones firmadas, que se someten a
un desbordamiento aritmtico en el medio de la gama binaria del tipo de datos.
Aqu es donde la limitacin viene. 4 Suponemos que los diseadores Arduino
decidieron as porque queran disburden los usuarios de entendimiento este
tipo de cosas y de utilizar extern "C".
Pgina 36
36 CAPTULO 4. ESCRIBIR UN RTUINOS APLICACIN He aqu un ejemplo de la
situacin normal: La duracin tic de la hora del sistema es de 1 ms y un
habitual tarea de 100 ms perodo de tiempo se implementa. La hora del
sistema tiene 8 bits. Un bucle infinito se implementa, que utiliza mientras

(rtos_suspendTaskTillTime (100)) como siempre verdadera condicin. Teniendo

en cuenta la ejecucin de la tarea tarda entre 45 y 67 ms el cdigo RTuinOS
encontrar con seguridad el prximo exigieron su momento entre el 55 y 33 ms
en el futuro. No va a ver una tarea arrasada como 100-45 y 100-67 ambos es
positivo en el elegido 8 bits aritmtica firmados. Dado un mal demasiado
tiempo, la ejecucin de tareas de, por ejemplo 102 ms RTuinOS sera reconocer
una tarea invadidos como 100-102 es negativo. Asumamos que el perodo de
tiempo de la misma tarea normal sera cambiado a 180 ms. Hay
definitivamente hay riesgo de entrar en excesos de tareas. Sin embargo, al
final de la ejecucin de la tarea, cuando la siguiente hoja de vida tiempo se
exige que depende si esto exige tiempo se ve en el futuro o en el pasado. Si la
ejecucin tom 67 ms el tiempo restante para suspender la tarea es 180-67 =
113, que es un nmero positivo, mientras 180-45 = 135 en el caso del tiempo
de ejecucin de la tarea ms corta se interpreta como el nmero negativo -121
en el elegido 8 bits con signo aritmtica. Para RTuinOS el tiempo de
reanudacin demandada es aparentemente en el pasado y que decida sobre
una sobrecarga de tareas. Atencin, el falso decisin sobre una tarea invadido,
que en realidad no la supere, es mucho peor que simplemente un incremento
del contador de diagnstico (ver rtos getTaskOverrunCounter). Si el tiempo de
reanudacin exigido de una tarea se encontr que en el pasado no se suspende
esta tarea, pero hizo vencimiento inmediato. Nuestro ejemplo tarea no se hizo
debido (y activos) cada 180 ms, pero irregular en funcin de su ejecucin real
tiempo. Esto es culpa de verdad! Para evitar este problema, el perodo de
tiempo de las tareas regulares no debe exceder de la mitad de la gama de los
elegidos temporizador del sistema. Si un perodo de la tarea de 127 tics a
demasiado poco lo que tendr que elegir el tiempo de 16 bits, lo que produce
sobrecarga de curso ms del sistema. Como una implicacin simple para
sistemas que aplican tareas regulares, la relacin de tiempos de periodo lento
y tarea ms rpido est limitada por medio del intervalo del temporizador de
sistema elegido. Si decide implementar tareas regulares de ejemplo 10 ms, 100
ms y 1.000 ms perodo de tiempo, esto podra ser manejados con una t uint8
(relacin 1: 100). Si quieres tener una tarea adicional de 1 ms, uint8 t ya no
baste (relacin 1: 1000), es necesario al menos uint16 t. (Uint32 t es
probablemente nunca til). 4.3.4 no reconocido de tareas Los desbordes
Cuanto ms corto sea el tipo elegido de la hora del sistema mayor es la
probabilidad de no reconocer los excesos de trabajo en la aplicacin de las
tareas regulares: Debido al carcter cclico de la definicin de tiempo de un
tiempo en el pasado es visto como un tiempo en el futuro si es de ms de la
mitad el nmero mximo nmero entero. Esto conduce a la decisin
equivocada si hemos invadido una tarea o no. Vea el ejemplo: Tipo de datos
sea uint8 t. Una tarea se implementa como tarea regular de 100 unidades
perodo de tiempo. Por lo tanto, al final del cdigo funcional suspende en s con
el tiempo incrementar 100 unidades. Digamos que haba sido reanudado
tiempo 123. En la operacin normal - no hay sobrecarga de tareas - que va a

terminar por ejemplo 87 tics ms tarde, es decir, en 210. La demandada

prxima vez currculum es 123 + 100 = 223, que es visto como 13 en el futuro.
Si la ejecucin de la tarea era demasiado de largo y termin por ejemplo
despus de 110 tics, la hora del sistema fue de 123 + 110 = 233. El tiempo de
reanudacin exigido 223 como se ve en 10 tics en el pasado y una sobrecarga
de tareas se reconoce. 5 Un problema aparece en la tarea excesiva
sobrecostos. Si la ejecucin por ejemplo, haba 230 tics el momento actual era
de 123 + 230 = 353 - 97 o debido a su carcter cclico. El tiempo de
reanudacin exigido 223 es 126 tics por delante, que se considera un tiempo
futuro - Que se haya sobrepasado tarea es reconocida. 6 El problema aparece
si el retraso dura ms de la mitad del tiempo de ciclo de la hora del sistema.
Con uint16 t este problema se vuelve insignificante. 4.3.5 Resumen He aqu un
breve resumen de la hora del sistema de tipo de datos de discusin: Elija el
tipo de datos de la hora del sistema lo ms corta posible 5 Cuando se reconoce
una sobrecarga de tareas la tarea vencimiento inmediato. La llamada tarea no
se omite, pero hizo algo demasiado tarde. 6 Una llamada de la tarea se ha
omitido en silencio y el siguiente es oportuna nuevo.
Pgina 37
4.4. CONFIGURACIN DEL SISTEMA interrupcin de temporizador 37 Elegir la
duracin del temporizador tic mientras aceptable. Si procede hacen que sea
idntica a la perodo de tiempo de la tarea ms rpido La duracin del
temporizador tic es la resolucin de las operaciones de tiempo de espera El
tiempo de perodo de la tarea de una tarea regular no debe exceder de la
mitad de la gama de la hora del sistema elegido tipo de datos.
Reconocimientos de tareas invadido falsas y resultantes calendario tarea mal,
probablemente sera la consecuencia El mximo razonable esperar tiempo
una tarea podra exceder su nominal perodo de tiempo no debe ser ms de la
mitad del rango del tipo de datos de tiempo de sistema elegido. De lo contrario
una sobrecarga de tareas no lo hara ser reconocidos como tales Elegir el tipo
se hace con RTOS macro DEFINE TIPO DE TIEMPO DEL SISTEMA, consulte [4].
4.4 Configuracin del sistema de interrupcin de temporizador La rutina de
servicio de interrupcin (ISR), que los relojes la hora del sistema y el que
realiza todas las acciones relacionadas como la reanudacin de las tareas, que
estn a la espera de un evento de temporizador, es un elemento central de la
aplicacin de RTuinOS. La aplicacin deja sin embargo abierta, que evento de
hardware real, es decir, que interrumpen fuente, se asocia con la rutina de
servicio. En la configuracin estndar, la fuente de interrupcin es la evento
rebasamiento del temporizador 2 (TIMER2 OVF), pero esto se puede cambiar
fcilmente por la aplicacin. En el entorno de AVR, un ISR se implementa
utilizando el ISR macro como prototipo de funcin. La fuente de interrupcin
especfico est asociado con el ISR por el parmetro de la macro. El nombre de
la interrupcin fuente se indica. Existe un microcontrolador lista predefinida,
dependiente de fuentes de interrupcin disponibles, por favor consulte [6],

seccin 14. En RTuinOS el parmetro de macro ISR, el nombre de la fuente de

interrupcin, se implementa como otra macro RTOS ISR SISTEMA TIMER TIC,
que se define en la solicitud archivo de configuracin de propiedad [4].
Simplemente cambiando la definicin de la macro cualquier otra fuente de
interrupcin puede ser elegido. Por lo general, se necesitan unas pocas
operaciones relacionadas hardware para hacer un dispositivo perifrico de una
interrupcin til fuente. En el caso de los temporizadores, las condiciones de
tiempo han de ser declarado (con qu frecuencia para ver una interrupcin); y
en general, la mayora de los perifricos requieren para establecer una llamada
de interrupcin bit de mscara para permitir como interrupcin fuente. La
configuracin estndar RTuinOS utiliza temporizador 2 como est en la
configuracin estndar de Arduino. Ar- duino utiliza este temporizador para la
salida PWM y ha elegido los ajustes apropiados. Lo nico RTuinOS aade a la
configuracin del temporizador es establecer el bit de mscara de interrupcin
del evento de desbordamiento. El cuencia cuencia de la interrupcin no se
cambia, la funcionalidad Arduino PWM no se ve afectada en absoluto. La
Configuracin Arduino provoca un evento de desbordamiento sobre cada 2 ms.
7 Este es, pues, el sistema estndar reloj de RTuinOS. La configuracin de
hardware de la fuente de interrupcin se realiza en los RTOS funcin void
enableIRQTi- Mertic. La funcin se implementa como una funcin dbil. En la
terminologa del compilador GNU esto significa que la aplicacin puede
redefinir la misma funcin. En lugar de obtener un error de vinculador mensaje
("smbolo doblemente definido") el enlazador descarta la aplicacin RTuinOS y
en su lugar poner implementacin de la aplicacin en el cdigo ejecutable. La
implementacin estndar se anula simplemente volver a la aplicacin de la
misma funcin en el cdigo de aplicacin. Precaucin: La firma del funcin
primordial necesita ser idntica, el atributo de tipo dbil sin embargo, no debe
ser utilizado de nuevo. La aplicacin intentar poner todas las operaciones
para configurar la fuente de interrupcin seleccionada por RTOS macro SISTEMA DE ISR TIMER TIC en la implementacin de la funcin y el
temporizador 2 ser como antes estar en el entorno estndar de Arduino. 7 El
valor exacto se puede encontrar como una macro en el archivo de
configuracin RTuinOS [4]. Cambio de la definicin de este macro pertenece a
las adaptaciones de cdigos, que son necesarios si la interrupcin del reloj del
sistema se reconfigura.
Pgina 38
38 CAPTULO 4. ESCRIBIR UN RTUINOS APLICACIN Otra modificacin del
cdigo, relacionado tiene que ser hecho por el programador de la aplicacin. La
funcin de par rtos entran inhibe / LeaveCriticalSection y vuelve a activar todas
esas interrupciones, que pueden llevar a una tarea cambiar - que la
interrupcin del temporizador evidentemente pertenece (ver seccin 3.8 ). Si
cambia la interrupcinfuente, es decir, si se modifica el valor de la macro RTOS
ISR SISTEMA TIMER TIC, que tendr que modificar el cdigo de estas funciones

en consecuencia. Se implementan como macros en la aplicacin de propiedad

archivo de configuracin [4] y por lo tanto se puede cambiar fcilmente. Por
favor, encontrar un ejemplo de una re-configurado temporizador del sistema
como TC05 ejemplo de cdigo en los RTuinOS distribucin bucin. 4.5 Uso de
interrupciones de aplicacin RTuinOS admite dos interrupciones de aplicacin.
La aplicacin configura la fuente de interrupcin de hardware y lo asocia con la
rutina de servicio de interrupcin ya existente. El ISR en s no debe ser nunca
cambiado. Se establece un evento predefinido especfico, que est relacionada
con la interrupcin de la aplicacin. Ajuste de la evento se realiza como
cualquier tarea podra hacer con el RTOS sendEvent funcin API. El caso de uso
previsto es que su aplicacin tiene una tarea que cclicamente se suspende a la
espera de este evento relacionado interrupcin y que es, por tanto, despertar
cada vez que se produce la interrupcin. Esta tarea es que el controlador real,
que implementa todas requerida operaciones para hacer el procesamiento de
datos. La solicitud de interrupcin 0 est habilitado en su aplicacin girando el
interruptor RTOS preprocesador - USO APPL INTERRUPCIN 00 de RTOS
FUNCIN OFF para RTOS funcin. Ahora, la relacionada ISR se compilar y uno
de los eventos de propsito general RTuinOS 'se cambia el nombre en RTOS
EVT ISR - USUARIO 00 que indica el significado especfico de este evento en
particular se pone; nunca debe ser fijada por una corriente tarea. El ISR
existente se asocia con la fuente de interrupcin que demanda su aplicacin
por medio de macro RTOS ISR USUARIO 00. El valor de esta macro se establece
en el nombre de la fuente de interrupcin. Una tabla de fuentes de interrupcin
disponibles se encuentran en el manual de su controlador especfico, ver por
ejemplo [6], seccin 14, de el microcontrolador de la placa Arduino Mega. El
interruptor RTOS USO APPL INTERRUPCIN 00 y la macro USUARIO RTOS ISR 00
se encuentran en el archivo de configuracin de la aplicacin de propiedad [4].
La fuente de interrupcin asociado debe configurarse para disparar eventos de
interrupcin. Muy a menudo, la fuentes de interrupcin son dispositivos
perifricos, que tienen algunos registros de hardware que se deben configurar.
Por ejemplo, una interrupcin de temporizador normal requerira para
establecer el modo de funcionamiento del temporizador / contador dispositivo,
el rango de contaje y la condicin, lo que desencadena la interrupcin. Usted
tendr que consultar su Manual de CPU para averiguarlo. Todos los ajustes
necesarios para configurar la alarma se implementan en la devolucin de
llamada funcin RTOS enableIRQUser00. rtos enableIRQUser00 no tiene una
implementacin por defecto, un error de vinculador ocurrir si no lo hace
implementarlo en el cdigo de aplicacin. Precaucin: Es invocado por el
cdigo de inicializacin RTuinOS a una momento en el que todas las tareas ya
estn configurados (completada la instalacin) y cuando el temporizador del
sistema de RTuinOS ya est en marcha. Esto significa que todas las
consideraciones multitarea ya surtan efecto. Necesitas anticipar interruptores
de trabajo y las condiciones de carrera resultantes. En realidad, la invocacin
de RTOS enableIRQUser00 se hace temprano desde dentro de la tarea vaca,

justo antes de bucle se ejecuta la primera vez. 8 Considere la posibilidad de

utilizar La funcin par rtos entran / LeaveCriticalSection para solucionar todos
los problemas posibles. Cuando utilice la aplicacin interrumpe otra, la
modificacin del cdigo relacionado tiene que ser hecho por la aplicacin
programador de cationes. La funcin par rtos entran inhibe /
LeaveCriticalSection y vuelve a activar todos los interrupciones, que pueden
llevar a un cambio de tarea - que pertenece evidentemente su interrupcin
(ver seccin 3.8) .Las funciones necesitan para inhibir adicionalmente y vuelva
a activar la alarma de que usted elija como fuente. Ellos son implementado
como macros en el archivo de configuracin de la aplicacin de propiedad [4] y
por lo tanto se puede cambiar fcilmente. 8 Tenga cuidado diseo de su
aplicacin: Si se define un conjunto de tareas, que no deja ningn tiempo para
ideling su aplicacin las interrupciones no se pondrn en marcha de forma
segura. Tome un conjunto de tareas round robin siempre debido a modo de
ejemplo. Considere para iniciar las tareas con un retraso.
Pgina 39
4.6. USO DE BIBLIOTECAS ARDUINO 39 RTO enableIRQUser00 vacos (sin valor)
{ / * Inhibir todas las interrupciones correspondientes a tareas de conmutacin.
* / rtosenter C rtitical S eccin (); / * Configurar el dispositivo perifrico para
producir su solicitud interrumpir, pero no permiten la interrupcin en su
mscara de interrupcin registrarse todava. * / . . . / * Vuelva a activar todas
las alarmas pertinentes tareas de conmutacin. Desde que ha modificado la
implementacin de rtosleave C rtitical S eccin Esto tambin establecer el bit
correspondiente en el registro de mscara de su equipo perifrico. * / rtosleave
C rtitical S eccin (); } Listing 4.3: Inicializacin de una interrupcin aplicacin
Por favor, considere que LeaveCriticalSection rtos implementa en parte lo que
RTOS enableIRQUser00 es ex- pera que hacer, consulte la lista de 4.3 por
ms.La segunda aplicacin disponible interrupcin 1 se tratar en consonancia,
slo hay que reemplazar el ndice 00 de 01 en todos los nombres de las
funciones y macro se refiere antes. 4.6 Uso de Arduino Bibliotecas El mayor
problema con RTuinOS es la falta de bibliotecas multitarea adecuados. No es
por lo general prohibido el uso de las bibliotecas todava Arduino pero esto trae
consigo algunos riesgos. Por alguna razn una funcin de biblioteca existente
no se puede utilizar as como as: En particular, cuando dirigindose a los
dispositivos de hardware, pueden existir condiciones de tiempo estrictos. En un
RTOS, cuando una tarea es suspender por un tiempo impredecible, esto puede
hacer un tiempo de espera de la operacin y falle. Sin embargo, incluso en un
sistema de un solo subproceso, la velocidad de ejecucin de cdigo no es
totalmente predecible ya que depende de configuracin del compilador e
interrupciones de todas las interrupciones del sistema. En particular, si el
hardware que sirve dispositivo se realiza en una tarea de alta prioridad la
discontinuidad de la ejecucin de cdigo no debe ser mucho peor en
comparacin con un nico sistema de asignacin de tareas que un tiempo de

espera se convierte en un grave riesgo. En consecuencia, el tiempo de cdigo

crtico no debe ser colocado en la tarea de ralent. Funciones de biblioteca
existentes podran utilizar los datos estticos, es decir, datos que no es local a
la invocacin de la funcin. Esto puede ser de datos definidas usando la
palabra clave registros de hardware estticas, sino tambin, lo que s existen
slo en una sola instancia, global. En este caso la invocacin arbitraria de
diferentes tareas seguramente producir resultados imprevisibles, incluyendo la
posibilidad de un accidente. Como la mayora de las funciones de biblioteca de
Arduino se ocupan de entidades de hardware, es muy probable que pertenecen
a este grupo. El uso de las libreras de Arduino es todava posible si sus tareas
de manera cooperativa comparten las entidades globales. Si hay por ejemplo,
slo una tarea que sirve a las salidas PWM y que permite a las dems tareas a
acceder slo indirectamente - a travs de la aplicacin propietaria,
implementado de forma segura la comunicacin entre tareas. Un ejemplo
especfico es la serie objeto global, que realiza alto nivel, la comunicacin
corriente basado a travs de USB. Obviamente hay ninguna posibilidad de
acceder a este canal en una, de manera arbitraria sin control por varios tareas.
Sin embargo, si slo un nico tareas hace la salida de la consola a la vez que
trabaja muy bien, aunque esta tarea es la ms fuertemente interrumpido tarea
vaca. Por experiencia, de serie es bastante tolerante contra discontinuidades
temporales del cdigo que invoca y se puede utilizar para propsitos de
depuracin durante el desarrollo de la aplicacin. Por otra parte, de serie se
implementa como funcin de bloqueo; la llamada de ejemplo println
devoluciones solamente despus de todo personajes han sido procesados. Por
lo tanto el objeto se puede pasar con xito en de una tarea a
Pgina 40
40 CAPTULO 4. ESCRIBIR UN RTUINOS APLICACIN otro luego de haber estado
un println. Cualquier tarea se hace a su vez de escribir un mensaje. Esto se
puede hacer por una mutex o no preferente, la multitarea cooperativa. Cuando
se ejecuta la funcin de configuracin RTuinOS ', sin multitarea est activo
todava. Aqu usted puede utilizar el Bibliotecas Arduino sin ms. En particular,
puede inicializar todos los puertos y dispositivos necesarios y la comunicacin
con Serial. Es similar a la biblioteca LiquidCrystal. La aplicacin es bsicamente
hilo-seguro; La biblioteca se puede utilizado. Por supuesto, las tareas deben
implementar cooperativamente una exclusin mutua cuando se accede a la
pantalla. El cdigo fuente contiene algunos retrasos hardware requerido, que
son, por supuesto, no se han aplicado RTOS conforman y que podra ser
sustituido por rtos demora como una mejora de la biblioteca para RTuinOS. Se
implementa utilizando delayMicroseconds de funcin biblioteca de Arduino El
retraso, que se basa en una CPU consume bucle de espera. Esto no significa
necesariamente que la tarea interruptores se inhiben o retrasan; evite utilizar
la biblioteca en una tarea de alta prioridad. No obstante, el tiempo de CPU se
pierde; estas funciones llamadas plantean la carga de la CPU sin necesidad. 9

La mayora de los retrasos significativos, la CPU consume ocurrir en la

inicializacin de la pantalla y esto puede por hacer en la configuracin antes de
realizar mltiples tareas que realmente sucede. Los nicos otros retrasos
indeseados se encuentran en Los comandos de control claro y casa - si stos se
evitan o si su prdida de tiempo de CPU no causa dolor no hay preocupacin de
utilizar LiquidCrystal de tareas RTuinOS. A pesar de todo, el uso de una
biblioteca desarrollada para una sola tarea en un entorno multi-tarea sigue
siendo un riesgo, que no debe ser tomada en un sistema de produccin. En un
sistema de produccin, las necesidades de la funcin de la biblioteca ser
revisado y modificado tal vez antes de usarlo. Afortunadamente, todo el cdigo
de Arduino est disponible como fuente cdigo, por lo que una revisin de
cdigo se puede hacer. 4.6.1 Los cambios de la funcin principal de Arduino El
main.cpp archivo del boceto Arduino estndar ha sido reemplazado por main.c
de RTuinOS. La aplicacin mentacin de la funcin principal contenida es casi el
mismo. El boceto norma finalmente entra en un corto, bucle infinito, que invoca
repetidamente bucle "tarea-funcin" de la aplicacin. Lo mismo bucle contina
existir en RTuinOS (aunque se ha movido hasta el final de RTOS initRTOS) con
un cambio importante: En el boceto estndar del bucle contiene el siguiente
cdigo, que se ejecuta de forma alterna con la funcin bucle: si
(serialEventRun) serialEventRun (); Esta funcin implementa un tipo de
despachador de caracteres recibidos a travs de los canales serie. Los clientes
pueden definir sus manejadores por razones imperiosas "dbiles" manejadores
predeterminados vacas. Depende de los controladores opcionales si esto
seguira trabajando bien con el programador de tareas RTuinOS. Decidimos no
dejar la llamada en el cdigo RTuinOS. Quien conoce a necesitar puede
considerar colocar la declaracin en funcin del bucle su aplicacin RTuinOS.
Ahora, el comportamiento es el mismo que en el boceto estndar - adems de
todo el diferencias obvias, dado interruptores de tareas. 4.7 Apoyo a las
diferentes placas Arduino RTuinOS se ha desarrollado sobre una placa Arduino
Mega 2560 y este es el nico tablero apoyado hasta lejos. Hay algunas
dependencias obvias en el microcontrolador: El tamao del contador de
programa es de tres bytes para un Atmega2560 pero slo dos bytes por alguna
otra derivados La disponibilidad de dispositivos perifricos depende del
microcontrolador y, adems, los nombres de los registros puede variar entre
los micro controladores, incluso para el mismo perifrico. 9 Funcin de retardo
de retardo de Arduino es diferente. Se compara el tiempo de retorno deseado
con la hora del sistema mundial, que es actualizado por una interrupcin. Si
una tarea usando retraso es interrumpida por otras tareas y si el tiempo que se
vuelva a activar de nuevo es por delante del tiempo de retorno deseado no va
a seguir bucle y consumir la CPU como delayMicroseconds hara.
Pgina 41
4.7. APOYO DE placas Arduino DIFERENTES 41 La aplicacin de RTuinOS utiliza
un interruptor preprocesador basado en la macro AVR Atmega2560 de la

biblioteca AVR cualquier lugar tenemos una dependencia plataforma tan obvia.
El caso ms es "aplicacin mentado "como directiva error para que usted est
apuntando directamente a todos estos lugares de cdigo simplemente
haciendo un compilacin con otro microcontrolador seleccionado en el
makefile. Todas las ubicaciones de cdigo, donde se coloca una directiva de
este tipo de errores son declaraciones fcil y sencillo de modificar. Usted
encontrar una cierta direccin en los comentarios de cdigo cerca de las
directivas de error. Sin embargo, decidimos a no probar una implementacin ya
que no se prob. Desafortunadamente, hay un riesgo restante, que hay ms
dependencias de la plataforma que actualmente previsto en el cdigo. Esto
slo se puede encontrar por hacer la migracin y las pruebas. La
retroalimentacin es bienvenida. El proceso de construccin makefile
controlado depende de la placa Arduino, tambin. Un cambio obvio es el
especificacin del microcontrolador en uso al compilar el cdigo. Sin embargo,
hay ms cambios requerida en el makefile. Por favor, consulte la seccin 4.2.4
para ms.
Pgina 42
Captulo 5 Panorama Esperamos que RTuinOS se considera til como es y que
aade un poco de valor para el mundo Arduino. No obstante, somos
conscientes de que tiene sus limitaciones y que una gran cantidad de mejoras
son imaginables y algunos incluso factible. Algunas ideas y comentarios se han
recogido aqu. Las listas que contienen las tareas que vencen se implementan
como matrices de longitud fija. Todas las clases de prioridad utilizar una lista de
idntica longitud. Esto ha sido decidido slo por las limitaciones de la
compilacin constante expresiones de tiempo y macros. El cdigo se ejecutara
sin ningn cambio si la matriz rectangular sosteniendo todas las listas seran
reemplazados por una serie lineal de los punteros, que se inicializan para que
apunte a la clase-individuo arrays lineales. Esta construccin se ahorrara
espacio de memoria RAM en las aplicaciones que tienen las clases de prioridad
de difiriendo significativamente de tamao. Adems de algunos RAM
almacenada y la inicializacin menos transparente en la aplicacin lado 1 no
hay absolutamente ninguna diferencia de ambos enfoques y, por tanto, la
urgencia de este cambio no es considerado suficientemente alto como para
hacerlo realmente. Actualmente, la tarea de inactividad se describe por un
objeto adicional de la matriz de tarea - aunque carece de la mayora de las
propiedades de una tarea verdadera. Ubicacin En realidad, slo el puntero de
pila guardar y el (siempre cero) vectores de eventos recibidos estn en uso. Si
el objeto de tarea se divide en dos de tales objetos (manteniendo las
propiedades de todos tareas y la celebracin de las propiedades de las tareas
verdaderas solamente) algunos bytes de RAM actualmente desperdiciados
podran salvarse. La prioridad de una tarea podra ser cambiado en tiempo de
ejecucin si slo los arrays son lo suficientemente grandes - pero esto es de
todos modos en la responsabilidad de la aplicacin. La aplicacin es sencilla, ya

que est cerca existente cdigo. La funcin de la API se implementa como

software interrumpir similares a los comandos suspender. La tarea activa se
saca de su lista de clase y poner al final de la lista de clase especfica. La lista
longitudes se adaptarn en consecuencia. Entonces el paso normal de buscar
el debido tarea ahora ms y haciendo de este el activo pondra fin a la
operacin. rtos sendEvent sera probablemente el mejor ajuste punto de la
aplicacin inicial. Esta idea no ha sido implementado como que no vemos un
caso de uso de ella. Actualmente, el tiempo de operacin por turnos (incluido el
modo de operacin por turnos de encendido / apagado mediante el
establecimiento de la hora a 0) es predeterminado en tiempo de compilacin pero sin ninguna necesidad tcnica. Sera fcilmente posible cambiar por API
llamar en tiempo de ejecucin. Si especificamos que un cambio no afectar a la
porcin de tiempo corriendo es muy fcil como la llamada de esta funcin no
provocar un cambio de tarea. No se requiere una interrupcin de software,
simplemente escriba el recargar valor del contador de round robin en una
operacin atmica. No hay ninguna razn tcnica fuerte, por qu no debera
terminar una tarea. Por el momento la direccin de retorno de una funcin de
tarea es la direccin de reposicin del microcontrolador. Modificando
prepareTaskStack lo posible convertirse en cualquier otra direccin, por
ejemplo, la direccin de una funcin implementada similares a los comandos
de suspensin. No pondra la tarea activa en la lista de tareas suspendidas,
pero en una nueva lista de tareas terminadas. Se requiere esta lista como la
terminacin de tareas slo tiene sentido si tambin hay una oportunidad de
crear otros nuevos. La lista de tareas terminadas sera la lista libre de objetos
para reutilizar cada vez que se crea una nueva tarea 1 No nos gusta hacer la
inicializacin dinmica con un lazo y una llamada de malloc interior en un
entorno integrado. Este probablemente consumir espacio de memoria RAM
administrativa en el montn de la misma magnitud que lo que puede ser
salvado por la cambio de diseo de la estructura de datos RTuinOS. 42
Pgina 43
43 tiempo de ejecucin. Inicio de una nueva tarea en tiempo de ejecucin
significara dejar prepareTaskStack operar en un momento sin uso objeto de
tarea y para colocar el objeto en una seccin crtica en la lista de tareas
suspendidas. Como en la actualidad, la aplicacin es responsable de obedecer
el tamao de las listas, en particular, si an hay espacio en el objetivo clase de
prioridad. Dado que no queremos introducir asignacin dinmica de memoria
en la aplicacin, cualquier tarea iniciada tiene que ser pre-configurado. Se tiene
que ser decidido si en estas circunstancias de terminacin / reiniciar una tarea
tiene una gran ventaja sobre simplemente suspender las tareas existentes de
forma permanente. Independientemente de estas y muchas otras mejoras
imaginables, consideramos RTuinOS sea un completo y el sistema operativo en
tiempo real til. Sus capacidades limitadas son un comercio bien elegido con el
capacidades del sistema de destino AVR que ofrece poco espacio de memoria

RAM y CPU no abrumadora de energa. La mayora de las aplicaciones en

tiempo real, que son factibles con esta arquitectura no deben ser demasiado
exigentes para nuestro sistema y seguramente va a beneficiar de ser
construido sobre RTuinOS.
Pgina 44
GNU Free Documentation License Versin 1.3, 03 de noviembre 2008 C 2000,
2001, 2002, 2007, 2008 Free Software Foundation, Inc. Copyright
<Http://fsf.org/> Se permite la copia y distribucin de copias literales de este
documento de licencia, pero cambindolo no est permitido. Prembulo El
propsito de esta Licencia es permitir que un libro de texto, u otro documento
manual, funcional y til "Libre" en el sentido de libertad: asegurar a todo el
mundo la libertad efectiva de copiarlo y redistribuirlo, con o sin modificaciones,
de manera comercial o no. Segundo trmino, esta Licencia proporciona el autor
y el editor una manera de obtener reconocimiento por su trabajo, sin que se le
considere responsable de modificaciones realizadas por otros. Esta licencia es
una especie de "copyleft", lo que significa que los trabajos derivados del
documento deben a ellos- mismos sean libres en el mismo sentido.
Complementa la Licencia Pblica General GNU, que es un copyleft licencia
diseada para el software libre. Hemos diseado esta Licencia para usarla en
manuales de software libre, ya que el software libre necesita documentacin
libre: un programa libre debe venir con manuales que ofrezcan la mismas
libertades que el software hace. Pero esta licencia no se limita a manuales de
software; que puede ser utilizado para cualquier textual trabajo, sin tener en
cuenta su temtica o si se publica como libro impreso. Recomendamos este
Licencia principalmente para trabajos cuyo fin sea instructivo o de referencia.
1. Aplicabilidad y definiciones Esta Licencia se aplica a cualquier manual u otro
trabajo, en cualquier soporte, que contenga una nota colocada por el titular del
copyright diciendo que puede ser distribuido bajo los trminos de esta Licencia.
Tal aviso subvenciones una licencia libre de regalas en todo el mundo, sin
lmite de tiempo, el uso de dicho trabajo en las condiciones indicadas en el
presente documento. El "Documento", a continuacin, se refiere a cualquiera
de dichos manuales o trabajos. Cualquier miembro del pblico es un
licenciatario y ser referido como "usted". Usted acepta la licencia si copia,
modifica o distribuye el trabajo de cualquier modo que requiera permiso segn
la ley de derechos de autor. Una "Versin Modificada" del Documento significa
cualquier trabajo que contenga el Documento o una porcin de ella, ya sea una
copia literal o con modificaciones y / o traducido a otro idioma. Una "Seccin
Secundaria" es un apndice con ttulo o una seccin preliminar al prlogo del
Documento que trata exclusivamente con la relacin de los editores o autores
del Documento para el conjunto de documentos sujeto (o asuntos relacionados)
y cuyo contenido no entra directamente en este tema general. (Por lo tanto, si
el Documento es en parte un texto de matemticas, una Seccin Secundaria
puede no explicar nada de matemticas.) La relacin puede ser un asunto de

conexin histrica con el tema o con temas relacionados, o de posicin legal,

comercial, filosfica, tica o poltica con respecto a ellos. Las "Secciones
Invariantes" son ciertas Secciones Secundarias cuyos ttulos son designados
como los de Secciones Invariantes en la nota que indica que el documento es
liberado bajo esta Licencia. Si una seccin 44
Pgina 45
45 no se ajusta a la definicin de Secundaria, no se puede designarse como
Invariante. La Documento puede no tener Secciones Invariantes. Si el
Documento no identifica las Secciones Invariantes entonces no hay ninguno.
Los "Textos de Cubierta" son ciertos pasajes cortos de texto que se listan como
Textos de Cubierta Delantera o Back- Textos de Cubierta, en la nota que indica
que el documento es liberado bajo esta Licencia. Una de Cubierta Delantera El
texto puede tener como mucho 5 palabras, y un Texto de Cubierta Trasera
puede tener hasta 25 palabras. Una copia "Transparente" del Documento
significa una copia para lectura en mquina, representada en un formato cuya
especificacin est disponible al pblico en general, apto para que los
contenidos lineal hacia delante con editores de texto genricos o (para
imgenes compuestas por puntos) con programas genricos o (para dibujos)
con algn editor de dibujos ampliamente disponible, y que sea adecuado para
exportar a formateadores de texto o para traduccin automtica a una
variedad de formatos adecuados para la entrada a formateadores de texto.
Una copia hecha en una de lo contrario formato de archivo transparente cuyo
marcaje o ausencia de margen de beneficio, ha sido diseado para impedir o
modificaciones posteriores por los lectores no es Transparente. Un formato de
imagen no es Transparente si se utiliza para cualquier cantidad sustancial de
texto. Una copia que no es "Transparente" es llamada "Opaca". Como ejemplos
de formatos adecuados para copias Transparentes estn ASCII puro sin
marcaje, Texinfo formato de entrada, formato de LaTeX, SGML o XML usando
una DTD disponible pblicamente, y de normas conforme HTML simple,
PostScript o PDF diseado para modificaciones humanas. Ejemplos de
transparente formatos de imagen son PNG, XCF y JPG. Los formatos Opacos
incluyen formatos propietarios que pueden ser ledos y editado nicamente en
procesadores de palabras propietarios, SGML o XML para los cules las DTD y /
o procesamiento herramientas no estn generalmente disponibles, y la
mquina generados HTML, PostScript o PDF generados por algunos
procesadores de palabras slo como salida. La "Portada" significa, en un libro
impreso, la pgina de ttulo, ms las pginas siguientes que son necesaria para
mantener legiblemente el material que esta Licencia requiere que aparezca en
la portada. Para trabajos en formatos que no tienen pgina de portada como
tal, "Portada" significa el texto cercano a los ms destacados apariencia del
ttulo del trabajo, precediendo el comienzo del cuerpo del texto. El "editor"
significa cualquier persona o entidad que distribuye copias del Documento para
el pblico. Una seccin "Titulada XYZ" significa una subunidad llamada del

Documento cuyo ttulo es precisamente XYZ o contiene XYZ entre parntesis a

continuacin de texto que traduce XYZ a otro idioma. (Aqu XYZ representa un
nombre de seccin especfica que se menciona a continuacin, como
"Agradecimientos", "Dedicatorias", "Aprobaciones" o "Historia".) para
"preservar el ttulo" de tal seccin cuando se modifica el Documento significa
que permanece una seccin "Titulada XYZ", de acuerdo a esta definicin. El
Documento puede incluir Limitaciones de Garanta cercanas a la nota que
indica que esta Licencia se aplica al documento. Estas limitaciones de garanta
se considerarn incluidos como referencia en la Licencia, pero slo en cuanto a
limitaciones de garanta: cualquier otra implicacin que estas Garanta
Renuncias puedan tener es nula y no tiene efecto sobre el significado de esta
Licencia. 2. COPIA LITERAL Usted puede copiar y distribuir el Documento en
cualquier medio, ya sea comercial o no, siempre y cuando esta Licencia, las
notas de copyright y la nota de licencia que esta Licencia se aplica a la
Documento se reproduzcan en todas las copias y que usted no aada ninguna
otra condicin a las de la presente Licencia. Usted no puede usar medidas
tcnicas para obstruir o controlar la lectura o copia posterior de la copias que
haga o distribuya. Sin embargo, usted puede aceptar compensacin a cambio
de las copias. Si distribuye un nmero suficientemente grande de copias
tambin deber seguir las condiciones de la seccin 3. Usted tambin puede
prestar copias, bajo las mismas condiciones establecidas anteriormente, y
puede exhibir pblicamente copias. 3. COPIADO EN CANTIDAD Si publica copias
impresas (o copias en soportes que tengan normalmente cubiertas impresas)
del documento, que suman ms de 100, y la nota de Licencia del Documento
exige Textos de Cubierta, debe incluir la copias con cubiertas que lleven en
forma clara y legible todos esos Textos de Cubierta: Textos de Cubierta
Delantera en la parte frontal
Pgina 46
46 CAPTULO 5. PERSPECTIVAS cubierta, y Textos de Contra-tapa de la cubierta
trasera. Ambas cubiertas deben clara y legible identificarle como editor de
tales copias. La cubierta debe mostrar el ttulo completo con todas las palabras
del ttulo igualmente prominente y visible. Usted puede aadir otro material en
las cubiertas. Las copias con cambios limitados a las cubiertas, siempre que
conserven el ttulo del Documento y satisfagan estas condiciones, pueden ser
tratados como copia literal en otros aspectos. Si los textos requeridos para la
cubierta son muy voluminosos para que ajusten legiblemente, debe colocar los
primeros enumerada (tantos como sea razonable colocar) en la verdadera
cubierta y situar el resto en pginas adyacentes. Si publica o distribuye copias
Opacas del Documento cuya cantidad exceda las 100, debe incluir una copia
legible por mquina transparente junto con cada copia Opaca, o bien mostrar,
con cada copia Opaca una ubicacin de la red informtica de la que el pblico
que usa la red en general tenga acceso descargar usando protocolos de red
pblicos estndar una copia Transparente del Documento completa, sin

material adicional. Si utiliza la ltima opcin, deber tomar las medidas

necesarias, cuando comenzar la distribucin de las copias Opacas en
cantidad, para asegurar que esta copia Transparente permanecer accesible en
el sitio establecido por lo menos un ao despus de la ltima vez que
distribuya una copia Opaca (Directamente oa travs de sus agentes o
distribuidores) de esa edicin al pblico. Se solicita, aunque no es obligatorio,
que se contacte con los autores del Documento antes de redistribucin
contribuyendo cualquier gran nmero de copias, para darles la oportunidad de
ofrecerle una versin actualizada del Documento. 4. MODIFICACIONES Usted
puede copiar y distribuir una Versin Modificada del Documento bajo las
condiciones de las secciones 2 y 3 anteriores, siempre que usted libere la
Versin Modificada bajo esta misma Licencia, con la Versin Modificada
haciendo el rol del Documento, por lo tanto dando licencia de distribucin y
modificacin de la Versin modificada a quienquiera posea una copia de la
misma. Adems, debe hacer lo siguiente en la modificacin Versin: A. Usar en
la Portada (y en las cubiertas, si hay alguna) un ttulo distinto al del
Documento, y de los de las versiones anteriores (que deberan, si hay alguna,
estar listado en la seccin de Historia Documento). Usted puede usar el mismo
ttulo que una versin anterior si el editor original de esa versin da permiso. B.
Listar en la Portada, como autores, una o ms personas o entidades
responsables de la autora de las modificaciones en la Versin Modificada, junto
con por lo menos cinco de los autores principales del Documento (todos sus
autores principales, si hay menos de cinco), a menos que le eximan de tal
requisito. C. Mostrar en la Portada como editor el nombre del editor de la
Versin Modificada, como el editor. D. Conservar todas las notas de copyright
del Documento. E. Aadir una nota de copyright apropiada a sus
modificaciones, adyacente a las otras notas de copyright. F. Incluir,
inmediatamente despus de las notas de copyright, una nota de licencia dando
el permiso para usar la versin modificada en los trminos de esta Licencia, de
la forma mostrada en la Adenda a continuacin. G. Conservar en esa licencia
notar el listado completo de las Secciones Invariantes y de los Textos de
Cubierta requerida en nota de Licencia del Documento. H. Incluir una copia sin
modificacin de esta Licencia. I. Conservar la seccin Titulada "Historia", y su
ttulo, y aadirle un elemento que declare al menos el ttulo, el ao, los nuevos
autores y el editor de la Versin Modificada como reza en la Portada. Si no hay
una seccin titulada "Historia" en el Documento, crear una estableciendo el
ttulo, ao, autores, y el editor del Documento, tal como figura en su Portada,
aadiendo adems un elemento describiendo la modificacin Versin como se
indica en la frase anterior.
Pgina 47
47 J. Conservar la direccin en red, si la hay, dada en el Documento para el
acceso pblico a una copia Transparente del Documento, y como las otras
direcciones de red dadas en el Documento para versiones anteriores se bas

en. Pueden ubicarse en la seccin "Historia". Se puede omitir la ubicacin en

red de un trabajo que fue publicado por lo menos cuatro aos antes que el
Documento mismo, o si el editor original de dicha versin da permiso. K. En
cualquier seccin Titulada "Agradecimientos" o "Dedicatorias", preservar el
ttulo de la seccin, y preservar en la seccin toda la sustancia y el tono de
cada uno de los reconocimientos a los contribuyentes y / o dedicaciones aqu
mencionados. L. Conservar todas las Secciones Invariantes del Documento, sin
alterar su texto ni sus ttulos. Nmeros de seccin o el equivalente no son
considerados parte de los ttulos de la seccin. M. Borrar cualquier seccin
titulada "Aprobaciones". Una seccin de este tipo no puede ser incluido en el
Modificado Versin. N. No cambiar el ttulo de ninguna seccin existente a ser
titulada "Aprobaciones" o para que entre en conflicto con cualquier Seccin
Invariante. O. Conservar todas las Limitaciones de Garanta. Si la Versin
Modificada incluye secciones o apndices que califiquen como de Secundaria
Secciones y contienen material no copiado del Documento, puede
opcionalmente designar algunas o la totalidad de estas secciones como
invariantes. Para ello, aada sus ttulos a la lista de Secciones Invariantes en la
Modificado nota de licencia de la versin. Tales ttulos deben ser distintos de
cualquier otro ttulo de seccin. Puede aadir una seccin titulada
"Aprobaciones", siempre que contenga nicamente aprobaciones de su Versin
Modificada por otras fuentes, por ejemplo, observaciones de peritos o que el
texto tiene sido aprobado por una organizacin como la definicin oficial de un
estndar. Puede aadir un pasaje de hasta cinco palabras como Texto de
Cubierta Delantera y un pasaje de hasta 25 palabras como Texto de Cubierta
Posterior, al final de la lista de Textos de Cubierta en la Versin Modificada.
Solamente un pasaje de Texto de Cubierta Frontal y uno al de Cubierta Trasera
texto puede ser adicionado por (oa manera de arreglos hechos por) una
entidad. Si el Documento ya incluye un texto de cubierta para la misma
cubierta, aadidos previamente por usted o por arreglo hecho por la misma
entidad que est actuando en nombre de, usted no puede aadir otro; pero
usted puede reemplazar el anterior, con permiso explcito del editor anterior
que aadi el antiguo. El autor (s) y editor (s) del Documento no dan con esta
Licencia permiso para usar su nombres para publicidad ni para asegurar o
implicar aprobacin de cualquier Versin Modificada. 5. DOCUMENTOS
COMBINACIN Usted puede combinar el Documento con otros documentos
liberados bajo esta Licencia, en los trminos definido en la seccin 4 anterior
para versiones modificadas, siempre que incluya en la combinacin todas las
Secciones Invariantes de todos los documentos originales, sin modificar,
listadas todas como Secciones Invariantes de trabajo combinado en su nota de
licencia, y que debe incluir la Limitacin de Garanta. El trabajo combinado
necesita contener solamente una copia de esta Licencia, y mltiples idnticos
Invariante Las secciones pueden ser reemplazadas por una sola copia. Si hay
varias Secciones Invariantes con el mismo nombre pero con contenidos
diferentes, hacen que el ttulo de cada una de estas secciones nico

aadindole al final del mismo, entre parntesis, el nombre del autor o editor
original de esa seccin, si es conocido, o no, un nmero nico. Hacer el mismo
ajuste a los ttulos de seccin en la lista de Secciones Invariantes en la nota de
licencia del combinado trabajo. En la combinacin, debe combinar cualquier
seccin titulada "Historia" en los distintos docu- originales umentos, formando
una seccin titulada "Historia"; la misma forma combine cualquier seccin
titulada "Confirmacin tos ", y cualquier seccin titulada" Dedicatorias ". Debe
borrar todas las secciones tituladas "Aprobaciones". 6. COLECCIONES DE
DOCUMENTOS
Pgina 48
48 CAPTULO 5. PERSPECTIVAS Puede hacer una coleccin que conste del
Documento y de otros documentos liberados bajo esta Licencia y reemplazar
las copias individuales de esta Licencia en todos los documentos por una sola
copia que se incluye en la coleccin, siempre que siga las reglas de esta
Licencia para cada copia literal de cada uno de los documentos en todos los
dems aspectos. Puede extraer un solo documento de una de tales colecciones
y distribuirlo individualmente bajo esta Licencia, siempre que inserte una copia
de esta Licencia en el documento extrado, y siga esta Licencia en todos los
dems aspectos relativos a la copia literal de dicho documento. 7.
AGREGACIN CON TRABAJOS INDEPENDIENTES Una recopilacin del
Documento o sus derivados y de otros documentos separados e
independientes o obras, en o sobre un volumen de un medio de
almacenamiento o distribucin, que se llama un "agregado" si el derecho de
autor resultante de la compilacin no se usa para limitar los derechos legales
de los usuarios de la compilacin ms all de lo los trabajos individuales
permiten. Cuando el Documento se incluye en un agregado, esta Licencia no
aplicarse a los otros trabajos del agregado que no sean en s mismos derivados
del Documento. Si el requisito de Texto de Cubierta de la seccin 3 es aplicable
a estas copias del Documento y el Documento es menor que la mitad del
agregado entero, Textos de Cubierta del Documento pueden colocarse en
cubiertas que enmarquen solamente el Documento dentro del agregado, o el
equivalente electrnico de las cubiertas si el Documento est en forma
electrnica. En caso contrario deben aparecer en cubiertas impresas
enmarcando el conjunto agregado. 8. TRADUCCIN Traduccin es considerada
como un tipo de modificacin, por lo que puede distribuir traducciones del
Documento en los trminos de la seccin 4. El reemplazo las Secciones
Invariantes con traducciones requiere permiso especial a los titulares de
derechos de autor, pero puede incluir traducciones de algunas o todas las
Secciones Invariantes adicionalmente a las versiones originales de las
Secciones Invariantes. Puede incluir una traduccin de esta Licencia, y todas
las notas de licencia del documento, y las Limitaciones de Garanta, a condicin
de que incluya tambin la versin original en Ingls de esta Licencia y las
versiones originales de las notas y renuncias. En caso de desacuerdo entre la

traduccin y la versin original de esta licencia o una notificacin o descargo

de responsabilidad, la versin original en Ingls prevalecer. Si una seccin del
Documento est Titulada "Dedicatorias" "Agradecimientos", o "Historia", la rerequisito (seccin 4) de Conservar su Ttulo (Seccin 1) requerir, tpicamente,
cambiar su ttulo. 9. TERMINACIN Usted no puede copiar, modificar,
sublicenciar o distribuir el Documento excepto como prev expresamente bajo
esta licencia. Cualquier intento de copiar, modificar, sublicenciar o distribuir es
nulo, y terminar automticamente sus derechos bajo esta Licencia. Sin
embargo, si deja de violacin de esta Licencia, entonces su licencia desde el
poseedor del copyright correspondiente ser restituida (a) provisionalmente, a
menos que y hasta que el titular del derecho de autor por terminada explcita y
su licencia, y (b) de forma permanente, si el titular del derecho de autor no le
ha notificado de la violacin por algn razonable significa antes de 60 das
despus de la cesacin. Por otra parte, su licencia desde el poseedor del
copyright correspondiente ser restituida permanentemente si el derecho de
autor titular le notifica de la violacin por algn cauce, esta es la primera vez
que ha recibido notificacin de violacin de esta Licencia (para cualquier
trabajo) de ese poseedor de copyright, y usted subsana la violacin antes de
30 das desde la recepcin de la notificacin. La cancelacin de sus derechos
en virtud de esta seccin no canceladas las licencias de terceros que tengan
recibido copias o derechos de usted bajo esta Licencia. Si se han terminado sus
derechos y no restituidos de forma permanente, la recepcin de una copia de
parte o la totalidad del mismo material no le otorga ningn derecho para
usarlo.
Pgina 49
49 10. REVISIONES FUTURAS DE ESTA LICENCIA La Free Software Foundation
puede publicar versiones nuevas y revisadas de la documentacin libre GNU
Licencia de vez en cuando. Tales versiones nuevas sern similares en espritu a
la presente versin, pero pueden diferentes en detalles para considerar nuevos
problemas o preocupaciones. Ver http://www.gnu.org/copyleft/. Cada versin de
la Licencia tiene un nmero de versin que la distingue. Si el Documento
especifica que una versin especial numerada de esta licencia o "cualquier
versin posterior" se aplica a l, usted tiene la opcin de seguir los trminos y
condiciones, bien de la versin especificada o de cualquier versin posterior
que haya sido publicada (no como borrador) por la Free Software Foundation. Si
el Documento no especifica una versin nmero de esta Licencia, puede
escoger cualquier versin que haya sido publicada (no como borrador) por la
Free Software Fundacin. Si el Documento especifica que un apoderado puede
decidir qu versiones futuras de esta licencia puede utilizarse, la declaracin
pblica de ese proxy de la aceptacin de una versin permanentemente le
autoriza para elegir esa versin para el Documento