Esta semana conversei com Gustavo Denardin, professor da Universidade Tecnológica Federal do Paraná, e autor do BRTOS, um Sistema Operacional de Tempo Real 100% nacional. Ele falou sobre sua carreira, o projeto BRTOS e deu algumas dicas para quem esta começando na área de sistemas embarcados.

Gustavo, fale um pouco sobre você, sua formação e como você começou a trabalhar com sistemas embarcados.
Sou de Santa Maria/RS, me formei em Engenharia Elétrica na UFSM em 2002 e começei o mestrado. Não sabia praticamente nada de microcontroladores e sistemas embarcados na época, e no meu mestrado desenvolvi um power modem de baixo custo. Foi quando tive meu primeiro contato com sistemas embarcados. Comecei programando em Assembly para o HC08. No fim do mestrado comecei uma empresa, a Advance Sistemas Eletrônicos, terceirizando desenvolvimento de sistemas embarcados. Em 2005, fui informado de um concurso para professor na UTFPR (naquela época CEFET-PR), em Pato Branco/PR. Sem muita perspectiva, pois nunca havia pensando em ser professor, prestei a prova. Fui aprovado e comecei a lecionar. A empresa foi fechada pois meu sócio havia se mudado para Porto Alegre e começado a trabalhar no CIETEC. Lecionei durante 4 anos, de 2005 a 2008, sem nunca ter pensado em RTOSes. Assumi as cadeiras de controle, sistemas microprocessados e redes industriais da universidade. Trabalhei bastante com C e máquina de estados, mas nada ainda com sistemas operacionais.

Quais foram as motivações para o desenvolvimento do BRTOS? Fale um pouco do histórico.
No início do doutorado, estava trabalhando com protocolos de rede para redes de sensores sem fio, e meu orientador e um colega comentaram sobre RTOSes. Com o menor interesse, recusei a idéia. Então me mostraram o FreeRTOS, mas pouco se sabia de RTOSes em nosso grupo de pesquisa. Estávamos começando a aprender a utilizá-lo. Até que meu orientador me passou o código de um chaveador de contexto, e resolvi portá-lo para o HCS08. Quando entendi a idéia fiquei maravilhado. Então li o livro do Jean Labrosse do uc/OS-II, e os conceitos de um RTOS ficaram bem claros para mim. Outras pessoas começaram a me incentivar a melhorar este chaveador de contexto. Fomos sentindo necessidade de outras coisas como semáforos, mutex, filas, etc. E tudo foi sendo implementado sob demanda. Assim nasceu o BRTOS.

B de Brazilian ou de Basic?
De Brazilian mesmo, por pura falta de criatividade. Quem batizou foi um colega, porque o nome original era MyRTOS. Até que vi que ja existia um, então demos o nome de BRTOS.

Quem trabalhou no desenvolvimento deste projeto e onde ele é utilizado hoje?
No início o código foi praticamente todo escrito por mim, mas tive um colega muito importante por um motivo: criticava tudo (sempre críticas positivas). O que estava ruim, o que podia melhorar. O nome dele é Carlos Henrique Barriquello. Atualmente todas as modificações e melhorias do BRTOS são discutidas com o Carlos. Inclusive, algumas otimizações do kernel da versão 1.05 e as funções Pend e Post das filas foram implementadas por ele. Hoje o BRTOS é usado em vários projetos acadêmicos em que nosso grupo de pesquisa está envolvido e começou a ser utilizado na cadeira de Sistemas Embarcados na UFSM. Já recebi alguns contatos de empresas querendo saber mais informações, mas a verdade é que ele é um projeto de apenas 1 ano. Ainda está em caráter experimental. Abrimos o código sob a licença MIT de forma que pudéssemos encontrar mais colaboradores.

Que tipo de algoritmo você usa no escalonador de tarefas e como você gerencia as prioridades? O algoritmo usado evita problemas como inversão de prioridade?
O escalonador é preemptivo por prioridades, com 32 níveis (0-31), sendo 0 a tarefa de maior prioridade. As prioridades são fixas, salvo quando se usa mutex, que utiliza um algoritmo de priority ceiling.

Quais são as deficiências do BRTOS hoje?
O BRTOS funciona bem e não compromete em desempenho. Mas pensamos mais do que portar para outras arquiteturas. Estamos avaliando uma reestruturação completa, para uma segunda versão. A principal deficiência na minha opinião é o tempo de latência, já que algumas tarefas do sistema bloqueiam as interrupções. Também não gosto muito do escalonador, dá para melhorar seu algoritmo.

Existem 40 chamadas à OSEnterCritical nos fontes do BRTOS. Qual o impacto disso no tempo de latência para o tratamento de interrupção?
Bom, tentei minimizar o codigo dentro destas chamadas, mas nem sempre foi possível. O mutex por exemplo ficou um pouco complexo, e possui mais código bloqueado do que eu gostaria. Na última versão obtivemos baixa latência, pior caso em torno de 10us. Fizemos esta medição através da troca de estado de um pino em uma interrupção periódica e um osciloscópio de altíssima resolução, com diversas interrupções ligadas e vários serviços de sistemas sendo chamados ao mesmo tempo.

Hoje o BRTOS suporta o Coldfire V1, HCS08 e o MSP430. Quais os desafios de portar para outras arquiteturas?
Quase nenhuma, é relativamente simples. Basicamente, precisamos configurar a instalação das tarefas, o timer do sistema, os modos de baixo consumo, a função de troca de contexto (geralmente interrupção de software) e o salvamento/restauramento do contexto. O resto são drivers. Já pensamos em portar para PIC e ARM Cortex M3, mas falta tempo para focar neste desenvolvimento devido ao meu doutorado. 

Quem quiser colaborar, o que deve fazer?
Entrar em contato comigo ou com o Carlos Barriquelo através da página do projeto. A contribuição pode ser feita de diversas maneiras, enviando sugestões, melhorando o código ou portando para outras arquiteturas. É trabalhoso, mas também é divertido. Uma vez dormi na frente do teclado às 5 da manhã de um sábado, porque tinha ficado muito emocionado com os primeiros resultados do projeto…:)

Que ferramentas você usa no dia a dia para desenvolver software embarcado?
Já usei o Code Composer da Texas, quando trabalhei com DSPs. Usei também o Keil quando brinquei um pouco com 8051. Agora uso o CodeWarrior. Sempre em ambiente Windows. Já pensei em migrar para Linux, mas sinto falta de boas ferramentas. Atualmente estou pensando em começar a utilizar o Eclipse, mas ainda acho ele um pouco pesado.

Dê algumas dicas para quem esta começando a carreira na área?
Tenho notado que o pessoal mais novo quer tudo de “mão beijada”, tudo pronto. E acaba não entendendo o que está acontecendo por “baixo dos panos”, então minhas dicas são: nunca pense que é um bom programador, você nunca deixará de aprender; procure conhecer um pouco da arquitetura que esta utilizando, assembly, CPU, etc; e nem sempre o caminho mais curto é o melhor; no inicio tente desenvolver seus próprios códigos, que o aprendizado não tem preço.

Para fechar, se você fosse para uma ilha deserta, qual CPU, linguagem de programação e sistema operacional você levaria?
Coldfire V1, linguagem C e claro, o BRTOS. O problema seria quando acabasse a bateria…:)

Quem estiver interessado em colaborar com o projeto do BRTOS, entre em contato com o Gustavo através do site do projeto.

Atualização: Aqueles que estiverem interessados em desenvolver um porte do BRTOS para outra arquitetura, podem acessar este how-to aqui.

Um abraço,

Sergio Prado