Os sis­temas com­puta­cionais estão pre­sentes em diver­sas áreas do nosso cotid­i­ano e têm evoluído de forma expo­nen­cial nos últi­mos anos. Novos micro­proces­sadores com novos recur­sos com­puta­cionais, operando a fre­qüên­cias maiores, maior capaci­dade de memória e várias inter­faces de comu­ni­cação de I/O embu­ti­das num único chip, tudo isso a um custo baixo e acessível.

Essa evolução tem con­tribuído com o aumento da com­plex­i­dade dos pro­je­tos de sis­temas embar­ca­dos, que por con­se­qüên­cia tem exigido novos níveis de abstração em soluções de soft­ware que pos­sam inter­a­gir com o hard­ware da forma mais efi­ciente possível.

Den­tro deste con­texto, destaca-se um grupo de sis­temas que tra­bal­ham com restrições de tempo, chama­dos Sis­temas de Tempo Real. Estes sis­temas, além de exe­cutarem as tare­fas de proces­sa­mento e con­t­role de infor­mações, pos­suem a car­ac­terís­tica de que suas respostas ao ambi­ente devem ser dadas em um tempo hábil o sufi­ciente para que o sis­tema não entre em um estado incon­sis­tente ou inválido.

Um Sis­tema de Tempo Real é, por­tanto, o soft­ware que geren­cia os recur­sos de um sis­tema com­puta­cional, com o obje­tivo de garan­tir com que todos os even­tos sejam aten­di­dos den­tro de suas restrições de tempo, e geren­ci­a­dos da forma mais efi­ciente pos­sível. O soft­ware respon­sável pelo geren­ci­a­mento dos recur­sos com­puta­cionais tam­bém é chamado de Ker­nel (ou núcleo) do Sis­tema de Tempo Real, e con­hecido no mer­cado como RTOS (Real-Time Oper­a­tion Sys­tem) ou Sis­tema Opera­cional de Tempo Real.

Para enten­der­mos a importân­cia de um Sis­tema de Tempo Real, pre­cisamos enten­der o con­ceito de restrição de tempo para even­tos ou tare­fas computacionais.

Restrições de Tempo

Toda tarefa com­puta­cional recebe um estí­mulo (ou evento), que pode ser interno ou externo, real­iza o proces­sa­mento e pro­duz uma saída. Um evento com restrição de tempo pos­sui um tempo lim­ite (máx­imo) de proces­sa­mento para que sua saída seja gerada.

Podemos citar alguns exem­p­los de even­tos com restrições de tempo:

1. Um sen­sor de tem­per­atura que gera um input para um micro­con­tro­lador, indi­cando que níveis críti­cos de tem­per­atura foram atingi­dos, para que o micro­con­tro­lador possa atuar sob o sis­tema de refrig­er­ação. Se o micro­con­tro­lador não aten­der às restrições de tempo do sen­sor de tem­per­atura, a tem­per­atura poderá atin­gir níveis críti­cos, e todo sis­tema poderá se dan­i­ficar. Este caso é nor­mal­mente chamado de “Hard Real-Time Sys­tems”, ou numa tradução livre, Sis­temas de Tempo Real alta­mente restritivos.

2. Um sis­tema de radar aeroe­s­pa­cial, que recebe infor­mações de posi­ciona­mento das aeron­aves, para que pos­síveis col­isões sejam detec­tadas e evi­tadas. Se o sis­tema não tratar estas entradas den­tro de suas restrições de tempo, poderá causar uma tragé­dia. Este caso, assim como o caso ante­rior, tam­bém é chamado de “Hard Real-Time Systems”.

3. Um teclado que gera inputs de teclas pres­sion­adas para um sis­tema micro­proces­sado. Se o sis­tema não tratar estas teclas den­tro de suas restrições de tempo, o oper­ador poderá ter a sen­sação de que o sis­tema “travou”, o que poderá causar até a desistên­cia da uti­liza­ção do pro­duto. Este caso é nor­mal­mente chamado de “Soft Real-Time Sys­tems”, ou Sis­temas de Tempo Real lev­e­mente restritivos.

Podemos ver através dos exem­p­los acima que, se even­tos com restrições de tempo não forem trata­dos de forma cor­reta, ter­e­mos con­se­qüên­cias tão diver­sas quanto a per­cepção de baixa qual­i­dade de um pro­duto, a pos­si­bil­i­dade de queima de um equipa­mento ou até risco de morte!

Um Sis­tema de Tempo Real sim­pli­fica o pro­jeto do pro­duto e min­i­miza o risco de prob­le­mas com restrições tem­po­rais através da divisão do sis­tema em pequenos ele­men­tos inde­pen­dentes chama­dos tarefas.

Tare­fas

Tare­fas são pequenos tre­chos de pro­grama com respon­s­abil­i­dades especí­fi­cas e bem definidas. Cada tarefa pos­sui um con­junto de atrib­u­tos, den­tre eles a pri­or­i­dade, que deve ser atribuída de acordo com sua importân­cia. É a par­tir desta pri­or­i­dade que ten­ta­mos garan­tir com que even­tos com restrições de tempo pos­sam ser exe­cu­ta­dos de forma eficiente.

Como exem­p­los de tare­fas, podemos citar a leitura de sen­sores, trata­mento de pro­to­co­los de comu­ni­cação, leitura de teclado, aciona­mento de leds indica­tivos, escrita em dis­plays, comu­ni­cações seri­ais, log de infor­mações, etc.

Por­tanto, um Sis­tema de Tempo Real é mod­e­lado através da divisão da apli­cação em um con­junto de peque­nas tare­fas, com funções especí­fi­cas, e que inter­agem entre si.

Inter­ação entre as tarefas

Cada tarefa é exe­cu­tada de forma inde­pen­dente, mas elas pre­cisam inter­a­gir entre si para que o sis­tema atinja seus objetivos.

Para exem­pli­ficar, vamos supor um sim­ples sis­tema de alarmes:

1. A tarefa 1 é respon­sável pela leitura con­stante dos sen­sores de pre­sença e movimento.

2. A tarefa 2 é respon­sável pelo aciona­mento da sirene.

3. A tarefa 3 é respon­sável pelo aciona­mento da discagem telefônica.

4. A tarefa 4 é respon­sável pela lóg­ica de detecção de intru­sos do sis­tema de alarme.

Vamos supor que um sen­sor de movi­mento tenha sido acionado, a tarefa 1 irá detec­tar esse aciona­mento, e pre­cisa noti­ficar a tarefa 4. Esta noti­fi­cação é feita através do envio de uma men­sagem para a tarefa 4. A tarefa 4 irá então rece­ber esta men­sagem, e de acordo com sua lóg­ica, irá enviar uma men­sagem de aciona­mento para a tarefa 2, 3 ou para ambas.

Este exem­plo uti­liza a troca de men­sagens, tam­bém chamada de Mes­sage Queues, como forma de comu­ni­cação entre as tarefas.

Podemos ainda citar como meios de comu­ni­cação entre as tare­fas os semá­foros, ou Sem­a­phores, que são mecan­is­mos para o com­par­til­hamento de recur­sos entre as tarefas.

Para aten­der todas as tare­fas solic­i­tadas, den­tro de suas respec­ti­vas restrições de tempo, o Ker­nel neces­sita de algum mecan­ismo de geren­ci­a­mento de tare­fas, classificando-as e orde­nando de acordo com sua pri­or­i­dade. Isso é feito através do escalon­a­mento de tarefas.

Escalon­a­mento de tarefas

O escalon­a­mento de tare­fas é uma função real­izada pelo Ker­nel para deter­mi­nar quando uma tarefa mais impor­tante pre­cisa ser executada.

Con­forme já foi dito, um Sis­tema de Tempo Real é com­posto pelo Ker­nel e pelas tare­fas da apli­cação. Por­tanto, o con­t­role da CPU estará sem­pre com uma tarefa ou com o Ker­nel (esta­mos assu­mindo aqui sis­temas com um único processador).

Para que o Ker­nel possa realizar o escalon­a­mento, é necessário que o mesmo assuma o con­t­role da CPU, através de um dos seguintes eventos:

1. Uma tarefa manda uma men­sagem para outra tarefa. Neste momento o Ker­nel assume o con­t­role da CPU, prepara o envio da men­sagem, e ver­i­fica qual a tarefa mais pri­or­itária para exe­cução no momento.

2. Uma tarefa req­ui­sita um tempo de espera (delay) para o Ker­nel. Neste momento o Ker­nel assume o con­t­role da CPU, e ver­i­fica qual a próx­ima tarefa mais pri­or­itária para exe­cução no momento.

3. Uma inter­rupção do timer do sis­tema é ger­ada e tratada pelo Ker­nel. Neste caso, a tarefa em exe­cução no momento é colo­cada em espera para que o Ker­nel possa escalonar para a tarefa mais pri­or­itária. Nor­mal­mente um Ker­nel com este recurso é chamado de preemptivo.

4. Um evento que uma tarefa de pri­or­i­dade maior estava esperando ocorre e causa a inter­rupção da tarefa em exe­cução. Este evento pode ser, por exem­plo, uma inter­rupção ger­ada por um dis­pos­i­tivo qualquer.

O Ker­nel man­tém um con­junto de infor­mações do estado atual de cada tarefa, tam­bém chamado de con­texto de exe­cução da tarefa, em uma estru­tura de dados chamada TCB (Task Con­trol Block).

Todas as tare­fas pos­suem um campo no sta­tus que indica o estado atual da tarefa. Este campo é armazenado no TCB, e é atu­al­izado sem­pre que é real­izado o escalon­a­mento de tare­fas pelo Ker­nel.

O TCB con­tém tam­bém o con­teúdo de alguns dos reg­istradores da CPU salvos no momento em que a exe­cução da tarefa foi sus­pensa. A troca de tare­fas em exe­cução pelo Ker­nel tam­bém é chamada de mudança de con­texto, pois o con­texto da tarefa a ser sus­pensa é salvo no TCB, e o con­texto da tarefa a ser exe­cu­tada é recu­per­ado do TCB.

Para exem­pli­ficar o escalon­a­mento de tare­fas, vamos anal­isar o seguinte caso de escalonamento:

1. Uma tarefa de pri­or­i­dade menor está sendo executada.

2. Um evento esper­ado por uma tarefa de pri­or­i­dade maior ocorre e causa uma inter­rupção no processador.

3. O proces­sador salva o con­texto da tarefa em exe­cução (reg­istros da CPU) e exe­cuta a rotina de trata­mento da inter­rupção (ISR – Inter­rupt Ser­vice Routine).

4. A rotina de trata­mento da inter­rupção com­pleta e chama um serviço do Kernel.

5. O Ker­nel prepara e exe­cuta a rotina de maior prioridade.

6. A rotina de maior pri­or­i­dade entra em execução.

7. A rotina de maior pri­or­i­dade chama uma função do Ker­nel para aguardar por outro evento. Isso faz com que o Ker­nel seja acionado, e pre­pare nova­mente a rotina de menor pri­or­i­dade para execução.

8. A rotina de menor pri­or­i­dade entra em execução.

Um RTOS provê toda esta arquite­tura de soft­ware para o desen­volvi­mento de Sis­temas de Tempo Real, incluindo funções para a cri­ação de tare­fas, troca de men­sagens entre as tare­fas, com­par­til­hamento de recur­sos, ISR’s genéri­cas, etc.

Escolha de um RTOS

Um RTOS deixará o pro­duto mais con­fiável com relação ao trata­mento de tare­fas com restrição de tempo, além de pos­si­bil­i­tar uma mel­hor mod­e­lagem da sua apli­cação através da divisão da apli­cação em peque­nas tare­fas. Porém, nem sem­pre é vál­ida ou mesmo viável a escolha de um RTOS para deter­mi­na­dos pro­du­tos. Essa decisão pode depen­der de vários fatores:

1. CPU: A CPU uti­lizada no pro­jeto pode deter­mi­nar se você pode ou não uti­lizar um RTOS no seu pro­jeto. Por exem­plo, uma CPU de 4 bits, sem os reg­istradores necessários, ou de baixa fre­quen­cia, é feita especi­fi­ca­mente para sis­temas bem sim­ples e de baixo custo, tor­nando inviável a uti­liza­ção de um RTOS.

2. ROM: Quan­ti­dade de memória de pro­grama disponível para o seu pro­jeto. Pre­cisa ser grande o sufi­ciente para armazenar o código do Ker­nel mais o código da sua apli­cação. Depen­dendo do Ker­nel, você pode pre­cisar de memória entre 4K e 200Kb, ape­nas para o Ker­nel de RTOS’s mais simples.

3. RAM: Quan­ti­dade de memória disponível para os dados do seu pro­grama. O RTOS uti­liza bas­tante memória para armazena­mento das infor­mações de con­texto de exe­cução das tare­fas no TCB e no stack. O valor da memória RAM deve ser grande o sufi­ciente para suprir as neces­si­dades do Ker­nel e das tare­fas da sua aplicação.

4. Custo: Tanto o custo do RTOS quanto o custo extra do hard­ware necessário para supor­tar o RTOS devem ser lev­a­dos em consideração.

Iden­ti­fi­cada a neces­si­dade e a via­bil­i­dade da uti­liza­ção de um RTOS no seu pro­jeto, é necessário escol­her o mel­hor para a sua apli­cação. Cada RTOS disponível no mer­cado pos­sui van­ta­gens e desvan­ta­gens. A escolha do mel­hor sis­tema depende dos req­ui­si­tos de hard­ware e soft­ware do produto.

Os critérios de escolha podem variar bas­tante, desde a pop­u­lar­i­dade e rep­utação do RTOS, o custo e a disponi­bil­i­dade do código-fonte, a porta­bil­i­dade e escal­a­bil­i­dade, per­for­mance, fer­ra­men­tas disponíveis e profis­sion­ais cer­ti­fi­ca­dos no mercado.

Exis­tem diver­sos RTOS’s no mer­cado, alguns pagos e out­ros de livre dis­tribuição. Alguns dos prin­ci­pais disponíveis no mer­cado são eCos, QNX, MicroC/OS-II, VxWorks, Monta Vista, FreeR­TOS, etc.

Na segunda parte deste post vou dar um exem­plo prático de imple­men­tação de um pro­jeto uti­lizando o MicroC/OS-II da Micrium.

Um abraço e até lá!

Ser­gio Prado

Sem posts relacionados.